Option to apply presets from systemctl preset-all to /usr instead of /etc

[septatrix]

The users of mkosi are often redistributors whose config/presets should be placed under usr instead of etc. Furthermore, this also helps with sysupdate images where usr is updated but the root is a persistent volume. New default presets are not applied in that case as machine-id already exists leading to inconsistent states.

I am aware of the existence of systemd-update-done.service which could be used to call systemctl preset-all upon booting after an update, however, using that unit is more complex than simply having the correct presets on the usr partition. Another argument against that approach is that systemctl preset-all will touch configs from the user when the distributor wants to enable new stuff and disable old stuff. In that case configs from the user will be overwritten (either reenabled, or disabled). Also there are a few correctness problems with systemctl preset-all when using templated units (systemd/systemd#18825, systemd/systemd#15065) which are easier to workaround in a finalize script than having to perform that before the systemd-update-done.service unit.

[septatrix]

Or should this be raised as an RFE over at the systemd repo?

[behrmann]

That sounds like something to raise in the systemd repo. Maybe an option to choose between /usr/lib/, /usr/local/lib, /runand/etc`.

Another argument against that approach is that systemctl preset-all will touch configs from the user when the distributor wants to enable new stuff and disable old stuff.

I'm not entirely sure I understand that point. I assume "configs from the users" means "config in /etc/. When running systemctl preset-allI think it's reasonable to assume, that things one has written, might be overwritten by other config and if one wants to be sure, give it a sufficiently low number. For units there was issue systemd/systemd#30439, we should maybe add a similar note to thesystemd.presetman page. With something like that in place usingsystemd-update-done.serviceto callsystemctl preset-all` would be sufficent, but maybe I'm missng part of the picture.

[septatrix]

I'm not entirely sure I understand that point. I assume "configs from the users" means "config in /etc/". When running systemctl preset-all I think it's reasonable to assume, that things one has written, might be overwritten by other config and if one wants to be sure, give it a sufficiently low number. For units there was issue systemd/systemd#30439, we should maybe add a similar note to the systemd.preset man page. With something like that in place using systemd-update-done.service to call systemctl preset-all would be sufficent, but maybe I'm missng part of the picture.

My problem is that it touches units which were manually enabled/disabled. When invoking systemctl enable they will get overwritten, especially if the presets contain disable * as a fallback which is quite common. In my case this resulted in the removal of openvpn@<foobar>.service nearly locking me out of the device. And including these templated units in the presets file does not really seem feasible. But I agree that this is just a limitation of how unit enabling/disabling works. Therefore the option to preset units under /usr would be much appreciated. I will open an RFE over at the systemd repo for that.

[septatrix]

I opened systemd/systemd#33373 over at the systemd repo

[behrmann]

Just for completeness:

1. preset files have ignore directives in addition to enable and disable, which seem to be what you want at least for some cases
2. you can add templates in preset files, e.g. foo@.service bar qux for the instances bar and qux.

[septatrix]

Just for completeness:

1. preset files have `ignore` directives in addition to `enable` and `disable`, which seem to be what you want at least for some cases

Oh I did not knew that. That might make some things easier though ultimately having the symlinks shipped under /usr is still preferrable IMO.

2. you can add templates in preset files, e.g. `foo@.service bar qux` for the instances `bar` and `qux`.

Yeah I already saw that in your bug report I linked above (systemd/systemd#15065). However, this does not really work for me as I do not have control over the templated name but I guess in this case I might be able to get away with using ignore foo@.service?

[anadon]

This is a part of a series of bug reports related to a tool I'm building, depauditd. Reports will be cross-linked after all submissions, and have related files here at commit b27c12551a915616ac6e2c4a17bd2c8f75e37d6d3d6417bb4f065869fac35811. Reports are LLM generated and have been reviewed by me before submission.

Adding a concrete data point to the discussion.

Scenario: user installs a custom oneshot service into the image via mkosi.extra/etc/systemd/system/<name>.service and enables it from mkosi.postinst.chroot with systemctl enable <name>.service. Expected behaviour: the enable symlink at /etc/systemd/system/multi-user.target.wants/<name>.service survives to boot and the service fires on first boot.

Observed behaviour: the symlink is created by postinst.chroot — visible in the build log — and then removed by the systemctl --root=/buildroot preset-all step that mkosi runs after postinst. Fedora's default preset (90-default.preset) disables unknown services, and user-installed services have no preset file, so preset-all strips the enable.

Workaround that's stable across Fedora / Arch / Ubuntu / Debian presets: ship a preset file of our own via ExtraTrees at mkosi.extra/usr/lib/systemd/system-preset/50-<name>.preset containing:

enable <name>.service

The 50- prefix sorts before the distro's 90-default.preset so our directive wins. With this in place, preset-all leaves the enable symlink intact and the service fires on boot as expected.

Documenting this here in case the discussion settles on either:

• Letting user-postinst enables survive preset-all by default (e.g. preset-all runs before postinst, or preset-all has an opt-out for hand-installed symlinks).
• Leaving the current behaviour in place but adding a one-line warning from mkosi when postinst.chroot created an enable symlink that preset-all subsequently removed.

#3565
#4278
#4277
NixOS/nixpkgs#510071
NixOS/nixpkgs#510074
NixOS/nixpkgs#510068