The previous centralization into enable-services.sh accidentally changed semantics for three services: docker.socket, iwd.service, and power-profiles-daemon.service used to be enabled with bare 'sudo systemctl enable' (no --now); chrootable_systemctl_enable promoted them to 'enable --now' outside chroot. For iwd this is the riskiest: it's typically what's keeping the installer online, so starting it mid-install is at best a no-op and at worst can disrupt the active network connection. For docker.socket and power-profiles-daemon the change is cosmetic (the socket is already inactive, the daemon does no harm to start) but the original intent was deferral to first boot. New helper in install/helpers/chroot.sh: chrootable_systemctl_enable_only <unit> # plain enable, no --now enable-services.sh uses it for the three services that were previously bare-enabled. The other five (bluetooth, cups, cups-browsed, avahi-daemon, linux-modules-cleanup) keep the --now behavior they had under chrootable_systemctl_enable.
18 lines
907 B
Bash
18 lines
907 B
Bash
# Central place for unconditional service enables. Services that should NOT
|
|
# be started during install (sddm, ufw) live in their own scripts. Hardware-
|
|
# gated services (t2fanrd, intel_lpmd, thermald, omarchy-nvme-suspend-fix)
|
|
# also live with their detection.
|
|
#
|
|
# Two variants:
|
|
# chrootable_systemctl_enable -> enable + start now (safe to start)
|
|
# chrootable_systemctl_enable_only -> enable only (don't risk starting during
|
|
# install)
|
|
chrootable_systemctl_enable bluetooth.service
|
|
chrootable_systemctl_enable cups.service
|
|
chrootable_systemctl_enable cups-browsed.service
|
|
chrootable_systemctl_enable avahi-daemon.service
|
|
chrootable_systemctl_enable linux-modules-cleanup.service
|
|
chrootable_systemctl_enable_only docker.socket
|
|
chrootable_systemctl_enable_only iwd.service
|
|
chrootable_systemctl_enable_only power-profiles-daemon.service
|