Drop another machine-id's Limine entries without rebuilding the UKI

[joshuaswarren]

This PR targets the convergence branch (#14431), because it changes omarchy-provision-owner as that branch has it. It can move to quattro when #14431 lands.

Owner provisioning refreshes the boot entries whenever limine.conf holds an entry for a machine-id other than this machine's. That refresh starts the menu over from the template and runs limine-update, which is a full UKI build. On an encrypted Apple Silicon first boot, it runs right after the re-key's own UKI build. It cost 9 s on a 14-inch M2 Max (2026-10-06) and 9 s on a 13-inch M1 (2026-10-01).

When this machine's entry is already in the menu, the refresh now drops the other machine-ids' OS entries with limine-entry-tool --remove-entry, deletes their ESP directories, and builds nothing. Two cases still start the menu over and rebuild, as before. A menu without this machine's entry (a factory reset's fresh identity) does. An entry tool that fails does too. A second commit makes the log say which of these happened.

test/shell.d/limine-foreign-entries-test.sh is new, with four cases:

• A menu holding this machine's entry drops another machine-id's entries without a rebuild.
• A menu without this machine's entry starts over and rebuilds.
• A failed entry tool falls back to starting the menu over.
• A current menu is left alone.

luks-rekey-journal-test.sh gets one stub line. Its fixture's stale entries come from another identity with no entry for this machine, so the entry tool cannot drop them, and the menu starts over as that test expects. It passes (27 ok, 0 not ok).

Checked at d4d6950, rebased on the convergence branch head 58a6463, on a Debian host:

• limine-foreign-entries-test.sh passes (4 ok), and so does luks-rekey-journal-test.sh when run alone.
• ./test/shell, the full suite: 51 of 346 test files fail on this branch and 53 of 345 on 58a6463 alone. Every failing file on the branch also fails on 58a6463, which has two more (flaky). So this change adds no failing file. The failures come from this host, which has no display and no systemd session. luks-rekey-journal-test.sh fails inside the full run on both trees, under load, and passes alone.

Not measured yet: a first boot with this change. The 9 s is the cost of the build it removes, on the two boots above. A separate mac-pkgs change (omacom/omarchy-mac-pkgs#17) removes the other duplicate build in the re-key. The two are independent.

Update, ba6711a (greptile review): the other machine-id's ESP directory is now deleted before the entry tool runs, and a refused delete falls back to the rebuild instead of looking like a clean refresh. limine-foreign-entries-test.sh has a fifth case for it (5 ok; the new case fails on d4d6950). luks-rekey-journal-test.sh still passes.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] This PR appears safe to merge; no new actionable issue was found.

Summary

Owner provisioning now removes foreign machine-id entries without rebuilding the UKI when the current machine already has a menu entry.

• Missing current entries, failed directory deletion, failed entry removal, or remaining stale entries use the existing reset-and-rebuild path.
• Five fixture cases cover removal, fallback, and an unchanged menu.
• The earlier cleanup finding is addressed: a refused directory deletion returns failure before the entry tool runs.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Check boot menu] --> B{Stale entries?}
  B -->|No| F[Continue provisioning]
  B -->|Yes| C{Current machine entry exists?}
  C -->|No| E[Reset menu and rebuild UKI]
  C -->|Yes| D[Delete foreign directories and remove entries]
  D --> G{Succeeded and menu is current?}
  G -->|No| E
  G -->|Yes| F
  E --> F

Loading

_{Reviews (3) · Last reviewed commit: "Delete the other machine-id's ESP direct..." · Reviewed by Greptile}