News & Updates

LamBoot now reads far more of your real storage natively, in memory-safe Rust compiled into the loader, with no firmware filesystem driver and no GPLv3 helper binary for any of it. The native read set grows from ext4, btrfs, and FAT to ext4, btrfs, FAT, XFS, exFAT, and ZFS, plus a read-only media-filesystem stack. A new opt-in feature boots a Linux distribution directly from an .iso. Every new backend is read-only by construction, and a default-config boot is unaffected.

What changed since v0.15.2

• More of your real storage, read natively. The native read set grows to ext4, btrfs, FAT, XFS, exFAT, and ZFS, with XFS also read on an LVM logical volume. XFS unblocks the RHEL family, where XFS is the default /boot and root. ZFS covers the Ubuntu and Debian root-on-ZFS boot pool, single-disk, mirror, and single-parity RAIDZ1, unencrypted, decoding all six OpenZFS compressors. exFAT covers removable boot media larger than 4 GiB.
• A read-only media-filesystem stack. EROFS, ISO 9660, SquashFS, cramfs, romfs, and UDF mount as ordinary read-only volumes and are scanned for kernels, so an EROFS or SquashFS root, and live and immutable media images, are read like any other volume.
• Boot a distribution straight from an .iso (opt-in). Point LamBoot at an .iso on a volume it can read, or at an inserted disc, and it boots the distribution directly, with no write to a USB stick first. It reuses the distribution's own loopback configuration when present and falls back to a per-family recipe otherwise. Experimental and off by default. Arch 2026.05 and Fedora 44 are validated end to end.
• A stronger kernel load path. The native PE loader now reads the kernel's PE header itself with no third-party parser, and falls back to firmware LoadImage for the Linux EFI-stub kernels it does not load natively, so the kernel always loads while the parsing LamBoot does stays memory-safe Rust.
• Wider install reach. LamBoot now installs its own UEFI boot entry, discovers MBR and BlockIO-only partitions in addition to GPT, and handles kernel-upgrade entries in place on an XFS /boot.

Read-only by construction

Every new backend, XFS, exFAT, ZFS, and the whole media stack, only reads. There is no write path, and the ESP writer only ever targets the FAT backend. A default-config boot is byte-for-byte unaffected, because the boot-from-ISO gates default off and the new readers only read. The media mounts do not yet add an integrity check of media content; a verified-media path is on the roadmap.

The shape of it

About 21,200 lines of Rust across 62 modules, around 1.05 MB on disk (about 922 KB on aarch64). It reads your real /boot across the filesystems Linux actually uses, records what it verified to a trust-evidence log on the ESP every boot, loads the kernel with its own PE loader, and recovers itself after a bad boot.

Download

Tag v0.16.5. Tarball: lamboot-0.16.5-x86_64.tar.gz (about 1.05 MB, 1,100,288 bytes unsigned), with a .sha256 and a .asc GPG signature. The aarch64 build is about 922 KB. The published checksum and signature are on the GitHub release; the Install page has the verification steps and the signing-key fingerprint.

lamboot-tools 0.8.0 changes the architecture of the suite. It did not shrink. It federated. The suite is now shell-only at its core, and it bundles prebuilt, statically linked binaries of two Rust components that have moved into their own repositories. The shell tools orchestrate. The Rust components do the heavy parsing and auditing.

What is in this release

• Nine shell tools plus a dispatcher. diagnose, esp, backup, repair, migrate, doctor, uki-build, signing-keys, and inspect, with the lamboot-toolkit dispatcher. Each diagnoses, repairs, or migrates UEFI boot on any UEFI Linux system.
• Two bundled Rust binaries. lamboot-capcheck 0.1.0, a firmware and platform capability auditor across 12 domains, and lamboot-reader 0.1.0, a GRUB config reader and resolver. Both ship static against musl, one binary per architecture, with no runtime dependency.
• Bootloader-agnostic. GRUB, systemd-boot, rEFInd, Limine, and LamBoot are first-class peers. If your system boots through UEFI, these tools work on it.
• Structured output you can act on. Every tool emits structured JSON, schema_version v1, and every warning-or-above finding carries a machine-readable remediation command and a documentation URL.
• A Proxmox VE companion. The lamboot-toolkit-pve subpackage adds host-side fleet tooling: per-VM setup, fleet operations, host-side boot-health reading, and OVMF_VARS building.

Download

Tag v0.8.0. The signed GitHub release carries the full product, including the architecture-specific lamboot-tools-firmware binaries. Core tarball: lamboot-tools-0.8.0.tar.gz. SHA-256: 5581a05e2f1a31d3ab608e2ab3d7d27af3fe53f16a18b5b80b6b064306227450. Also on Fedora COPR, AUR, and a Homebrew tap, with the shell core on RPM Fusion and Debian. MIT OR Apache-2.0.

The first public release since v0.9.1. The intervening work was tested privately across many tagged builds, and v0.15.2 brings the public release current with the development tree. It is the first release published under Lamco Development LLC, and the first GPG-signed one.

