Red Hat Bugzilla – Bug 167585
kernel-2.6.13-1.1536_FC5 pauses at ID "5" similar to 1532
Last modified: 2007-11-30 17:11:13 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050901 Fedora/1.7.11-4 Description of problem: kernel-2.6.13-1.1536_FC5 pauses and states it will pause for 5 minutes before attempting to continue. Hitting ctl-alt-delete does not reboot the computer. kernel-2.6.13-1.1535_FC5 which is the dev release between the two versions boots up and is usable. Check the fedora-test mailing list for several comments regarding the problem and amount of users effected by the bug. A user who had a 64-bit arch stated 1532 booted up on his box. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1536_FC5 How reproducible: Always Steps to Reproduce: 1. Allow computer to boot 2. Notice the computer stops booting 3. See several messages with ID "1" through ID "5" as last displayed messages Actual Results: 1. Computer started booting. 2. Waited for 5 minutes but boot did not proceed. 3. Reported this problem since 1532 exhibited similar issues. Expected Results: Computer to boot up better than it did with the previous kernel release. Additional info: since there are so many entries for the kernel in development, a new way to track kernel problems should be devised which would make the latest release the default version. This is especially needed with mostly everyday releases to the kernel. I don't know if bugzilla is capable of this or not. It would be a worthwhile feature to add for easier tracking of development bugs.
Created attachment 118481 [details] DMESG from bootable kernel Since I have no serial console to capture the screen output, a middleground working kernel is submitted for clues as to why this one boots and the preceeding and folowing kernel does not boot.
Some comment on the list relayed mention of the "git snapshot", better film would be nice.
Just a few comments. For me it's tty 1 through tty 6 (in runlevel 5). I haven't tried different run levels, but it's so early on I'd be surprised if it made a lot of difference. Maybe single might work. I'm seeing this in today's kernel 1538
Also with the latest (2.6.13-1.1538_FC5) on i686. I get "Id 1: Respawning too fast" for all ids 1 through 6. Also, on x86_64 it works fine (foolishly updated and rebooted...)
kernel-2.6.13-1.1538_FC5 made it a little further through the boot process than before. It made it to ID 6 before stopping. Since I thought runlevels might make a difference, I tried runlevel 1 and 5 as well as runlevel 3 which is my normal boot level. Runlevel 1 stopped at "no more processes to run or similar. Runlevel 2,3,4 and 5 stopped at ID "6". I was able to reboot using alt-sysrq-b and the system rebooted as expected with each stoppage in the boot process loading.
This bug should be a Severity 1 bug: I cannot even boot.
Welcome to rawhide ;-] Actually, this bug should be marked FIXED as tomorrow's rawhide kernel fixes the problem.
Created attachment 118576 [details] DMESG output for kernel-2.6.13-1.1542_FC5 There is an error related to hdc in the log, but this is probably a hardware problem with my system. If the problem was corrected, closing this report will be fine. Should we wait until the follow-up kernel before closing the bug report?
Jim, given that the kernel now boots, I would suggest you're problem is another bug altogether and that this bug should be closed, and you should open another bug for this problem you now have. Rodd
I was more concerned on the fix being a fluke, like between the two kernels. Since the lead regarding the fix was from a pretty reliable source, I'll close the bug. I believe the CDROM problem within dmesg was related to the hardware itself and not kernel related. Fixed in rawhide with kernel-2.6.13-1.1542_FC5