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 -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel