On 29.01.2015 17:38, Chris Murphy wrote: > On Thu, Jan 29, 2015 at 2:20 AM, Felix Miata <mrma...@earthlink.net> wrote: >> I wrote "clone" for a reason. I don't "just copy" files. I clone (logical, >> root, autonomous) *partitions*, subsequently modifying only fstab, volume >> label and UUID before attempting boot from it. > > Clone is a generic term, it doesn't require a particular process. Are > you changing the volume UUID with, e.g. tune2fs -U random? > > >>> 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 >> >> The process I wrote was intended to make it clear that no bootloader that may >> have been on a Fedora / partition was used for booting a Fedora clone as >> adjusted to its new location. It's a process that was relatively simple and >> reliable until humanly memorable cmdline root= parameters what worked >> formerly began being disregarded by Fedora's boot process in apparent favor >> of incorporating a root filesystem UUID subject to change during >> backup/restore process in its initrd. > > Like I said, I can't reproduce this behavior. The BIOS system boots > fine without rebuilding the initramfs just by changing fstab and > grub.cfg UUIDs to match the root volume's UUID. Therefore I see no > evidence root= is ignored on Fedora. > > The failed UEFI boot is strictly due to the old ESP UUID not being > found. The failure has nothing to do with root=. > > dracut -f -v --debug shows only on UEFI is there a wait for device by uuid > /usr/lib/dracut/modules.d/99base/module-setup.sh@113(install): > wait_for_dev /dev/disk/by-uuid/5AC5-5766 > >
will follow up in private email and on the bugzilla _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
