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