On Wed, Jan 28, 2015 at 1:19 AM, Felix Miata <mrma...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel