From: "Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>
To: <HimaniRamesh.Barde@windriver.com>,
<openembedded-core@lists.openembedded.org>
Cc: <Randy.MacLeod@windriver.com>, <Shiva.Komati@windriver.com>
Subject: Re: [OE-core] [PATCH] systemd.bbclass: fix service enablement for cross-install scenarios
Date: Fri, 17 Jul 2026 20:02:43 +0200 [thread overview]
Message-ID: <DK11L8A7P6BN.2E0LE48SCL6SU@bootlin.com> (raw)
In-Reply-To: <20260716061519.765593-1-HimaniRamesh.Barde@windriver.com>
On Thu Jul 16, 2026 at 8:15 AM CEST, Himani Ramesh Barde via lists.openembedded.org 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.
>
> The issue is that the entire enable logic is gated behind
> "if 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
>
> Fix this by separating the offline ($D set) and online ($D unset)
> code paths into distinct branches. The previous code used a single
> OPTS variable to switch between "--root=$D" (offline) and "" (online)
> within one unified block. This variable is removed because the two
> scenarios now have dedicated branches with different logic:
>
> - Offline ($D set): Tries "systemctl --root=$D preset" first, 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.
>
> - Online ($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 offline path functional.
>
> Fixes [YOCTO #14118]
>
> Signed-off-by: Himani Ramesh Barde <HimaniRamesh.Barde@windriver.com>
> ---
Hi Himani Ramesh,
I tried to pick this patch, but I can see some conflicts with the master
branch. Can you confirm this is targeting the master branch and based on
a recent master?
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2026-07-17 18:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 6:15 [PATCH] systemd.bbclass: fix service enablement for cross-install scenarios Himani Ramesh Barde
2026-07-17 18:02 ` Mathieu Dubois-Briand [this message]
2026-07-22 6:47 ` [PATCH v2] " Himani Ramesh Barde
2026-07-22 6:49 ` Barde, Himani Ramesh
2026-07-22 9:49 ` [OE-core] " Jörg Sommer
2026-07-22 10:16 ` Barde, Himani Ramesh
2026-07-22 10:14 ` [PATCH v3] " Himani Ramesh Barde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DK11L8A7P6BN.2E0LE48SCL6SU@bootlin.com \
--to=mathieu.dubois-briand@bootlin.com \
--cc=HimaniRamesh.Barde@windriver.com \
--cc=Randy.MacLeod@windriver.com \
--cc=Shiva.Komati@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox