Red Hat Bugzilla – Bug 238462
can't find /dev/root after install of F7 Test4, possible LVM problem
Last modified: 2007-11-30 17:12:03 EST
Booting from the F7 Test4 live cd or regular DVD iso works fine and I was able to install without a hitch. I have a rather intersting HD partition scheme. /dev/hda1 * 1 3824 30716248+ 7 HPFS/NTFS /dev/hda2 3825 3856 257040 83 Linux /dev/hda3 3857 5131 10241437+ 8e Linux LVM /dev/hda4 5132 12161 56468475 5 Extended /dev/hda5 5132 6406 10241406 8e Linux LVM /dev/hda6 6407 7681 10241406 8e Linux LVM /dev/hda7 7682 8956 10241406 8e Linux LVM /dev/hda8 8957 12161 25744131 83 Linux hda1 = evil OS hda2 = boot hda3 and hda5 are in the volumegroup F7686VG00 hda6 and hda7 are in the volumegroup VolGroup01 hda8 is irrelevant both volumegroups have 2 LV's, a / and a swap partition. The F7686VG00 has my new F7Test4 install and VolGroup01 has my FC6 install. My /boot/grub/grub.conf looks like: title Fedora (2.6.20-1.3104.fc7) root (hd0,1) kernel /vmlinuz-2.6.20-1.3104.fc7 ro root=/dev/F7686VG00/LogVol01 initrd /initrd-2.6.20-1.3104.fc7.img title Fedora Core 6 (2.6.20-1.2944.fc6) root (hd0,1) kernel /vmlinuz-2.6.20-1.2944.fc6 ro root=/dev/VolGroup01/LogVol01 initrd /initrd-2.6.20-1.2944.fc6.img title Other rootnoverify (hd0,0) chainloader +1 When I boot FC6 (and everything works fine) I saw something like this snippet go by: Scanning logical volumes Reading all physical volumes. this may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "F7686VG00" using metadata type lvm2 Activating logical volumes 2 logical volumes(s) in volume group "VolGroup01" now active 2 logical volumes(s) in volume group "F7686VG00" now active Trying to resume from /dev/VolGroup01/LogVol00 When I boot F7 (and it panics) I see this as the last thing on the screen. (I typed this in by hand, so ignore the typos and such) Scanning logical volumes Reading all physical volumes. this may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "F7686VG00" using metadata type lvm2 Activating logical volumes 2 logical volumes(s) in volume group "VolGroup01" now active Trying to resume from /dev/VolGroup01/LogVol00 No suspend signature on swap, not resuming. Creating root device. Mounting root filesystem. mount: cound not find filesystem '/dev/root' Setting up other filesystem. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mount internal defaults setuproot: error mount /proc: No such file or directory setuproot: root mount /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 Booting has failed. Kernel panic - no syncing: Attempted to kill init! I doesn't seem like it ever activated the LV's inside /dev/F7686VG00 so it didn't have the device I specified in grub. (I also tried using root=LABEL=/ which is correct for F7 with the same results)
Comparison of the initrds for the two installations could be helpful. You can compare them yourself (they are just .cpio.gz files) or upload them as attachments. The file /init is the one to look at.
--- FC6/init 2007-05-02 10:42:44.000000000 -0400 +++ F7/init 2007-05-02 10:42:32.000000000 -0400 @@ -47,6 +47,8 @@ insmod /lib/ohci-hcd.ko echo "Loading ehci-hcd.ko module" insmod /lib/ehci-hcd.ko mount -t usbfs /proc/bus/usb /proc/bus/usb +echo "Loading mbcache.ko module" +insmod /lib/mbcache.ko echo "Loading jbd.ko module" insmod /lib/jbd.ko echo "Loading ext3.ko module" @@ -59,6 +61,10 @@ echo "Loading libata.ko module" insmod /lib/libata.ko echo "Loading ata_piix.ko module" insmod /lib/ata_piix.ko +echo Waiting for driver initialization. +stabilized --hash --interval 250 /proc/scsi/scsi +echo "Loading ata_generic.ko module" +insmod /lib/ata_generic.ko echo "Loading dm-mod.ko module" insmod /lib/dm-mod.ko echo "Loading dm-mirror.ko module" @@ -69,6 +75,8 @@ echo "Loading dm-snapshot.ko module" insmod /lib/dm-snapshot.ko echo Making device-mapper control node mkdmnod +insmod /lib/scsi_wait_scan.ko +rmmod scsi_wait_scan mkblkdevs echo Scanning logical volumes lvm vgscan --ignorelockingfailure @@ -76,10 +84,12 @@ echo Activating logical volumes lvm vgchange -ay --ignorelockingfailure VolGroup01 resume /dev/VolGroup01/LogVol00 echo Creating root device. -mkrootdev -t ext3 -o noatime,ro /dev/VolGroup01/LogVol01 +mkrootdev -t ext3 -o defaults,ro LABEL=/ echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot +echo Booting has failed. +sleep -1
Created attachment 153959 [details] init from the initrd for my F7 install
This sounds very similar to bug 236825...
Well, I tracked down the problem. I'm going to need to reinstall to see if it does it again. I'm pretty sure this is going to need to get moved to anaconda or something in the installer. The main issue is that my new / directory was created with no e2label. If I did e2label /dev/F7686VG00/LogVol01 it would just return a blank. My new /etc/fstab and all of the stuff inside the initrd all were based on LABEL=/ I'm pretty sure my grub was based on LABEL= as well, but I changed that so early on to be hard coded I can't remember. Basically my / had not label, so /etc/fstab, the init inside the initrd, and probably grub were all wrong. once i fixed those all by hand I was able to boot. uggh.
So, let me be sure - your old root partition (/dev/VolGroup01/LogVol01) had LABEL=/, but the new one had no label? Did you (attempt to) set a label on your new / partition, or did you just accept the anaconda default? Sounds like this is a problem with partition labeling in anaconda - reassigning.
Well, I wish I could recall all of the history of this laptop. When I checked some time ago (before I tried to fix all this) I found no label at all when I ran e2label on both /dev/VolGroup01/LogVol01 and /dev/F7686VG00/LogVol01. I'm reasonably sure that long long ago I had a VolGroup00 which had FC5. It most likely was labeled / but it has been gone a long time. When I installed FC6 it appears to have not labeled the root LV and the installer decided to use full path names for the location of / When I installed F7 it again appears to have not given a LABEL to the new / but F7 still decided to use LABEL=/ everywhere. When I manually made it use the full path names F7 started working. I could be lieing about the FC6 install since I have since labeled the root on both of my installs but I'm reasonably sure that when I checked neither of my VolGroup01 or F7686VG00 installs had a label on their respective / directories... I definitely did not try to change the labeling defaults when installing F7 (I didn't even know that was possible)
We don't label filesystems on logical volumes so I don't see how you should have gotten LABEL=/ anywhere. Was this an install over top of an existing installation, or an upgrade? It sounds like the former to me. In that case, perhaps you previously labeled the filesystems yourself and modified your fstab? That possibly could have confused anaconda.
Any relation with bug #214184 ?
requested by Jams Antill
I have very similar problems with F8t2. sda1 = Lenovo recovery partition sda2 = Windows sda3 = /boot sda5 = openSUSE /boot sda6 = reserved for CentOS sda7 = swap sda8 = LVM: /dev/system/{root_fedora,root_opensuse,local} Will investigate if tinkering with labels (perhaps removing them before calling Anaconda) would work. I did the partitioning outside Anaconda, since on Thinkpads parted, fdisk and Windows all use different geometries, and Anaconda's partitioner won't let me specify the starting cylinder (so I can skip one or two cylinders to be on the safe side).
A couple of things that could potentially have ended up down this path have been fixed in recent rawhide. So closing as RAWHIDE since we don't have full details on how you made it happen and that there definitely are things that have been improved