Hi,

Apologies for the delayed response.
It looks like /proc and /sys are already mounted during the beginng of the do_rootfs_postprocess task via rootfs_do_mounts function. Shell function run order:
```
$ grep "DEBUG: Shell" temp/log.do_rootfs_postprocess
DEBUG: Shell function rootfs_do_mounts finished
DEBUG: Shell function rootfs_do_qemu finished
DEBUG: Shell function image_postprocess_disable_systemd_firstboot finished
DEBUG: Shell function image_postprocess_sshd_key_regen finished
DEBUG: Shell function image_postprocess_machine_id finished
DEBUG: Shell function image_postprocess_mark finished
DEBUG: Shell function image_postprocess_configure finished
DEBUG: Shell function generate_sbom finished
DEBUG: Shell function rootfs_postprocess_clean_package_cache finished
DEBUG: Shell function rootfs_postprocess_clean_log_files finished
DEBUG: Shell function rootfs_postprocess_clean_debconf_cache finished
DEBUG: Shell function rootfs_postprocess_clean_pycache finished
DEBUG: Shell function rootfs_postprocess_clean_ldconfig_cache finished
DEBUG: Shell function rootfs_postprocess_clean_tmp finished
DEBUG: Shell function rootfs_generate_manifest finished
DEBUG: Shell function rootfs_export_dpkg_status finished
DEBUG: Shell function rootfs_cleanup_isar_apt finished
DEBUG: Shell function image_postprocess_populate_systemd_preset finished
DEBUG: Shell function image_disable_systemd_networkd finished
DEBUG: Shell function rootfs_do_umounts finished
``` 

Added "ls -l" to list the rootfs directories after do_mounts: (/proc and /sys mounted)

```
lrwxrwxrwx   1 root       root          7 Mar  2 21:50 bin -> usr/bin
drwxr-xr-x   2 root       root       4.0K Apr 23 06:28 boot
-rwxr-xr-x   1 root       root       3.5K Apr 21 11:05 chroot-setup.sh
drwxr-xr-x  15 root       root       3.4K Apr 23 06:27 dev
drwxr-xr-x  58 root       root       4.0K Apr 23 06:28 etc
drwxr-xr-x   3 root       root       4.0K Apr 23 06:28 home
lrwxrwxrwx   1 root       root         29 Apr 23 06:28 initrd.img -> boot/initrd.img-6.12.78-cip19
lrwxrwxrwx   1 root       root         29 Apr 23 06:28 initrd.img.old -> boot/initrd.img-6.12.78-cip19
drwxr-xr-x   5 industrial industrial 4.0K Apr 21 11:05 isar-apt
drwxr-xr-x  11 industrial industrial 4.0K Apr 23 06:28 isar-work
lrwxrwxrwx   1 root       root          7 Mar  2 21:50 lib -> usr/lib
lrwxrwxrwx   1 root       root          9 Mar  2 21:50 lib64 -> usr/lib64
drwxr-xr-x   2 root       root       4.0K Apr 21 11:05 media
drwxr-xr-x   2 root       root       4.0K Apr 21 11:05 mnt
drwxr-xr-x   3 root       root       4.0K Apr 23 06:28 opt
dr-xr-xr-x 813 root       root          0 Apr 23 06:28 proc
drwx------   3 root       root       4.0K Apr 23 06:28 root
drwxr-xr-x   9 root       root       4.0K Apr 23 06:28 run
lrwxrwxrwx   1 root       root          8 Mar  2 21:50 sbin -> usr/sbin
drwxr-xr-x   2 root       root       4.0K Apr 21 11:05 srv
drwxr-xr-x  13 root       root          0 Mar  2 21:50 sys
drwxrwxrwt   2 root       root       4.0K Apr 23 06:28 tmp
drwxr-xr-x  12 root       root       4.0K Apr 21 11:05 usr
drwxr-xr-x  11 root       root       4.0K Apr 21 11:05 var
lrwxrwxrwx   1 root       root         26 Apr 23 06:28 vmlinuz -> boot/vmlinuz-6.12.78-cip19
lrwxrwxrwx   1 root       root         26 Apr 23 06:28 vmlinuz.old -> boot/vmlinuz-6.12.78-cip19
```

Will send a v4 patch with a “Fixes” tag. That should unblock builds for Bookworm or earlier that mask the systemd service.

Many Thanks,
Badrikesh

On Friday, February 20, 2026 at 1:51:04 PM UTC+5:30 MOESSBAUER, Felix wrote:
On Thu, 2026-02-19 at 20:10 +0100, Jan Kiszka wrote:
> On 19.02.26 18:52, Jan Kiszka wrote:
> > On 19.02.26 05:44, 'Badrikesh Prusty' via isar-users wrote:
> > > changes in v3:
> > > * Do not disable pre-population of enabled systemd services during build,
> > > as this is the correct default behavior. Downstream layers can disable
> > > it if needed.
> > > * Ignore failures from systemd preset only.
> > >
> > > changes in v2:
> > > * Disable populate-systemd-preset at build time by default due to service
> > > failures observed on some systems.
> > >
> > > Badrikesh Prusty (1):
> > > image-postproc: ignore systemd preset failures
> > >
> > > meta/classes-recipe/rootfs.bbclass | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> >
> > Is this series aiming at these new warnings of Isar?
> >
> > DEBUG: Executing shell function image_postprocess_disable_systemd_firstboot
> > /proc/ is not mounted. This is not a supported mode of operation. Please fix
> > your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
> > Your mileage may vary.
> > Created symlink '/etc/systemd/system/systemd-firstboot.service' → '/dev/null'.
> > WARNING: Your image is not configured completely according to systemd-firstboot.
> > WARNING: It prompted: ""
> > DEBUG: Shell function image_postprocess_disable_systemd_firstboot finished
> >
>
> Hmm, no. This seems to be another to-do for Felix' rootless patches. I
> was running them, and this warning is gone when going back to vanilla Isar.

Good catch. We need /proc and /sys mounted, which we currently not do
in this task.

Felix

>
> Jan
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center

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

--
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/a5997ec4-bc73-4772-80f3-3713a9c788ebn%40googlegroups.com.