Red Hat Bugzilla – Bug 135574
should rhgb be disabled (automatically) if graphics hardware changes?
Last modified: 2007-11-30 17:10:51 EST
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):
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.
On removing the kernel boot options 'rhgb quiet' the boot continues
fine - kudzu kicks in and detects the hardware changes - and
I'm guessing the change in graphics part of the hardware upsets rhgb -
hence the hang with it.
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?
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.
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
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?.
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".
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
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).
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.)
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.
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.
*** Bug 139890 has been marked as a duplicate of this bug. ***
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?
I have the fix (found today, not trivial) but didn't pushed it yet.
It shoudl show up in the next update, probably tomorrow,
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
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.
*** Bug 136926 has been marked as a duplicate of this bug. ***
*** Bug 124384 has been marked as a duplicate of this bug. ***
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.
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..
(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)
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.
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)
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 ?
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)