Productslamboot-tools › Use Cases

Use Cases

How teams use lamboot-tools in practice.

USE CASE 1

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.

200
servers migrated
0
manual verifications
exit 0
success signal per host
Fleet migration pipeline
#!/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.

USE CASE 2

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.

.github/workflows/boot-health.yml
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.

USE CASE 3

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.

Rescue recovery session
# 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.

USE CASE 4

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.

Baseline Secure Boot deployment
# 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.

USE CASE 5

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.

Proxmox fleet standardization
# 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
USE CASE 6

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.

Provisioning post-install hook
#!/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.