{"id":133662,"date":"2023-05-12T08:00:00","date_gmt":"2023-05-12T08:00:00","guid":{"rendered":"https:\/\/fedoramagazine.org\/?p=38259"},"modified":"2023-05-12T08:00:00","modified_gmt":"2023-05-12T08:00:00","slug":"make-use-of-btrfs-snapshots-to-upgrade-fedora-linux-with-easy-fallback","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2023\/05\/12\/make-use-of-btrfs-snapshots-to-upgrade-fedora-linux-with-easy-fallback\/","title":{"rendered":"Make use of Btrfs snapshots to upgrade Fedora Linux with easy fallback"},"content":{"rendered":"

Back in 2018, a previous article<\/a> demonstrated how to use LVM to clone the root filesystem before upgrading Fedora Linux so as to have a fallback in the unlikely event that something goes wrong. Today, the default Fedora Workstation install uses Btrfs. Now you can use a Btrfs snapshot to make creating a bootable fallback much easier. Note that converting or migrating a system to Btrfs from another filesystem is outside the scope of this article.<\/p>\n

<\/span> <\/p>\n

Check that root filesystem is Btrfs<\/h2>\n

This example uses a Pinebook aarch64 laptop. Before proceeding, first make sure that Btrfs is being used for the root (system) filesystem. Not every spin or image uses Btrfs by default.<\/p>\n

$ df -T\nFilesystem Type 1K-blocks Used Available Use% Mounted on\ndevtmpfs devtmpfs 4096 0 4096 0% \/dev\ntmpfs tmpfs 998992 0 998992 0% \/dev\/shm\ntmpfs tmpfs 399600 6360 393240 2% \/run\n\/dev\/mmcblk2p3 btrfs 56929280 39796116 15058348 73% \/\ntmpfs tmpfs 998996 24 998972 1% \/tmp\ntmpfs tmpfs 5242880 0 5242880 0% \/var\/lib\/mock\n\/dev\/mmcblk2p3 btrfs 56929280 39796116 15058348 73% \/f34\n\/dev\/mmcblk2p3 btrfs 56929280 39796116 15058348 73% \/home\n\/dev\/mmcblk2p2 ext4 996780 551888 376080 60% \/boot\n\/dev\/mmcblk2p1 vfat 194348 31648 162700 17% \/boot\/efi\ntmpfs tmpfs 199796 100 199696 1% \/run\/user\/1000\ntmpfs tmpfs 199796 84 199712 1% \/run\/user\/0<\/pre>\n
List the existing Btrfs subvolumes<\/h2>\n
The above example output shows that the file system mounted on “root” (“\/”) is type Btrfs. Notice that three mountpoints show the same backing device and the same Used<\/em> and Available<\/em> blocks. This is because they are parts (subvolumes) mounted from a single Btrfs filesystem. The \/f34<\/em> subvolume is my bootable snapshot from last year.<\/p>\n
A default Fedora Btrfs install creates one Btrfs filesystem with two subvolumes — root<\/em> and home<\/em> — mounted on \/ and \/home respectively. Let’s see what other subvolumes I’ve added:<\/p>\n
$ sudo btrfs subvol list \/\nID 272 gen 110428 top level 5 path root\nID 273 gen 110426 top level 5 path home\nID 300 gen 109923 top level 5 path f34\nID 301 gen 95852 top level 5 path home.22Jul26\nID 302 gen 95854 top level 5 path f36.22Jul26<\/pre>\n
There is an f34<\/em> subvol from the last system-upgrade and two readonly snapshots of home<\/em> and f36<\/em>. The easiest way to add and delete snapshots is to mount the Btrfs root. I will update the system and create a new snapshot of the current f36 root<\/em> subvolume. If you have renamed your root<\/em> subvolume, then you presumably know enough to adjust the following example accordingly for your system.<\/p>\n
Create the Btrfs fallback snapshot<\/h2>\n
$ sudo dnf update --refresh\n... lots of stuff updated (reboot if kernel updated)\n$ sudo mkdir -p \/mnt\/root\n$ sudo mount \/dev\/mmcblk2p3 \/mnt\/root\n$ cd \/mnt\/root\n$ ls\nf34 f36.22Jul26 home home.22Jul26 root\n$ sudo btrfs subvol snapshot root f36\nCreate a snapshot of 'root' in '.\/f36'<\/pre>\n
Because Btrfs snapshots are filesystem based, it is not necessary to “sync” before the snapshot, as I recommended for LVM. To boot from the new subvol as a fallback, you will need to edit \/mnt\/root\/f36\/etc\/fstab with your favorite editor. If you are a beginner, nano is a dirt simple text editor with minimal features. Here are some lines from my fstab<\/em> file:<\/p>\n
LABEL=PINE \/ btrfs subvol=root,compress=zstd:1 1 1\nUUID=e31667fb-5b6f-48d9-aa90-f2fd6aa5f005 \/boot ext4 defaults 1 2\nUUID=75DB-5832 \/boot\/efi vfat umask=0077,shortname=winnt 0 2\nLABEL=PINE \/home btrfs subvol=home,compress=zstd:1 1 1\nLABEL=SWAP swap swap\tdiscard=once\t0 0<\/pre>\n
Change subvol=root<\/em> to subvol=f36<\/em>. This change is to the file in the snapshot, not your production fstab<\/em>. You can compare them with diff \/etc\/fstab \/mnt\/root\/f36\/etc\/fstab<\/kbd>. In my case, I also deleted my f34<\/em> snapshot from last year with sudo btrfs subvol delete f34<\/kbd>.<\/p>\n
Test the Btrfs fallback snapshot<\/h2>\n
Now you are ready to test the fallback. You could use grubby<\/a> or edit an entry in \/boot\/loader\/entries to change subvol=root<\/em> to subvol=f36<\/em>. But in the interest of safety for beginners, I will have you edit the GRUB entry at boot time instead. Checkout this article on GRUB<\/a> for tips on getting to the GRUB menu. Once you are there, press the e<\/strong> key to edit the default kernel entry. Don’t worry — your changes are in volatile memory only. If you mess up, reboot to start over. Just like with fstab, find subvol=root<\/em> and change it to subvol=f36<\/em>. Press F10<\/strong> or Ctrl<\/strong>+X<\/strong> to boot your modified entry. With these changes, the system should boot into your new snapshot. Look at \/etc\/fstab to make sure you are booting from the right subvol, or enter mount | grep subvol<\/kbd> to see what subvolume is mounted on “\/”. <\/p>\n
Do the Fedora Linux system upgrade<\/h2>\n
If your fallback is working, reboot back to your normal root filesystem (and confirm as above). Then proceed with the standard system-upgrade outlined on the wiki page<\/a>. TIP: Before running dnf system-upgrade reboot<\/kbd>, make another snapshot of root. Call it something like root.dl<\/em>. That way, you don’t have to download five gigabytes of packages again should you discover that there wasn’t enough free space. The snapshot will not take up any additional space because all but the downloaded packages are shared with root<\/em> and f36<\/em>. About that sharing of disk blocks \u2026 <\/p>\n
dnf system-upgrade<\/kbd> gets confused about free space as reported by Btrfs because the f36 files in the root<\/em> subvolume use the same disk locations as the same files in the f36<\/em> subvolume. So removing them from the root<\/em> subvolume during the upgrade process doesn’t actually free up any space. If you run out of space, and you reboot — the graphical user interface (GUI) won’t start. Use Ctrl<\/strong>+Alt<\/strong>+F2<\/strong> to login on a text console and practice your command line interface skills. Figuring out what to remove to free up space or how to expand the root filesystem is beyond the scope of this article (mine is often on an LVM volume and can be expanded). Having more than 50% free for the upgrade is a safe bet.<\/p>\n
Recovery<\/h2>\n
Should something go wrong, you can reboot and edit the GRUB entry to boot the fallback. If you are a beginner, you’ll want some hand holding if you do end up needing to change the GRUB entry on disk (so you don’t have to edit at each boot). It is straight forward to delete or rename the broken root<\/em> subvol. Snapshot the f36<\/em> subvol (or the root.dl<\/em> snapshot) to try the system-upgrade process again. Here is an example of starting over after booting into the fallback system on subvol f36:<\/p>\n
$ mount | grep subvol\n$ sudo mount \/dev\/mmcblk2p3 \/mnt\/root\n$ cd \/mnt\/root\n$ sudo mv root root.failed\n$ sudo btrfs subvol snapshot f36 root\nCreate a snapshot of 'f36' in '.\/root' Don't forget to edit \/mnt\/root\/root\/etc\/fstab to change the subvol mounted on \"\/\" to \"root\".<\/pre>\n
As it turns out, the new kernel-6.2.11 for f38 did not boot on my Pinebook after the system-upgrade! (Don’t worry, ARM is an alternative CPU architecture for Fedora Linux — this is very unlikely to happen to you on a mainstream device.) I was indeed able to boot back to f36 by editing the GRUB entry for kernel-6.2.10 at boot time as described above. I am now using f38 again — but with kernel-6.2.10 from f36. <\/p>\n
Update<\/strong>: kernel-6.2.12 is out and it works on the Pinebook.<\/em><\/p>\n
Expiration<\/h2>\n
As you update the f38 system, it will eventually want to delete the last f36 kernel from \/boot. That is normally not a problem, as by that time you have settled into f38, and the f36 snapshot is just an archive. If you want to keep your fork (f36 snapshot) bootable indefinitely, you should preserve a working f36 kernel under \/boot. The simplest way to do so is to set installonly_limit=0<\/em> in \/etc\/dnf\/dnf.conf and manually remove old kernels. It is simple and safe (but annoying).<\/p>\n
Outline of a more complex solution (not for beginners): Run find \/boot -name \"*fc36*\"<\/kbd> to list all the kernel and GRUB files for your f36 subvolume snapshot that are under \/boot (which is not in the snapshot). Copy them to a backup location (I would mount the f36 subvolume and copy to a backup directory there). While booted from f38, for each f36 kernel version, use dnf to remove that specific kernel version (for example, dnf remove kernel-core-5.19.11-200.fc36<\/kbd>). Do not remove the f38 kernels! Now restore the f36 kernels you saved to \/boot. The f38 system doesn’t know about f36 kernels anymore, and it will not remove them from \/boot.<\/p>\n
The problem with that method is the danger of accidentally removing the running f38 kernel. If anyone has a better method, let me know in the comments.<\/p>\n
Future directions<\/h2>\n
Those comfortable with modifying GRUB entries might consider creating a snapshot subvolume named f38<\/em>, modifying the current GRUB entry to boot into that, rebooting, and running the system-upgrade in that subvolume. Then always name the subvol for the root filesystem after the Fedora Linux release it contains. I did not do that for this article for two reasons.<\/p>\n
    \n
  1. Naming the current active subvolume root<\/em> matches the Fedora Linux default.<\/li>\n
  2. Sticking with root<\/em> for the current subvol does not require any permanent changes outside of the normal system-upgrade procedure.<\/li>\n<\/ol>\n
    As this article has demonstrated, readonly snapsnots are useful as local restore points in case things go wrong when making significant system changes (such as a system release upgrade). These snapshots can also be sent to a remote backup using Btrfs’ send<\/em> subcommand. (And if the remote backup device already contains previous backups, Btrfs can do an incremental send that only transmits changed files to save time and space.) If you intend to archive these snapshots long term, the key to not getting confused about which ones are which and what order to restore them is to use a consistent naming convention. See the article on Btrfs snapshots for backup<\/a> for more information about using Btrfs’ send<\/em> command to create backups.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Back in 2018, a previous article demonstrated how to use LVM to clone the root filesystem before upgrading Fedora Linux so as to have a fallback in the unlikely event that something goes wrong. Today, the default Fedora Workstation install uses Btrfs. Now you can use a Btrfs snapshot to make creating a bootable fallback […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[48],"tags":[1157,606,45,46,47,1480,1481],"class_list":["post-133662","post","type-post","status-publish","format-standard","hentry","category-fedora-os","tag-btrfs","tag-faqs-and-guides","tag-fedora","tag-magazine","tag-news","tag-snapshot","tag-system-upgrade"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/133662","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=133662"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/133662\/revisions"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=133662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=133662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=133662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}