Bug 135574 - should rhgb be disabled (automatically) if graphics hardware changes?
should rhgb be disabled (automatically) if graphics hardware changes?
Product: Fedora
Classification: Fedora
Component: rhgb (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: 124384 136926 139890 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-10-13 12:18 EDT by Satish Balay
Modified: 2007-11-30 17:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-14 11:42:33 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 Satish Balay 2004-10-13 12:18:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
If the graphics hardware changes, fedora doesn't boot in 'rhgb quiet'
mode. It boots fine if the options 'rhgb, quiet' are removed

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

How reproducible:

Steps to Reproduce:
1. install FC3T3 on a Thinkpad 600E (with x)
2. remove the HDD and plug it into a T40 and try to boot.

Actual Results:  Boot just hangs after printing the following text:

Initializing hardware... storage network audio done    [ok]
configuring kernel parameters:  [blink]

Expected Results:  Boot to continue - kudzu, detect hardware changes -
and the new hardware gets configured.

Additional info:

On removing the kernel boot options 'rhgb quiet' the boot continues
fine - kudzu kicks in and detects the hardware changes - and
configures them.

I'm guessing the change in graphics part of the hardware upsets rhgb -
hence the hang with it.
Comment 1 Satish Balay 2004-10-13 12:31:01 EDT
Forgot to add in package versions

[balay@localhost ~]$ rpm -q rhgb kernel

perhaps rhgb code should somehow check if 'graphics' info changed -
and disable itself?
Comment 2 Daniel Veillard 2004-10-13 12:54:19 EDT
Don't know what you mean by "boot just hangs"
If the graphic conf changes, X should not start, which is not a 
problem, the boot should just go on in text mode. If the system
hangs, then it's an X bug.

Comment 3 Satish Balay 2004-10-13 13:22:41 EDT
I see the following on the screen. (cut/paste from above)

Initializing hardware... storage network audio done    [ok]
configuring kernel parameters:  [cursor_keeps_blinking_here]

Now the laptop just stays there for ever - and doesn't proceed.

I suspect the kernel tries to process 'rhgb' option - and attempts to
go into rhgb/graphics mode - fails - and just stays there?

Note: its not even started any services - so its nowere close to
Comment 4 Satish Balay 2004-10-13 13:31:34 EDT
Also, I need to press the power button for 5-10 seconds - to invoke a
hard reboot - to get out of this freeze - so maybe its a kernel issue?.
Comment 5 Justin Georgeson 2004-10-17 16:35:19 EDT
I am experiencing a boot hang in the same place after installing
fc3t3, but not in relation to changing the graphics hardware. I
installed on a dual PII with a PCI 3dfx and an AGP nVidia Riva TNT2.
After the install completed I rebooted and the boot process hangs at
"configuring kernel parameters".
Comment 6 Justin Georgeson 2004-10-17 22:43:39 EDT
I found bug 134835 and I'm pretty sure that's what I was seeing. I was
able to boot by taking 'rhgb quiet' out (probably just needed to
remove rhgb) and the X config util was launched. After getting X
configured I rebooted (again taking out 'rhgb quiet'). This time
firstboot ran and the system launched gdm and everything seems fine.
I'm running up2date right now and will try leaving 'rhgb quiet' when I
reboot after it finishes. So, should I file a bug that the x.org
config generated by Anaconda left me with a system that wouldn't boot
without intervention?
Comment 7 Alexandre Oliva 2004-10-20 22:20:04 EDT
Since today's rawhide had a broken X, I was able to observe a similar
problem.  If X crashes (or, as the original report says, fails to
start for whatever reason), rhgb should fail gracefully, instead of
getting the box into a state in which boot won't complete, and the
only way to get out of it is to reach for the power button (or
Alt-Sysrq e, Ctrl-Alt-Del, if you're lucky to have it enabled).
Comment 8 Alexandre Oliva 2004-10-20 22:20:19 EDT
Since today's rawhide had a broken X, I was able to observe a similar
problem.  If X crashes (or, as the original report says, fails to
start for whatever reason), rhgb should fail gracefully, instead of
getting the box into a state in which boot won't complete, and the
only way to get out of it is to reach for the power button (or
Alt-Sysrq e, Ctrl-Alt-Del, if you're lucky to have it enabled).
Comment 9 Barry K. Nathan 2004-10-21 01:09:17 EDT
FWIW in FC2, my experience is that if X fails to start, rhgb *does*
fail gracefully. If that's not the case in FC3 anymore, then that's a
regression. (Just mentioning this for what it's worth.)
Comment 10 Daniel Veillard 2004-10-21 10:08:01 EDT
well rhgb starts X asynchronously. If X dies then it continues
but if X doesn't dies it tries to connect to it to start the 
graphical widget and if this operation gets stuck, then unless
adding a timeout I don't really see how to make progresses.
It also depends how "X crashes" unfortunately at this point.

Comment 11 Daniel Veillard 2004-11-18 12:37:16 EST
I found the problem, it was a deadlock on a fifo between rhgb and
firstboot, I have a patch I will make a update probably tomorrow.

Comment 12 Daniel Veillard 2004-11-18 12:39:03 EST
*** Bug 139890 has been marked as a duplicate of this bug. ***
Comment 13 Glover George 2004-11-18 12:45:01 EST
After installing the updated kernel kernel-smp-2.6.9-1.678_FC3, as
well as the new rhgb rhgb-0.15.1-1.FC3, fedora automatically stuck the
rhbg crap back in all of my entries in /etc/grub.conf.  Anyway, I
figured let's try it out, rebooted.... same thing!  Still locks up at
Configuring kernel paramaters. 

Anything else i can do to help you debug the problem?
Comment 14 Daniel Veillard 2004-11-18 12:55:42 EST
I have the fix (found today, not trivial) but didn't pushed it yet.
It shoudl show up in the next update, probably tomorrow,

Comment 15 Kim Lux 2004-11-19 11:23:33 EST
I've got the same problem.  I can get the machine going by booting 
without rhgb, but I need to ship a FC3 hard drive to a customer for 
installation in a machine that I've never seen before.  He isn't 
going to be able to configure X !  I guess what I am saying is that I 
need this to work.   
I'm available for testing.  Feel free to email me if I can be of any 
Comment 16 Daniel Veillard 2004-11-19 11:27:11 EST
I have pushed rhgb-0.16.1 to rawhide and FC3-updates earlier today,
I don't know exactly when it will be available though the update but
you can get the source RPM from 
for testing in the meantime.

Comment 17 Daniel Veillard 2004-11-19 11:41:44 EST
*** Bug 136926 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Veillard 2004-11-19 11:42:09 EST
*** Bug 124384 has been marked as a duplicate of this bug. ***
Comment 19 Kim Lux 2004-11-20 12:44:53 EST
I upgraded to the new rhgb from the mirrors.  I tested it on two
machines by pulling the hard drives and running them on different
hardware with different video cards.  Both machines booted fine with
no hang ups.  Thank you very much for fixing this.   
Comment 20 Satish Balay 2004-11-23 17:51:34 EST
rhgb-0.16.1-1 works for me as well. I'm able to swap the hdd between 'T40' &
'600E' (thinkpds) - and I see no hang.

Kudzu kicks in correctly - and attempts to reconfigure all devices.

this issue can be marked resolved..
Comment 21 J.L. Argente 2004-11-23 18:26:20 EST
(Kernel 2.6.9-1.681_FC3 #1 Thu Nov 18 15:10:10 EST 2004 i686 i686 i386

I think there is a global problem with kudzu.
It dont like hardware change, my 2 cents with 2 problems :

= On my FC3 up to date (only official) i have replaced my crt monitor
with lcd monitor. Kudzu hang on next reboot, Grrr...
Boot on rescue, modify by hand xorg.conf, boot again and all is OK.

= Test, moving my USB mouse to PS2 port, and so Kudzu hang again on
next boot, Grrr...

= I try to delete *rhgb quiet* from grub.conf, nothing; kudzu always hang.

= I start in *Interractive mode" without loading kudzu, all is fine.
In a terminal windows, i run kudzu... it hangs, Grrr...

= I plug again my mouse in initial position, plug in USB port, and all
is fine, no more problem with Kudzu.

For me, every time some hardware change on my computer, kudzu hang.

With google and here, i have read that many peoples seem to have same
problems, with network card, hard disk and so on.

(hope you can understand me, my english is so bad)

Jean Louis
Comment 22 Jeff Dever 2004-12-27 03:25:49 EST
I had the same issue where the boot up would hang after "Configuring
kernel parameters".  This was on an AMD64.   Initially it was
intermittent, 1 every 8 or so boots would hang.  After applying some
of the updates, it hung every time.

After reading this bug report, I tried the workaround by removing the
rhfb from grub: worked.  Installed the updated rhgb (0.16.1) and the
system does boot now.

I can confirm that it is now fixed for me.

Thanks Daniel.
Comment 23 Jason Merrill 2005-10-04 21:49:16 EDT
I'm having a somewhat similar problem now.  I have a Thinkpad T30 2366-QU8
running FC4.  When the system starts up, it does the "configuring hardware"
step, then starts rhgb.  About 2/3 of the time, at this point my computer
crashes.  It becomes completely nonresponsive, and the LCD loses power, though
the backlight is still on, so I see flowing patterns.  My only recourse is to
hold down the power button for 5 seconds to turn off the computer, and then try
again.  Just now it took 5 tries to get rhgb to actually start up.  Disabling
rhgb seems to solve the problem.

Kernel 2.6.13-1.1526_FC4 (also happened with 2.6.12-1.1398)
Comment 24 Christian Iseli 2007-01-19 20:02:01 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Comment 25 Ray Strode [halfline] 2007-08-14 11:42:33 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

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