Red Hat Bugzilla – Bug 154650
kernel-2.6.11-1.14_FC3 hang on boot
Last modified: 2015-01-04 17:18:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1
Description of problem:
If i try to boot 2.6.11-1.14_FC3 kernel with rhgb the system hangs just after the devices initialization (i use nv driver) . If i try to boot the 2.6.11-1.14_FC3 kernel without rhgb the system hangs at the swap activation. If i boot the 2.6.10-1.770_FC3 kernel with or without rhgb all is fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot with 2.6.11-1.14_FC3 kernel
2. system hangs
Actual Results: system hangs
Expected Results: system boot normally
When the 2.6.11-1.14_FC3 kernel hang with or without rhgb i can't find anything
related to this kernel in /var/log/messages so i can't see why it hangs.
I'll bet its hanging loading some module.
can you do the following..
mv /sbin/modprobe /sbin/modprobe.real
and create a /sbin/modprobe script which is..
(don't forget the chmod +x /sbin/modprobe :-)
that should echo to the screen the last module it loaded just before it went bang.
When you say "(i use nv driver)", you do mean the opensource X.org driver, and
not the binary NVidia driver right ?
In fact i have binary NVidia driver installed and the kernel module for
2.6.10-1.770_FC3 kernel. When i boot the 2.6.10-1.770_FC3 i have driver "nvidia"
in /etc/X11/xorg.conf but when i boot the kernel-2.6.11-1.14_FC3 i have driver
"nv" in /etc/X11/xorg.conf to test it without rebuilding the kernel module
against the new kernel. If i understand well rhgb use the driver listed in
xorg.conf to know the driver to use with rhgb so i prefer to test the kernel
with "pure" module.
ok. try the modprobe thing then, that should at least point the finger in the
I seem to have a similar problem. My system hangs at boot after upgrading from
kernel-smp-2.6.10-1.770_FC3.i686 to kernel-smp-2.6.11-1.14_FC3.i686. I added
printouts to rc.sysinit (the modprobe script didn't work), and it seems to hang
while loading the bt878 module.
I have a VisionDTV PCI card (nowdays called TwinhanDTV).
So i tried the modprobe script and i understand nothing. First of all i saw
nothing more written during boot process due to this script. The problem is with
this script the 2.6.11-1.14_FC3 kernel boot fine with or without rhgb!! Ican't
understand. Maybe the sleep ??
I'm afraid to remove this script and the system hang one more time ...
that is very odd. without rhgb, you should be seeing extra messages logged to
teh console every time it loads a module.
Without rhgb i saw no more message than before using this script or maybe one
module parameter sometimes but that's all.
ok, if you remove the 'sleep' does it hang again ? If so, what was the last
thing it printed ?
i removed the sleep. First i reboot and the kernel boot fine. Second i try to
cold boot (from poweroff) and the system hangs at the same place just after swap
initialization [ok]. I saw nothing more written on the screen!
So i hard reboot and the system asks to press y to control the integrity ... i
try to press y but nothing happened (seems that the keyboard does not respond)
and it continue the boot process and hangs at the same point. I hard reboot and
select the 2.6.10 kernel but strangely the system did not ask me to press y to
control the integrity!! and boot fine. I put the sleep in the script and will
I understand nothing. It seems to be a random problem :-)
*** Bug 158607 has been marked as a duplicate of this bug. ***
*** Bug 158609 has been marked as a duplicate of this bug. ***
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.