Archinstall unmounts the ESP before the Omarchy finalizer runs, leaving /boot empty in the target chroot. Mount it so Limine setup can access the generated configuration and EFI artifacts.
The installed ESP uses root-only masks while finalization runs as the target user. Mount it temporarily with fmask=0022,dmask=0022 and verify the target user can traverse /boot; the installed fstab remains unchanged.
Remove the fallback shell from the installer invocation so finalizer errors propagate instead of reporting a completed installation and rebooting a partially configured system.
Pairs with omarchy-pkgs' fold of omarchy-limine into omarchy-settings.
Changes:
- EARLY_BOOTSTRAP_PACKAGES in phases_impl.py drops omarchy-limine.
The limine configs it shipped (mkinitcpio hooks, entry-tool drop-ins,
snapper template, default/limine/, default/snapper/) now come with
omarchy-settings, which is already in the early bootstrap.
- builder/build-iso.sh's offline-mirror seed list and post-mirror filter
no longer reference omarchy-limine.
- builder/build-omarchy-packages.sh's build queue drops omarchy-limine.
- Test manifests (fresh-4.json, fresh-4-semantic.json) no longer expect
omarchy-limine in the installed-packages list. The /etc/pacman.d/hooks/
99-omarchy-limine.hook entry stays — that hook file is generated by the
orchestrator regardless, and the filename is descriptive, not tied to
the package name.
Pairs with omarchy-installer's rename of bin/omarchy-setup-user to
bin/omarchy-finalize-user. The orchestrator now invokes
omarchy-finalize-user --force --first-install in the run_chroot_finalizer
phase, and the phase-ordering docstring is updated to match.
archinstall 4.3 maps the deprecated top-level 'bootloader': 'Limine'
to BootloaderConfiguration(bootloader=Limine, removable=True) (per
lib/args.py:185-190 and lib/models/bootloader.py:56-69). Our new
_install_limine_omarchy mirrors archinstall's removable handling: it
would copy BOOTX64.EFI to EFI/BOOT (fallback path) and SKIP
efibootmgr, neither of which is what we want.
Switch to the explicit bootloader_config form with removable=false
so we take the EFI/limine path + register the 'Limine' NVRAM entry
as intended.
archinstall's add_bootloader creates EFI/arch-limine/{BOOTX64.EFI, BOOTIA32.EFI}, writes a limine.conf with an Arch Linux entry, and registers an efibootmgr label "Arch Linux Limine Bootloader" — only for limine-snapper.sh to delete it all and rebuild with Omarchy branding via limine-mkinitcpio-hook.
Replace the add_bootloader call with _install_limine_omarchy, which does the same work archinstall's _add_limine_bootloader does (UEFI EFI binary copy + efibootmgr register, or BIOS limine-bios.sys + limine bios-install) but with Omarchy-owned paths and labels from the start:
- EFI subdir: EFI/limine (not EFI/arch-limine)
- efibootmgr: label "Limine" (not "Arch Linux Limine Bootloader")
- loader path: \EFI\limine\BOOTX64.EFI
Compute the kernel cmdline directly from disk_config instead of harvesting it from a file archinstall wrote (whose path keeps drifting across versions). Then write /etc/default/limine and /etc/kernel/cmdline, and stage /boot/limine.conf from our styling template — limine-mkinitcpio-hook will add the actual boot entries when it deploys.
Adds limine + efibootmgr to EARLY_PACKAGES (archinstall used to pacstrap these as a side effect of add_bootloader).
Does not modify limine-snapper.sh — its cleanup code will simply no-op because there are no arch-limine paths or "Arch Linux Limine Bootloader" entries to find. That code can be pruned in a follow-up.
archinstall 4.3 writes limine.conf to <target>/<esp_mount>/EFI/arch-limine/
limine.conf for UEFI non-removable installs (lib/installer.py:1487), not
to /mnt/boot/limine.conf as our code assumed. Older archinstall versions
used different paths.
Probe the 4.3 paths (arch-limine, BOOT, limine subdir) and the legacy
/boot/limine.conf in order; pick whichever exists. Error message now
lists everywhere it looked so future drift is easy to diagnose.
Restore the env + redirect setup that the previously-working ISO
installer used (matching /home/ryan/Downloads/ISO scripts/.automated_script.sh):
export COLUMNS=$(tput cols)
export LINES=$(tput lines)
exec > >(tee >(sed CSI-strip >> log) 2>/dev/null) 2>/dev/tty
export CLICOLOR_FORCE=1
export FORCE_COLOR=1
The cutover commit (064b5e2) silently dropped these. Subsequent
attempts to fix the TTY/gum rendering by reshaping the redirect were
all symptom-chasing — the proven shape was correct. The key insight:
- gum draws its TUI on stderr, not stdout. 2>/dev/tty keeps that
rendering on the real terminal.
- stdout-as-pipe (via tee) is *desired*: it lets gum detect a
non-TTY stdout and skip cursor-position probes (CSI 6n). Without
that detection, the DSR replies leak as visible ^[[13;1R bytes.
- CLICOLOR_FORCE/FORCE_COLOR force gum to still emit colour despite
stdout being a pipe.
Also drops the configurator's _drain_tty workaround — unnecessary
once gum stops sending DSR queries in the first place.
David Heinemeier Hansson