https://github.com/coreos/bootupd

Bootloader updater
https://github.com/coreos/bootupd

bootloaders ostree

Last synced: 26 days ago
JSON representation

Bootloader updater

• Host: GitHub
• URL: https://github.com/coreos/bootupd
• Owner: coreos
• License: apache-2.0
• Created: 2020-06-20T15:28:33.000Z (over 4 years ago)
• Default Branch: main
• Last Pushed: 2024-04-12T02:33:08.000Z (8 months ago)
• Last Synced: 2024-04-12T09:57:08.079Z (8 months ago)
• Topics: bootloaders, ostree
• Language: Rust
• Homepage:
• Size: 872 KB
• Stars: 86
• Watchers: 13
• Forks: 21
• Open Issues: 24
• Metadata Files:
  • Readme: README-design.md
  • License: LICENSE
  • Code of conduct: code-of-conduct.md

Awesome Lists containing this project

• awesome_atomic - bootupd - Distribution-independent updates for bootloaders. (Lower level tools)
• awesome-starred - coreos/bootupd - Bootloader updater (others)

README

        
# Overall design

The initial focus here is updating the [ESP](https://en.wikipedia.org/wiki/EFI_system_partition), but the overall design of bootupd contains a lot of abstraction to support different "components".

## Ideal case

In the ideal case, an OS builder uses `bootupd install` to install all bootloader data,

and thereafter it is fully (exclusively) managed by bootupd.  It would e.g. be a bug/error

for an administrator to manually invoke `grub2-install` e.g. again.

In other words, an end user system would simply invoke `bootupd update` as desired.

However, we're not in that ideal case.  Thus bootupd has the concept of "adoption" where

we start tracking the installed state as we find it.

## Handling adoption

For Fedora CoreOS, currently the `EFI/fedora/grub.cfg` file is created outside of the ostree inside `create_disk.sh`.  So we aren't including any updates for it in the OSTree.

This type of problem is exactly what bootupd should be solving.

However, we need to be very cautious in handling this because we basically can't

assume we own all of the state.  We shouldn't touch any files that we

don't know about.

## Upgrade edges

We don't necessarily want to update the bootloader data, even if a new update happens to be provided.

For example, Fedora does "mass rebuilds" usually once a release, but it's not strictly necessary

to update users' bootloaders then.

A common policy in fact might be "only update bootloader for security issue or if it's strictly necessary".

A "strictly necessary" upgrade would be one like the GRUB BLS parsing support.

There is not yet any support for upgrade edges in the code apart from a stub structure.