Bug 484508

Summary:	Fedora 11 alpha anaconda places invalid UUID for boot partition in grub.conf
Product:	[Fedora] Fedora	Reporter:	Clyde E. Kunkel <clydekunkel7734>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	rawhide	CC:	anaconda-maint-list, danielbristot, esandeen, gvarisco, hdegoede, martin.sourada
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-08 13:35:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***