LamBoot does four things the bootloaders shipping today do not, and it does the standard things cleanly. Here is what is actually different, all verified in the source at v0.15.2.
Native, memory-safe reading of your real /boot
ext4, btrfs, and FAT, including on LVM, read in place
LamBoot reads ext4, btrfs, and FAT itself, in memory-safe Rust compiled into the loader, including those filesystems on LVM (btrfs on LVM and FAT on LVM). A separate /boot is read in place, with no copy of your kernels onto the ESP. By contrast: systemd-boot reads FAT only and relies on the firmware for anything else; Limine removed ext4 support in version 9.0; GRUB reads them inside a large C codebase; rEFInd reads them only by loading separate driver binaries that are not memory safe. The code that reads your /boot under Secure Boot is Rust you can audit.
A trust-evidence log, written every boot, to the ESP
What it verified, how, and the SHA-256 that actually ran
On every boot LamBoot writes \loader\boot-trust.log to the EFI System Partition, one JSON object per line. Each record names the event (boot_start, driver_loaded, driver_rejected, boot_attempt, legacy_loadimage_used), the image path, how it was verified (verified_via: firmware_db, shim_mok, shim_vendor, security_override, sb_disabled, or rejected), the UEFI status, and the SHA-256 of the image. The image LamBoot verified and the image it loaded carry the same SHA-256, checked in code.
cat /boot/efi/loader/boot-trust.log | jq .
It is a record you can verify, not a cryptographic seal: it is advisory, written to a writable ESP. The full field and value vocabulary is on the Security page.
LamBoot loads the kernel itself
Its own PE loader instead of firmware LoadImage
Instead of handing the kernel to firmware LoadImage, LamBoot verifies and loads it with its own PE loader. This structurally removes a shim 15.8 failure mode that breaks ext4 /boot under Secure Boot, because the kernel path never depends on the firmware LoadImage behavior.
It recovers from a bad boot
An NVRAM crash-loop state machine that picks a fallback
LamBoot keeps a small state machine in NVRAM (LamBootState: Fresh, Booting, BootedOK, CrashLoop), counts boots, and at the crash threshold selects a fallback entry automatically. It is compatible with systemd-bless-boot, so it cooperates with the wider boot-assessment ecosystem.
Standards, done cleanly
BLS Type 1 with UAPI version sort and boot counting. Unified Kernel Images as first-class entries. LoadFile2 initrd handoff. A kernel-install plugin plus distro postinst hooks. A graphical menu with a working mouse over a double-buffered GOP renderer, and a serial console fallback for headless and serial-over-LAN.
Memory-safe Rust, and a structure you can read
About 16,000 lines of Rust across 46 modules, #![no_std], organized into eight layers with one-way dependencies. If you want the depth, the Architecture page walks the layers and the ten-phase boot flow.