This is a method I’ve used to upgrade Linux machines that aims to minimise issues and downtime. It’s especially handy if, like me, your main computer runs Linux and you don’t like being unable to use it for long periods of time. It does come at a cost of disk space however, since we’re using extra partitions. If that’s an issue for you, then it’s probably better that you use some other option instead.
So firstly, a bit of background: what are A/B partitions? It’s basically the idea of having 2 copies of an operating system on your hard drive and only one is updated at a time, ensuring you always have a working OS to boot into. If you’re using A as the main partition, then the next update is applied to B. When you reboot, it loads B first and if that fails for any reason, it falls back to booting A which is untouched since you last used your device. If B works fine however, the system marks B as the new main partition and A will be used to install the next update into. You can think of it like hiking up a mountain, you only lift your back foot when you’re sure your front foot has a solid grip.
A/B partitions are used by Google to apply ‘seamless’ updates to Android and Chrome OS, although what we’re doing won’t be quite as effortless as Google’s implementation. This is because we’ll need to manually decide what is considered the main partition, which has benefits and drawbacks. For example, we can use this to test out Fedora alongside our main Ubuntu installation, without having to set Fedora as the main OS just because it boots successfully. It does mean we have to manage the partitions ourselves though, which somewhat increases the complexity of the system. In general, I apply any normal updates directly to my main partition, but apply any potentially risky updates to the secondary partition.
Preparing the partitions
Before you start doing anything: make a backup and test it! Your data should probably be safe but messing with partitions is always a risky manoeuvre, don’t tempt fate and just have a backup.
For the purposes of this post, I’m going to assume you have a regular enough partition layout of a boot partition, a single main OS partition and maybe a swap partition. It doesn’t really matter what you have though, just adapt the instructions to your set up and it should work out. The only partition we’ll be working with is that main OS partition so we can ignore the rest.
First, make a live USB from the latest stable Ubuntu release (or another distro of your choice). Boot into it and use the disk manager to shrink your main OS partition. Ideally shrink it by half, but if you don’t have that much space, make it as small as you can while still having enough space to comfortably run the OS in.
Next, create a new partition to fill up all the free space you’ve just created. Choose ext4 as the filesystem and
/ as the mount point if asked. You can name this partition ‘B’ and the shrunken main OS partition ‘A’ to keep track of which is which.
You should now have the partition layout set up with an A partition that contains your main OS, and a B partition that’s ready to install an OS into.
Applying A/B style updates
Given the high frequency of Linux updates, as well as the slight hassle involved in switching the chosen main partition, I usually just apply normal updates directly to the current main partition. I’ve never been burned by this so I figure it’s a safe enough option.
For riskier updates, I do use the A/B partitions to ensure I always have a fallback option. There are 2 different strategies I use to handle these updates and I’ll go through them both:
Clone and Update: For whatever reason, you’ve decided a new update could be risky. It could be using a new kernel, or switching a core piece of the OS, but the specifics don’t really matter. What I’d do is clone the main partition (e.g. A) into the other partition (e.g. B) before applying any updates. Then, boot into the B partition and install the update. If the update works, set B as the main partition and off you go. If it fails, keep using A as the main partition and no damage was done. This type of approach is probably more useful if you use a rolling release distro such as Arch or Solus.
Install and Upgrade: Upgrading from an old version of a distro to a newer version can often cause problems that are tricky to solve. While you could just upgrade directly (from the cloned partition of course), it’s usually safest to do a fresh install. This is easy with the A/B partitions as you can install the new OS into the secondary partition, leaving the main partition intact. You can then migrate at your own pace to the new OS and mark the updated partition as the main one whenever you’re ready. I mostly use standard release distros so this is my favoured approach.
Specifying the grub loader: If the default grub loader being used isn’t the one you’d like, you can manually set which one to use instead. Boot into the OS that contains your chosen grub loader and run
sudo grub-install /dev/sda, replacing
/dev/sdawith the default boot device set in the BIOS. You’ll probably want to run
sudo update-grubafterwards to help it detect any other operating systems that are also installed.
Customising the grub loader: If you want to further customise your grub loader, Grub Customizer is a useful GUI program. It supports reordering, renaming and removing boot options, changing the grub colour-scheme and many other features. If you want to do something with your grub that’s not a simple terminal command, this is probably the right tool for the job.
Testing backups: If you’re using the ‘Install and Upgrade’ option described above, it provides a perfect opportunity to test your backup restoration strategy. You should be able to restore everything you want in your new OS without having to mount the other partition. If this isn’t the case, then it’s a good thing you found it out this way and not in a real failure scenario instead.
That’s pretty much all you need to know about using A/B partitions with Linux. Best of luck with it and happy updating!