What changed since v0.9.1

• Native filesystem reading completed. A read-only FAT backend, including FAT on LVM, closes the last firmware dependency in the /boot read path. A separate /boot is now read in place rather than mirrored onto the ESP. LamBoot reads ext4, btrfs, and FAT natively, including those filesystems on LVM.
• Security hardening. A full security and architecture audit closed 43 of 54 findings, with no CRITICAL or HIGH issues left open.
• Machine-checked eight-layer architecture. The 46-module core is organized into an enforced eight-layer dependency graph. An upward dependency or a missing layer declaration fails the build on every commit.
• Installer integration. An auto-loading archinstall plugin, a Calamares module, and the lamboot-install v1 protocol (--json, --root, --capabilities, --no-prompt).
• Proxmox guest integration. Fleet identity flows to the guest over QEMU fw_cfg (opt/lamboot/config), with fleet and role fields recorded in the trust log.

The shape of it

About 16,000 lines of Rust across 46 modules, around 650 KB on disk. It reads your real /boot, records what it verified to a trust-evidence log on the ESP every boot, loads the kernel with its own PE loader, and recovers itself after a bad boot. The same four things that make it different, now on a completed native filesystem foundation.

Download

Tag v0.15.2. Tarball: lamboot-0.15.2-x86_64.tar.gz, with a .sha256 and a .asc GPG signature. SHA-256: b628146bf0b7f1f1f2ba5d1b0d2f73e3e0d2c0c6dc278f5635b01c8dfb22ad45.

Bugfix-cadence release on top of v0.9.0. Three fixes from the v0.9.1 sprint punch list, plus a closed audit and repository-infrastructure polish.

What shipped

• P1 — Packaging: v0.9.0 tarball was missing lib/esp-deploy.sh; lamboot-install aborted on fresh extracts. Fixed in package-release.sh — the file is now in the tarball staging tree and in the required-artifact sanity check.
• P2 — OVMF VARS docs: New §1.1 in docs/OVMF-VARS-PROXMOX.md: virt-fw-vars --add-mok alone leaves LamBoot un-bootable directly under SB. The cert must be in firmware db (--add-db), not just MOK. The pitfall silently fell back to the distro shim entry — diagnosable only by efibootmgr post-boot.
• P3 — Trust log on firmware-LoadImage: Operators with [loader].native_pe = "never" got a silent post-boot_attempt log because firmware events were never flushed before kernel handoff. firmware_load_and_start now emits legacy_loadimage_used before LoadImage and flushes the log to disk before start_image.
• Pop!_OS autodiscovery audit closed with “no gap” — discover_systemd_boot_dir_style in discovery.rs already covers the layout end-to-end.

Also in this release window

Repository infrastructure (issue and PR templates, CODEOWNERS, contributor lifecycle policy in CONTRIBUTING.md), an in-place OVMF VARS modification path for VMs with pre-existing UEFI state (docs/OVMF-VARS-PROXMOX.md §5a), and a documented optimization that skips the MokManager pause while keeping shim in the trust chain (docs/SECURE-BOOT-DEPLOYMENT.md §4.1).

Download

Tag v0.9.1. Tarball: lamboot-0.9.1-x86_64.tar.gz. SHA-256: 08c88f0248f203d9565bb89ebffe2c193d94a4b91fd28f498b909f7c7df1c10a.

LamBoot v0.9.0 closes the long-standing shim 15.8 ShimLock-uninstall gap that previously broke stock distro /boot-on-ext4 under Secure Boot — structurally, not via a workaround. v0.8.3 said “use UKI as workaround”; v0.9.0 says “stock distros work.”

What shipped

• Native ext4 read backend (SDS-2) on top of the ext4-view Rust crate — read-only by design
• Native PE loader (SDS-3) — own image verification + load, no firmware LoadImage chainload
• Native trust chain (SDS-4) — covers what shim/firmware can’t see
• BLS multi-FS discovery (SDS-5) — scan BLS Type 1 entries on every mounted volume
• Pop!_OS / systemd-boot-discoverable-EFI auto-discovery — first non-systemd-boot bootloader to pick up Pop!_OS kernels
• EFI Fallback chainload self-loop guard — safe to write LamBoot to the firmware-fallback path repeatedly
• Append-mode trust log with per-image SHA-256

The Pop!_OS angle

Pop!_OS uses System76’s kernelstub to lay kernels out at \EFI\Pop_OS-<root-uuid>\vmlinuz.efi — a systemd-boot-style auto-discovered layout per the Boot Loader Specification, with no BLS Type 1 entries. Before v0.9.0, LamBoot’s discovery missed Pop!_OS entirely. Pop!_OS is the only mainstream distro shipping kernelstub-managed kernels-on-ESP without BLS Type 1 entries; LamBoot now picks it up first-class. Live evidence from VM 124: trust log shows entries_discovered total=7, Pop!_OS Recovery selected, image_verified verified_via=degraded_trust_sb_direct, image_loaded_native loader=native_pe_loader.

