Red Hat Bugzilla – Bug 212460
kernels panic on boot
Last modified: 2008-04-09 20:40:51 EDT
Description of problem:
this occurs in both kernel-2.6.17-1.2187_FC5 and in
this does NOT occur in kernel-2.6.17-1.2157_FC5
this is the last screen before the panic:
Loading ext.ko module
Loading dm-mod.ko module
device-mapper: 4.6.0-ioctl (2006-02-17) initialized:
Loading dm-mirror.ko module
Loading dm-zero.ko module
Trying to resume from /dev/VolGroup00/LogVol01
Unable to access resume device (/dev/VolGroup00/LogVol01)
Creating rood device.
Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!
Version-Release number of selected component (if applicable):
both kernel-2.6.17-1.2187_FC5 and in
always on boot.
Steps to Reproduce:
1.start the box in either of the two kernels
using the following (since it seems to panic on lvm problem)
both the new kernels are pristine, with no extra modules, btw.
Having the problem. System boots on 2.6.17-1.2174_FC5.
sheesh! somehow, in a fit of utter stupidity i typed 2157 instead of 2174.
2174 is what i actually use at this point. however, i can also boot into 2157
just fine, as well.
are any of you using raid ?
not here. BTW, the condition applies to 2.6.18-1.2239.fc5 kernel as well.
box was clean fc4 install, upgraded to fc5.
i'm afraid to try an upgrade to fc6 in case it won't recognize the lvm either.
yep - using lvm2 over raid. Getting a panic on a different machine as well, I
am now getting a panic when using kernel-2.6.18-1.2239.fc5 but not with
Please also see bug 220269. I am (the reporter of that bug) using RAID.
Strangely, I have this problem with kernel 2.6.18-1.2257.fc5smp but not with
kernel 2.6.18-1.2239.fc5smp. Anyone have any ideas?
I have exactly the same problem with new 2.6.19-1.2895.fc6. initrd doesn't like
logical volumes...I'm NOT using raid. Maybe initrd-2.6.19-1.2895.fc6.img was
compiled without lvm support...it's much smaller than initrd-2.6.18-
I found https://fcp.surfsite.org/modules/newbb/viewtopic.php?
I fixed the problem when recompiled initrd -
mv initrd-2.6.19-1.2895.fc6.img initrd-2.6.19-1.2895.fc6.img.orig
mkinitrd --force-lvm-probe --with=ext3 /boot/initrd-2.6.19-1.2895.fc6.img
Can anyone confirm this fix - what do i need to run mkinitrd? The kernel sources?
Someone confirmed my fix there...
you don't need sources...check in /lib/modules if you have dir named as kernel
Then go to /boot and execute the commands above...
The indication that lvm module has been included in the new image will be that
size of the new image is about 800k bigger...
This fix will fix the problem caused by lvm not being included into the image...
I think RAID problem is separate...good luck...
(In reply to comment #7)
> Please also see bug 220269. I am (the reporter of that bug) using RAID.
If your LV involves raid5, you may also need to specify -preload=raid456 to the
mkinitrd command. See bug 220269.
Brilliant, thanks Michael - that worked great! Have to say, i'm slightly
disheartened that something so basic could have slipped past testing, in what
appears to be multiple kernels, especially as partitions are LVM by default in
new installs of FC.
This happened to me on a fresh, pristine, bare install of F7.
I got a kernel panic on boot IF I installed to LVM, but NOT if I installed to a
normal ext3 system.
How to reproduce:
Install onto LVM.
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
i suppose that all of us who were affected by this bug have long since moved on
to newer releases of fedora, so it seems appropriate to close it.
however, what i think is missing here is the most important part of fixing a bug
-- even if you aren't going to. and that is finding how something so
fundamental and so completely disastrous happened in the first place, AND
putting appropriate solutions in place to ensure that it can't happen again.
how could such a fundamental problem end up happening? how could testing miss
it? WAS it tested, or did someone bypass normal quality procedures? HOW do we
be sure that it can't happen again? that's pretty basic root cuase analysis,
frankly, i think that was the most important issue in this bug. and it appears
to have been completely dropped on the floor.
i've worked waaay too much time in organizations which are swamped in bug
repor5ts. the process of ignoring a bug, hoping that it will go away, and
waiting till it's old, then closing it, is symptomatic of organizations which
end up having it come back again. it's not symptomatic of organizations which
end up providing high quality systems.
i'm rather disappointed that that happened to this bug. and particularly
disappointed that it is being allowed to happen again.
Thank you for your update.