Products › LamBoot
v0.16.5 · Native ext4, btrfs, FAT, XFS, exFAT, and ZFSLamBoot
A memory-safe UEFI bootloader for Linux, built in Rust from the ground up.
It reads your real /boot natively, across the filesystems Linux actually uses, 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 · pacman.lamco.ai · Fedora / openSUSE / RHEL (OBS) · GitHub
See it
The boot menu
A bootloader you can read, and one that records what it did
LamBoot is a memory-safe Linux bootloader: a UEFI boot manager 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, FAT, XFS, exFAT, and ZFS on its own, including XFS 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 21,200 lines of Rust across 62 modules, around 1.05 MB on disk. When a boot goes wrong, you can read why.
Five things the bootloaders shipping today do not do
It reads your real /boot, natively, across the filesystems Linux uses.
ext4, btrfs, FAT, XFS, exFAT, and ZFS, read in place by memory-safe Rust compiled into the loader, with XFS also read on an LVM logical volume. 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 this set natively from a memory-safe bootloader is LamBoot alone. XFS unblocks the RHEL family, ZFS covers the Ubuntu and Debian root-on-ZFS boot pool, and exFAT covers removable media larger than 4 GiB.
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.
It can boot a distribution straight from an .iso (opt-in).
Turn it on, point LamBoot at an .iso on a mounted volume, or at an inserted disc, and it boots the distribution directly, with no write to a USB stick first. It reads the distribution's own loopback configuration when present and falls back to a per-family recipe table otherwise. This is experimental and off by default. Arch 2026.05 and Fedora 44 are validated end to end so far.
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 (aarch64 is a build target from source; no aarch64 binary release yet). 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. Booting straight from an .iso, from disk or from an optical drive, is available as an opt-in feature you turn on in policy. The new XFS, exFAT, ZFS, and media-filesystem readers only read, the same way the ext4 and btrfs readers do, so they cannot modify the volumes they mount. 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 21,200 lines of Rust across eight clean layers. Install paths from homelab Secure Boot off to Proxmox zero-touch.
Pair LamBoot with lamboot-tools
lamboot-tools
The Linux UEFI boot toolkit: diagnose, repair, and migrate UEFI boot on any UEFI Linux system, for any bootloader. Structured JSON output with a remediation command on every finding, plus a Proxmox VE companion. LamBoot is its reference target, and the tools work on any bootloader.