<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">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">daan.j.demeyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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" target="_blank" rel="noreferrer">martin.petzold@tavla.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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>
    <pre cols="72">
</pre>
  </div>

</blockquote></div>
</blockquote></div>