Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 227857 - rhgb freezes when entering runlevel 5 without prefdm
rhgb freezes when entering runlevel 5 without prefdm
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhgb (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Depends On:
  Show dependency treegraph
Reported: 2007-02-08 11:49 EST by Rik Her
Modified: 2012-06-20 12:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 12:18:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rik Her 2007-02-08 11:49:03 EST
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:


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 12:27:50 EST
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 16:07:39 EST
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 11:28:18 EST
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 02:31:32 EDT
Any updates on this issue?  Thanks.
Comment 5 Ray Strode [halfline] 2007-05-29 15:01:46 EDT
Do you still see this with RHEL 4.5?
Comment 6 Rik Her 2007-06-03 11:33:25 EDT
I'll download RHEL 4.5 and try it out and update you.
Comment 7 Charles Slivkoff 2007-06-26 13:54:23 EDT
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 14:59:27 EDT
Charles, can you try with RHEL 4.5?
Comment 9 Charles Slivkoff 2007-06-26 15:30:42 EDT
I just tried upgrading rhgb from rhgb-0.14.1-8.i386.rpm to

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 16:37:56 EDT
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 11:35:39 EDT
(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 16:27:20 EDT
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 12:18:04 EDT
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.