Re: [PATCH] image-postproc: apply all systemd preset rules and ignore failures

["'Heinisch, Alexander' via isar-users" <isar-users@googlegroups.com>]

On Tue, 2025-12-16 at 02:32 +0000, Prusty, Badrikesh (FT FDS CES LX PBU
2) wrote:
> Hi,
>
> > Before I introduced this postprocessing step some services got
> > enabled
> > on first boot which was not reflected in the images rootfs after
> > build.
> > So the idea was to align the build artifacts to what was actually
> > running on the system. (and by that supporting ro /usr + /etc
> > systems)
> >
> > Systemd back then (and afaik as of now) on first boot only
> > populates
> > the presets with flag --enable-only.
> >
>
> I agree with the goal of aligning the build artifacts with what
> actually runs on the
> system. However, I think the closer match to first-boot behavior
> would be to run
> `systemctl preset-all`. According to the systemd man pages, this is
> what is executed
> on first boot, whereas enable-only changes the semantics.
>
While this holds true for invocations of of systemctl preset-all, this
is not the case for systemd during first-boot!

From systemd changelog:

```
* Systemd can optionally do a full preset in the "first boot" condition
          (instead of just enable-only). This behaviour is controlled
by the
          compile-time option -Dfirst-boot-full-preset. Right now it
defaults
          to 'false', but the plan is to switch it to 'true' for the
subsequent
          release.
```

According to [1],[2] and [3] this (defaults to false) is still the
case.
Also on the debian source package (for trixie) I could not find any
patch changing this.


[1]:
https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a15c87025/meson_options.txt#L32
[2]:
https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a15c87025/meson.build#L335
[3]:https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a15c87025/src/core/manager.c#L1940


> Using enable-only ignores disable presets and still enable units (as
> in the case
> I shared earlier), which can cause the rootfs to diverge from the
> intended preset
> policy. preset-all respects both enable and disable presets and
> should align the
> image more closely.
>
> > system). At least such feature should be opt-in. Also a note about
> > this
> > change should be put in the RECIPE-API-CHANGELOG.md
> >
>
> This change is already well documented in RECIPE-API-CHANGELOG.md,
> so no additional note should be necessary.

It clearly states enable only semantics.


BR Alexander

