Description of problem: grub.conf kernel root parameter of LV UUID fails with /dev/root not found Version-Release number of selected component (if applicable): 11 Alpha How reproducible: every time Steps to Reproduce: 1. boot i386 install DVD 2. select LV for / partition 3. reboot at end of software installation (desktop with gnome and kde) Actual results: boot fails with /dev/root not found Expected results: normal first boot Additional info: replacing root=UUID=(long uuid string) with /dev/VolGroup01/fedora11 allows booting to first boot. The UUID anaconda placed in grub.conf does not match the UUID of any of the LVs or VGs or PVs or other partitions. Note: request HIGH priority since a user without recourse to edit the grub.conf file would not be able to install this release. Further note: there was some kind of oops or traceback after clicking reboot on each test install, but it was gone too fast to get any meaningful info.
I got the same error on x86_64.
so what was the wrong UUID and what is the correct UUID? Can you do # blkid paste or attach the output, and point out what the UUID *should* be, and also what it *was* ? Thanks, -Eric
Hi Eric, I had the same problem on x86_64 today. The error was something like "mount: unable to mount /dev/root". I replaced /dev/root 's UUID (8e12215e-bafb-443f-ac94-9db7abaa5e22) with /dev/vg_gvarisco/lv_root and it worked. Here is the output of "blkid": /dev/sda2: UUID="a35020b1-cd3a-4ec7-8137-ce831056443e" TYPE="crypt_LUKS" /dev/sda1: LABEL="/boot" UUID="99233c1c-7cb0-4638-a1cc-770e12ed40c1" TYPE="ext3" SEC_TYPE="ext2" /dev/mapper/luks-a35020b1-cd3a-4ec7-8137-ce831056443e: UUID="ZY8fu5-Ayma-Vfhi-N71U-LyKE-V60P-Cwj0bH" TYPE="lvm2pv" /dev/mapper/vg_gvarisco-lv_root: UUID="8e12215e-bafb-443f-ac94-9db7abaa5e22" TYPE="ext4" /dev/mapper/vg_gvarisco-lv_swap: TYPE="swap" UUID="5b70858a-77eb-4b6f-ad14-72a939298b85" /dev/vg_gvarisco/lv_root: UUID="8e12215e-bafb-443f-ac94-9db7abaa5e22" TYPE="ext4" /dev/vg_gvarisco/lv_swap: TYPE="swap" UUID="5b70858a-77eb-4b6f-ad14-72a939298b85" /dev/root: UUID="8e12215e-bafb-443f-ac94-9db7abaa5e22" TYPE="ext4" Both /dev/root and /dev/vg_gvarisco/lv_root have (and had) the same UUID (if I am not blind). Actually I'm not sure grub boots *at all* by using root=UUID=$number and ext4 (not sure if it is related). Let me know if I can provide you further details.
Hi Gianluca - So, what was the original UUID (or the original root=* parameter) that was in grub.conf? I've done some ext4 installs that worked so it doesn't seem to be a generic problem... You could add another grub stanza, something like title Fedora (2.6.29-0.78.rc3.git5.fc11.x86_64) root (hd0,1) kernel /vmlinuz-2.6.29-0.78.rc3.git5.fc11.x86_64 ro root=UUID=8e12215e-bafb-443f-ac94-9db7abaa5e22 rhgb quiet initrd /initrd-2.6.29-0.78.rc3.git5.fc11.x86_64.img (with all the right versions etc) to test the UUID in grub again. I guess this system is also root-drive encrypted w/ dm-crypt?
Oh, sorry, should have read more carefully. So 8e12215e-bafb-443f-ac94-9db7abaa5e22 is what *was* in grub.conf I assume, and it is correct for /dev/root. And it's also correct for /dev/vg_gvarisco/lv_root Hrm...
Note that I had exactly the same problem when installing from Desktop Live CD. I haven't tried replacing it with root=/dev/VolGroup00/Rawhide_ROOT because I gave up before stumbling upon this bug and wiped the partition out... I'll do the install once again and see the results. Note that the same grub boots fine into my F10 install which has root specified by UUID as well... It was ext3 on i386 btw.
This may not be an anaconda problem after all. The UUID inserted in grub.conf is the correct one as reported by blkid (side note: why does lvdisplay show a different uuid for the LV?). The original install fstab used /dev/VolGroup01/fedora11 to mount root. I changed that to the UUID=etc, etc, as displayed in grub.conf and recreated the .img file and now that kernel boots normally. I had already updated the system and I see that the mkinitrd that I used to recreate the .img file is mkinitrd-6.0.76-1.fc11.i386, while the mkinitrd on the install DVD was mkinitrd-6.0.75-1.fc11.i386. So, there may have been a mkinitrd issue. However, I wonder why UUID was used in grub, abd /dev/VolGroup/fedora11 was used in the fstab? Given the above, this bz should probably be given a lower priority.
mount by UUID not working in the alpha is a known problem in nash in the alpha. Please update to mkinitrd-6.0.76, and regenerate your initrd: mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r) Then this problem should go away. *** This bug has been marked as a duplicate of bug 480667 ***