LamBoot does several 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.16.5.
Native, memory-safe reading of your real /boot, across the filesystems Linux uses
ext4, btrfs, FAT, XFS, exFAT, and ZFS, read in place
LamBoot reads ext4, btrfs, FAT, XFS, exFAT, and ZFS itself, in memory-safe Rust compiled into the loader. XFS is read on a whole partition and on an LVM logical volume, which is the default RHEL root layout. ZFS is read from an unencrypted boot pool, the Ubuntu and Debian root-on-ZFS pattern, covering single-disk, mirror, and single-parity RAIDZ1 pools and decoding all six OpenZFS compressors. exFAT covers removable boot media larger than 4 GiB. 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. As of v0.16.1 the loader reads the kernel's PE header itself with no third-party parser, and when it meets a Linux EFI-stub kernel it cannot load natively it hands off to firmware LoadImage, so the kernel always loads while the parsing LamBoot does itself stays memory-safe Rust you can audit. Loading the kernel itself also structurally removes a shim 15.8 failure mode that breaks ext4 /boot under Secure Boot.
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.
It can boot a distribution directly from an .iso
Opt-in. From an .iso on disk, or from an optical disc
With the [boot-from-iso] feature enabled in policy, LamBoot boots a Linux distribution straight from an .iso file on any volume it can read (ext4, btrfs, XFS, FAT, including the ESP), and with optical turned on, from an inserted CD, DVD, or Blu-ray. It reads the kernel and initrd off the mounted ISO and hands them off through the same measure, verify, and initrd-register path as a normal Linux boot. It reuses the distribution's own loopback.cfg when the ISO carries one, so the booted system finds its ISO with no per-distribution knowledge, and falls back to a maintained per-family recipe table when it does not. Because a distribution kernel is a Linux EFI-stub PE, the ISO path hands off to firmware LoadImage when the native loader cannot load it. This is experimental and opt-in. Arch 2026.05 and Fedora 44 are validated end to end in this release, and the other distribution families are recipe-validated and host-tested.
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 21,200 lines of Rust across 62 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.
A native media-filesystem stack
LamBoot also mounts six read-only media filesystems natively, EROFS, ISO 9660, SquashFS, cramfs, romfs, and UDF, so an EROFS or SquashFS root or /boot, and live and immutable media images, are mounted as ordinary read-only volumes and scanned for kernels. EROFS reads uncompressed, LZ4, and the compressed-compact codecs (deflate, zstd, and MicroLZMA). SquashFS reads gzip, xz, zstd, lz4, and lzo. ISO 9660 reads zisofs. These media mounts read only and do not yet verify media content; verified media is a later pass.