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

[Badrikesh Prusty]

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.

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

[MOESSBAUER, Felix]

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.

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.

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

[Heinisch, Alexander]

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

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

[Prusty, Badrikesh]

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

[Prusty, Badrikesh]

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-...@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)

To view this discussion visit https://groups.google.com/d/msgid/isar-users/SG2PR06MB5107E12994821DDF3B9F34B191ADA%40SG2PR06MB5107.apcprd06.prod.outlook.com.

[Heinisch, Alexander]

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