The idea

I have been eyeing on Silverblue for a long time. Regular Fedora has served me well, but I’ve always felt that the idea of keeping the base OS as clean as possible would be a good idea.

Last week I took the plunge and replaced Fedora Workstation with Silverblue. I used to have separate users for work and personal/study use, but now I figured that I’d get all in on the toolbox/container workflow with Fedora. I use VMs a lot for work, and I like that the work environment keeps separate from the personal stuff, so I decided to create a separate container for work and another one for other personal stuff like this blog.

Preparation

Like mentioned, I replaced my previous Workstation installation with Silverblue. I made backups of everything utilizing btrfs send to my home server. As the workstation disk layout was done using plain defaults Fedora suggests (can’t remember which version, the first one defaulting to btrfs), the boot partition was the only “regular” filesystem. I made a copy of the /boot directory with

rsync -arxXhv /boot/ /boot_backup/

This creates a copy of the /boot directory as /boot_backup, but won’t recurse into the EFI partition mounted at /boot/efi on Fedora (the -x flag), while copying other subdirectories (-r) and copying extended attributes (-X). The -h and -v stand for human-readable sizes and verbose output respectively.

After that I copied over the filesystems to the server’s storage. First the top level subvolume, subvolid=5, needs to be mounted somewhere. Normally you would do this with e.g.

mount -o subvolid=5 /dev/sdXY /mnt

If your snapshot storage location is e.g. a subvolume named .snapshots nested above the parent subvolume, this isn’t necessary at this stage. But I have found it is good practice to store the snapshots somewhere outside the source tree, so I tend to create a subvolume for snapshots on the toplevel.

When the top level subvolume has been mounted, the subvolume(s) need to be snapshotted, which is normally done with something along the lines of

btrfs subvolume snapshot -r /mnt/root /mnt/snapshots/root-snapshot

for each subvolume. Note the -r to take readonly snapshots, and the above command assumes you have mounted the toplevel subvolume to /mnt, it contains a subvolume named root and a directory or another subvolume called snapshots.

I have however been writing my own btrfs management script called snapsh, which is still a work in progress, but on a flat subvolume layout works quite well and has a few handy shortcuts. First of all, the mounting and unmounting the toplevel is done automatically to a location that can be defined (defaulting to /root/btrfs-toplevel), so no manual mounting is necessary. Taking the snapshots is simply:

snapsh -s root -d 'Backup before switching to Silverblue'
snapsh -s home -d 'Backup before switching to Silverblue'

Once the subvolumes are snapshotted, sending them to another place requires the toplevel to be mounted. With standard btrfs tools the method was shown above, but using snapsh it can be done with a simple

snapsh --mount

Now that the toplevel is mounted (/mnt/snapshots is just an example location), the actual send operation over SSH is done with:

btrfs send /mnt/snapshots/root-snapshot | ssh root@target.ip 'btrfs receive /path/to/btrfs/backups'

which replicates the root-snapshot subvolume as /path/to/btrfs/backups/root-snapshot on the target machine.

I’m only going to use those backups to restore particular files and folders to the new Silverblue installation, so I could have user other tools like just rsync or borg to make them.

Installation

The laptop I’m using is a dual boot wih Windows, so the Silverblue installer is a bit tricky. According to the Silverblue documentation, there might be issues so I decided to do the partitioning manually. Silverblue uses quite a different partition/subvolume layout compared to Workstation, so I had to do some research on how the layout should be. After a bit of time with search engines, I settled on the following:

As far as I can tell, this is the same layout the installer would make on a clean installation without the dual-boot. With the partitions laid out (and other things configured), I proceeded to start the installation. However, the installation failed!

Back to the drawing board. At this stage I was happy that I had the backups, even though the plan was to wipe and start fresh. Since I had started the installation process, the partitions marked for formatting were wiped and now only Windows was working.

I refused to boot Windows on my free time just because of a slight inconvenience like this, and proceeded to search the web about the particular error on my phone. If you run into problems like this, you can switch to a TTY from the installer with ctrl+alt+F2, and the log files are under /tmp.

Everything I found seemed to indicate that dualbooting Silverblue is entirely possible. On a seemingly unrelated Redhat Bugzilla ticket there were mentions of the installer not knowing how to deal with a non-empty EFI\fedora directory on the EFI partition. I thought that I have no reason preserving the previous bootloader files, so I mounted the EFI partition from the TTY and deleted the fedora folder, rebooted, reconfigured the installer and there you go! The installation succeeded!

If you are replacing an existing Fedora installation with Silverblue, delete the bootloader files from the EFI partition!

The screenshot contains customizations

Links:

• https://github.com/0ranki/snapsh
• Fedora Docs on partition layout
• RedHat Bugzilla on EFI partition