[systemd-devel] root= ignored

[Chris Murphy]

On Wed, Jan 28, 2015 at 1:19 AM, Felix Miata <mrmazda at earthlink.net> wrote:
> Chris Murphy composed on 2015-01-27 23:29 (UTC-0700):
>
>> Felix Miata wrote:
>
>>> Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100):
>
>>>> Hmm, Fedora doesn't obey root=? That sounds like a bug.
>
>> I'm not sure what it means, Fedora doesn't obey root=. Since a long
>> time it uses root=UUID= and this has worked for me.
>
> All current distros whose bootloaders I've used include a root= in each of
> their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
> stanzas.

That's true unless LVM is being used, which happens to be the default,
in which case it's root=VG/LV.

> When Fedora is the source and clone, attempting boot of clone using default
> initrd produces an emergency shell, unlike openSUSE.

I'm unable to reproduce this problem on a BIOS system. Old volume is
Btrfs, new volumes is Btrfs (new volume UUID), and I just copy the
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create
a new grub.cfg with grub2-mkconfig in order for the correct new volume
root=UUID= to be set. And I also had to edit the fstab on the new
volume so that the right UUIDs are called for there too. The resulting
system boots fine.

However, on UEFI that's not the case, I get dropped to a dracut shell:

[  188.409072] f21s2.localdomain dracut-initqueue[263]: Warning:
/dev/disk/by-uuid/083A-7E6C does not exist

That UUID is for the old FAT32 EFI System Partition. Somehow dracut is
baking in the EFI System partition UUID into the initramfs, instead of
honoring the correct one that I put into fstab. As a result boot fails
and will always fail until I rebuild the initramfs. So I'd definitely
consider that a bug.

https://bugzilla.redhat.com/show_bug.cgi?id=1187007


-- 
Chris Murphy