Description of problem:
We are trying different motherboards in a machine and with a
mATX MSI 945GM2 a working installation fails during boot when
in can't find the volume group on which / resides.
The install worked fine on an ASUS board but now it's a
new SATA-chipset and I suspect that it is something wrong
with the initrd, and our combination of 2 disks, swraid
and lvm on top of that.
Version-Release number of selected component (if applicable):
This is the output on boot.
Scanning logical volumes
Reading all physical volumes. This may take a while...
No volume groups found
Unable to find volume group "servervol01"
ERROR: /bin/lvm exited abnormally with value 5 ! (pid 392)
mount: error 6 mounting ext3
ERROR opening /dev/console!!!!: 2
error dup2'ing fd of 0 to 0
error dup2'ing fd of 0 to 1
error dup2'ing fd of 0 to 2
switchroot: mount failed: 22
Kernel panic - not syncing: Attempted to kill init!
When I booted with the fc4 rescue-cd it said that there was some
error in mounting some partitions, but at the shell everything
The rescue cd had inserted ata_piix.ko, and not sata_nv.ko which
the ASUS motherboard used.
In rescue mode lvscan and lvdisplay looked fine, all devices
were mapped and all partitions were mountable and chrootable.
I tried some 2.6.14 kernels as well but to no effect.
Created attachment 125033 [details]
Console output of the booting kernel over serial console.
Created attachment 125180 [details]
dmesg after rescue kernel boots
This it dmesg output from the bash prompt when booting
with the rescue image from FC4.
Here something is very wrong.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: autorun ...
md: considering sdb3 ...
md: adding sdb3 ...
md: adding sda3 ...
md: created md4
md: running: <sdb3><sda3>
raid1: raid set md4 active with 2 out of 2 mirrors
md: ... autorun DONE.
Wierdest part is that the dmesg from 2.6.15 it autoruns
and does nothing exactly 6 times, and that's how many
raid partitions there is on each drive.
I've now tried to make it boot without lvm and raid by
booting in rescue mode and creating an extra partition
and copying / to it. But it still fails to boot.
I've tried many kernels between 2.6.11 and 2.6.15, both up and
smp, but none of them works except the one on the rescue image.
I'm really stumped here and I need some pointers on figuring out
what's wrong with the initrd. Is it just a module that is missing?
Created attachment 126153 [details]
dmesg from rescue kernel as soon as the bash prompts appears
I managed get some more of the early dmesg messages from the
working kernel, from directly when the bash prompts appears.
[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
Please retest with Fedora Core 5.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
(this is a mass-close to kernel bugs in NEEDINFO state)
As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.
If you believe that this bug was closed in error, please feel free to reopen