LamBoot v0.16.5

LamBoot v0.16.5

Product page · Install · Documentation · by Lamco Development LLC

First public release since v0.15.2. This release brings the public tree current
with development versions v0.16.0 through v0.16.5; the per-version changes below
are reproduced verbatim from the project CHANGELOG. The release is GPG-signed
(see "Verifying this release" at the end).

---

[0.16.5] — Dependency pins: lamfat 0.4.2 + lamzfs 0.1.1

A dependency-sourcing patch with no change to boot behavior. The native FAT and
ZFS readers move to freshly republished crate versions.

Changed

• FatRo now consumes lamfat =0.4.2 — a republish of the read-only
  FAT reader without the fscommon dependency. Read behavior is byte-for-byte
  identical; this trims a transitive dependency from the FAT-backend layer.
• lamzfs pinned to =0.1.1, which moves its LZ4 block decompressor from
  lz4_flex 0.11 to 0.13. The ZFS boot-pool reader decodes the same blocks;
  this is a dependency refresh with no behavior change.

Infrastructure

• SBAT version string aligned to 0.16.5 (generation column unchanged at 1:
  human-facing string only, no revocation).

[0.16.4] — Kernel-upgrade BLS entries fixed on XFS /boot (kernel hook)

A kernel upgrade on an XFS /boot (RHEL/Rocky/Alma/CentOS — surfaced by a RHEL
9.7 → 9.8 upgrade) produced an unbootable, red-X BLS entry for the new
kernel: lamboot-kernel-hook (the incremental writer invoked by
kernel-install / the Debian kernel hooks) had two bugs that only bit XFS and
kernel-install-driven distros. The bootloader binary is unchanged; this is a
host-side tooling fix.

Fixed

• lamboot-kernel-hook now writes XFS /boot entries in place, not on the
  ESP. Its resolve_bls_dir placement set was vfat|ext2|ext3|ext4|btrfs —
  missing xfs, so it never picked up lamboot-install's v0.16.0 "xfs →
  boot_in_place" change and wrote the new kernel's entry to the ESP instead of
  the XFS /boot.
