From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 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: Always 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. 3. 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.
Forgot to add in package versions [balay@localhost ~]$ rpm -q rhgb kernel rhgb-0.13.5-2 kernel-2.6.8-1.541 kernel-2.6.8-1.607 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. Daniel
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 init5/start-Xserver
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 without intervention?
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. Daniel
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. Daniel
*** 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, Daniel
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 help.
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 http://fr.rpmfind.net/pub/veillard/rhgb-0.16.1-1.src.rpm for testing in the meantime. Daniel
*** 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.. thanks, Satish
Hi, (Kernel 2.6.9-1.681_FC3 #1 Thu Nov 18 15:10:10 EST 2004 i686 i686 i386 GNU/Linux) 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
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.
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) rhgb-0.16.2-3
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 ? Thanks.
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)