Red Hat Bugzilla – Bug 234683
fc5 kernel-2.6.20-1.2307 goes panic instead of boot
Last modified: 2008-08-02 19:40:36 EDT
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
How reproducible: every restart after upgrade
Steps to Reproduce:
1. cold restart
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
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.
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
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:
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.