HalogenOS/image-builder
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update A/B Updates and Provisioning

River 2025-04-27 18:50:17 -04:00
parent 4ced872305
commit 74c5da844c
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
A%2FB-Updates-and-Provisioning.md

@ -10,7 +10,7 @@ Here's how an update works in HalogenOS:
- The latest release files are downloaded to a persistent temporary directory.
- Each release file is validated using the release key burned into the system partition.
- The inactive slot is located, and the system partition and verity images are burned.
- A kernel EFI binary pointing to the inactive slot is deployed in the boot partition.
- If the kernel needs to be updated, a new UKI will be installed in the boot partition.
- The new kernel binary is signed using the locally generated secure boot keys.
- The user is prompted to reboot as soon as possible, or a reboot is triggered automatically.
- The new system partition updates the bootloader, and other files on the root partition.
@ -22,6 +22,4 @@ Since the system only needs one working slot to operate, then installation can b
## Failure Recovery
When a kernel EFI binary is installed in the boot partition, a counter is appended to its file name. Every time the bootloader loads this kernel, it decrements the counter. Once the system is fully booted and known to work, it re-increments this counter. If the counter for a given kernel ever reaches zero, the bootloader will switch over to the other kernel. From there, a valid system is available, which will automatically repair the broken slot.
To avoid nullifying the benefits of this scheme, the initial bootloader that handles the A/B logic will be updated infrequently, tested heavily, and written purely in Rust to avoid memory-related failures. The old bootloader can also be maintained on the boot partition as a backup, available to load the OS proper if the user chooses its boot entry.
The two system partitions will have labels attached to them, indicating whether they are the A or B partitions. They will also be suffixed by a counter, which will be initialized to 3 every time a system image is installed to the partition. When the kernel attempts to boot from that partition, it decrements the counter, and re-increments it if it reaches a fully booted state. The kernel will refuse to boot a partition whose boot count has reached 0, and will instead boot the other partition, which will detect the problem and attempt a repair.