Hi,

I've not investigated the root cause yet but I might have a concrete 
example for the mentioned issue:
I have a recipe which has following masks at postinst to disable sleep 
states on the target:

systemctl mask \
        ctrl-alt-del.target \
        hibernate.target \
        hybrid-sleep.target \
        sleep.target \
        suspend-then-hibernate.target \
        suspend.target

At Debian Bookworm, build ends up with "Failed to preset unit, unit 
/etc/systemd/system/sleep.target is masked.", until  
"populate-systemd-preset" is opt-out.
But I don't have any issue at Debian Trixie. Not sure if this might be a 
clue.

Best,
Gokhan

On Wednesday, January 14, 2026 at 12:46:44 PM UTC+3 Heinisch, Alexander 
wrote:

> On Tue, 2026-01-13 at 09:48 -0500, Badrikesh Prusty wrote:
> > Disable running populate-systemd-preset at build time by default.
> > Although systemd runs enable-only presets at first boot, running this
> > step during image creation changes the enabled state of units before
> > systemd’s first-boot logic runs, 
> Why is this a problem? The reasons why to have services prepopulated
> are listed here [1].
>
> > ignores disable rules, and can cause
> ...as is the case with current systemd
>
> > some services to fail during runtime.
>
> What's the difference compared to enabling on first-boot?
> > 
> > Downstream users can opt in when preset population is required.
>
> Imo, having the pre population enabled seems to me a propper default.
> If downstream has issues with the prepopulation, for some reason (maybe
> you can clarify based on concrete cases) then you always can opt-out
> via: ROOTFS_FEATURES:remove = "populate-systemd-preset"
>
> Initially your V1 was about not only enabling but also disabling
> services in the postprocessing. What caused the change to neither
> populate enabled nor disabled units? As above, maybe a concrete example
> helps to understand your requirements.
>
> BR Alexander
>
> 1:
>
> https://github.com/ilbers/isar/blob/master/RECIPE-API-CHANGELOG.md#populate-systemd-units-based-on-presets-during-image-postprocessing
>
> > 
> > Opt-in:
> >   ROOTFS_FEATURES:append = " populate-systemd-preset"
> > 
> > Signed-off-by: Badrikesh Prusty <badrikes...@siemens.com>
> > ---
> >  RECIPE-API-CHANGELOG.md           | 14 ++++++++++++++
> >  meta/classes-recipe/image.bbclass |  1 -
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > index 0bad8a44..46c8c905 100644
> > --- a/RECIPE-API-CHANGELOG.md
> > +++ b/RECIPE-API-CHANGELOG.md
> > @@ -962,3 +962,17 @@ INSTALLER_UNATTENDED_ABORT_ENABLE = "1"
> >  # Optional: set countdown timeout in seconds (default 5)
> >  INSTALLER_UNATTENDED_ABORT_TIMEOUT = "5"
> >  ```
> > +
> > +### Make populate-systemd-preset opt-in
> > +
> > +Running populate-systemd-preset at build time is disabled by
> > default.
> > +Although systemd runs enable-only presets by default at first boot,
> > +running this step at build time changes the enabled state of units
> > +before systemd’s first-boot logic runs, ignores disable rules, and
> > +can cause some services to fail during runtime.
> > +
> > +Downstream users can explicitly enable this feature when preset
> > +population is required during image creation.
> > +
> > +Opt-in:
> > +  ROOTFS_FEATURES:append = " populate-systemd-preset"
> > diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-
> > recipe/image.bbclass
> > index e605bc80..47ed068d 100644
> > --- a/meta/classes-recipe/image.bbclass
> > +++ b/meta/classes-recipe/image.bbclass
> > @@ -101,7 +101,6 @@ ROOTFS_FEATURES += "\
> >      export-dpkg-status \
> >      clean-log-files \
> >      clean-debconf-cache \
> > -    populate-systemd-preset \
> >      generate-sbom \
> >      "
> >  ROOTFS_PACKAGES += "${IMAGE_PREINSTALL}
> > ${@isar_multiarch_packages('IMAGE_INSTALL', d)}"
>
> -- 
> Alexander Heinisch
> Siemens AG
> 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/b57081a7-d0ab-49ae-8d88-efb37e17cbbcn%40googlegroups.com.