BIOS-to-UEFI fleet migration
An operations team needs to move 200 servers from legacy BIOS boot to UEFI over a maintenance window, without reinstalling operating systems and without a manual post-migration verification step for each machine.
#!/usr/bin/env bash
# Run on each host in Ansible or parallel-ssh
set -euo pipefail
# 1. Check migration readiness
sudo lamboot-migrate preflight || { echo "Preflight failed on $HOSTNAME"; exit 4; }
# 2. Backup first
sudo lamboot-backup save "pre-migration-$(date +%Y%m%d)"
# 3. Migrate (exits 0 on success, 3 if already UEFI)
sudo lamboot-migrate to-uefi --yes
rc=$?
[[ $rc -eq 3 ]] && { echo "Already UEFI on $HOSTNAME"; exit 0; }
[[ $rc -ne 0 ]] && { echo "Migration failed on $HOSTNAME: $rc"; exit $rc; }
# 4. Schedule reboot and post-boot verification
sudo systemctl reboot
After reboot, a systemd one-shot unit runs lamboot-diagnose --json and POSTs the result to a central endpoint. Central tooling aggregates results and alerts if any host reports a non-zero exit code.
Boot health check in CI
A platform team wants boot environment issues caught by the CI pipeline before they reach production, not discovered when a machine fails to reboot after a kernel update.
name: Boot health
on:
schedule:
- cron: '0 6 * * *'
workflow_dispatch:
jobs:
boot-health:
runs-on: [self-hosted, linux, x86_64]
steps:
- name: Diagnose boot environment
run: |
sudo lamboot-diagnose --json --fail-on error \
> diag.json 2>&1
echo "exit $?" >> "$GITHUB_STEP_SUMMARY"
- name: Upload diagnostic report
if: always()
uses: actions/upload-artifact@v4
with:
name: boot-diagnostic
path: diag.json
With --fail-on error, the workflow step exits non-zero only when a critical or error-severity finding is present. The uploaded diag.json includes remediation commands for every finding, so the on-call engineer can act without additional investigation.
Rescue mode recovery
A server fails to boot after a kernel update. The on-call engineer needs to diagnose the failure and restore the boot environment without data loss, remotely over IPMI/iDRAC SOL.
# Boot from rescue medium (includes lamboot-tools)
# 1. Identify the disk and mount root filesystem
lsblk -f
mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot/efi
# 2. Diagnose in offline mode (no chroot needed for read-only checks)
sudo lamboot-diagnose --offline /dev/sda
# 3. List existing backups
sudo lamboot-backup list --backup-dir /mnt/var/backups/lamboot/
# 4. Restore the last known-good backup
sudo lamboot-backup restore pre-migration --backup-dir /mnt/var/backups/lamboot/
# 5. Or repair the specific finding
sudo lamboot-repair run --finding bootloader.grub.pe_format
# 6. Reboot
sync && reboot
The structured JSON output from lamboot-diagnose --json can be piped to jq to extract the exact remediation commands, making remote diagnosis faster even over a slow SOL connection.
Secure Boot with custom keys
A security team needs to deploy servers with Secure Boot enforced using the organization's own keys, and wants kernel updates to automatically produce a signed UKI without manual intervention.
# Run once: generate and enroll org keys
sudo lamboot-signing-keys generate --org "Acme Corp" --cn "Acme Boot 2026"
# (Enter firmware Setup Mode, then:)
sudo lamboot-signing-keys enroll
# Build and install the first UKI
sudo lamboot-uki-build build
sudo lamboot-uki-build install
# Install the kernel post-install hook for auto-rebuild
cat > /etc/kernel/postinst.d/90-lamboot-uki << 'EOF'
#!/bin/sh
sudo lamboot-uki-build build --kernel "$1"
sudo lamboot-uki-build install --kernel "$1"
EOF
chmod +x /etc/kernel/postinst.d/90-lamboot-uki
After initial setup, kernel package installs trigger the hook automatically. lamboot-diagnose --category secureboot can verify the Secure Boot state any time. The GPG signing key for the toolkit itself uses subkey 405CB1E36258DA1DA406A852A236DDB84E0EC96E.
Proxmox VM boot standardization
A team manages 40 Proxmox VMs, some provisioned years ago as BIOS VMs. They want to standardize on UEFI for all VMs and enforce it for new ones, while auditing the fleet to track progress.
# 1. Audit current fleet boot modes
sudo lamboot-pve-fleet audit --json | tee fleet-audit.json
# 2. Count BIOS vs UEFI
jq '[.vms[] | .boot_mode] | group_by(.) | map({mode: .[0], count: length})' fleet-audit.json
# 3. Migrate all ready BIOS VMs
sudo lamboot-pve-fleet audit --json | \
jq -r '.vms[] | select(.boot_mode == "bios" and .migration_ready == true) | .vmid' | \
while read vmid; do
echo "Migrating VM $vmid..."
sudo lamboot-pve-migrate run "$vmid"
done
# 4. Configure UEFI as the default for new VMs
sudo lamboot-pve-setup configure
Bare-metal provisioning bootstrap
A DevOps team uses PXE to provision bare-metal servers. They want the post-provision boot environment verified and any issues fixed automatically before the machine is handed off to the application layer.
#!/usr/bin/env bash
# cloud-init or Kickstart %post section
set -euo pipefail
# Verify the boot environment looks correct for a freshly-provisioned machine
lamboot_diag=$(sudo lamboot-diagnose --json --fail-on error 2>/dev/null)
rc=$?
if [[ $rc -ne 0 ]]; then
# Apply automated repairs
sudo lamboot-repair run --auto --yes
# Re-check; fail provisioning if repairs didn't resolve issues
sudo lamboot-diagnose --json --fail-on error
fi
# Save a named baseline backup that can be used for recovery
sudo lamboot-backup save baseline-provision
echo "Boot environment verified."
The baseline backup created here is the recovery point used in Use Case 3 (rescue recovery). Tagging it baseline-provision makes it easy to identify among accumulated backups on a long-running server.