Bug 484508 - Fedora 11 alpha anaconda places invalid UUID for boot partition in grub.conf
Summary: Fedora 11 alpha anaconda places invalid UUID for boot partition in grub.conf
Keywords:
Status: CLOSED DUPLICATE of bug 480667
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-07 16:30 UTC by Clyde E. Kunkel
Modified: 2009-02-08 13:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-08 13:35:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Clyde E. Kunkel 2009-02-07 16:30:40 UTC
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.

Comment 1 Daniel Bristot 2009-02-07 18:53:05 UTC
I got the same error on x86_64.

Comment 2 Eric Sandeen 2009-02-07 20:24:53 UTC
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

Comment 3 Gianluca Varisco 2009-02-07 20:53:53 UTC
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.

Comment 4 Eric Sandeen 2009-02-07 21:14:37 UTC
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?

Comment 5 Eric Sandeen 2009-02-07 21:21:07 UTC
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...

Comment 6 Martin Sourada 2009-02-07 22:21:58 UTC
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.

Comment 7 Clyde E. Kunkel 2009-02-08 00:03:19 UTC
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.

Comment 8 Hans de Goede 2009-02-08 13:35:53 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.