Hi Paul, The use case comes from Bugzilla #14118 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=14118. The reporter (Daniel) uses Yocto-generated deb packages with multistrap on an Ubuntu 24.04 host to assemble a root filesystem outside of bitbake.
Their workflow: 1. Build with PACKAGE_CLASSES = "package_deb" 2. Host the generated deb feed via HTTP 3. Use multistrap to create a rootfs from that feed 4. Run postinst scripts via fakeroot In this scenario, systemd-systemctl-native is not available since they're outside of bitbake's environment. The postinst scripts are run by the host's dpkg infrastructure, not by bitbake's do_rootfs. I understand the current behavior is deliberate for the normal Yocto image build path. The issue is specifically about consuming Yocto-generated packages outside of bitbake - which is a supported use case when package-management is enabled, and packages are meant to be installed via apt/dpkg at runtime or for external rootfs assembly. Would it be acceptable to handle this as a fallback only when systemctl is not available (i.e., not change anything for the normal do_rootfs or on-target paths)? Or would you prefer a different approach? Regards, Himani ________________________________ From: Paul Barker Sent: Thursday, July 30, 2026 7:49 PM To: Barde, Himani Ramesh; [email protected] Cc: MacLeod, Randy; Komati, Shiva Subject: Re: [PATCH v3] systemd.bbclass: fix service enablement for cross-install scenarios On Wed, 2026-07-22 at 10:14 +0000, Himani Ramesh Barde wrote: > When packages are installed outside of Yocto's normal image creation > (e.g., using multistrap, debootstrap, or dpkg directly on a host), > the postinst script fails to enable systemd services. Hi, What's the use case for this? I'm not aware of a reason to install packages generated via a Yocto Project build using multistrap/debootstrap or via dpkg on the host. > The issue is that the entire enable logic is gated behind > "if type systemctl >/dev/null 2>/dev/null". In cross-install scenarios: > - If systemctl is absent on the host: the check fails, script is skipped > - If host systemctl is present: it cannot find target unit files This is deliberate. On target, if systemd is in use then systemctl will be available. At do_rootfs time, we depend on systemd-tools-native to provide systemctl, the intention is that we're running the native systemctl binary that we built, not the host's systemctl binary. > Fix this by separating the image-build ($D set) and on-target ($D unset) > code paths into distinct branches. The previous code used a single > OPTS variable to switch between "--root=$D" (image-build) and "" > (on-target) within one unified block. This variable is removed because > the two scenarios now have dedicated branches with different logic: > > - Image-build ($D set): Uses "systemctl --root=$D preset" per service, > which reads preset files from the target rootfs and creates symlinks > without needing the host systemctl to understand the target's unit > files. Falls back to "systemctl --root=$D enable" per service. > > - On-target ($D unset): Same as before - enable, daemon-reload, preset, > restart. No behavioral change for on-target installs. > > The OPTS variable is no longer needed because each branch now directly > uses the appropriate systemctl invocation for its context, making the > intent clearer and the image-build path functional. > > Fixes [YOCTO #14118] > > Signed-off-by: Himani Ramesh Barde <[email protected]> Best regards, -- Paul Barker
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#242411): https://lists.openembedded.org/g/openembedded-core/message/242411 Mute This Topic: https://lists.openembedded.org/mt/120391669/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
