Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227857 - rhgb freezes when entering runlevel 5 without prefdm
Summary: rhgb freezes when entering runlevel 5 without prefdm
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhgb
Version: 4.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-08 16:49 UTC by Rik Her
Modified: 2012-06-20 16:18 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:18:04 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Rik Her 2007-02-08 16:49:03 UTC
Description of problem:

If you comment out the prefdm line from /etc/inittab and restart your machine,
rhgb will freeze the GUI and keyboard after starting all the services.

Version-Release number of selected component (if applicable):

RHEL ES v4 U4 but I've reproduced it on other versions of RHEL v4

How reproducible:

Always

Steps to Reproduce:
1. Edit /etc/inittab and # the prefdm line
2. Restart the machine/server
3. Afer init has run the init scripts and started the services, the GUI and
keyboard freeze
  
Actual results:

GUI and keyboard freezes

Expected results:

rhgb shouldn't freeze.  Although run level 5 usually means that an X server is
running, this is totally customizable.  So rhgb shouldn't take it for granted
that it will find an X server running on :0.

Additional info:

I isolated the issue by disabling rhgb from the grub kernel line and the server
boots fine without rhgb.

Comment 1 Ray Strode [halfline] 2007-02-08 17:27:50 UTC
Does it freeze with a graphical mouse cursor still on the screen?
or does it freeze with a blank black screen?
or does it just end up on the wrong vt (and ctrl-alt-f1 works to bring it back)?

Comment 2 Rik Her 2007-02-08 21:07:39 UTC
Thanks for your prompt reply.  It freezes with the graphical mouse cursor still
on the screen the the GUI running.

Comment 3 Rik Her 2007-02-09 16:28:18 UTC
Just wanted to add that as far as I can tell, this isn't hardware dependent.  I
was able to replicate the problem on more than one machine (with different
hardware) as well as on VMware.

Comment 4 Rik Her 2007-05-28 06:31:32 UTC
Any updates on this issue?  Thanks.

Comment 5 Ray Strode [halfline] 2007-05-29 19:01:46 UTC
Do you still see this with RHEL 4.5?

Comment 6 Rik Her 2007-06-03 15:33:25 UTC
I'll download RHEL 4.5 and try it out and update you.

Comment 7 Charles Slivkoff 2007-06-26 17:54:23 UTC
I see this behavior now with RHEL 4 update 3 on a HP Proliant DL380 (via remote
console) as well as with VMware.

There is no rhgb or X server running. 
The screen is frozen with the progress bar at 100%.
There is no activity on the display at all.

The system is booted & I am able to ssh to login.
The mingetty processes are running on tty1-tty6.
The KDE display manager, kdm, is running, but no X server is configured to start
in /etc/X11/xdm/Xservers.

I can start an X server from a remote session and it is functional, but on
termination, the display is frozen, with no mouse cursor visible.

I can find no means to reset the display to a state where the vc's are usable
for text logins.

To duplicate the behavior:
1) disable X server startup (gdm.conf or Xservers)
2) reboot



Comment 8 Ray Strode [halfline] 2007-06-26 18:59:27 UTC
Charles, can you try with RHEL 4.5?

Comment 9 Charles Slivkoff 2007-06-26 19:30:42 UTC
I just tried upgrading rhgb from rhgb-0.14.1-8.i386.rpm to
rhgb-0.14.1-10.el4.i386.rpm.

The problem seems to be resolved, at least with the VMware system that I've been
testing. I do not have a physical system that I can reboot at the moment.

Is there any chance that there might be a way to recover the console in the
event that a system gets stuck in this state, pre 4.5?


Comment 10 Ray Strode [halfline] 2007-06-26 20:37:56 UTC
if you remove "rhgb" from the kernel command line in the grub menu then the
system will boot without rhgb

Comment 11 Charles Slivkoff 2007-07-02 15:35:39 UTC
(In reply to comment #10)
> if you remove "rhgb" from the kernel command line in the grub menu then the
> system will boot without rhgb

Thanks, I am aware of this option. It requires a reboot, which does not happen
often.  Is there any alternative?

Also, is there any means to detect a system console that is in this state
without visiting the console of each system?


Comment 12 Charles Slivkoff 2007-07-02 20:27:20 UTC
I discovered another option to disabling rhgb:

In /etc/sysconfig/init, set GRAPHICAL="no". 

This seems like a better solution than removing rhgb from grub.conf as I could
not find any documentation which explains how grubby updates grub.conf when
kernel RPMs are installed/updated.



Comment 13 Jiri Pallich 2012-06-20 16:18:04 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


Note You need to log in before you can comment on or make changes to this bug.