Let updates take over the drop-ins omarchy-settings ships on aarch64 - #651
Merged
Merged
Conversation
omarchy-settings now ships its memory, USB and mkinitcpio drop-ins on aarch64 too, so a Mac with an unowned copy had every takeover refused and every update failed. The Mac keeps only its boot chain, /usr/lib/initcpio and pacman configuration, plus an mkinitcpio file whose own HOOKS carry the asahi or busybox encrypt hook: the HOOKS baseline sorts before it, so replacing it would move a legacy Mac to the systemd line while GRUB still unlocks with cryptdevice=.
The HOOKS baseline carries a busybox encrypt line in an indented branch, so an unowned copy of it was refused as if it set the Mac's unlock.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
omarchy-settings ships its memory, USB and mkinitcpio drop-ins on aarch64 now (omarchy-pkgs #638), but omarchy-mac-boot's
update-takeover(#636) and quattro-upstream's inline copy inomarchy-update-system-pkgs-when-conflictedstill refused them. A Mac with an unowned copy (afteromarchy-upgrade-to-quattro --overwrite, say) had every takeover refused, so every update failed.Both lists now keep only the boot chain (
/boot, GRUB, Limine),/usr/lib/initcpioand the pacman configuration. One narrow guard stays for mkinitcpio: a file whose own top-levelHOOKS=/HOOKS+=line carries theasahior busyboxencrypthook is refused, with the fix in the message. The HOOKS baseline (00-omarchy-hooks.conf) sorts beforeomarchy_hooks.conf, so replacing a legacy Mac's unowned copy would switch its initramfs to the systemd line while GRUB still unlocks withcryptdevice=.Testing (Arch container, non-root):
mac-update-takeover-test.sh(kept paths refuse; every aarch64 settings drop-in passes absent or present; the legacy HOOKS layouts refuse, commented orsd-encryptlines don't), the boot package suite, andtest/shell.d/update-file-conflict-test.sh(the settings drop-ins no longer refuse on Apple Silicon). shellcheck clean. Second review: no blockers; its one finding (indented HOOKS lines in the baseline's own branches counted, so an unowned copy of the baseline was refused) is fixed by reading top-level lines only, with a test. Scott's round-2 review of omacom#13362 raised the list; design debated before coding.