You are not logged in.
Project homepage | AUR package | Installation instructions | Man page | System installation guide
Motivation
Recall that on UEFI systems, you can use Unified Kernel Images to bundle the kernel, initramfs and kernel parameters together into a single image. This is good for robustness, because it's hard to mess up a single file, and also because the image can boot by itself without the need for a bootloader. In addition, it's convenient for signing for Secure Boot, because the image can be signed as a single unit.
Problem
It would be nice if you could simply make backups of these images and boot them in case something goes wrong. Unfortunately, that doesn't work, because on Arch Linux upgrading the kernel removes the modules for the previous kernel, so these old kernels will not boot.
To make this work, you also need to take btrfs snapshots of the system. However now things become tricky. The EFI images need to be kept in sync with the collection of snapshots, so that each EFI image boots into a compatible snapshot. And as snapshots are created and destroyed, the images that boot into them need to be created and destroyed too. Furthermore, thorny questions arise as to how to handle multiple kernels, when to make snapshots, and what to do if you try to update the system while running a backed-up version of it.
The solution
Bootmap solves all these problems. The result is a robust system restore mechanism that lets you boot any of a number of old EFI images (even if your bootloader is busted - you can still do this from the UEFI menu), and have them seamlessly boot up into an old copy of the system made just before the kernel was updated. With some other tweaks to your configuration, you can even guarantee that your system will be fine after an accidental rm -rf / --no-preserve-root. (Yes, I have checked this. No, not on my actual system - in a VM!). As with any system snapshotter, it also lets you get out of other configurational mishaps, like a non-booting kernel, a broken sudoers file, or any other one of the innumerable ways to accidentally screw up with Arch Linux. (Come on, we've all been there.)
I hope bootmap can be useful to you, and help make your system more robust. You should never need a system recovery medium again; system recovery can always be done from an old copy of the system itself.
More information
Check out the links above! You can find more information and rationale on the project homepage, or try it out yourself using the AUR package.
All questions, feedback and suggestions are welcome.
Thanks also to Head_on_a_Stick for answering some of my forum questions regarding some details about remounting needed to make this work.
Last edited by PBS (2022-01-15 03:38:54)
Offline
Version 0.9.2 is now out. It features a number of small refinements I made after using it to set up a new Arch Linux installation in a VM. This revealed a number of assumptions I had made that were not valid on all configurations, and they have now been fixed. It's also worth using for a small number of bug fixes that stress-testing revealed, as well as improvements to the defaults.
This release, I also added an Arch Linux system installation guide showing how bootmap fits into your boot process, which should hopefully make it clearer exactly what it does. Feedback from the experienced forum members regarding this guide, the C++20 codebase, and the supporting bash scripts/pacman hooks is always appreciated.
After this point, I anticipate bootmap will settle down, with no more significant changes or bugfixes. That does not mean it is unmaintained - I will be using it on my systems for the foreseeable future. If anything goes wrong, I'll be the first to know about it, and will issue a prompt fix.
Offline
Phew! Bootmap just saved my ass for the first time in real life!
Just installed kernel 5.16.9, rebooted, and now boot hangs at the BIOS logo. Previously this would have been a major pain to sort out, and would have at the very least required me to get out of bed. Instead I just restarted, mashed Esc to enter setup, hit F9 for boot options, entered admin password, picked 5.16.7.efi, and now I'm in a working backup system.
IMAGE SUBVOLUME USED AS
linux-zen-5.16.9 [nextboot] → /root Current
linux-zen-5.16.7 [running] → /bootmap/root-backup-1 [running] Backup 1
linux-zen-5.16.0 → /bootmap/root-backup-2 Backup 2Then I mounted the broken system, arch-chrooted, and ran pacman -U /var/cache/pacman/pkg/linux-zen-5.16.7.zen1-1-x86_64.pkg.tar.zst to downgrade the kernel.
IMAGE SUBVOLUME USED AS
linux-zen-5.16.7-2 [nextboot] → /root [running] Current
linux-zen-5.16.7 [running] → /bootmap/root-backup-1 Backup 1
linux-zen-5.16.0 → /bootmap/root-backup-2 Backup 2Reboot and it's working again, all in about two minutes.
IMAGE SUBVOLUME USED AS
linux-zen-5.16.7-2 [running] → /root [running] Current
linux-zen-5.16.7 → /bootmap/root-backup-1 Backup 1
linux-zen-5.16.0 → /bootmap/root-backup-2 Backup 2For the record, and by contrast, my previous two arch linux screwups were both my fault:
Uninstalling systemd-sysvcompat. I thought it was only for sysv compatibility; I didn't realise it was init. Fortunately I had a live usb around.
Downgrading the kernel to fix an intel vulkan driver regression past the point where zstd support was added. On next boot, it couldn't read the initramfs. This time I wasn't so lucky, and didn't have a live usb or access to a computer that could make one. I had to buy a special adapter (ripoff) and make one with my phone >:(
Offline
Hey, @PBS! Thank you for bootmap, it's realy cool tool.
Can you make it for support sbctl instead sbsign?
Offline
It was always the intent that the user could adapt bootmap to any setup by overriding its scripts. For sbctl support, it can be done by copying generate.sh from /usr/lib/bootmap to /etc/bootmap.d (just like for systemd) and slightly editing it to
That said, sbctl is probably common enough to want to support upstream too. Annoyingly there's no support for it in systemd's ukify, which only supports sbsign and pesign.
Offline