Hardware-agnostic Silverblue Backup & Restore

I need to replace my laptop because certain parts are failing. It runs Silverblue. The old laptop will be retired, so I want to do a full transfer, but can’t simply transfer the physical disk from one machine to the other. Cloning the entire disk might work (or not, as it seems some hardware-specific things are written to disk at install time), but the old laptop has a Windows partition that I don’t want to keep. Other people may want to accomplish this with differently sized disks, so it’s not a particularly unique situation. So, this is what I tried:

  • Install fresh Silverblue on target to achieve ideal partition sizes & layout
  • Use CloneZilla to clone Boot & Btrfs partitions from old to new

Of course, this broke boot because the partition GUIDs are mismatched. The EFI partition on the target machine looks for the old boot GUID, the Boot partition references the old computer’s EFI partition. The instructions for repairing GRUB don’t work with Silverblue (and these Silverblue-specific instructions don’t work with UEFI), but I was able to repair it by hand easily enough from a Fedora Worksatation Live USB.

… but the system boots into emergency mode. I can’t ask journalctl why, because I get “the root account is locked”. The solution to that likewise requires chroot.

I might be having the same problem posted to this closed thread.

Since all UUID’s and the bootloader match the source when using dd to clone, the problem most likely is a missing kernel module for the nvme - and rebuilding the initrd via chroot the way to go

Seems accurate! Unfortunately, the following instructions are terse and incomplete. Yet again, chroot from live is required (maybe?), and who among us can truly comprehend what is meant by “make ‘dracute’ inside old system, than was boot LiveUSB Fedora 33 and make ‘dd copying’, old-drive-system was cloned and booted successfully from new storage without any magic actions”.

I could keep going down this UEFI/GRUB rabbit hole… but instead of fighting Silverblue’s structure, it seems like I should be able to embrace it: Freshly install Silverblue on the target machine, install the same layers with rpm-ostree, then copy the user data. Isn’t that supposed to be one of the primary benefits that justifies the complexity of having a readonly system partition?

The problem there is: the only answers I could find regarding how to back up and restore Silverblue are uselessly vague suggestions without proof of work or meandering and contradictory. And that’s wrong, after all, because passwd is completely absent from the var and home subvolumes - so there is user-specific persistent state in the root subvolume. And restoring the root subvolume onto the new machine will break its ability to boot because GRUB and the /boot/ostree contents won’t reference the correct ostree folders in /.

So… what am I supposed to do here? Are there any viable ways to transfer a Silverblue system image from one UEFI machine to another? Or is the only truly supported option to start fresh and restore or reconstruct account/apps/settings/files separately?

AFAIK there are no hardware specific bits put into the OS at install time that should prevent just relocating the drive from the old machine to the new one. You have already noted and addressed the issues with UUIDs and cloning the drive without also verifying that the UUIDs are updated.
UUIDs needed would need to be updated in /etc/fstab, /boot/efi/EFI/fedora/grub.cfg and /boot/loader/entries. Also dracut may need to update the initramfs image.

All that is easily done on a normal system but I don’t know how silverblue would manage that.

There are different approaches.

What I will do:

  1. Fresh install Silverblue to the new system
  2. Silverblue, as checked with version 37, is using btrfs . use btrfs send / receive to copy the filesystem to the new system
  3. Adjust boot entries, so that it will load the copied btrfs subvolumes

… there are no hardware specific bits put into the OS at install time…

That was my general understanding, what with the Linux kernel being monolithic. However, “the problem most likely is a missing kernel module for the nvme - and rebuilding the initrd via chroot the way to go” from the linked thread made me doubt that. With BIOS and SATA, I know a disk that boots on one system should boot on another in 99% of cases, but UEFI and NVME are newer and more complex and less familiar so as far as I know there could be off-filesystem state.

Lo and behold, I see that I have some Intel-specific Flatpaks installed. I didn’t install those, and I doubt I would have found them installed if I had an AMD chip. These Flatpaks are surely not the problem, of course. But it gives reason to doubt that there are 0 install-time decisions written to disk.

I hope that you are right, though. I was hoping someone familiar with the installer’s implementation details might be able to confirm or deny the suspicion.

UUIDs would need to be updated in /etc/fstab

I checked fstab in the OSTree deployment directories and none of the UUIDs in there needed changing. It only references the EXT4 /boot & BTRFS / partitions, which were both cloned preserving their IDs. The only difference is the UEFI partition ID.

Also dracut may need to update the initramfs image

Now this is something I didn’t do. It was suggested in one of the linked threads, but I can’t figure out how to do that without more clarity, or hours and hours of research and troubleshooting. Which initramfs images? Where do I find them? What kernel string should I use? Which of the dozens of Dracut parameters should I care about and what arguments are appropriate?

My question for you is: Why does the initramfs image need to be updated? What specific difference is accomplished by the update?

Hey, Sampson, that’s almost exactly what I did. The only difference is that I used CloneZilla instead of btrfs send/btrfs receive. CloneZilla might even use those under the hood. My cloned BTRFS partition was mountable and free of errors, confirmed from Live CD. So, I would wager that your process will also result in an unbootable system.