Summary
On a fresh manual install (git clone + install.sh) onto a GRUB-booted Arch system whose kernel is newer than the one pinned in the omarchy repo, the installer leaves /boot in an unbootable state. The next reboot drops the machine into an unbootable kernel (on EC2: no ENA network driver, instance unreachable; had to recover via volume surgery from another instance).
Mechanism
install/preflight/disable-mkinitcpio.sh moves 60-mkinitcpio-remove.hook and 90-mkinitcpio-install.hook to *.disabled to speed up package installation — a reasonable optimization.- During package install, the omarchy repo downgrades
linux to its pinned version (in my case host was 7.1.2-arch3, omarchy repo pins 7.0.10-arch1).
- With the hooks disabled, the downgrade neither copies the new
vmlinuz to /boot nor regenerates the initramfs.
- Nothing re-enables the hooks afterwards —
grep -rn 'hook.disabled' across the repo shows only the disable side; no restore in post-install/.
Result after install:
/boot/vmlinuz-linux → still the old kernel (7.1.2)/usr/lib/modules/ → only the new pinned kernel (7.0.10)- initramfs → stale
- ⇒ boot panics or comes up without disk/network modules
On Limine/UKI systems the omarchy-managed boot tooling presumably papers over this, but the manual-install path explicitly supports existing bootloaders (guard.sh only warns about non-Limine setups), and there the breakage is silent until reboot.
Repro
Arch official cloud image (GRUB, kernel newer than omarchy pin) on EC2 → manual install v3.8.2 → reboot → unbootable. Verified the same disable-without-restore logic is present on current master.
Suggested fix
In post-install/ (or a trap on installer exit):
for h in 60-mkinitcpio-remove 90-mkinitcpio-install; do
[[ -f /usr/share/libalpm/hooks/$h.hook.disabled ]] && sudo mv /usr/share/libalpm/hooks/$h.hook.disabled /usr/share/libalpm/hooks/$h.hook
done
# if the linux package changed during install:
KVER=$(ls /usr/lib/modules | head -1)
sudo cp "/usr/lib/modules/$KVER/vmlinuz" /boot/vmlinuz-linux
sudo mkinitcpio -p linux
Related but distinct from #5026 (that's a DKMS/depmod ordering race on updates; this is the install-time disable-without-restore on the manual path).
Happy to PR if the direction sounds right.
Summary
On a fresh manual install (git clone +
install.sh) onto a GRUB-booted Arch system whose kernel is newer than the one pinned in the omarchy repo, the installer leaves/bootin an unbootable state. The next reboot drops the machine into an unbootable kernel (on EC2: no ENA network driver, instance unreachable; had to recover via volume surgery from another instance).Mechanism
install/preflight/disable-mkinitcpio.shmoves60-mkinitcpio-remove.hookand90-mkinitcpio-install.hookto*.disabledto speed up package installation — a reasonable optimization.linuxto its pinned version (in my case host was 7.1.2-arch3, omarchy repo pins 7.0.10-arch1).vmlinuzto/bootnor regenerates the initramfs.grep -rn 'hook.disabled'across the repo shows only the disable side; no restore inpost-install/.Result after install:
/boot/vmlinuz-linux→ still the old kernel (7.1.2)/usr/lib/modules/→ only the new pinned kernel (7.0.10)On Limine/UKI systems the omarchy-managed boot tooling presumably papers over this, but the manual-install path explicitly supports existing bootloaders (guard.sh only warns about non-Limine setups), and there the breakage is silent until reboot.
Repro
Arch official cloud image (GRUB, kernel newer than omarchy pin) on EC2 → manual install v3.8.2 → reboot → unbootable. Verified the same disable-without-restore logic is present on current master.
Suggested fix
In
post-install/(or a trap on installer exit):Related but distinct from #5026 (that's a DKMS/depmod ordering race on updates; this is the install-time disable-without-restore on the manual path).
Happy to PR if the direction sounds right.