<div dir="ltr">We just run preset-all near the end of our image (really ostree) build after all packages have been installed and nearly all customizations have been applied. Then you're recording the state of the enabled and disabled units in the image.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br>Dan Nicholson | Endless OS Foundation</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 1, 2023 at 2:45 PM Martin Petzold <<a href="mailto:martin.petzold@tavla.de">martin.petzold@tavla.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Using the presets is a little tricky. Because during debootstrap
Debian installation a machine-id is created and the
90-systemd.preset seems to be applied. After this initial Debian
package installation there may be Debian packages installed via
apt which enabled service units without using presets (e.g. sshd).
Using a 99-disable.preset (disable *) can have unintended
side-effects, especially if presets are applied again (by
'systemctl preset-all' or again during boot). In my setup it seems
to be safer NOT to use the 99-disable.preset, rather disable all
own and unused service units within own preset. </p>
<p>However, removing the machine-id from my image does result in a
new machine-id creation on next boot, BUT does not apply the
presets again.</p>
<p>Is it also possible to reset the boot preset status, so that it
is applied again on next boot? Or do I need to run 'systemctl
preset-all'?</p>
<p>Thanks,</p>
<p>Martin<br>
</p>
<div>Am 29.04.23 um 18:20 schrieb Dan
Nicholson:<br>
</div>
<blockquote type="cite">
<div dir="auto">For Endless OS we went the opposite way under the
idea that we don't want to have to go add an entry for every
service that might get added when the packages change. Basically
we work under the assumption that a package included in the OS
that provides a service usually should be enabled. So, we
disable selected units in our preset and let everything else get
enabled.
<div dir="auto"><br>
</div>
<div dir="auto"><a href="https://github.com/endlessm/eos-boot-helper/blob/master/50-eos.preset" target="_blank">https://github.com/endlessm/eos-boot-helper/blob/master/50-eos.preset</a><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Apr 29, 2023, 9:55 AM
Daan De Meyer <<a href="mailto:daan.j.demeyer@gmail.com" target="_blank">daan.j.demeyer@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">Disabling manually will still get overridden
by preset on first boot. Debian does not ship
99-disable.preset because deb-systemd-helper relies on
systemctl preset to enable services on install. Shipping
that file would break backwards compat because no services
would be enabled anymore.
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">If I were you I would ship
99-disable.preset and add 85-mydevice.preset enabling
only the services you want to be enabled.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Cheers,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Daan</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 29 Apr 2023, 17:47
Martin Petzold, <<a href="mailto:martin.petzold@tavla.de" rel="noreferrer" target="_blank">martin.petzold@tavla.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Dear Daan,<br>
</p>
<div>Am 29.04.23 um 17:43 schrieb Daan De Meyer:<br>
</div>
<blockquote type="cite">
<div dir="auto">Systemd does a preset on first boot
when there's no machine ID yet. If no preset from a
preset file applies, the default is to enable it.
Since debian does not ship a 99-disable.preset with
disable * in it, all services are enabled on
firstboot on Debian.
<div dir="auto"><br>
</div>
</div>
</blockquote>
<p>What would you then suggest:<br>
</p>
<p>a. Disable every single service unit after copy to
the /lib/systemd/system location manually?<br>
b. Add a 99-disable.preset file with 'disable *'? (I
wonder why Debian does not have it and if it then may
brake something)</p>
<p>Thanks,</p>
<p>Martin<br>
</p>
<blockquote type="cite"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 29 Apr
2023, 17:27 Martin Petzold, <<a href="mailto:martin.petzold@tavla.de" rel="noreferrer noreferrer" target="_blank">martin.petzold@tavla.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
Paul,<br>
<br>
Am 29.04.23 um 17:13 schrieb Paul Menzel:<br>
> Dear Martin,<br>
><br>
><br>
> Am 29.04.23 um 16:12 schrieb Martin Petzold:<br>
><br>
>> we are building our OS with debootstrap
(Debian bullseye). Our image <br>
>> shall be flashed on embedded devices. In
order to get a unique <br>
>> machine-id we removed '/etc/machine-id'
as instructed in [1] and also <br>
>> removed '/var/lib/dbus/machine-id' as
instructed in [2]) from the <br>
>> golden image.<br>
>><br>
>> After we flash the image and boot it, new
machine-ids are created and <br>
>> identical.<br>
>><br>
>> However, now we realized that some of our
systemd service units added <br>
>> to '/lib/systemd/system' are enabled and
starting on boot. We did not <br>
>> enable them, we just copied them to that
location at the end of our <br>
>> rootfs build. They are just there to be
used in some special test cases.<br>
>><br>
>> We already checked
'/lib/systemd/system-preset/*'. But there is only
<br>
>> a single file '90-systemd.preset' and
there is no rule which matches <br>
>> our service units.<br>
>><br>
>> 1. Why are our service units placed in
'/lib/systemd/system' enabled?<br>
> Sorry, you provide not enough information.<br>
><br>
> Please provide an example `systemctl status
X` and `systemctl cat X` <br>
> for service X, that is started but does not.
Does that happen with all <br>
> services you add?<br>
=========================================<br>
<br>
tavla@tavla:~$ sudo systemctl status tavla-test<br>
<br>
× tavla-test.service - TAVLA Platform OS Tester
Service<br>
Loaded: loaded
(/lib/systemd/system/tavla-test.service; enabled;
<br>
preset: enabled)<br>
Active: failed (Result: signal) since Sat
2023-04-29 15:52:12 <br>
CEST; 17min ago<br>
Process: 388 ExecStart=/opt/tavla/bin/test
(code=killed, signal=HUP)<br>
Main PID: 388 (code=killed, signal=HUP)<br>
CPU: 118ms<br>
<br>
Apr 29 15:52:12 tavla systemd[1]: Starting
tavla-test.service - TAVLA <br>
Platform OS Tester Service...<br>
Apr 29 15:52:12 tavla systemd[1]:
tavla-test.service: Main process <br>
exited, code=killed, status=1/HUP<br>
Apr 29 15:52:12 tavla systemd[1]:
tavla-test.service: Failed with result <br>
'signal'.<br>
Apr 29 15:52:12 tavla systemd[1]: Failed to start
tavla-test.service - <br>
TAVLA Platform OS Tester Service.<br>
<br>
=========================================<br>
<br>
tavla-test.service is 'enabled' (and started), but
I never enabled it. <br>
It was enabled after I removed machine-id and did
a reboot. Before that, <br>
it was disabled. The service unit <br>
('/lib/systemd/system/tavla-test.service') was
copied to this location <br>
during image build after debootstrap and apt
installation of systemd.<br>
<br>
Here is the only preset ('90-systemd.preset'):<br>
<br>
=========================================<br>
<br>
enable remote-fs.target<br>
enable remote-cryptsetup.target<br>
enable machines.target<br>
<br>
enable <a href="mailto:getty@.service" rel="noreferrer noreferrer" target="_blank">getty@.service</a><br>
enable systemd-timesyncd.service<br>
enable systemd-networkd.service<br>
enable systemd-network-generator.service<br>
enable systemd-resolved.service<br>
enable systemd-homed.service<br>
enable systemd-userdbd.socket<br>
enable systemd-pstore.service<br>
enable systemd-boot-update.service<br>
<br>
disable console-getty.service<br>
disable debug-shell.service<br>
<br>
disable halt.target<br>
disable kexec.target<br>
disable poweroff.target<br>
enable reboot.target<br>
disable rescue.target<br>
disable exit.target<br>
<br>
disable systemd-networkd-wait-online.service<br>
disable systemd-time-wait-sync.service<br>
disable systemd-boot-check-no-failures.service<br>
disable proc-sys-fs-binfmt_misc.mount<br>
<br>
disable syslog.socket<br>
<br>
disable systemd-journal-gatewayd.*<br>
disable systemd-journal-remote.*<br>
disable systemd-journal-upload.*<br>
<br>
=========================================<br>
<br>
><br>
>> Platform:<br>
>><br>
>> systemd 252.5-2~bpo11+1 (from
bullseye-backports)<br>
>> systemd-resolved and systemd-networkd
with iwd (all from <br>
>> bullseye-backports)<br>
>> Custom Debian bullseye (with some
packages from bullseye-backports)<br>
>> Custom Kernel 5.10<br>
>> U-Boot<br>
>><br>
>> [1] <a href="https://systemd.io/BUILDING_IMAGES/" rel="noreferrer noreferrer noreferrer
noreferrer" target="_blank">https://systemd.io/BUILDING_IMAGES/</a><br>
>> [2] <a href="https://wiki.debian.org/MachineId" rel="noreferrer noreferrer noreferrer
noreferrer" target="_blank">https://wiki.debian.org/MachineId</a><br>
<br>
Best regards,<br>
<br>
Martin<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>