Skip to content

Fix ARM Snapper dependency and first-run keyboard service packaging - #341

Open
scottjones wants to merge 1 commit into
omacom:masterfrom
scottjones:fix/arm-first-run-packages
Open

scottjones wants to merge 1 commit into
omacom:masterfrom
scottjones:fix/arm-first-run-packages

Conversation

@scottjones

@scottjones scottjones commented Sep 7, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Require Snapper on aarch64 as well as x86_64 in both desktop recipes; only the Limine stack remains x86-specific. Fresh btrfs Apple Silicon installs need Snapper for root configuration.
  • Install omarchy-brightness-keyboard-auto.service into systemd's user-unit directory from both settings recipes when the source contains it. Current Mac first-run setup requires this unit; its omission prevents the completion marker and repeats the notification stack.
  • Keep the existing stable source pin buildable: it does not contain this newer unit, so installation is conditional. Source pins and release versions are unchanged.

Verification

  • Shell syntax and git diff --check pass.
  • The companion desktop regression test executes the real package functions for all eight stable/development × aarch64/x86_64 × current-source/actual-stable-pin combinations. All pass; current-source cases verify every unit requested by the real first-run leaf.
  • Full ISO/rootfs rebuild with local desktop/settings packages 4.0.2-5 and Snapper 0.13.1-3, followed by a fresh encrypted M3 (j613) install: Snapper configuration and factory snapshot present, first-run marker complete, required user services enabled. Tester subsequently confirmed reboot and no repeated alerts.
  • This is source for review, not a production release/publish operation; the local test build supplied its own package release override.

Related work

@malik-na

Copy link
Copy Markdown
Member

Review and follow-up qualification on an M1 Mac, including a booted disposable ARM VM.

The Snapper dependency and conditional keyboard-unit packaging changes look correct. I found two separate integration issues in the surrounding recipes that matter for the Mac rollout. A proposed fix has been implemented and tested locally; no source changes have been pushed. The remote PR head was rechecked before this comment and remains 6d27290193109c07b0134360d382e64790ae5dda.

