Bug 14118

(In reply to comment #0)
> When installing systemd via package feed (deb packages) some services (e.g.
> getty@tty1.service, systemd-networkd.service, ...) are not enabled.
> 

Hi Daniel,
Do you mean install systemd to a sysvint image via package feed? Or upgrade systemd in a systemd image via the package feed?

If the previous case, I suspect it is not supported. If the latter one, would you like to give more detailed steps please?

Thanks,
Kai

Hi Kai,
we have two use cases:
1. at the development host we are using the Multistrap tool (https://wiki.debian.org/Multistrap) to create a rootfs from a given list of packages using the debian packages from package feed.
2. at the target we are using the dpkg tool to install packages from the feed to a (new) rootfs (dpkg --root  /some/other/location -i systemd)

In both cases the dpkg tool is unpacking the debian package to a new (empty) root directory and after that the postinst scripts are called. The new systemd version requires to call "systemctl preset-all" in the postinst script to enable these services.

Regards,
Daniel

Daniel,
Kai doens't have time to work on this issue. YP does support dpkg feeds so it's a valid bug but honestly, I don't know of many people or organizations who are using that rather than rpm/dnf for pkgs so it may be a long time before anyone picks this up from the long list of unassigned bugs.

If you are able to work on this defect and send a patch, that would be great.
Thanks.

Bulk move of 64 bugs to 4.3 M3 after a quick review.
If a bug is actually fixed, please add a commit link and resolve it.
-- Randy for YP bug team.

Moved to M4.

Bulk move to 5.0 M1. -- Randy

Bulk move of 52 5.0-M1 bugs to M2.

Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.

Bulk move of bugs from 5.0-M3 to 5.99.
The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024.

If you disagree, please move back to a 5.[012...]-M* milestone.

Daniel,

Is this still happening for you?
Can you provide more detailed steps to reproduce the issue, please?
That might help someone decide to work on this problem.

There are more people interested in using dpkg now so maybe someone will get
to this bug eventually.

Someone at WindRiver will work on this.

Hello,

I tried to validate this issue on a supported Yocto release (scarthgap LTS) using the following steps:


Configured the build to use .deb packaging and systemd:
PACKAGE_CLASSES = "package_deb"
DISTRO_FEATURES:append = " systemd usrmerge"
VIRTUAL-RUNTIME_init_manager = "systemd"
EXTRA_IMAGE_FEATURES += "package-management"

Built the image:
bitbake core-image-minimal

Booted the image in QEMU:
runqemu qemux86-64

Verified systemd status and services:
systemctl status
systemctl list-unit-files --state=enabled


Observations:
systemd is running correctly
Services such as getty and systemd-networkd are enabled and active by default

Conclusion:
Based on testing with scarthgap LTS, the issue does not appear to be reproducible.

Question:
Could you please share the exact steps or environment where this issue can be reproduced? (e.g., specific Yocto version, installation method using dpkg, etc.)


Thanks
Himani

(In reply to Himani Barde from comment #12)
Hi Himani,
thanks for taking care of this issue.

We can reproduce this issue with the following setup:

- Packaging format: `package_deb`
- Package feed generated by Yocto and hosted via HTTP
- Target image includes `apt` and `dpkg`

Reproduction method 1: upgrade on target
1. Install an older version of the image on the device
2. Configure `/etc/apt/sources.list` to use the Yocto-generated package feed
3. Run:
   `apt update && apt full-upgrade`

Reproduction method 2: rootfs generation from feed
1. Generate and host the Yocto Debian package feed via HTTP
2. Use `multistrap` (https://manpages.debian.org/testing/multistrap/multistrap.1.en.html) to create a root filesystem from that feed

Our actual use case is method 2.

Regards,
Daniel

(In reply to daniel.dittmann from comment #13)
> (In reply to Himani Barde from comment #12)
> Hi Himani,
> thanks for taking care of this issue.
> 
> We can reproduce this issue with the following setup:
> 
> - Packaging format: `package_deb`
> - Package feed generated by Yocto and hosted via HTTP
> - Target image includes `apt` and `dpkg`
> 
> Reproduction method 1: upgrade on target
> 1. Install an older version of the image on the device
> 2. Configure `/etc/apt/sources.list` to use the Yocto-generated package feed
> 3. Run:
>    `apt update && apt full-upgrade`
> 
> Reproduction method 2: rootfs generation from feed
> 1. Generate and host the Yocto Debian package feed via HTTP
> 2. Use `multistrap`
> (https://manpages.debian.org/testing/multistrap/multistrap.1.en.html) to
> create a root filesystem from that feed
> 
> Our actual use case is method 2.
> 
> Regards,
> Daniel

Hello Daniel,

Thanks for sharing the detailed reproduction steps.

-I now understand that the issue occurs specifically during systemd installation/upgrade via apt/dpkg from a package feed, particularly when upgrading from an older image.

-In my testing, I validated the behavior on a freshly built scarthgap image (using QEMU), where systemd services such as getty and systemd-networkd are already enabled and running correctly.

-However, I was not able to fully reproduce the upgrade-based scenario due to limitations in my environment (specifically, setting up a full package feed and stable rebuilds for multiple image versions).

-Based on my understanding, the issue appears to be related to systemd post-install script behavior during dpkg-based installation rather than the initial image generation.

-Could you please confirm if the issue still reproduces with the latest scarthgap packages when upgrading from an older image?

Regards,
Himani

Hello Daniel,

daniel.dittmann@rohde-schwarz.com

Any recommendations on my last comment - how i can reproduce it?

hello daniel daniel.dittmann@rohde-schwarz.com ,

I've been investigating this issue. Here's what I found:

Setup: Poky Scarthgap (systemd 255.21), PACKAGE_CLASSES = "package_deb", INIT_MANAGER = "systemd"

Root Cause:

The issue is in meta/classes-recipe/systemd.bbclass. It generates a postinst script for each package with SYSTEMD_SERVICE defined. Example from systemd-binfmt_255.21-r0_amd64.deb:

#!/bin/sh
set -e
if systemctl >/dev/null 2>/dev/null; then
    OPTS=""
    if [ -n "$D" ]; then
        OPTS="--root=$D"
    fi
    if [ "enable" = "enable" ]; then
        for service in systemd-binfmt.service; do
            systemctl ${OPTS} enable "$service"
        done
    fi
    ...
fi

The postinst checks if systemctl >/dev/null 2>/dev/null before doing anything. In a normal Yocto image build, a native systemctl wrapper is available so this passes. But with multistrap/dpkg on a host:

*If systemctl is absent: the check fails, entire script is skipped
*If host's systemctl is present (e.g., Ubuntu 24.04): the check passes but systemctl --root=$D enable fails because it can't find the service units in the target rootfs
Either way, services don't get enabled.

Reproduction (method 2 — simulating multistrap):

1.Built core-image-minimal with package_deb + systemd (5257 deb packages)
2.Extracted systemd deb into a fresh rootfs
3.Result: no symlinks in etc/systemd/system/multi-user.target.wants/ or getty.target.wants/ — services NOT enabled
4.Ran the postinst with D set — host's systemctl fails with "unit does not exist"

What does work:

The preset files (90-systemd.preset, 98-*.preset) are correctly packaged inside the .deb files with the right enable entries (getty@.service, systemd-networkd.service, etc.). The data is all there — it just never gets applied because the postinst logic fails in cross-install scenarios.

Workaround confirmed:

Running systemctl --root=<rootfs> --preset-mode=enable-only preset-all after package extraction correctly enables all expected services.

Package feed test (method 1):

Also set up a deb package feed (apt-ftparchive + HTTP server), booted image in QEMU with apt included, and confirmed apt can fetch packages from the feed successfully. On a freshly built image the services are already enabled by Yocto's image creation process — the bug specifically manifests when packages are installed outside of Yocto's normal rootfs creation (i.e., multistrap or apt upgrade with new service packages).