Read-only /boot guarantee

The ext4-view crate is read-only by design — LamBoot’s code literally cannot modify your /boot, backed by language and crate guarantees. This is a stronger claim than any other mainstream Linux bootloader can make.

Coordinated lamboot-tools v0.3.0

Shipped alongside: esp-deploy.sh as a canonical library sourced by other commands; a new offline lamboot-esp deploy subcommand for VM-template builders and offline repair; hardened foreign-bootloader detection at \EFI\BOOT\BOOTX64.EFI; first-class BootOrder reorder.

Coverage

Debian 13, Ubuntu 24.04 / 25.10, Fedora 43, and Pop!_OS 24.04 fully covered under specific Secure Boot + filesystem configs. Test suite: 137 host tests + 219 bats + verify-claims 84/0/1.

What’s next

v1.0’s anchor shifts to Path D — Microsoft shim-review submission, the first Rust bootloader through rhboot/shim-review. Removes per-system MOK enrollment; broadens trust baseline to Microsoft-signed level. Native btrfs and xfs read backends follow. Microsoft UEFI CA 2011 expires June 2026 — a timeline factor for fleet operators.

Download

Tag v0.9.0. Tarball: lamboot-0.9.0-x86_64.tar.gz. SHA-256: b7058cc5e58c5406d877cdb2991c75fe20919fef6c6b2b712c259bfaa0b9918d.

Lamco RDP Server v1.4.2 is now available with important compatibility fixes and expanded test coverage.

What's Fixed

• PipeWire/pipewire-rs 0.9.2 compatibility — resolved breaking changes in the latest PipeWire Rust bindings
• VA-API VP9 encoding fix — corrected hardware-accelerated VP9 encoding for libva 2.22+

Testing

The test suite now includes 415 passing tests, continuing our commitment to comprehensive automated verification.

Availability

v1.4.2 is available via Flatpak, AUR, and RPM Fusion. Debian packaging is pending sponsor review.

Lamco RDP Server is now available in RPM Fusion nonfree for Fedora 43 and Fedora 44 — making it the first Wayland-native RDP server available as a standard Fedora package.

Fedora users can install with a single command:

sudo dnf install lamco-rdp-server

Packages are available for both x86_64 and aarch64 architectures.

The lamco-rdp-server source package has been submitted to mentors.debian.net for inclusion in the Debian nonfree component. The package is awaiting sponsor review.

Once accepted, Debian and downstream distributions (including Ubuntu) will be able to install Lamco RDP Server directly from their package managers.

All 7 of our open source Rust crates have been updated with the latest improvements. Total downloads across all crates have surpassed 1,831.

Updated Crates

• lamco-rdp — Core RDP protocol implementation
• lamco-wayland — Wayland compositor integration
• lamco-gfx — Graphics pipeline and encoding
• lamco-input — Keyboard and mouse input handling
• lamco-clipboard — Clipboard synchronization
• lamco-audio — Audio playback via PipeWire
• lamco-net — Network transport and TLS

All crates are available on crates.io under permissive open source licenses.

We're excited to announce that NetKit v1.0.1, our professional WiFi analysis library for Kotlin, is now available on Maven Central!

What is NetKit?

NetKit is a comprehensive Kotlin Multiplatform library providing everything you need to build professional WiFi analysis tools. With 7 modular libraries and over 3,500 automated tests, NetKit brings enterprise-grade network analysis to Android, JVM, and Kotlin Multiplatform projects.

What's New in v1.0.1

Maven Central Publication

NetKit is now published to Maven Central under our verified io.lamco namespace. This means developers can add NetKit to their projects with zero configuration:

dependencies {
    implementation("io.lamco.netkit:core:1.0.1")
}

No custom repositories, no special setup - just add the dependency and go!

Four New Modules

We've expanded NetKit with four powerful new modules:

1. Analytics - Time series analysis, correlation detection, and visualization
2. Export - Multi-format export (CSV, JSON, PDF, Markdown, HTML, GeoJSON, KML)
3. Intelligence - ML-based predictions, anomaly detection, optimization
4. Security - Advanced security analysis with industry-first WPA3-SAE-PK detection

Quality & Documentation

• 3,561+ automated tests (92% code coverage)
• 100% KDoc API documentation
• GPG-signed releases for security
• Comprehensive examples and guides

Why Maven Central?

Maven Central is the industry standard for JVM libraries, used by millions of developers worldwide. Publishing to Maven Central signals that NetKit is:

• Production-ready - Used in real applications (like WiFi Intelligence)
• Professionally maintained - Semantic versioning, signed releases
• Trustworthy - Verified namespace, comprehensive testing
• Enterprise-grade - Suitable for commercial and enterprise use

Get Started

Visit our Developer Documentation to start building with NetKit, or browse the Maven Central Repository to see all available modules.

We can't wait to see what you build with NetKit!