The dotfiles clone used to land directly in /mnt/etc/skel, gated solely by
clone_skel_dotfiles. That meant run_tui=YES + clone_skel_dotfiles=NO cloned
nothing anywhere, so tui-install.sh (which only exists inside the repo, not
in the embedded live-ISO scripts) had nothing to run and the TUI step always
failed.
Clone the repo once into the live environment ($HOME/Dotfiles) whenever
either toggle is YES, then serve both the skel copy and — as a fallback
right before the TUI runs — a direct copy into the new user's home from
that single clone, no extra network fetch needed. arch-autoinstall.sh's
skel clone also moved out of the chroot heredoc so it can share the same
live clone.
When clone_skel_dotfiles=NO, the fallback copy in the new user's home is
transient: after tui-install.sh finishes, materialize every symlink that
shell-setup.sh/hyprlua/hyprland/niri point into ~/Dotfiles (shell rc's,
nvim/starship/alot/yazi/spotify-tui configs, config-updater scripts) into
real copies, then remove the checkout — so declining skel persistence
doesn't leave a system full of dangling symlinks.
Decouple the base installer's "run dotfiles TUI" choice from cloning the
dotfiles repo into /etc/skel and from the new user's default shell, so
declining both actually yields a bare system: no dotfiles, plain bash,
no DE, no display manager, and a working agetty login on tty1. Also add
an explicit toggle in the TUI for syncing the configured user's ~/.config
back into /etc/skel, previously unconditional.
Separately, core.sh's "svc" component unconditionally staged a greetd
config that launches Hyprland and enabled greetd.service — even when no
DE was selected, and even for DEs (GNOME, KDE Plasma, COSMIC, XFCE,
LXQt, Sway) that install their own display manager. That left greetd
racing the DE's native DM (or agetty, in the no-DE case) for tty1, and
Sway additionally got a greeter pointed at the wrong compositor. Gate
greetd on the DE selection and have every DE module disown getty/greetd
before enabling its own DM, matching the pattern hyprland.sh/niri.sh
already used; add a Sway-specific tuigreet config.
Found while testing both installers end-to-end in VMs:
- Wait for archiso's pacman-init.service instead of racing it. The installer
autostarts at login while the live keyring is still being populated
asynchronously, so every package failed with "signature is unknown trust" /
"invalid or corrupted package (PGP signature)". Do not run pacman-key --init
ourselves (corrupts the half-built keyring); wait, then refresh
archlinux-keyring so an ISO built weeks ago still trusts current keys.
- archbaseos-guided-install.sh: honor the answerfile's password/luks_password
fields; previously it always prompted interactively, so a documented
"zero-interaction" netboot/WDS install hung forever with no console.
- Install GRUB to the UEFI removable-media fallback (/EFI/BOOT/BOOTX64.EFI) in
addition to the NVRAM entry. Without it, an installed disk with empty/cleared
NVRAM (fresh board, CMOS reset, or a cloned/redeployed image — the whole point
of this installer) shows "No bootable device". Verified: the disk now boots to
the login manager with fresh NVRAM.
- build.sh: sudo rm -rf the work dir. mkarchiso runs as root and leaves
root-owned files if interrupted, so the next plain rm -rf aborted the script
under set -e before mkarchiso could run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MUhrcFU8J1Hnf7vNqNxZNi
Fixes found during a complete archiso → FreeIPA DC → client enrollment →
ansipa policy deployment test cycle (Rocky 9 client VM, FreeIPA in Docker):
arch-autoinstall.sh:
- Add openssh to pacstrap — was missing, breaking headless/automated installs
- Enable sshd at boot and set PermitRootLogin yes for post-install access
ansipa-install-packages.sh:
- Fix broken uninstall logic: three always-true conditions caused every package
removal to be silently skipped; replace with a state-file-based approach that
tracks packages installed by ansipa and removes only those when the IPA group
disappears
ansipa-enforce-policies.sh:
- Add usr_admin policy: creates /etc/sudoers.d/ansipa-usr-admin granting full
sudo to the FreeIPA usr_admin user group on every enrolled host; reverted
when the IPA group is deleted
- Add usr_prt_<printer> policy: auto-adds CUPS printers for FreeIPA user group
members at login; printer URI stored in IPA group description; per-user ACL;
reverted when group is deleted or membership ends
deploy-ansipa-policies.yml:
- Document usr_admin and usr_prt_* policies in header comment
- Install cups package on clients (required for printer policy)
FreeIPA container (image/):
- Add docker-env.service: extracts IPA_*/SMB_*/LUKS_*/KEYCLOAK_* env vars from
/proc/1/environ into /etc/container.env on container start; services read from
there rather than relying on PassEnvironment (which is lost on container restart)
- Add run.sh: wrapper that starts FreeIPA with --cgroupns host, required on cgroup
v2 hosts (WSL2, recent Linux) because Docker Compose schema does not expose
cgroupns_mode; also wires LUKS_KEY_UPLOAD_PASSWORD which the SMB service needs
- Dockerfile: copy + enable docker-env.service; add glibc-langpack-en for locale
- ansipa-smb.service: use EnvironmentFile=/etc/container.env (via docker-env.service)
instead of PassEnvironment; add docker-env.service dependency
- ipa-first-boot.service: add docker-env.service dependency + EnvironmentFile
- ipa-first-boot.sh: add --skip-mem-check (container has limited cgroup memory
visibility); remove --no-reverse from non-DNS path (was invalid without DNS)
- docker-compose.yml: add prominent cgroupns note explaining when to use run.sh
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DHops6PU4c2Mv5UyhUj8Ms
The temporary setup drop-in granted `NOPASSWD: ALL`, which covers `sudo <cmd>`
but NOT `sudo -v`. Installers run by the TUI (starship, rustup, …) call `sudo -v`
to pre-authorise, and that check still demands a password whenever the user has
any password-required sudoers entry — which they do, via the wheel rule in
10-wheel. The result was a hidden `[sudo] password for <user>:` prompt that
stalled the otherwise-unattended module install.
Add `Defaults:<user> !authenticate` to the 99-setup-nopasswd drop-in (in both
the auto and guided installers) so the auth check is skipped entirely for the
setup user; `sudo -v` and `sudo <cmd>` are now both passwordless during setup.
Verified live in a VM: `sudo -nv` for the user went from "a password is required"
to rc=0 after adding the line.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R5kHioUMK3mtf2eiLEozCM
Previously the user password (and the LUKS passphrase for encrypted installs)
were always prompted interactively, so an answerfile install could never be
fully hands-free. Add optional "password" and "luks_password" answerfile fields:
- arch-autoinstall.sh: read both via af_get; when present use them (chpasswd /
cryptsetup --key-file=- with --batch-mode and stdin-piped luksAddKey auth),
otherwise fall back to the interactive prompt. Empty/null/absent => prompt.
- generate-answerfile.sh: replace the "passwords are never stored" notice with
an optional confirmed-entry password prompt (and a LUKS one when encryption is
enabled); emit both as JSON (null when declined).
Secrets stored this way are plain text in the file (and world-readable once
embedded in an ISO) — documented in the header; decline to keep prompting.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R5kHioUMK3mtf2eiLEozCM
The base installers granted wheel sudo with `echo '%wheel ... ALL' >> /etc/sudoers`.
Because the stock sudoers ends with `@includedir /etc/sudoers.d`, that appended
rule is parsed AFTER the drop-ins, and since sudo applies the last matching rule,
it overrode the temporary 99-setup-nopasswd NOPASSWD rule — so the user had to
re-enter their password on every pacman/yay/flatpak call while the TUI installed
modules.
Grant wheel via /etc/sudoers.d/10-wheel instead, which sorts before
99-setup-nopasswd so NOPASSWD wins during the TUI run and password auth resumes
once the temp file is removed. Also guard that @includedir is present (so the
drop-ins are always read) and set both drop-ins to the canonical 0440 mode.
Applied to both archbaseos-guided-install.sh and arch-autoinstall.sh.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
#2 — Word-boundary match for all module patterns
Generator now pads SELECTED_APPS with spaces and uses *" id "* in
counters, summary, and dispatch, matching the conflict fix from #1.
plymouth-custom no longer false-triggers any plymouth check.
#3 — Guided installer now runs tui-install.sh
archbaseos-guided-install.sh was calling simple-install.sh; both
paths now use the full TUI (sentinel-managed, modules.conf-driven).
#4 — EFI/boot partition size unified at 10 GiB
arch-autoinstall.sh was 15 GiB, archbaseos-guided-install.sh was
5 GiB. Both now use 10 GiB.
#5 — Interactive retry for dotfiles clone (guided installer)
Clone moved outside the chroot heredoc so read() reaches the terminal.
Loops until success or the user skips; AF_MODE warns and continues.
#6 — PAM target unified on system-local-login
archbaseos-guided-install.sh was writing to system-auth (affects
sudo). Both installers now target system-local-login only.
#7 — Redundant second clone removed from autoinstaller
arch-autoinstall.sh had a second git clone inside the chroot as a
fallback that collided with the skel copy and printed a spurious
warning. Removed; skel-only approach matches the guided installer
(last updated). Also removed the individual .zshrc/.bashrc/.vimrc
cp block; aligned to the guided installer's cleaner skel structure.
#8 — Docs: remove stale plymouth core-module section
docs/md/modules.md still described plymouth under Core Modules.
Section removed; plymouth appears in Optional Applications (system
category) via the generated sentinel.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Problem: every module installs its config into the running user's ~/.config, but
/etc/skel was never updated afterwards. Any additional user created with
`useradd -m` later would get an empty home directory with no configs at all —
they would have to manually copy or re-run setup.
Solution: at the end of both TUI installer scripts (after every module and the
colorway step have finished), copy the fully-configured user's home into
/etc/skel so that it becomes the template for all future users.
How it works — tui-install.sh + simple-install.sh (identical block in both):
The block runs AFTER the last run_module call and AFTER apply-theme.sh, so
the snapshot is taken when the home directory is in its final state. It copies:
~/.config/ → /etc/skel/.config/ (all app configs, DE configs, etc.)
~/.themes/ → /etc/skel/.themes/ (GTK themes, including cyberqueer)
~/.zshrc → /etc/skel/.zshrc
~/.bashrc → /etc/skel/.bashrc
~/.vimrc → /etc/skel/.vimrc
Each copy is guarded ([[ -d ]] / [[ -f ]]) so missing files are silently
skipped rather than erroring. sudo is used because /etc/skel is root-owned
but the installer runs as the normal user.
arch-autoinstall.sh + archbaseos-guided-install.sh (chroot-phase changes):
The previous version tried to cherry-pick specific subdirectories from the
Dotfiles repo clone (hypr/, niri/, waybar/, etc.) using a long list of cp
commands. This was brittle — any new module that installs to ~/.config was
not automatically captured, and the list had to be manually maintained.
Replaced with a minimal block that only copies the three shell dotfiles
(.zshrc, .bashrc, .vimrc) from the repo clone into /etc/skel. This is
sufficient for the first user created during installation (useradd -m runs
immediately after, before any modules). The full ~/.config sync above then
takes over for all subsequent users after the modules have run.
arch-autoinstall.sh additionally had the skel setup moved to before the
useradd -m call (was missing entirely before) so even the first user gets
the shell dotfiles, with a fallback direct-clone path if the skel clone fails.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
nmtui is not available on the archiso live environment; direct users to
iwctl (WiFi) or ethernet instead, and pause for input before re-checking.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tui-install.sh: dialog height=40 apps checklist and height=24 confirm
dialog both exceeded the standard 24-row VT console, causing dialog to
exit with code 1 and silently skip all apps. Make both heights
terminal-adaptive via tput lines/cols. Also extend the EXIT trap to
reset the terminal so Ctrl-C during a dialog doesn't leave the console
in raw/no-echo mode.
arch-autoinstall.sh, archbaseos-guided-install.sh: add a ping 1.1.1.1
check early in both scripts. In interactive mode, launches nmtui if
offline, then re-checks; prompts to abort if still down. Answerfile
mode logs a warning and continues.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove -s flag from read so the password is visible while typing,
enabling piped input to work visibly on the ISO installer.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
On any ERR, both installers now trap the failure, log the line/exit
code, and pop a dialog yes/no asking whether to send the log to another
system via croc. Falls back to a plain read prompt if dialog is absent.
Added dialog and croc to packages.extra so they are present in the live ISO.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add full session logging (tee to logfile) to archbaseos-guided-install.sh,
matching the pattern already in arch-autoinstall.sh; copy log to /mnt/boot/
at the end so it survives into the new system
- Add part() helper to both installers so NVMe/eMMC drives use the correct
'p' separator (e.g. /dev/nvme0n1p1 instead of the broken /dev/nvme0n11)
- Add disk size guard to arch-autoinstall.sh: fail early with a clear message
if ROOT_GIB would be < 8GiB instead of passing a nonsense value to parted
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
arch-autoinstall.sh was missing the keymap handling added to the guided
installer in the previous two commits, so booting the ISO in auto mode
(answerfile embedded) never called loadkeys and left the installed system
with no /etc/vconsole.conf.
- Add the same KEYMAPS array + selection logic to arch-autoinstall.sh
(AF mode reads .keymap, interactive mode prompts)
- Call loadkeys and export KEYMAP into the chroot
- Write /etc/vconsole.conf inside the chroot
- Add keymap dialog to generate-answerfile.sh so the field is populated
- Document .keymap in the arch-autoinstall.sh answerfile field list
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Both arch-autoinstall.sh and archbaseos-guided-install.sh now ask
whether to enable disk encryption. If skipped, btrfs is formatted
directly on the root partition with an appropriate plain GRUB cmdline
(root=UUID=... rootflags=subvol=@).
When encryption is chosen, a 64-byte random key is generated, enrolled
as a second LUKS keyslot, and written to /_LUKS_BACKUP_KEY inside the
new system (mode 400, root-owned, inside the encrypted container).
Also fixes: duplicate 'encrypt' hook in original mkinitcpio HOOKS
strings, missing KERNEL export into arch-autoinstall chroot heredoc.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add setup/archiso/ with build.sh, releng overlay, motd, and
install-arch launcher command for the live ISO
- Fix cryptroot mapper name in arch-autoinstall.sh (was 'root',
breaking all subsequent mounts)
- Add base-devel to pacstrap in both installers (required for yay/makepkg)
- Clone dotfiles inside chroot so tui-install.sh is available immediately
- After base install, offer to run tui-install.sh as the regular user
inside the chroot via runuser, with a temporary NOPASSWD sudoers rule;
skip option available for base-only installs
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
