> Let’s first take a look at what the bootloader actually does. It manages 3 slots for operating system images, with each having around 500 KB reserved for it. Additionally, 2 redundant metadata structs are stored on different flash pages. During an update, one slot is overwritten, and then metadata is adjusted. We are resilient against power failures at any point, and as long as at least one image slot contains an operating system image, we can boot. [...]

> In our bootloader we can now enable a custom boot mode that ensures that if at least one image is bootable, it is booted, which will enable us to fix this problem remotely

"OneFileLinux: A 20MB Alpine metadistro that fits into the ESP" https://news.ycombinator.com/item?id=40915199 :

- eaut/efistub generates signed boot images containing kernels and initrd ramdisks in one file to ensure the verification of the entire initial boot process.

Are there already ways to fail to the next kernel+initrd for uboot, [ventoy, yumi, rufus], grub, systemd-boot, or efistub?

For EFI you could probably set BootNext to something else early on, in combination with some restarting watchdog. GRUB can store state between boots https://www.gnu.org/software/grub/manual/grub/html_node/Envi... and has "default" and "fallback" vars.

So the bootloader would always advance nextboot= to the next boot entry, and a process after a successful boot must update nextboot=$thisbootentry?

Is there another way with fewer write() calls?

Interesting.

Are there better MCUs on the market for these applications (other than massively expensive actual 'rad-hardened' space chips)? You can get MCUs with lockstep dual CPUs, for example (TMS570 etc., and I assume the automotive sector has loads of stuff).