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

["'Badrikesh Prusty' via isar-users" <isar-users@googlegroups.com>]

[-- Attachment #1.1: Type: text/plain, Size: 9741 bytes --]

Hi,

Thanks for the information and for pointing out the differences in the 
actual systemd code.
I have updated the patch to make populate-systemd-preset opt-in instead of 
opt-out, due to
the many service failures we observed when it was enabled during image 
postprocessing:
[PATCH v2 1/2] image-postproc: ignore systemd preset failures 
<https://groups.google.com/g/isar-users/c/UfEN7DuZiuQ/m/Nq8t4hM8EgAJ>

Thanks,
Badrikesh
On Tuesday, December 16, 2025 at 2:47:34 PM UTC+5:30 Heinisch, Alexander 
wrote:

> 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-...@googlegroups.com>
> > Sent: 15 December 2025 19:28
> > To: Heinisch, Alexander (FT RPD CED SES-AT);
> > isar-...@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...@siemens.com>
> > Sent: 15 December 2025 17:20
> > To: Prusty, Badrikesh (FT FDS CES LX PBU 2);
> > isar-...@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 <badrikes...@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+...@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+...@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/ef5c3500-e517-4629-bebf-1f4bd2ef4d5dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15155 bytes --]