[PATCH v2 1/2] image-postproc: ignore systemd preset failures

[PATCH v2 1/2] image-postproc: ignore systemd preset failures

['Badrikesh Prusty' via isar-users]

Add '|| true' to systemd preset invocation during image postprocessing
to tolerate failures caused by already-masked units.

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..ef3ddb84 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 --preset-mode="enable-only" || 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/20260113144832.3231870-1-badrikesh.prusty%40siemens.com.

[PATCH v2 2/2] image: make populate-systemd-preset opt-in

['Badrikesh Prusty' via isar-users]

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, ignores disable rules, and can cause
some services to fail during runtime.

Downstream users can opt in when preset population is required.

Opt-in:
  ROOTFS_FEATURES:append = " populate-systemd-preset"

Signed-off-by: Badrikesh Prusty <badrikesh.prusty@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)}"
-- 
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/20260113144832.3231870-2-badrikesh.prusty%40siemens.com.

Re: [PATCH v2 2/2] image: make populate-systemd-preset opt-in

['Heinisch, Alexander' via isar-users]

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 <badrikesh.prusty@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/04627060deedab9bb4b88a4b066027ae78f89cc8.camel%40siemens.com.

Re: [PATCH v2 1/2] image-postproc: ignore systemd preset failures

['Florian Bezdeka' via isar-users]

On Tue, 2026-01-13 at 09:48 -0500, 'Badrikesh Prusty' via isar-users
wrote:
> Add '|| true' to systemd preset invocation during image postprocessing
> to tolerate failures caused by already-masked units.

Hm. It's an assumption that this can only fail because of already-masked
units, no? Looking at the implementation below it looks more like that
we hide any error now.

> 
> 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..ef3ddb84 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 --preset-mode="enable-only" || 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/20260113144832.3231870-1-badrikesh.prusty%40siemens.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/195b950564b846dfac8fe4772f76bb38b8eeef6a.camel%40siemens.com.

Re: [PATCH v2 1/2] image-postproc: ignore systemd preset failures

['Badrikesh Prusty' via isar-users]

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

Hi,

>> Hm. It's an assumption that this can only fail because of already-masked
>> units, no? Looking at the implementation below it looks more like that
>> we hide any error now.
>>

Definitely not just an assumption, that’s one concrete reason among others.
For example, I have a package that runs `systemctl mask <service>` in its
postinst script of a package getting installed to rootfs during the 
rootfs_install
task. When the image postprocessing runs `systemctl preset ....` , it fails
because it tries to enable that masked service.

Thanks,
Badrikesh
On Tuesday, January 13, 2026 at 8:25:17 PM UTC+5:30 Florian Bezdeka wrote:

> On Tue, 2026-01-13 at 09:48 -0500, 'Badrikesh Prusty' via isar-users
> wrote:
> > Add '|| true' to systemd preset invocation during image postprocessing
> > to tolerate failures caused by already-masked units.
>
> Hm. It's an assumption that this can only fail because of already-masked
> units, no? Looking at the implementation below it looks more like that
> we hide any error now.
>
> > 
> > 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..ef3ddb84 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 
> --preset-mode="enable-only" || 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/20260113144832.3231870-1-badrikesh.prusty%40siemens.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/0e282996-91a7-4c2c-92b8-d00550eb1dben%40googlegroups.com.

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