Booting off a duplicated partition not working?

Ask Fedora
,
1

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).

2

Hi @mwichmann!

You don’t mention changing your fstab to also point to new root partition. It’s too simple a mistake to be true, but still…

We can try to troubleshoot this (by studying logs for example, maybe something else come to mind) if you’re into it, it could be interesting at the least if not actually useful.

3

oops, missed this reply. yes, the fstab was updated in the duplicate. I’ll try to see if I can capture a somewhat useful log; what I’ve seen so far was not more than was in the original posting - starting switch root, then death.

4

What about SELinux labels?
Probably using dd and tune2fs would be a safer approach.

Perhaps you need to force dracut to regenerate the initramfs images.
This was mandatory for me to properly rename the VG.

5

yeah. I’ve tried that, apparently haven’t gotten things done right. (it’s not selinux btw: off for that exercise to eliminate it as a factor).

1 Like