Exact revisions and test scope

  • Reviewed PR head: 6d27290193109c07b0134360d382e64790ae5dda. GitHub reports base a190c0e6b45a7f694f10bef867b07d0811036266.
  • The inspected synthetic merge was b3c83dc61adf19e0f8258faca7561849371a0ea3, whose first parent is be95483566c394a48b23e5f196631223cdc36882. These differ from the API-reported base, so they are recorded separately.
  • The final local proposal sits on local merge 2eb4708 of the PR branch and inspected master d5a2f30de7a9858be31eb090b1a7ecc71176b410. The implementation remains an uncommitted local diff; neither the merge nor the proposal was uploaded.
  • Final native ARM artifacts use Mac desktop source 5020d5cb514a6513946128e3b503573b66f3ca6c (merged desktop Add LM Studio Bionic #377). Source-compatibility checks also covered older source 346e69e1cec6c4e8924531874af6ba010a1bc99e and the integrated stable pin 0534987009061cbe2dacdde4ad564092ab698d12 (v4.0.3). Testing the upstream pin's packaging does not make it the Mac source used for the VM artifacts.

1. Existing Mac boot policy is removed by the ARM payload exclusion

The installed omarchy-settings 4.0.2-2 owns /etc/mkinitcpio.conf.d/omarchy_hooks.conf and thunderbolt_module.conf. The surrounding ARM recipe deletes that directory from the new payload. This exclusion already exists on the base: it is an integration issue exposed by this upgrade, not a defect introduced by this PR's Snapper/unit changes.

Comparing the effective configuration before and after that removal shows loss of plymouth and the explicit /etc/vconsole.conf inclusion, plus changed keyboard-hook ordering. Native asahi, encryption, filesystems, Btrfs and Apple HID configuration remain. I did not demonstrate an unbootable machine. The observed regression would affect a later initramfs rebuild; this paired package transaction does not itself rebuild it.

The local proposal keeps both historical paths owned and adds them to backup for both architectures. ARM receives native defaults at those paths; x86 retains its source-provided contents. This avoids needing a later migration to recover files already deleted by pacman.

Real pacman tests confirmed an important older-package case: the old archives have no backup hashes for these files. With backup protection introduced by the new package, existing stock and customized contents survive and the new defaults are staged as .pacnew. Missing files and fresh installs receive the defaults directly. Existing users should review .pacnew deliberately; automatically replacing it would defeat preservation.

The proposed ARM defaults extend the native hook arrays rather than replacing the encryption/storage stack: preserve custom hooks/modules/files, add missing Asahi/Plymouth support, place keyboard support before autodetect, and retain the console-file policy for Latin-capable layouts. Non-Asahi ARM is left with its native policy. Unsupported Asahi layouts or missing required hooks fail generation before mutating the arrays. Thunderbolt is added only if the selected kernel provides the module. This is scoped boot-file preservation, not a claim that every user setting is covered.

2. The integrated development recipe assumes a newer plocate source file

On the newer base, omarchy-settings-dev unconditionally installs default/systemd/system/plocate-updatedb.service.d/10-omarchy.conf. That file is absent from the tested Mac and older source trees, causing the actual package function to fail. This is independent of the keyboard-unit addition.

The local proposal uses the same existence guard already present in the stable recipe. Older source trees keep their existing locate setup leaf; newer trees still package the drop-in. The complete stable/dev source matrix passes with that guard.

Completed validation of the local proposal

Check Result and boundary
Native ARM builds PASS: all four desktop/settings stable/dev archives built with real makepkg, ImageMagick and fakeroot. These use the installed toolchain with dependency checks skipped at build time; they are not clean-container builds.
Source/architecture compatibility PASS: stable/dev settings against actual upstream stable and current Mac source for ARM/x86 architecture parameters, plus four executions against the older source. x86 staging is not a native x86 build or boot.
Archive inspection PASS: expected Snapper dependency, keyboard unit, root-owned config payload and backup metadata; no ARM Limine dependency injected.
Offline policy checks PASS: native/custom/systemd cases, repeated sourcing, non-Latin console case, other ARM, missing hooks/unsupported families and absent Thunderbolt.
Real pacman archive lifecycle in empty roots PASS: fresh, stock, customized, missing-config, rejected-transaction and repeat cases. These isolated roots disable dependency checks, hooks and scriptlets; the VM separately covers full transactions.
Booted KVM ARM guest transactions PASS: dependency-checked old 4.0.2-2 paired install, stock upgrade, customized upgrade, repeat, and fresh candidate reinstall, with real package hooks/scriptlets. Existing boot content and .pacnew behavior matched the preservation design.
Actual guest Snapper PASS: migration created the Btrfs root backend, cleanup timer enabled/active, repeat setup preserved a customized retention limit, and snapshot #1 was created. The actual migration runner then completed the pending migration and a second run without changing the preserved config. No restore was attempted.
Actual guest user manager PASS: keyboard-auto unit resolves from /usr/lib/systemd/user, loads and enables. It correctly skips activation because this generic VM has no Wayland/ambient-light environment (ConditionResult=no); this is not a physical keyboard test.
Native Asahi scratch initramfs PASS: baseline and candidate builds succeeded with identical file inventories, including Asahi, encryption, Plymouth, Btrfs and vconsole content. Effective hooks/modules/files match the installed policy. A missing-hook test failed while leaving an existing sentinel output unchanged. All outputs were scratch files; no host boot image was replaced.
Regression checks PASS: repository self-tests and desktop first-run/Snapper/keyboard fixtures. Local Docker build-isolation could not run because Docker API access was denied. The new local boot-policy CI test has not run on GitHub because nothing was pushed.

The first scratch initramfs attempt under fakeroot emitted a fakeroot diagnostic; both baseline and candidate were rerun successfully without fakeroot. Common firmware/consolefont/ARM microcode warnings were checked against the baseline, rather than attributed to the proposal.

VM policy and remaining acceptance limits

The VM booted a private copy of the RC Btrfs image with a generic ARM kernel, KVM and systemd. It had no network interface and only private guest disks. Its frozen-RC guard initially refused the package transaction as designed. To test the local unsigned packages, I archived only the disposable guest's /etc/omarchy-rc policy using the documented opt-out and used a guest-local pacman configuration permitting those local unsigned archives. This tests package behavior after opt-out; it does not qualify signed publication or normal frozen-RC updating. The guest finished with ALL_GUEST_TESTS_PASSED, migration-runner PASS and a clean poweroff.

The final stable test pair is labelled 4.0.3rc1-2 by local recipe metadata override; the Mac source version file still says 4.0.2. Development versions use a shallow-history count. These are qualification artifacts, not publication-ready version claims.

Physical Apple installation/boot/reboot, graphical unlock, real first-run session completion, keyboard idle/resume, lid/suspend, recovery and canary acceptance remain NOT TESTED for this proposal. Snapshot restore was explicitly SKIPPED. The reported keyboard idle symptom is not established as fixed by this PR: the relevant off/restore/wake helpers are unchanged. A successful generic ARM VM and scratch initramfs build cannot close those hardware gates.

No candidate packages, migrations, Snapper configuration or boot-policy changes were applied to the host. Local implementation, archives and logs are retained for review. No source push, PR title/body edit, merge or publication was performed. Mac rollout remains HOLD pending an agreed shipped fix and the remaining acceptance checks.

@malik-na malik-na left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Snapper dependency and conditional keyboard-unit changes look correct. Please resolve these two surrounding packaging issues here or in an explicit prerequisite before using this package set for the Mac rollout:

  1. Preserve the historical ARM mkinitcpio drop-ins with native defaults and pacman backup protection. Upgrading from 4.0.2-2 currently removes package-owned boot policy, losing Plymouth/console configuration and changing keyboard ordering on the next initramfs rebuild. This exclusion predates this PR; an unbootable machine was not demonstrated.
  2. Guard the integrated development recipe's plocate drop-in installation, as stable already does. Its unconditional install fails against the tested Mac/older source trees where that file is absent. This is independent of the keyboard-unit addition.

Local fixes are implemented for fresh installs and upgrades, including customized-file preservation. Native ARM builds, real pacman lifecycle checks and disposable ARM VM tests passed; the boot-policy checks were rerun successfully. Physical Apple boot/recovery acceptance remains outstanding. No source changes have been pushed.

The PR head and current master still match the tested revisions. Full evidence and fix details: #341 (comment)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants