A/B Updates and Provisioning

Like Android, HalogenOS uses A/B updates to ensure the system remains bootable if an update fails, is interrupted, or if a partition is tampered with.

Updates

Here's how an update works in HalogenOS:

The system notices a new update is available on the server.
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.
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 any volatile files on the root partition.
The stored release files are validated again and used to update the newly inactive slot.

Installation

Since the system only needs one working slot to operate, then installation can be completed by merely flashing a single system partition and verity image, and dropping the appropriate files into the boot partition. The newly booted system will automatically create the second system partition, the root partition with its encryption key, and secure boot keys with which it will sign all the boot EFI binaries. Any files that must reside in /etc can either be copied from, or linked to, /usr/etc on boot. As such, to reset the system, it is sufficient to destroy the encryption header for the root partition, then reboot. Automatic provisioning will restore the system layout on reboot.

Failure Recovery

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.