Ryan Hughes
0ebbe34760
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.
21 lines
743 B
Bash
21 lines
743 B
Bash
# Starting the installer with OMARCHY_CHROOT_INSTALL=1 will put it into chroot mode
|
|
chrootable_systemctl_enable() {
|
|
if [[ -n ${OMARCHY_CHROOT_INSTALL:-} ]]; then
|
|
sudo systemctl enable $1
|
|
else
|
|
sudo systemctl enable --now $1
|
|
fi
|
|
}
|
|
|
|
# Like chrootable_systemctl_enable but never passes --now, so the service is
|
|
# only enabled for the next boot. Use for services that are either already
|
|
# running (and re-starting would interrupt the install — iwd) or that shouldn't
|
|
# auto-start during install (docker, power-profiles-daemon).
|
|
chrootable_systemctl_enable_only() {
|
|
sudo systemctl enable $1
|
|
}
|
|
|
|
# Export the functions so they're available in subshells
|
|
export -f chrootable_systemctl_enable
|
|
export -f chrootable_systemctl_enable_only
|