Warn instead of failing update-verify on an owner-managed boot chain

[satchlj]

Posted by Claude (AI assistant) on behalf of @satchlj.

Cause

update-verify runs omarchy-apple-silicon-boot-check --boot-chain, which first needs linux-aurora or linux-asahi. A Mac that boots a kernel and m1n1 stage 2 its owner builds has neither installed. Every omarchy update would then end with "cannot tell which kernel boots: neither linux-aurora nor linux-asahi installed" and "This Mac might not boot what the update installed, so do not reboot yet", after the transaction, migrations and AUR builds have all run. Nothing the owner rebuilds makes it pass. Today the only way out is to remove omarchy-mac-boot, so that the dispatcher's status 3 makes it a warning. That also removes the Limine, initramfs and m1n1 hooks the rest of the Mac's boot still uses.

This came from an M3 MacBook Air (J613) whose daily boot is a hand-built kernel and m1n1 stage 2. It still runs omarchy-mx-mac, so the failure is read from the code, not observed: we compared the boot check with the Mac's recorded packages and its /etc/default/update-m1n1, which sets its own M1N1 and DTBS.

Fix

• The owner names the chain on the first non-blank line of /etc/omarchy-mac-boot/owner-boot-chain, next to dtb-overlays.opt-in.
• update-verify still runs the check, so what it found is still shown. When the check fails and the file exists, update-verify says the boot files were not verified, prints the named chain and exits 0. The update then finishes and offers its reboot. When the check passes, nothing extra is printed.
• Without the file nothing changes. The full boot check and omarchy-mac-snapshot-check do not read the file, so snapshot restores are still guarded.
• The Updates page of the manual describes this, in the same commit.

A question for review: would you rather have something narrower, such as a boot-check switch like M1N1_UPDATE_DISABLED that skips only what an owner took over? On this Mac that would need several switches (no packaged kernel, its own M1N1, its own DTBS), so one declaration for the whole chain seemed the honest scope. I can narrow it.

Tests

• omarchy-mac-boot/test/update-verify-test.sh, with the file present:
  • a chain that passes prints nothing extra;
  • a missing UKI and a Mac with no packaged kernel both exit 0 with a warning. They still show the check's reason and name the chain, or say the file names none.
  • Without the file, the Mac with no packaged kernel is still refused.
  • With the old entrypoint, the new case fails.
• test/integration/mac-update-boot-verify-test.sh: with a declared chain and a missing UKI, omarchy update -y exits 0 and offers the reboot. It shows the check's reason and the warning, and not "The update is not finished". This fails with the old entrypoint.
• Environment: Ubuntu 24.04 aarch64 (bash 5.2), not the Arch container CI uses. OMARCHY_TEST_RUNTIME was omacom/omarchy quattro @ 077ac1d; the two tests above also pass with the pinned runtime e1b0e5e.
  • Both tests above pass.
  • Every other omarchy-mac-boot suite and integration test passes, except five that fail the same way on main in this environment and do not touch these files:
    • dtb-overlays-test.sh stops at its dtc version check (it needs 1.7.1; the machine has 1.7.0);
    • update-m1n1-locale-test.sh (the machine's locales);
    • snapshot-check-test.sh, at "the check runs before the Limine activation gate";
    • apple-platform-hooks-test.sh and mac-keyboard-layout-seam-test.sh need node and lua, which the machine lacks.
  • check-scope and check-architecture-gates pass.
  • shellcheck was not available, so it was not run.
• Tested with the repository's test suites only, not on a Mac or any other device, and without the cold-boot evidence CONTRIBUTING asks of boot-critical changes. No boot files change; the change only decides whether a failed check ends the update.

🤖 Generated with Claude Code

[scottjones]

Thanks, this is a real problem for hand-built chains, and the fix is nicely contained: the check still runs and shows its reasons, the snapshot-restore check ignores the file, and the tests cover both sides.

On your scope question: I agree with one declaration for the whole chain. A set of narrower switches would be more fragile for a Mac like yours.

One thing I'd like addressed before approving: a forgotten declaration silently turns real failures into warnings. If an owner later goes back to the packaged kernel and m1n1 but leaves /etc/omarchy-mac-boot/owner-boot-chain in place, a genuine problem (a missing UKI, a stale m1n1) only warns, and the update offers the reboot. Because a passing check prints nothing extra, the file never shows up until the moment it hides something. Two small changes would cover it:

1. In the warning, say how to go back, e.g. "To have updates verify the boot files again, remove /etc/omarchy-mac-boot/owner-boot-chain."
2. Print one line on every update while the file exists, even when the check passes, e.g. "Boot files verified; /etc/omarchy-mac-boot/owner-boot-chain is present, so a failed check would only warn." That changes your "a chain that passes prints nothing extra" test, but it keeps the declaration visible.

Happy to approve once that's in.

[satchlj]

Posted by Claude (AI assistant) on behalf of @satchlj.

Thanks, @scottjones, good catch. Both changes are in 3c7899d, as a new commit:

1. The warning now ends with "To have updates verify the boot files again, remove /etc/omarchy-mac-boot/owner-boot-chain."
2. While the file exists, a passing check prints "Boot files verified; /etc/omarchy-mac-boot/owner-boot-chain is present, so a failed check would only warn." A Mac without the file prints nothing new.

The Updates page says both. update-verify-test.sh now expects that line where it used to expect nothing extra, checks the warning's new line, and checks that a Mac without the file is not told about it. The integration test adds a passing chain with the file present. With the previous entrypoint, both tests fail on the new lines.

Tests, Ubuntu 24.04 aarch64, with the runtime at the pinned e1b0e5e, 077ac1d and current quattro 77bfaca: update-verify-test.sh, mac-update-boot-verify-test.sh, check-scope and check-architecture-gates pass. The rest of both suites gives the same results as main on that machine: four suites fail there identically, for its dtc 1.7.0, its locales, and missing node and lua. Not run on a Mac.

🤖 Generated with Claude Code