You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously reported at yocto bugzilla, but now here as alternatives-symlinks-relative appears to be a karo-fork feature.
Busybox tells update-alternatives that start-stop-daemon should be located /sbin/start-stop-daemon, and could be linked to /bin/busybox.nosuid
Dpkg's subpackage dpkg-start-stop tells update-alternatives that start-stop-daemon should be located at /usr/sbin/start-stop-daemon, and could be linked to /usr/sbin/start-stop-daemon.dpkg
Busybox appears to be installed first (this might be a race condition), resulting in the link location being /sbin/start-stop-daemon
This in itself wouldn't be a problem, but when combined with DISTRO_FEATURESalternatives-symlinks-relative, this results in a relative symlink alternative being generated for the dpkg version, in the same directory as its target.
So:
/usr/sbin/start-stop-daemon.dpkg and /usr/sbin/start-stop-daemon are in the same directory
So the dpkg alternative relative symlink is just start-stop-daemon.dpkg
But the actual link location is /sbin/start-stop-daemon
update-alternatives then is instructed to create a link from /sbin/start-stop-daemon to start-stop-daemon.dpkg (effectively /sbin/start-stop-daemon.dpkg)
But as /sbin/start-stop-daemon.dpkg doesn't exist, update-alternatives refuses to do this, resulting in /sbin/start-stop-daemon being missing from the resulting system.
This is a combination of several things:
Disagreement between two packages on the correct location of the symlink
The relative symlink target being generated based on the specified symlink location, rather than the actual one
update-alternatives not warning about conficting symlink locations
update-alternatives refusing to create a link (without a warning I could easily find) when the highest-priority target doesn't actually exist
The final result is an image that does not have start-stop-daemon in either /sbin or /usr/sbin, despite having both busybox and start-stop-daemon.dpkg installed.
I've locally fixed this by putting the following in busybox_%.bbappend:
do_install:append() {
sed -i "s:^/sbin/start-stop-daemon:/usr/sbin/start-stop-daemon:" ${D}${sysconfdir}/busybox.links.nosuid
}
The text was updated successfully, but these errors were encountered:
I'm writing a patch to add checks to update-alternatives.bbclass to catch things like this, and I immediately found the following:
Running groupadd commands...
NOTE: busybox: Performing groupadd with [ --system utmp]
NOTE: busybox: group utmp already exists, not re-creating it
update-alternatives: Linking /usr/bin/arch to arch.coreutils
update-alternatives: renaming base32 link from /usr/bin/base32 to /bin/base32
update-alternatives: Linking /bin/base32 to base32.coreutils
warning: %post(busybox-1.36.1-r0.armv8a) scriptlet failed, exit status 1
root@device:~# ls -l /bin/base32
lrwxrwxrwx 1 root root 16 Sep 13 13:40 /bin/base32 -> base32.coreutils
root@device:~# ls -l /bin/base32.coreutils
ls: cannot access '/bin/base32.coreutils': No such file or directory
It's the same issue: coreutils installs /usr/bin/base32.coreutils, trying to link to it from /usr/bin/base32 and busybox tries to link from /bin/base32 to /bin/busybox.nosuid, but both are configured in /usr/lib/opkg/alternatives/base32, which breaks when using relative symlinks.
Previously reported at yocto bugzilla, but now here as
alternatives-symlinks-relative
appears to be a karo-fork feature.Busybox tells
update-alternatives
thatstart-stop-daemon
should be located/sbin/start-stop-daemon
, and could be linked to/bin/busybox.nosuid
Dpkg's subpackage
dpkg-start-stop
tells update-alternatives thatstart-stop-daemon
should be located at/usr/sbin/start-stop-daemon
, and could be linked to/usr/sbin/start-stop-daemon.dpkg
Busybox appears to be installed first (this might be a race condition), resulting in the link location being
/sbin/start-stop-daemon
This in itself wouldn't be a problem, but when combined with
DISTRO_FEATURES
alternatives-symlinks-relative
, this results in a relative symlink alternative being generated for the dpkg version, in the same directory as its target.So:
/usr/sbin/start-stop-daemon.dpkg
and/usr/sbin/start-stop-daemon
are in the same directorystart-stop-daemon.dpkg
/sbin/start-stop-daemon
update-alternatives
then is instructed to create a link from/sbin/start-stop-daemon
tostart-stop-daemon.dpkg
(effectively/sbin/start-stop-daemon.dpkg
)/sbin/start-stop-daemon.dpkg
doesn't exist,update-alternatives
refuses to do this, resulting in/sbin/start-stop-daemon
being missing from the resulting system.This is a combination of several things:
The final result is an image that does not have
start-stop-daemon
in either/sbin
or/usr/sbin
, despite having bothbusybox
andstart-stop-daemon.dpkg
installed.I've locally fixed this by putting the following in
busybox_%.bbappend
:The text was updated successfully, but these errors were encountered: