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.
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.
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'?
Thanks,
Martin
Am 29.04.23 um 18:20 schrieb Dan Nicholson:
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.
https://github.com/endlessm/eos-boot-helper/blob/master/50-eos.preset
On Sat, Apr 29, 2023, 9:55 AM Daan De Meyer <daan.j.deme...@gmail.com>
wrote:
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.
If I were you I would ship 99-disable.preset and add
85-mydevice.preset enabling only the services you want to be enabled.
Cheers,
Daan
On Sat, 29 Apr 2023, 17:47 Martin Petzold,
<martin.petz...@tavla.de> wrote:
Dear Daan,
Am 29.04.23 um 17:43 schrieb Daan De Meyer:
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.
What would you then suggest:
a. Disable every single service unit after copy to the
/lib/systemd/system location manually?
b. Add a 99-disable.preset file with 'disable *'? (I wonder
why Debian does not have it and if it then may brake something)
Thanks,
Martin
On Sat, 29 Apr 2023, 17:27 Martin Petzold,
<martin.petz...@tavla.de> wrote:
Dear Paul,
Am 29.04.23 um 17:13 schrieb Paul Menzel:
> Dear Martin,
>
>
> Am 29.04.23 um 16:12 schrieb Martin Petzold:
>
>> we are building our OS with debootstrap (Debian
bullseye). Our image
>> shall be flashed on embedded devices. In order to get
a unique
>> machine-id we removed '/etc/machine-id' as instructed
in [1] and also
>> removed '/var/lib/dbus/machine-id' as instructed in
[2]) from the
>> golden image.
>>
>> After we flash the image and boot it, new machine-ids
are created and
>> identical.
>>
>> However, now we realized that some of our systemd
service units added
>> to '/lib/systemd/system' are enabled and starting on
boot. We did not
>> enable them, we just copied them to that location at
the end of our
>> rootfs build. They are just there to be used in some
special test cases.
>>
>> We already checked '/lib/systemd/system-preset/*'. But
there is only
>> a single file '90-systemd.preset' and there is no rule
which matches
>> our service units.
>>
>> 1. Why are our service units placed in
'/lib/systemd/system' enabled?
> Sorry, you provide not enough information.
>
> Please provide an example `systemctl status X` and
`systemctl cat X`
> for service X, that is started but does not. Does that
happen with all
> services you add?
=========================================
tavla@tavla:~$ sudo systemctl status tavla-test
× tavla-test.service - TAVLA Platform OS Tester Service
Loaded: loaded
(/lib/systemd/system/tavla-test.service; enabled;
preset: enabled)
Active: failed (Result: signal) since Sat
2023-04-29 15:52:12
CEST; 17min ago
Process: 388 ExecStart=/opt/tavla/bin/test
(code=killed, signal=HUP)
Main PID: 388 (code=killed, signal=HUP)
CPU: 118ms
Apr 29 15:52:12 tavla systemd[1]: Starting
tavla-test.service - TAVLA
Platform OS Tester Service...
Apr 29 15:52:12 tavla systemd[1]: tavla-test.service:
Main process
exited, code=killed, status=1/HUP
Apr 29 15:52:12 tavla systemd[1]: tavla-test.service:
Failed with result
'signal'.
Apr 29 15:52:12 tavla systemd[1]: Failed to start
tavla-test.service -
TAVLA Platform OS Tester Service.
=========================================
tavla-test.service is 'enabled' (and started), but I
never enabled it.
It was enabled after I removed machine-id and did a
reboot. Before that,
it was disabled. The service unit
('/lib/systemd/system/tavla-test.service') was copied to
this location
during image build after debootstrap and apt installation
of systemd.
Here is the only preset ('90-systemd.preset'):
=========================================
enable remote-fs.target
enable remote-cryptsetup.target
enable machines.target
enable getty@.service
enable systemd-timesyncd.service
enable systemd-networkd.service
enable systemd-network-generator.service
enable systemd-resolved.service
enable systemd-homed.service
enable systemd-userdbd.socket
enable systemd-pstore.service
enable systemd-boot-update.service
disable console-getty.service
disable debug-shell.service
disable halt.target
disable kexec.target
disable poweroff.target
enable reboot.target
disable rescue.target
disable exit.target
disable systemd-networkd-wait-online.service
disable systemd-time-wait-sync.service
disable systemd-boot-check-no-failures.service
disable proc-sys-fs-binfmt_misc.mount
disable syslog.socket
disable systemd-journal-gatewayd.*
disable systemd-journal-remote.*
disable systemd-journal-upload.*
=========================================
>
>> Platform:
>>
>> systemd 252.5-2~bpo11+1 (from bullseye-backports)
>> systemd-resolved and systemd-networkd with iwd (all from
>> bullseye-backports)
>> Custom Debian bullseye (with some packages from
bullseye-backports)
>> Custom Kernel 5.10
>> U-Boot
>>
>> [1] https://systemd.io/BUILDING_IMAGES/
>> [2] https://wiki.debian.org/MachineId
Best regards,
Martin
