Booting off a duplicated partition not working?

For many years I’ve had one or two dev boxes where I follow this scheme:

  • except for boot, disks are under LVM
  • several identically sized logical volumes are available to be used as a root FS
  • when a new Fedora release is available, mkfs on an unneeded root-eligible LV and rsync current version to it
  • boot off the new LV by changing the root= argument in the grub line
  • upgrade the Fedora release
  • keep both fedoras around for a while, maybe till the older one stops receiving upgrades

The reasons for doing this way are a bit historical and less important to me now than they used to be, I could just keep VMs of older versions around to satisfy the remaining needs (I do this also, in fact), but the systems are set up this way now and I’m in the habit so I’m curious why it seems not to work out any more…

The last couple of releases (at least duplicated f28’s and f29’s haven’t booted), the “boot off the new partition” step doesn’t work any longer. Is there some new magic happening that doesn’t let a duplicated filesystem be booted off of? Is there information embedded in the initramfs that has to match something on the FS perhaps? Some grub argument maybe I’m missing? Magic with UUIDs? (fwiw the grub cfgs don’t use uuids except for identifying the boot partitions)

“Doesn’t work” is imprecise I know; I’ve seen a couple of different failures but this is far the most typical one:

[ OK ] Reached target Switch Root.
           Starting Switch Root...
[ !! ] Failed to execute /sbin/init
[    ] systemd[1]: Freezing operations
[!!!!!] Failed to exeucte fallback shell, freezing

Everything looks fine until the switch root. some internet searching suggests that people have run into this elsewhere, but the suggestions there don’t seem to match: the initramfs is not corrupt (same initramfs boots the LV that was duplicated just fine), the duplicated rootfs is not corrupt, the boot partition is not corrupt (it boots normally just fine), etc.

I’ve played games with renaming the LVs so that the target to boot off is the same name as the one that the initramfs would have been constructed on… just a shot in the dark but that has no effect (and the original can be booted off of under a different LV name).