7 releases

0.2.3 Nov 17, 2020
0.2.2 Nov 11, 2020
0.2.0 Oct 20, 2020
0.1.3 Oct 13, 2020
0.1.2 Sep 22, 2020
Download history 8/week @ 2020-09-09 35/week @ 2020-09-16 16/week @ 2020-09-23 6/week @ 2020-09-30 8/week @ 2020-10-07 27/week @ 2020-10-14 10/week @ 2020-10-21 17/week @ 2020-10-28 10/week @ 2020-11-04 31/week @ 2020-11-11 12/week @ 2020-11-18

57 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 binaries in /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:

  • /boot/efi
  • 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 grubby and ostree.


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 shimx64.efi binary before 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 by e.g. apt/zypper/yum/rpm-ostree update today.

fwupd comes as a UEFI binary today, so bootupd could take care of updating fwupd 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

systemd bootctl can update itself; this project would probably just proxy that if we detect systemd-boot is in use.

Other goals

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 specially. 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 /boot/efi. 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 bootupctl backend.


~186K SLoC