This logic is "borrowed" from Fedora, and replaces /etc/resolv.conf with
a symlink to the systemd-resolved stub. Fedora does this from an install
script, but that doesn't work for image-based installs since those never
run install scripts on the device, and /etc persists across updates.
I've also seen cases in testing where the symlink was removed by e.g.
accidentally running resolvconf or something similar. So
this runs from a oneshot unit at boot instead, which is ordered before
network-pre.target so NetworkManager doesn't get there first. The old
resolved.post-install script is dropped since the unit covers both cases.
There are some conditions where resolv.conf is **not** replaced:
- when resolv.conf is already a symlink
- when systemd-resolved isn't enabled
- when its stub listener is disabled (via DNSStubListener= in config)
- when systemd isn't running, since resolved isn't either and replacing
resolv.conf would just break dns (e.g. when running the unit's script
by hand)
- when resolv.conf is a bind mount (e.g. in a chroot or container)
This assumes that if a user/sys admin wants to hand-roll their own
resolv.conf, that they either disable the systemd-resolved unit or
disable the stub listener in config if they want to use foreign mode.
The resolved drop-ins are also renamed with a 10- prefix, to match the
numbering ranges UAPI.6 recommends for vendor config in /usr.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9109>
initramfs starts USB NCM gadget and unudhcpd for SSH login.
This requires special handling since unudhpcd is unmanaged by the
service manager until the userspace is started. Once entered in userspace,
the usb-moded-developer-mode needs to be activated which configures
NetworkManager and starts unudhcpd under the service manager.
This way, a full handover is possible and the gadgets can be properly
switched without any leftovers from the initramfs due to the unmanaged
situation.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8553>
This unit will activate `time-sync.target` after system time is synced,
e.g. by NTP. We can use this target to delay starting some units until
we know that system time is correct. IIUC this shouldn't have any impact
on system startup otherwise, including existing units we enable, so
nothing should be slowed down by adding this.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7711>
The trigger runs `systemctl preset cups.service`, but then if it runs
preset on the other two *afterwards* it will disable them (because no
explicit preset and we default to disable). This helps ensure they're
kept enabled.
The same seems to also happen for NetworkManager-wait-online and the
other things here, leading to them being accidentally disabled.
This also removes cups.service, it should be socket-activatable now that
cups.socket is enabled.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7029>
Installing systemd-resolved by default is still probably not a good
idea (e.g. until #1430 is fixed, at least?), but this adds config for
NM and sd-resolved to get the stub resolver set up automatically when
systemd-resolved is installed manually by a user.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6250
[ci:skip-build]: already built successfully in CI
This enables systemd-oomd by default and provides some default
configuration for system.slice and for all slices that run under user.
This default slice config is inspired by what Fedora ships,
which seems like a sensible default for us to start with. Units/slices
within these two top-ish level slices can set their own limits and
actions if they want.
I evaluated using systemd/zram-generator but decided against it for the following reasons:
1) it was more difficult to configure using the existing deviceinfo var
we have for zram_pct, this meant that we would ultimately couldn't have
a consistent way to configure zram stuff for all supported init systems
2) it's a Rust app, and was failing to build in CI for armv7, riscv64,
and armhf with some weird qemu crashes, failed tests, etc
3) zram-init Just Works, upstream ships a unit file for it so they
support running under systemd already
[ci:skip-build]: already built successfully in CI
Achill Gilgenast