Products › LamBoot
v0.15.2 · Native ext4, btrfs, and FAT, even on LVMLamBoot
A memory-safe UEFI bootloader for Linux, built in Rust from the ground up.
It reads your real /boot natively, records every trust decision it makes, and recovers itself when a boot goes bad. Standards native, compiled small, auditable by design.
#![no_std]
|
MIT OR Apache-2.0
Available on apt.lamco.ai · AUR · Fedora / openSUSE / RHEL (OBS) · GitHub
A bootloader you can read, and one that records what it did
LamBoot is a memory-safe UEFI bootloader written in Rust. It speaks the same Boot Loader Specification language as systemd-boot and runs Linux through LoadFile2 the way a modern loader should, and it adds things the bootloaders shipping today do not. It reads ext4, btrfs, and FAT on its own, including on LVM, so the kernel load path does not depend on firmware filesystem drivers. It writes a structured trust-evidence record to the EFI System Partition on every boot, documenting each image-authentication decision it made. It has a graphical menu with a working mouse, a crash-loop recovery state machine kept in NVRAM, and pre-boot diagnostic modules. About 16,000 lines of Rust across 46 modules, around 650 KB on disk. When a boot goes wrong, you can read why.
Four things the bootloaders shipping today do not do
It reads your real /boot, natively.
ext4, btrfs, and FAT, including on LVM, read in place by memory-safe Rust compiled into the loader. systemd-boot reads FAT only. Limine dropped ext4 on purpose. GRUB reads them, but inside a large C codebase. rEFInd reads them only through separate, non memory-safe driver binaries. Reading ext4 and btrfs natively from a memory-safe bootloader is LamBoot alone.
It records what it did.
Every boot, LamBoot writes a trust-evidence log to the ESP: what it verified, how it verified it, and the SHA-256 of the image that actually ran. You read it from Linux after boot. No mainstream bootloader writes a per-image authentication record like this.
It loads the kernel itself.
LamBoot verifies and loads the kernel with its own PE loader instead of handing off to firmware LoadImage, which 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 counts boots, and at a threshold it selects a fallback entry automatically. It is compatible with systemd-bless-boot, so it cooperates with the wider boot-assessment ecosystem rather than fighting it.
Modern Linux boot, done right
BLS Type 1 entries with UAPI version sort and boot counting. Unified Kernel Images as first-class menu entries. LoadFile2 initrd handoff. A kernel-install plugin plus distro postinst hooks, so a kernel upgrade regenerates entries on its own. No GRUB scripting language to learn or break.
Who LamBoot is built for
Homelab Linux users
Whose GRUB config breaks on kernel upgrades, and who want a real graphical menu.
Security-conscious desktop users
Who want to audit what verified what, with a record they can read after every boot.
Rust and systems people
Who want to read a small, layered, no_std bootloader instead of forty thousand lines of C.
Running Linux in VMs, especially on Proxmox? LamBoot adds a fleet and host-monitoring layer on top of all of this. See LamBoot in Proxmox →
Scope, requirements, and where the boot path ends
LamBoot runs on UEFI firmware, on x86_64 and aarch64. For Secure Boot today you enroll its signing key once through MOK, and the shim-review submission that removes even that one-time step is on the roadmap. The trust-evidence log is a record you can read and verify, written fresh on every boot. The point where the boot path ends and the kernel takes over is documented on the Security page.
Install today. Read the code on the way to bed.
MIT OR Apache-2.0 dual license. About 16,000 lines of Rust across eight clean layers. Install paths from homelab Secure Boot off to Proxmox zero-touch.