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

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

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.

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.


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.

-- 
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/SG2PR06MB51078039269E79B69350839091AAA%40SG2PR06MB5107.apcprd06.prod.outlook.com.