>
> Many thanks,
> Badrikesh
>
> ________________________________________
> From: 'Prusty, Badrikesh' via isar-users
> <isar-users@googlegroups.com>
> Sent: 15 December 2025 19:28
> To: Heinisch, Alexander (FT RPD CED SES-AT);
> isar-users@googlegroups.com; Moessbauer, Felix (FT RPD CED OES-DE)
> Subject: Re: [PATCH] image-postproc: apply all systemd preset rules
> and ignore failures
>
>
> Hi Felix / Alex,
>
> Thanks for review.
>
> > is this change in sync regarding what Debian does during
> > installation?
>
> Debian does not run `systemctl preset-all` automatically at the end
> of the OS installation.
>
> The systemd manpage in Debian states that on the first boot, systemd
> will enable or disable
> services according to preset policy, similar to running `systemctl
> preset-all`.
> Reference:
> https://manpages.debian.org/bookworm/systemd/systemd.preset.5.en.html
>
> > Enabling additional services should be fine in general, but
> > disabling
> > bears some risk in case packages that otherwise only enable
> > services
> > via symlink in /etc get disabled again.
>
> Yes, the point is correct and, but here `systemctl preset-all` would
> only apply according
> to the rules defined in /usr/lib/systemd/system-preset/*.preset (or
> /etc/systemd/system-preset/),
> not to all services.
>
> The other issue I encountered was with a custom preset rule. For
> example,
> I created a preset file 90-no-reboot.preset containing the following
> rule:
> ```
> disable ctrl-alt-del.target
> ```
>
> When running `systemctl preset-all --preset-mode=enable-only` this
> rule is ignored,
> and enabled ctrl-alt-del.target (i.e., gets symlinked to
> reboot.target). However, running
> `systemctl preset-all` without specifying `--preset-mode` (i.e., the
> default full mode)
> correctly applies the preset and disables ctrl-alt-del.target.
>
> Thank you,
> Badrikesh
>
>
> ________________________________________
> From: Heinisch, Alexander (FT RPD CED SES-AT)
> <alexander.heinisch@siemens.com>
> Sent: 15 December 2025 17:20
> To: Prusty, Badrikesh (FT FDS CES LX PBU 2);
> isar-users@googlegroups.com; Moessbauer, Felix (FT RPD CED OES-DE)
> Subject: Re: [PATCH] image-postproc: apply all systemd preset rules
> and ignore failures
>
> On Mon, 2025-12-15 at 07:31 +0000, Moessbauer, Felix (FT RPD CED OES-
> DE) wrote:
> > On Fri, 2025-12-12 at 00:32 -0500, 'Badrikesh Prusty' via isar-
> > users
> > wrote:
> > > Update image postprocessing to run 'systemctl preset-all' without
> > > restricting to '--preset-mode=enable-only', so that both enable
> > > and
> > > disable rules from systemd preset files are applied.
> > >
> > > Add '|| true' to ignore failures from already masked units set by
> > > package post-install scripts during rootfs_install tasks.
> >
> > Hi,
> >
> > is this change in sync regarding what Debian does during
> > installation?
> > Enabling additional services should be fine in general, but
> > disabling
> > bears some risk in case packages that otherwise only enable
> > services
> > via symlink in /etc get disabled again.
> >
>
> Before I introduced this postprocessing step some services got
> enabled
> on first boot which was not reflected in the images rootfs after
> build.
> So the idea was to align the build artifacts to what was actually
> running on the system. (and by that supporting ro /usr + /etc
> systems)
>
> Systemd back then (and afaik as of now) on first boot only populates
> the presets with flag --enable-only.
> One can change this behavior with compile time flag -Dfirst-boot-
> full-
> preset which seems not to be the case.
>
> Imo, disabling services during the postprocessing changes the image
> in
> an unexpected way (as this does not happen by default on the running
> system). At least such feature should be opt-in. Also a note about
> this
> change should be put in the RECIPE-API-CHANGELOG.md
>
> BR Alexander
>
> > Do you know if this topic has already been discussed in upstream
> > Debian?
> >
> > +CC Alexander
> >
> > Felix
> >
> > >
> > > Signed-off-by: Badrikesh Prusty <badrikesh.prusty@siemens.com>
> > > ---
> > >  meta/classes-recipe/rootfs.bbclass | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-
> > > recipe/rootfs.bbclass
> > > index 8485b32f..7e79bb8e 100644
> > > --- a/meta/classes-recipe/rootfs.bbclass
> > > +++ b/meta/classes-recipe/rootfs.bbclass
> > > @@ -574,7 +574,7 @@ image_postprocess_populate_systemd_preset() {
> > >          --show systemd || echo "" )
> > >
> > >      if (test "$SYSTEMD_INSTALLED" = "installed"); then
> > > -        sudo chroot '${ROOTFSDIR}' systemctl preset-all --
> > > preset-
> > > mode="enable-only"
> > > +        sudo chroot '${ROOTFSDIR}' systemctl preset-all || true
> > >      fi
> > >  }
> > >
> > > --
> > > 2.47.3
> > >
> > > --
> > > You received this message because you are subscribed to the
> > > Google
> > > Groups "isar-users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to isar-users+unsubscribe@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/isar-users/20251212053214.80936-1-badrikesh.prusty%40siemens.com
> > > .
>
> --
> Alexander Heinisch
> Siemens AG
> http://www.siemens.com/
>
> --
> You received this message because you are subscribed to the Google
> Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/isar-users/SG2PR06MB5107E12994821DDF3B9F34B191ADA%40SG2PR06MB5107.apcprd06.prod.outlook.com
> .

--
Alexander Heinisch
Siemens AG
http://www.siemens.com/

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/decd3e7edcd8b836d356ae963c625a28c38f72b7.camel%40siemens.com.