|0.2.9||Jan 20, 2023|
|0.2.6||Sep 8, 2021|
|0.2.5||Jan 6, 2021|
|0.2.4||Dec 15, 2020|
|0.1.2||Sep 22, 2020|
#83 in Operating systems
31 downloads per month
bootupd: Distribution-independent updates for bootloaders
Today many Linux systems handle updates for bootloader data
in an inconsistent and ad-hoc way. For example, on
Fedora and Debian, a package manager update will update UEFI
/boot/efi, but not the BIOS MBR data.
Transactional/"image" update systems like OSTree and dual-partition systems like the Container Linux update system are more consistent: they normally cover kernel/userspace but not anything related to bootloaders.
The reason for this is straightforward: performing bootloader
updates in an "A/B" fashion requires completely separate nontrivial
logic from managing the kernel and root filesystem. Today OSTree e.g.
makes the choice that it does not update
/boot/efi (and also doesn't
update the BIOS MBR).
The goal of this project is to be a cross-distribution, OS update system agnostic tool to manage updates for things like:
- x86 BIOS MBR
- Other architecture bootloaders
This project originated in this Fedora CoreOS github issue.
The scope is otherwise limited; for example, bootupd will not
manage anything related to the kernel such as kernel arguments;
that's for tools like
Currently a work in progress and is not ready to ship for production updates, but early feedback on the design is appreciated!
Relationship to other projects
dbxtool manages updates
to the Secure Boot database -
bootupd will likely need to
perform any updates to the
dbxtool.service starts. But otherwise they are independent.
bootupd could be compared to fwupd which is
a project that exists today to update hardware device firmware - things not managed
apt/zypper/yum/rpm-ostree update today.
fwupd comes as a UEFI binary today, so bootupd could take care of updating
but today fwupd handles that itself. So it's likely that bootupd would only take
care of GRUB and shim. See discussion in this issue.
systemd bootctl can update itself; this project would probably just proxy that if we detect systemd-boot is in use.
One idea is that bootupd could help support redundant bootable disks.
For various reasons it doesn't really work to try to use RAID1 for an entire disk; the ESP must be handled
bootupd could learn how to synchronize multiple EFI system partitions from a primary.
More details on rationale and integration
A notable problem today for rpm-ostree based
systems is that
rpm -q shim-x64 is misleading because it's not actually
updated in place.
Particularly this commit makes things clear - the data
from the RPM goes into
/usr (part of the OSTree), so it doesn't touch
But that commit didn't change how the RPM database works (and more generally it
would be technically complex for rpm-ostree to change how the RPM database works today).
What we ultimately want is that
rpm -q shim-x64 returns "not installed" - because
it's not managed by RPM or by ostree. Instead one would purely use
bootupctl to manage it.
However, it might still be built as an RPM, just not installed that way. The RPM version numbers would be used
for the bootupd version associated with the payload, and ultimately we'd teach
rpm-ostree compose tree
how to separately download bootloaders and pass them to
Questions and answers
- Why is bootupd not part of ostree?
A key advertised feature of ostree is that updates are truly transactional. There's even a a test case that validates forcibly pulling the power during OS updates. A simple way to look at this is that on an ostree-based system there is no need to have a "please don't power off your computer" screen. This in turn helps administrators to confidently enable automatic updates.
Doing that for the bootloader (i.e. bootupd's domain) is an entirely separate problem. There have been some ideas around how we could make the bootloaders use an A/B type scheme (or at least be more resilient), and perhaps in the future bootupd will use some of those.
These updates hence carry different levels of risk. In many cases actually it's OK if the bootloader lags behind; we don't need to update every time.
But out of conservatism currently today for e.g. Fedora CoreOS, bootupd is disabled by default. On the other hand, if your OS update mechanism isn't transactional, then you may want to enable bootupd by default.
- Why is bootupd a daemon?
It's not, really. The name was intended to be "bootloader-upDater" not "bootloader-updater-Daemon"; the choice of a "d" suffix is in retrospect probably too confusing.
At a technical level, yes there is a socket-activated systemd service
which will spawn a
bootupd.service. However - the service will
very quickly auto exit. There's nothing long-running, so it's
not really a daemon.
The rationale behind this design is:
- Using a systemd service provides a robust natural "locking" mechanism.
- Using a systemd service ensures that critical logging metadata always consistently ends up in the systemd journal, not e.g. a transient client SSH connection.
- systemd services can easily have sandboxing applied, and while bootupd is obviously privileged we can still make use of some of this.
- Ultimately, we do probably want a non-CLI API (whether that's DBus or Cap'n Proto or varlink or something else). Having a socket (without a defined stable API) is preparatory work for that.