Is lamboot-diagnose safe to run on a production system?
Yes. lamboot-diagnose is strictly read-only. It inspects the ESP, bootloader binaries, NVRAM, and Secure Boot state without modifying anything. It requires root only to read NVRAM and firmware data that are not accessible to unprivileged users. The --offline DISK flag is also read-only and works on unmounted devices.
What does lamboot-tools back up before making changes?
Every mutating tool creates an automatic backup before the first change. The backup captures the full ESP file tree, NVRAM boot entries, and relevant configuration files. It is stored in /var/backups/lamboot/ by default, and its path is included in the backup_dir field of all --json output. You can also create a named backup at any time with lamboot-backup save LABEL.
sudo lamboot-backup save before-uefi-migration
sudo lamboot-backup list # Confirm backup is listed
Does lamboot-migrate work on a running system, or do I need a rescue environment?
For most BIOS-to-UEFI migrations on single-disk systems, lamboot-migrate to-uefi can be run from the running OS. The tool stages changes safely: it prepares all UEFI artefacts and NVRAM entries, then makes the cutover on reboot rather than mid-run. However, for production servers or high-risk migrations (for example, when the MBR partition layout needs restructuring), running from a bootable rescue environment with a live lamboot-tools installation is strongly recommended.
What distributions does lamboot-tools support?
lamboot-tools is distribution-agnostic. It works at the firmware and filesystem layer, not at the package manager or init system layer. It has been tested on Debian, Ubuntu, Fedora, openSUSE, and Arch Linux. The only distribution-specific behavior is in lamboot-doctor's repair recommendations, which suggest distro-appropriate package names when a prerequisite is missing.
Can I use the JSON output in my own scripts? Will it break between releases?
Yes, the --json output is the stable programmatic interface. The envelope carries a schema_version field set to "v1". Within a major toolkit version, only additive changes are made: new fields may be added to the envelope or to findings[].context, but existing fields are never removed or renamed. A breaking change bumps schema_version to "v2" in lockstep with the toolkit major version. Pin your scripts on schema_version == "v1" to guard against future changes.
output=$(sudo lamboot-diagnose --json)
version=$(echo "$output" | jq -r '.schema_version')
if [[ "$version" != "v1" ]]; then
echo "Unexpected schema version: $version" >&2; exit 1
fi
Do I need Secure Boot enabled to use lamboot-tools?
No. Secure Boot is optional. All 11 core tools work on systems with Secure Boot disabled, not enrolled, or in audit mode. The lamboot-signing-keys and lamboot-uki-build tools are only needed if you want to manage or enroll Secure Boot keys and build signed UKIs. lamboot-diagnose will report Secure Boot status as an informational finding, not an error, if it is disabled.
Is there a package repository (APT, AUR, Copr) I can add?
Not in 0.9.1. lamboot-tools is distributed exclusively via GitHub Releases. This makes the GPG-verified tarball the single authoritative source and avoids repository trust chain complexity. If demand for native packages is significant, it will be tracked in the GitHub repository discussion. Pull requests for distribution-specific packaging are welcome.
What's the difference between lamboot-repair and lamboot-doctor?
lamboot-repair is a direct, non-interactive tool: you run it with a category or finding ID and it applies the fix silently. It is designed for automation and scripting. lamboot-doctor is an interactive session: it runs the full diagnostic, explains findings in plain language, asks before applying each change, and produces a before/after summary. Doctor calls repair (and other tools) internally to apply changes. It is a guided layer over the same repair primitives. For unattended use, pass --auto to doctor, which answers all prompts automatically.
Where can I report bugs or contribute?
Open issues and pull requests at github.com/lamco-admin/lamboot-tools. When filing a bug, attach the output of lamboot-diagnose --json (redact anything sensitive) and the output of lamboot-toolkit list --json. The run_id field in the JSON correlates log lines to the failing invocation. See the Troubleshooting page for the full list of information to collect.