• The linux path now references the /boot kernel copy, not kernel-install's
  source image. On Fedora/RHEL/CentOS, kernel-install add passes
  /lib/modules/<version>/vmlinuz (the package staging path); the hook copied
  that into the BLS linux field (mangled to //lib/modules/...) instead of the
  bootable /boot/vmlinuz-<version> copy → LamBoot couldn't find the kernel
  (preflight red X). It now prefers a /boot-located image, else
  /boot/vmlinuz-<version>; bls_path is hardened against the // double-slash.
• Placement parity is now build-enforced. tools/check-fs-coverage-parity.py
  additionally asserts the hook's in-place set equals
  is_filesystem_natively_covered minus zfs (the lamzfs read-in-place deferral).
  The hook can no longer silently drift from the installer — the exact regression
  class behind this fix. (zfs stays ESP-placed in both, by design.)

[0.16.3] — Robust partition discovery (MBR) + bootloader NVRAM self-install

Robustness work surfaced by the first RHEL-family validation (RHEL 9.7, a BIOS
install converted to UEFI). LamBoot now discovers and boots a Linux install whose
/boot is a plain filesystem on a legacy-MBR disk — the canonical layout of
a BIOS-installed RHEL/Rocky/Alma/CentOS — and manages its own persistent UEFI
boot entry directly from the firmware environment.

Added

• Bootloader-side NVRAM self-install of the LamBoot boot entry. LamBoot now
  ensures a labeled Boot#### entry pointing at \EFI\LamBoot\lambootx64.efi
  exists, creating it (and front-loading BootOrder) from the UEFI environment
  if absent. This is the OS-independent pathway for the persistent entry: no
  efibootmgr, no OS, and on SELinux-enforcing distros no confined-service block
  in the way (Boot####/BootOrder are non-authenticated, so no Secure Boot
  keys are involved). Idempotent — it keys on the exact LamBoot description, so
  it never duplicates or churns NVRAM and coexists with the OS-side efibootmgr
  pathway. New module boot_entry (UEFI I/O) over boot_entry_pure (the
  byte-exact EFI_LOAD_OPTION/BootOrder codecs, host-tested).
• [boot-entry] self_install policy gate (default on; set false to
  opt out for operators who manage firmware boot order externally).

Fixed

• Partition discovery now covers MBR and BlockIO-only partitions, not just
  GPT. scan_discoverable_partitions previously consumed only GPT entries from
  the PartitionInfo protocol, so a BIOS-installed disk with an msdos table
  (e.g. RHEL's XFS /boot as a primary partition) yielded zero discovered
  partitions and its /boot was never mounted — LamBoot showed no entries and
  fell into the fallback self-loop. It is now a three-source enumerator,
  de-duplicated by handle: GPT via PartitionInfo, MBR via
  PartitionInfo.mbr_partition_record() (classified by a host-tested os_type
  predicate), and BlockIO-only logical partitions for firmware that installs
  PartitionInfo on the ESP alone. Every native FS backend (lamxfs/ext4/btrfs/
  exfat/zfs/LVM/media) picks them up unchanged.
• The fallback self-loop guard now actually fires. The old guard compared the
  on-disk \EFI\BOOT\BOOTX64.EFI against the in-memory, firmware-relocated
  running image — hashes that never match — so a no-entries boot would offer and
  auto-select the fallback, chainloading LamBoot into itself. Replaced with a
  reliable path check: if LamBoot was launched from the removable fallback path,
  that synthetic is suppressed and the recovery menu shows instead.
• First-boot NVRAM service no longer retries forever. A persistently-blocked
  write (e.g. a mislabeled binary on enforcing SELinux) now fails non-fatally
  after a bounded number of attempts with an actionable message, instead of
  re-running every boot.
• Installer relabels its files for SELinux (restorecon). A hand-deployed
  (non-rpm) install copied through /tmp leaves files labeled user_tmp_t,
  which init_t may not execute — so the first-boot service's exec of
  lamboot-install (a symlink into /usr/share/lamboot) was denied on enforcing
  RHEL. lamboot-install now runs restorecon on its installed files +
  payload dir when SELinux is enabled (idempotent no-op on rpm/non-SELinux).
  This is the correct fix; no custom SELinux policy module is shipped.

[0.16.2] — Fix: installer misclassified its own old fallback as systemd-boot

A point fix for the upgrade path on systems whose firmware boots LamBoot via the
removable-media fallback \EFI\BOOT\BOOTX64.EFI (e.g. a Proxmox VM whose ESP
lives on a disk not in the VM's boot: order, where named NVRAM entries don't
persist). On those systems lamboot-install --update --fallback aborted and the
upgrade never reached the binary the firmware actually loads.

Fixed

• identify_bootloader now detects LamBoot before systemd-boot. LamBoot's
  own binary embeds the string systemd-boot (its SecurityOverride mirrors
  systemd-boot's ShimLock dance), and the loader-classifier grepped for
  systemd-boot before the LamBoot self-check — so an existing LamBoot
  fallback was misclassified as a foreign systemd-boot, and install_fallback
  refused to refresh it without --replace-fallback. The LamBoot check now runs
  first; an old LamBoot fallback is correctly recognized as our own and updated
  in place on --update --fallback. Covered by a new
  tools/tests/installer/identify_bootloader.bats regression suite.

Added

• Install-time warning when the ESP is on a separate disk from the OS root.
  On a hypervisor whose firmware only boot-indexes the disks in the VM's boot:
  order (Proxmox/QEMU OVMF), a named LamBoot NVRAM entry pointing at a
  non-boot-indexed disk is pruned on reboot — so an upgrade silently reverts to
  booting the fallback. lamboot-install now detects this (ESP parent disk ≠ OS
  root disk under systemd-detect-virt) in warn_if_esp_on_separate_disk() and
  warns with the actionable qm set --boot fix (or --fallback), plus an
  esp_on_separate_disk trust event. Tested by
  tools/tests/installer/warn_esp_disk.bats.

[0.16.1] — Fix: goblin 0.9.3 could not boot Linux kernels (native PE loader)

A hotfix for a boot regression introduced in 0.16.0. The goblin PE-parser pin was
moved =0.10.5 → =0.9.3 to align with the Debian archive, but goblin 0.9.3's
Header::parse rejects the Linux EFI-stub layout — the kernel omits the MSVC DOS
stub (e_lfanew == 0x40), and 0.9.3's DosStub::parse fails the end_offset <= start_offset check (0.10.5 relaxed it to <). Every native-PE Linux-kernel load
therefore failed with pe_parse_failed, dead-ending the boot — observed as the VM
powering off on kernel selection. SB-off, directly-signed, and MOK kernels booted via
the native loader are all affected; a default-config Linux boot does not complete.

Fixed

• Native PE loader no longer depends on goblin. The single goblin::Header::parse
  call is replaced by a hand-rolled no_std PE/COFF reader that reads only the
  load-bearing COFF + PE32+ optional-header fields from their fixed offsets and never
  parses the MSVC DOS stub or Rich header — the structures goblin 0.9.3 mis-validated.
  number_of_rva_and_sizes bounds the data-directory accessors (Linux kernels ship
  fewer than the full 16). PE32 (0x10b) is rejected cleanly. goblin — and its
  transitive plain / scroll deps — leave the dependency tree entirely, which is what
  the Debian archive needs. Verified end-to-end: the exact kernel 0.16.0 rejected now
  loads with image_loaded_native … SUCCESS.
• boot_linux gains a native → firmware BS->LoadImage fallback. A native-PE
  parse/load failure on a Linux kernel is no longer terminal — it degrades to a firmware
  boot (logged as `kernel...

LamBoot v0.15.2

LamBoot v0.15.2

First public release since v0.9.1 (May 2026). The intervening work was tested
privately across many tagged builds; v0.15.2 brings the public release current
with the development tree and is the first release published under Lamco
Development LLC.

This is also the first GPG-signed release (signing applies from v0.10.0
onward). See "Verifying this release" below.

Highlights since v0.9.1

• Native filesystem reading completed (v0.15.0–v0.15.1). A read-only FAT
  backend (FatRo), including FAT on LVM, closes the last firmware dependency in
  the /boot read path. A separate /boot is now sourced in place rather than
  mirrored onto the ESP.
• Security hardening (v0.14.0). Closed 43 of 54 findings from a full
  security and architecture audit; no CRITICAL or HIGH issues remain open.
• Machine-checked 8-layer architecture (v0.13.0). The 46-module core is
  organized into an enforced 8-layer dependency DAG. An upward dependency or a
  missing layer declaration fails the build on every commit.
• Installer integration (v0.11.x–v0.12.0). An auto-loading archinstall
  plugin (portable across 3.x/4.x), a Calamares module, and the
  lamboot-install v1 protocol (--json, --root, --capabilities,
  --no-prompt).
• Proxmox guest integration (v0.11.x). fw_cfg opt/lamboot/config parsing,
  fleet/role/host-node fields in the trust log, and a host-side integration
  layer.
• Native PE loader and signing pipeline (v0.10.0). Inspect-and-verify PE
  loading; production Secure Boot signing.

This release (v0.15.2)

• Relicensed to Lamco Development LLC. Terms are unchanged: LamBoot remains
  dual-licensed MIT OR Apache-2.0.
• lamboot-core now consumes lambutter (=0.3.0) and lamlvm (=0.1.0) from
  crates.io rather than in-repo path dependencies. These two no_std readers
  are now independently published library crates.

Full history is in CHANGELOG.md.

Verifying this release

# Import the signing key (Lamco Development release key)
gpg --keyserver keyserver.ubuntu.com --recv-keys CA11F781516743D5D9A1A12F17B95B68A50CD3A7

# Verify signature and checksum
gpg --verify lamboot-0.15.2-x86_64.tar.gz.asc lamboot-0.15.2-x86_64.tar.gz
sha256sum -c lamboot-0.15.2-x86_64.tar.gz.sha256

gpg --verify should report a good signature from
Greg Lamberson (Debian packaging) <greg@lamco.io> using RSA key
405CB1E36258DA1DA406A852A236DDB84E0EC96E.

LamBoot v0.9.1

[0.9.1]

Bugfix-cadence release. Closes the v0.9.1 sprint punch list: a
packaging regression in v0.9.0, a documentation gap that bit fleet
operators rolling their own OVMF_VARS, a silent-trust-log
correctness bug on the firmware-LoadImage path, and a Pop!_OS
autodiscovery audit that closed with "no gap."

Fixed — packaging: tarball now ships lib/esp-deploy.sh

The v0.9.0 release tarball was missing lib/esp-deploy.sh —
lamboot-install sources this canonical ESP-layout library at one
of three paths (<self-dir>/../lib/esp-deploy.sh,
/usr/lib/lamboot/esp-deploy.sh, <self-dir>/lib/esp-deploy.sh).
The third path is the tarball case; the file was simply never
copied into the staging tree, so a fresh extract failed with
ERROR: lamboot-install could not source esp-deploy.sh library.
and required a manual workaround.

• package-release.sh now copies lib/esp-deploy.sh into
  lamboot-<VERSION>/lib/esp-deploy.sh in the staging tree, where
  lamboot-install's third lib-search candidate finds it.
• lib/esp-deploy.sh is now in the REQUIRED[] sanity-check
  array, so a future regression of the same shape (file missing
  from lib/) will fail the package step before producing a
  tarball.

Fixed — silent trust log on [loader].native_pe = "never"

Operators who set [loader].native_pe = "never" — a documented
v0.8.3-rollback knob — got a trust log that went silent after
boot_attempt, with no record of the firmware-LoadImage path
being taken. Two issues compounded:

1. The image_loaded_firmware event was emitted but never
   flushed to \loader\boot-trust.log before transferring
   control. The kernel ExitBootServices reclaimed the in-memory
   log, so audit consumers saw nothing.
2. There was no event marking the routing decision — only the
   post-load success.

firmware_load_and_start now:

• Records a new legacy_loadimage_used event before the
  LoadImage call, with note=size=<N> policy=<auto|always|never>
  capturing why the firmware path was taken.
• Calls trust_log.flush(esp) before start_image, mirroring the
  native path's existing flush at boot.rs ~617. Events on this path
  now persist to disk.

The new event uses verified_via=firmware_loadimage (existing
stable token); adding the legacy_loadimage_used event name is
semver-additive per the trust-log schema vocabulary in
SECURITY-MODEL.md.

Documented — --add-mok vs --add-db distinction in OVMF-VARS-PROXMOX.md

Operators rolling their own OVMF_VARS with virt-fw-vars (rather
than the pre-built OVMF_VARS_lamboot.fd) sometimes used
--add-mok alone, expecting that to make LamBoot directly
bootable under SB. It does not — MOK is consulted by shim, not by
firmware. With the cert in MOK only, firmware rejects LamBoot's
binary and falls back to whatever other Boot#### entry exists
(typically the distro's shim), with BootCurrent no longer
matching LamBoot. Direct boot under SB requires the cert in
firmware db (virt-fw-vars --add-db).

docs/OVMF-VARS-PROXMOX.md now has a §1.1 "Common pitfall" callout
making the distinction explicit, plus a back-reference from §7
where virt-fw-vars is actually used.

Audit — Pop!_OS auto-discovery: no gap in autodiscovery.rs

POPOS-AUTO-DISCOVERY-FINDINGS-2026-04-25 §1 flagged
autodiscovery.rs as a separate audit target alongside the new
discover_systemd_boot_dir_style scanner shipped in v0.9.0.
End-to-end audit closed with no code change: find_initrd() is
called only from bls.rs:171 (BLS Type 1 entries). The
<distro>-<root-uuid>/vmlinuz.efi layout that Pop!_OS uses is
handled entirely by discover_systemd_boot_dir_style in
discovery.rs, which constructs initrd_paths from the sibling
initrd.img file directly and never traverses autodiscovery.rs.

LamBoot v0.9.0

[0.9.0]

The v0.9.x SDS ladder: native ext4 read backend, native PE loader,
native trust chain, BLS multi-FS discovery, legacy UEFI FS driver
deprecation. Plus first-class Pop!_OS / systemd-boot-discoverable-EFI
auto-discovery, the lamboot-tools v0.2.0 toolkit gap closures
(esp-deploy.sh canonical lib + offline lamboot-esp deploy +
fallback-foreign detection + BootOrder reorder), and a comprehensive
five-document strategic coverage analysis.

Added — Pop!_OS / systemd-boot-discoverable-EFI auto-discovery

LamBoot now picks up Pop!_OS kernels at the kernelstub-managed
\EFI\Pop_OS-<root-uuid>\vmlinuz.efi layout and the Pop!_OS Recovery
counterpart at \EFI\Recovery-<short-uuid>\vmlinuz.efi. Same scanner
covers Garuda variants and any custom systemd-boot installation
that uses the <distro>-<uuid> directory pattern.

• New lamboot-core/src/discovery.rs::discover_systemd_boot_dir_style
  function. Iterates /EFI/<dirname> directories on the ESP, recognizes
  <name>-<uuid> patterns via discovery_pure::looks_like_distro_uuid_dir,
  reads sibling vmlinuz.efi + cmdline + initrd.img files, emits
  EntryKind::LinuxLegacy entries.
• New lamboot-core/src/discovery_pure.rs — host-testable pure helpers
  (recognizer + display renderer + path-style converter). Same
  #[path]-include pattern used by bls_parse, pe_loader_pure,
  trust_log_pure. 24 host tests covering positive/negative dirname
  recognition + display rendering + path conversion.
• Pop!_OS-specific display: Pop_OS-<uuid> renders as Pop!_OS
  (System76 escapes the ! as _ in directory names).
• Last-known-good kernel surfaced as a sibling entry: when
  vmlinuz-previous.efi is present, a (previous kernel) BootEntry is
  emitted with paired initrd.img-previous.

Live evidence (VM 124 Pop!_OS COSMIC): trust log shows
entries_discovered total=7 with Pop!_OS Recovery selected via
entry_selected id=sdboot-Recovery-79EB-58C6 kind=LinuxLegacy,
image_verified verified_via=degraded_trust_sb_direct sha256=c74f5c68…,
image_loaded_native loader=native_pe_loader — full v0.9.x boot path
exercised on Pop!_OS for the first time.

Added — EFI Fallback chainload self-loop guard

discover_other_loaders now takes the running LamBoot image's
SHA-256 and skips the synthetic "EFI Fallback" entry when
\EFI\BOOT\BOOTX64.EFI is itself a copy of LamBoot. Prevents
chainload self-loop when operators use the toolkit's
belt-and-suspenders pattern (repair.fallback.replace_with_lamboot)
to write LamBoot's signed binary to the firmware-fallback path.

run_bootloader computes the self-hash via LoadedImageProtocol
(image_base + image_size) and threads it through
discovery::discover_all_entries(self_image_sha256: Option<[u8; 32]>).

v0.9.x ladder context

The five SDSes that constitute the v0.9.x foundation are now landed
(see prior ## [Unreleased] sections, retained below for the per-SDS
detail). This release is the first to ship them all together as a
coherent stack.

— end of v0.9.0 entry —

LamBoot v0.8.4

[0.8.4] — 2026-04-22

Release posture: coordinated lamboot v0.8.4 + lamboot-tools v0.2.0
per docs/CROSS-REPO-STATUS.md. v0.8.3 shipped the signing + audit
layer; v0.8.4 closes the Proxmox-toolkit coordination gaps so the
companion lamboot-tools v0.2.0 toolkit (11 tools across 3 RPM
subpackages) can ship alongside.

Tarball SHA256: 4671691f597627ee354f36e945dc5d68a75709af4524a88c5a6aa9ae87056830

Proxmox integration test on pve.a.lamco.io (VM 120): PASS on all 8
verifications. See docs/analysis/V0.8.4-PROXMOX-INTEGRATION-TEST-2026-04-22.md.

See also: lamco-admin/lamboot-tools v0.2.0.

Fixed

• tools/lamboot-hookscript.pl rewritten to fw_cfg file-reference pattern (commit 2892446). Pre-0.8.4 hookscript called qm set --args during pre-start, which silently failed because Proxmox config-locks the VM config during that lifecycle phase. The rewrite removes all qm set calls: lamboot-pve-setup from the toolkit sets the permanent args: line once on a stopped VM, and this hookscript's pre-start job becomes writing /var/lib/lamboot/<VMID>.json for QEMU to expose via fw_cfg. Version header # version: 0.8.4 allows lamboot-pve-setup doctor-hookscript to detect and verify. See docs/specs/ + ~/lamboot-tools-dev/docs/SPEC-LAMBOOT-TOOLKIT-V1.md §11.2 for the full protocol.

Added

• lamboot-install --toolkit-prompt (commit c4a9b4e). Interactive Install lamboot-tools for diagnostic and repair utilities? [y/N] prompt at the end of a successful install, plus --install-toolkit / --no-install-toolkit flag overrides for non-interactive scripts. Distro-aware install guidance: Fedora/RHEL/EPEL shows dnf copr enable lamco/lamboot-tools; Debian/Ubuntu/Arch shows the source-tarball URL with a note that native packaging lands in lamboot-tools v0.3. Skipped on --dry-run, --update, --quiet, or partial failure.
• /etc/lamboot/fleet.toml schema v1 consumption (commits ada5cb6 + 2892446). Both tools/lamboot-monitor.py and tools/lamboot-hookscript.pl now read the shared fleet config authored as canonical in ~/lamboot-tools-dev/docs/SPEC-LAMBOOT-TOOLKIT-V1.md §16 Appendix C. Monitor seeds argparse defaults for --alert-webhook (HTTPS enforced) and --log-path from [monitor]. Hookscript reads [hookscript] inject flags plus [roles] explicit VMID mapping and [tags] tag-to-role mapping for per-VM role resolution. Additive with graceful fallback: missing file / missing TOML parser / wrong schema version / malformed TOML all fall back to hardcoded defaults so v0.8.4 is safe to deploy before fleet.toml exists.
• docs/CROSS-REPO-STATUS.md (commit 51ce546). Rolling coordination tracker between lamboot-dev and lamboot-tools-dev per the toolkit spec §14.5. Mirror counterpart lives in the toolkit repo; owner perspectives flipped between them.

Changed

• docs/LAMBOOT-TOOLS-OVERVIEW.md rewritten (commit 51ce546) to reflect the real state of the companion toolkit. Previously described "5 bash CLI utilities"; now describes 11 tools across 3 RPM subpackages (lamboot-tools, lamboot-migrate dual-pub, lamboot-toolkit-pve) with Copr-based install flow and Option 2 packaging architecture.
• README.md adds "Diagnostic and repair utilities" section (commit b812fea) linking github.com/lamco-admin/lamboot-tools and cross-referencing CROSS-REPO-STATUS.md + the toolkit spec.
• docs/STATUS-2026-04-22-TOOLKIT-PIVOT.md §9 "Post-Q state" appendix added (commit 51ce546). Captures what happened after the pivot doc was written: the toolkit repo ran its Session A–Q arc the same day, turning 5 v0.1.0 scripts into 11 production-grade tools; all 23 R1–R23 research questions from §4 of the pivot doc are resolved in ~/lamboot-tools-dev/docs/SPEC-LAMBOOT-TOOLKIT-V1.md; lamboot-migrate v1.0.0 ships SDS-7 in full. §1-§8 of the pivot doc preserved as historical record.
• docs/ROADMAP.md "Toolkit Pivot" intro updated (commit 51ce546) with current toolkit state and CROSS-REPO-STATUS.md pointer.
• docs/specs/SPEC-LAMBOOT-MIGRATE.md §14 reconciliation flipped to RESOLVED (commit 51ce546). The v1.0.0 implementation landed in lamboot-tools-dev Session C closes every gap from §14.1–§14.7, plus --remove-grub distro-aware cleanup beyond spec. Each row marked RESOLVED / RESOLVED+ / KEPT.

Added — should-have cross-references

• docs/KEY-GENERATION.md §10 "Operator tooling" (commit 51ce546) back-links to lamboot-signing-keys in the toolkit; lists generate/rotate/enroll/sign-binary/revoke/list/show/verify/import/export subcommands.
• docs/SECURE-BOOT-AND-SIGNING-STRATEGY.md "Operator tooling" (commit 51ce546) maps sign-binary/rotate/verify to procedures in the strategy doc.
• docs/OVMF-VARS-PROXMOX.md §12 (commit 51ce546) notes lamboot-pve-ovmf-vars in the toolkit is a mirror of tools/build-ovmf-vars.sh here; canonical source stays in this repo.

LamBoot v0.8.3

[0.8.3] — 2026-04 (unreleased)

Release posture: the signing + audit layer. v0.8.3 ships the production signing pipeline, SecurityOverride (Path F), trust-evidence log, and install-script hardening. It is the foundation every later release builds on.

What v0.8.3 is good for: Secure-Boot-off installs (full feature set, all filesystems, no caveats); Secure-Boot-on installs with UKI on the ESP; Secure-Boot-on installs with firmware-DB-signed kernels; Proxmox VM fleets using UKI-based images.

Known limitation accepted for v0.8.3: stock /boot on ext4 under Secure Boot fails on shim 15.8 (current Ubuntu/Debian shim). Root cause: shim 15.8 uninstalls its ShimLock protocol after our UEFI ext4 driver's StartImage completes, so later kernel verification has no shim to delegate to. Fully diagnosed with per-hook counters; documented in docs/analysis/CONFIG-4-TRUST-CHAIN-GAP-2026-04-21-AMENDED.md. Structural fix in v1.0 via a native Rust ext4 reader (ext4-view) plus a native PE loader (on top of goblin) — no UEFI FS driver load required, no firmware LoadImage re-check. See docs/analysis/NATIVE-FS-AND-PE-LOADER-STRATEGY-2026-04-21.md and docs/INTEGRATED-PLAN-V0.8.3-TO-V1.0.md.

Effective positioning for v0.8.3:

• "Modern Rust UEFI bootloader for Linux, with an honest signing and audit layer"
• NOT "Secure Boot on stock Linux just works" — that's v1.0's promise (~14 weeks out)

Changed (breaking default)

• lamboot-install now makes LamBoot the default boot entry on install. Previous default was to preserve the existing default and append LamBoot last in BootOrder (safe-trial behavior). New default matches grub-install / bootctl install / refind-install: when you install LamBoot, the firmware will pick LamBoot next boot. The previous default is always preserved as the next entry in BootOrder, so it remains one keystroke away from the firmware boot menu. Opt back into the old behavior with --no-make-default. The explicit --set-default / --make-default flags are retained for scripts that want to be unambiguous.

Added

• Production signing key hierarchy — PK 4096, KEK 4096, db 2048 per shim-MOK compatibility constraints (see docs/KEY-GENERATION.md and docs/analysis/RSA-4096-COMPATIBILITY-ANALYSIS-2026-04-20.md).
• Bootloader signing pipeline — build.sh + tools/sign-lamboot.sh produce lambootx64-signed.efi using sbsign with SBAT section added via llvm-objcopy (GNU objcopy produces corrupt PE output).
• Session-cached signing workflow — tools/sign-unlock + tools/sign-lock for tmpfs-backed db.key decryption per terminal session.
• Secure Boot deployment documentation — docs/SECURE-BOOT-DEPLOYMENT.md covering four configurations: (1) SB disabled, (2) firmware db enrollment, (3) shim + MOK, (4) custom OVMF VARS (Proxmox zero-touch).
• MOK enrollment guide — docs/MOK-ENROLLMENT-GUIDE.md with screen-by-screen MokManager walkthrough.
• Proxmox OVMF VARS guide — docs/OVMF-VARS-PROXMOX.md for zero-touch fleet deployment per storage backend.
• Install-script Secure Boot flags — --signed, --no-shim, --no-mok on tools/lamboot-install. MOK auto-enrollment via mokutil --import.
• Path F: SecurityArchProtocol override — new lamboot-core/src/security_override.rs implements the systemd-boot pattern for driver loading under shim+MOK. Resolves MOK-signed driver ACCESS_DENIED on shim < v16 (Ubuntu 25.10, Debian 13, current Fedora). See docs/analysis/SECURE-BOOT-ECOSYSTEM-AND-REAL-FIX-2026-04-21.md.
• ShimRetainProtocol support — request_shim_retain_protocol() sets the shim 15.8+ variable to prevent ShimLock protocol from being uninstalled after driver StartImage() (shim #444 / sd-boot precedent).
• Trust-evidence log — lamboot-core/src/trust_log.rs writes structured JSON to \loader\boot-trust.log on the ESP recording every image-authentication decision. First-of-kind in the Linux bootloader space.
• Unified Kernel Image (UKI) first-class menu integration — automatic discovery of UKIs in \EFI\Linux\*.efi with PE section metadata extraction (.osrel, .cmdline, .uname).
• Migration Tier 2 (--replace) — ESP + NVRAM backup, GRUB cmdline extraction, atomic migration to LamBoot with fallback entry.
• Debian/Ubuntu kernel hooks — kernel-hooks/zz-lamboot-postinst + zz-lamboot-postrm, deployed to /etc/kernel/{postinst,postrm}.d/ on install, keeping BLS entries synchronized with installed kernels.
• BLS entry lifecycle handling — install script's --update path detects stale LamBoot-owned BLS entries (kernel they reference no longer exists) and regenerates.
• SECURITY.md — responsible-disclosure policy and security-reporting procedures.
• docs/SECURITY-MODEL.md — honest threat model: what LamBoot defends against vs. what remains in the ecosystem. Breaks from the bootloader norm of glossing over SB trust-chain gaps.
• Public repo reservations — lamco-admin/lamboot and lamco-admin/lamboot-tools GitHub repositories (initially empty placeholders).

Changed

• Retired "LamBoot Dev" test keys; replaced with production keys named CN=LamBoot Platform Key, CN=LamBoot Key Exchange Key, CN=LamBoot Release Signing Key 2026 under O=Lamco Development, C=US, ST=IL, emailAddress=office@lamco.io.
• Driver loading now wraps uefi::boot::load_image with SecurityArchProtocol override for MOK-trust delegation.
• boot.rs::find_volume_for_path now returns Option<usize> — explicit None instead of silently defaulting to the ESP when a BLS-referenced kernel file is absent.

Fixed

• build.sh now copies kernel-hooks/ into dist/kernel-hooks/ so the install script's find_dist_file locates the Debian/Ubuntu postinst/postrm scripts.
• Install script's --update no longer treats previously-generated BLS entries as "native distro" — it distinguishes manifest-tracked entries and regenerates when their kernels are missing.
• Logging clarity: boot.rs no longer emits misleading Kernel found on volume 0 when the kernel was actually absent everywhere.

Documented limitations

• Canonical-signed Ubuntu kernels may fail to load under LamBoot in Config 3 (shim+MOK) on distros where /boot is on ext4 root. Workaround: use UKIs in \EFI\Linux\, or Config 4 with Canonical's CA added to custom OVMF VARS. See docs/SECURITY-MODEL.md §3.1.
• Trust-evidence log is not yet cryptographically signed (planned for v0.9.x via Path G — own PE loader).
• ShimLock authenticode verification has edge cases with PE-gap-containing kernels that shim doesn't accept even when they chain to trusted CAs. Root cause documented in docs/analysis/UEFI-SECURITY-ECOSYSTEM-DEEP-DIVE-2026-04-21.md §4.4.

Roadmap

• v0.9.x: Path G — own PE loader with direct Authenticode verification, structured cert-chain walking, signed trust log entries, Trust Evidence Panel in GUI, policy-driven trust enforcement.
• v1.0: Microsoft rhboot/shim-review submission (first Rust bootloader), PQ signature support via MOK, composefs integration, bootupd-style self-update.
• v2.0: TrenchBoot / DRTM integration, full UKI management suite, upstream PE-loader crate contribution to uefi-rs.

---