Description of problem:updated by yum to 2.6.20-1.2307 and system will not reboot. After several errors related to file paths not existing the last line is "Kernel Panic - attempting to stop init" - machine is hung. Reverting to previous version 2.6.18-1.2239fc5 and system works OK. Version-Release number of selected component (if applicable):kernel-2.6.20-1.2307.fc5 How reproducible: every restart after upgrade Steps to Reproduce: 1. cold restart 2. 3. Actual results: Expected results: Additional info:
Same problem here on x86_64. Kernel can't find my root filesystem on /dev/vg0/root. The "1.2300" release of the same 2.6.20 kernel (kernel-2.6.20-1.2300.fc5) from a few days ago works fine.
SHOULD BE HIGH SEVERITY Similar problem here. 2300 and 2307 are MAJORLY BROKEN. I have 15 FC5 boxes in the field and 3 reliably PANIC on boot when running 2300/2307. All boxes work 100% stable in pre-2300: tested up to 2.6.19-1.2288.2.4.fc5smp. 3 boxes proves it's not just one config. However, 2300/2307 so far runs well on around 7 other boxes. I can't figure out what the common thread is. I captured a couple of panics. I'll attach the one I wrote on paper. I have a screenshot of another around here somewhere. Some ideas as to commonalities on these boxes: - all Intel chipsets, mostly 845 - all running SMP kernel on a uniproc (1 socket / single core) mobo - there *may* be a NIC in common, but I'd have to check - ? maybe more
Created attachment 152540 [details] panic debug output, manually transcribed
Another commonality: all 3 boxes are running 2.6ipsec. But 2 of the the other ends of those VPNs are ok on 2300/2307, so this may be a red herring. In fact, the SMP-on-uniproc theory seems to be more and more tempting. I have no examples right now of other boxes that break this theory. Unfortunately, testing is a bit tricky because they are all offsite and a panic gives me a major panic!
After some testing, I believe I have figured out why this bug occurs on a few of my boxes. It was like I said in #4, it looks like you cannot stably run an SMP kernel on a unicore system. Switching non-SMP boxes from SMP to UP kernel has so far made the bug go away. Something was introduced after 2288 to cause SMP kernel to be buggy on UP boxes.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
As per my comment #5, I'm still convinced this was a running MP on UP problem, which is completely mitigated by the fact that in F8 the MP/UP kernels are combined. So that means as of F8 this is fixed. I have not seen anything problems like this on F8.