Repair missing zram configuration before activating swap

[mostlydev]

On an ARM install upgraded to omarchy-settings 4.0.2-2, the zram default exists under /usr/share/omarchy/default/ but no configuration is installed where zram-generator reads it. Migration 1787669934.sh then starts systemd-zram-setup@zram0.service, fails with Device zram0 not found, and leaves the migration queue blocked. Rebooting does not restore the missing configuration.

Repair the existing migration so pending installations can reach the fix: copy the shipped default to /etc/systemd/zram-generator.conf only when no main configuration or drop-in exists at any supported configuration level, then reload systemd and start dev-zram0.swap. Starting the swap unit activates swap as well as setting up the device. Existing configuration, empty files, symlink masks, and active swap are preserved; an active device with missing persistent configuration gets the fallback without being restarted.

The fallback deliberately avoids an unowned /usr/lib file. A future package can restore its vendor drop-in without a file conflict, and that drop-in takes precedence over the fallback main configuration. This is a repair for the blocked migration, not a replacement for the package payload fixes in #353 or checkout wiring in #319. Users who already completed this migration still need the package fix. Related to #369 and #311.

Validation:

• Focused zram regression tests pass: missing and existing packages, absent configuration, custom configurations at all supported levels, empty/disabled/masked configurations, active swap with absent persistent configuration, repeated users, and package/configuration/activation failures.
• The installed zram-generator passes an unprivileged ZRAM_GENERATOR_ROOT integration test: no swap unit before repair; a swap unit with the setup dependency and swap.target link afterward.
• Independent QA and diff review pass for the focused change. Command metadata checks pass for 458 commands; parser-aware syntax checks pass.
• Local ./test/all: CLI passes; 255/256 shell test files pass on both this branch and untouched origin/quattro (291a6989). Both fail the same unrelated launch-about-test.sh assertion, a roomy window animates. No green local aggregate is claimed.
• Local ./tests/all has the same pre-existing piped --help assertion failure in test-mac-setup.sh on both revisions. Hosted PR CI passes test/all, tests/all, and Syntax + shellcheck.
• The hosted ARM installation fails the existing package-source assertion (hyprtoolkit installed=0.5.4-6 expected=0.5.4-5.1), unrelated to these two changed files. An independent unchanged-quattro run on my fork reproduces the identical failure. Isolating the existing package-selection fix from Integrate Apple Silicon stabilization fixes for 4.0.3rc1 #377 yields a passing ARM run, including the real-Pacman regression and fresh/repeat installation, with all three selected compositor package versions retained. That comparison branch does not include this zram change; it establishes the independent installer defect and its existing fix.

No privileged migration or swap changes were run on the host as part of testing this PR.

[malik-na]

Missing zram config is restored, /dev/zram0 activates, reruns are idempotent, and existing custom config is preserved.

Good to merge.

[scottjones]

Reviewed independently and tried to break it; it holds.

Things I checked rather than took on trust:

• The four-level detection loop matches zram-generator.conf(5), and testing -e || -L correctly treats an empty file or a /dev/null symlink mask as a deliberate decision to disable zram rather than something to overwrite.
• The precedence argument in the description is correct, not hand-waving. The man page: "The main configuration file is read before any of the configuration directories, and has the lowest precedence." So a corrected settings package can ship /usr/lib/systemd/zram-generator.conf.d/90-omarchy.conf and it will override this fallback, with no file conflict. Leaving /usr/lib package-owned was the right call.
• daemon-reload runs before systemctl show, so LoadState is read after the generator has had a chance to produce the unit. That ordering matters and it's right.
• Switching the start target from systemd-zram-setup@zram0.service to dev-zram0.swap is the substance of the fix, not a rename: the setup service alone creates the device without enabling swap.
• The real-generator integration test is doing real work. Against the installed zram-generator on an aarch64 Asahi machine it produced no swap unit before the repair, and afterwards dev-zram0.swap with Requires=systemd-zram-setup@zram0.service and the swap.target link. That's the assertion that makes the fallback content believable.
• Full test file: 8/8 pass. bin/omarchy commands --check 458 commands. ./test/cli green.

One correction to the description, in your favour. It says "users who already completed this migration still need the package fix." They didn't complete it — the old sudo systemctl start systemd-zram-setup@zram0.service failed non-zero on exactly the affected machines, so omarchy-migrate never wrote the marker and the queue stayed blocked. The repaired migration re-runs for precisely the population that was broken, which is a better outcome than the description claims.

Two non-blocking notes for later:

• OMARCHY_ZRAM_ROOT is a test seam in production code. There's precedent in the repo and it buys a genuinely good test, so I'm not asking for a change — just flagging it as a deliberate choice rather than an accident.
• docs/file-layout.md:129 documents /usr/lib/systemd/zram-generator.conf.d/90-omarchy.conf as the canonical destination, and this fallback deliberately lands somewhere else and stays there permanently once written. A line in that doc, or in the migration comment, saying the /etc file is a permanent unowned fallback would save the next person the reasoning.

Approving.

[duketopceo]

Checked this out on a MacBookPro18,1 (aarch64, omarchy-settings 4.0.3-1) and ran both suites: zram-package-test.sh 8/8 pass, zram-migration-test.sh all pass — including the real zram-generator invocation creating dev-zram0.swap from the repaired config.

The approach composes correctly with 1785013000: writing the fallback to /etc/systemd/zram-generator.conf (not /usr/lib) means the drop-in migration's guard still works, and a future packaged drop-in takes precedence over the fallback without a file conflict.

One interaction worth noting (also posted on #369): on machines like mine the /etc conf already exists, so this repair no-ops — correct. But 1785013000 exits 0 while the /usr/lib drop-in is absent, so it's marked complete and will never clean up the legacy /etc conf once the drop-in finally ships. Not this PR's job to fix, but the packaging fix will want a companion cleanup step.

[malik-na]

Pushed 9304639d7be44fbd417c5c86eacb0f9ea2fbff54 to fix incorrect migration completion when the ARM package helper skips an unavailable zram-generator and returns success. The migration now checks that the required package is actually installed before touching configuration or services; otherwise it fails and remains pending.

The regression test uses the real package helpers and migration runner with inert package/service operations. It verifies failure without a completion marker, successful recovery when the package becomes available, and no repeated work after completion. The new test fails on the original PR migration and passes with this correction.

Validation:

• 154 focused functional/CLI checks passed on the corrected PR and its merge with quattro; metadata, parser checks, and independent source review passed.
• Fresh GitHub fetch confirmed quattro at 2d14b6a479341d7955609f0b604fc04358721ddd and the original PR head at e55c1a37aa0485f2f5aaa2bd3a051b595f08a00f. Rebuilding that merge from the fetched refs and replaying the identical fix passed all 19 focused zram checks, including real generator output validation; the negative control failed at the expected assertion.
• Only the migration and its existing test file changed. No live package installation, swap activation, or reboot was performed.

Fresh hosted CI is still needed for this new commit. The previous ARM installation job failed on hyprtoolkit installed=0.5.4-6 expected=0.5.4-5.1; that failure was not caused by this migration diff. This correction does not replace the runtime package delivery in omarchy-mac/omarchy-pkgs-aarch64#13 for new installs and users whose migration was already completed.