Will LamBoot replace GRUB on my current Ubuntu install?
No — LamBoot is added as a separate UEFI boot entry alongside GRUB. You can choose which to boot from the firmware boot menu (usually F12 / F11 / Esc at POST). lamboot-install never touches GRUB.
Does LamBoot work with Secure Boot?
Yes — four different configurations. The simplest for Linux desktops is shim + MOK enrollment via lamboot-install --signed. The simplest for Proxmox VM fleets is the pre-enrolled OVMF_VARS_lamboot.fd template. See the security page for all four configurations.
Is it shim-review approved?
Not yet. v1.0 target. Today, LamBoot ships with self-signed db certs that users enroll via MOK (standard Linux practice) or via pre-populated OVMF VARS (Proxmox Config 4). When shim-review approves us, no user action is required — existing distro shim will chain-trust.
What’s this “trust-evidence log” I keep hearing about?
\loader\boot-trust.log on the EFI System Partition — a JSON-lines file listing every image-authentication decision LamBoot made during the current boot. No other mainstream bootloader ships this. It makes Secure Boot auditable rather than just claimed. See the security page for the schema.
Why not just use systemd-boot?
systemd-boot is an excellent bootloader. If you already run it and love it, stay. LamBoot is what you want if you also want: a memory-safe language, a GUI, an audit log, a Proxmox host-side monitoring story, and a maintainer who writes honest threat models. See the comparison page.
Can I use LamBoot on non-UEFI (legacy BIOS) systems?
No. Modern UEFI firmware (x86_64 or aarch64) only.
Does it support Btrfs snapshots / ZFS boot environments?
LamBoot can load kernels from ext4 / btrfs / ZFS / xfs / ntfs / f2fs / iso9660 via the bundled EFI filesystem drivers. It does not present a Btrfs-snapshot-aware menu like grub-btrfs. A Btrfs-snapshot-aware discovery plugin is on the community wish list.
Is it production-ready?
Yes for homelabs and controlled VM fleets. For enterprise-scale deployment with formal support SLAs, the commercial-support conversation hasn’t started yet. The code has been running on developer machines and Proxmox VMs for months; v0.8.3 is the first release aimed at a broader audience.
What’s the license?
MIT OR Apache-2.0 (same dual license as most Rust ecosystem projects). Filesystem drivers shipped in dist/EFI/LamBoot/drivers/ are GPL-2.0 from the rEFInd project and distributed as separate binaries per GPL linking exception.
Can I contribute?
Yes — see CONTRIBUTING.md and docs/DEVELOPER-GUIDE.md in the repo. Good first issues: new filesystem driver packaging, distro-specific install script polish, diagnostic modules (memory tests, NVMe SMART, PCI enumeration).
Who’s behind it?
Lamco Development — a small vendor-neutral shop working on Linux tooling. LamBoot is one of several projects; others include a Wayland-native RDP stack.
How do I report a security issue?
See SECURITY.md in the repo — responsible disclosure via security@lamco.io with GPG key. Please do not file public issues for vulnerabilities.
Is Rust suitable for firmware?
Yes. The Linux kernel merged Rust for drivers. Windows is writing firmware in Rust. uefi-rs is mature and LamBoot exercises it in production-like scenarios. Every unsafe block in LamBoot carries a SAFETY: comment.