GPT review:
Review: partly right, but the mkinitcpio claim is overstated for current Omarchy.
- Omarchy already uses mkinitcpio’s host-specific mechanism: autodetect.
- Current source sets:
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
- The one defensive choice is keyboard before autodetect. Per mkinitcpio, hooks before autodetect are installed “in full”, so moving autodetect before keyboard would shrink the keyboard/HID module set.
- I tested temporary initramfs builds locally:
- current Omarchy-style order: ~375 modules, ~30M image
- autodetect before keyboard: ~171 modules, ~28M image
- without Plymouth: ~26M image / ~13.5M main compressed cpio
So yes, there’s cleanup possible, but not a 150MB → 15MB win on the normal Omarchy path. A 150MB image is likely a fallback/full image or UKI accounting, not the regular host-autodetected image.
The risky part: making the initramfs more host-only can break early boot in edge cases: external keyboards for LUKS, changed storage controller, moved disk, Thunderbolt docks, rescue/fallback
scenarios. Omarchy’s current broad keyboard choice looks intentional.
The NetworkManager-wait-online point is more actionable. Omarchy already masks systemd-networkd-wait-online.service, but not NetworkManager-wait-online.service. Since Omarchy doesn’t use NetworkManager
by default, adding a guarded mask for existing Arch installs that still have it would be low-risk and could prevent offline boot delays.
Recommendation:
1. Add guarded masking for NetworkManager-wait-online.service in install migration.
2. Do not blindly switch mkinitcpio to more aggressive host-only defaults unless tested on encrypted-root external keyboard/dock cases.
3. If we want the mkinitcpio optimization, make it opt-in or benchmark-driven.