> 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.

> 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 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?