Note: I'm not sure if this is the right product&component for the poky/meta layer. The wiki unfortunately didn't help me much in this regard. 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_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 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
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.
alternatives-symlinks-relative is not a commonly use DISTRO_FEATURE. What layer is that used in? Are you able to reproduce the problem using just oe-core/poky? Moving to the 5.2.
I did find this line: DISTRO_FEATURES:append = " alternatives-symlinks-relative rauc u-boot-fw-utils" in this documentation: https://karo-electronics.github.io/docs/software-documentation/rauc/index.html but meta-rauc nor any of the 113 meta-foo repos I have on hand have that string and meta-rauc's, poky's, meta-oe's commit logs patches do not contain the string: alternatives-symlinks-relative
The default local.conf [1] for karo-nxp-base uses alternatives-symlinks-relative. This is from karo's setup repository [2] for some of their systems. [1] https://github.com/karo-electronics/karo-nxp-base/blob/mickledore/conf/templates/default/local.conf.sample [2] https://github.com/karo-electronics/karo-nxp-base/blob/mickledore/karo-setup-release.sh
Thanks. I see that DISTRO_FEATURE (DF) being used in that layer and mentioned in the documentation but I don't see where it is defined. Perhaps it's irrelevant? Sorry that I am not able to take time to work on the issue rather than asking all these questions but that's what I have time for now. Does the issue still happen if you don't use that DF and you only use poky?
I'm not sure if I understand your question, but: > $ ack alternatives-symlinks-relative > poky/meta/classes-recipe/update-alternatives.bbclass > 264: if bb.utils.contains('DISTRO_FEATURES','alternatives-symlinks-relative',True,False,d): > > base/conf/templates/default/local.conf.sample > 91:DISTRO_FEATURES:append = " alternatives-symlinks-relative" I can try turning it off, but not right now, and there's probably a reason why it's in the default config. It was added in this commit [1], when the file was created. [1] https://github.com/karo-electronics/karo-nxp-base/commit/18009364b5cc93b5657db3e0b8b4c22f1cb5210a
Ah, karo has a fork of poky and there's a commit here: https://github.com/karo-electronics/poky/commit/38282b7fdd8 that is not part of: https://git.yoctoproject.org/poky/ On kirkstone the two trees differ quite a bit: ❯ diff -Naur poky.git/meta karo/karo-poky.git/meta | diffstat | tail -1 1924 files changed, 20332 insertions(+), 156609 deletions(-) Anyway, alternatives-symlinks-relative seems like an interesting perhaps useful change but there isn't even any sign of it being sent to the oe-core list: https://lore.kernel.org/openembedded-core/?q=alternatives-symlinks-relative so you'll have to talk with the karo developers. They or you are welcome to send the change to oe-core (1) once 5.2 development opens up or even now as an RFC. Since this isn't a problem with the upstream version of poky, I'm going to close the defect as invalid. Please comment to let me know that you understand and agree with this resolution and of course re-open as needed. Thanks again and good luck, ../Randy 1) https://www.yoctoproject.org/community/contribute/ but really this is the list you or others should subscribe to and then send the patch to: https://lists.openembedded.org/g/openembedded-core
Okay, I agree that the problem only shows up on the karo fork, and I've reported it there [1], but there are still a few things wrong that contribute to this: dpkg and busybox still disagree on the proper location of start-stop-daemon. This may mean that depending on the order of installation of the packages, the symlink may be in /usr/sbin or /sbin. There appears to be a missing check in the processing of update-alternatives.bbclass: if for some reason the target of the highest-priority target doesn't exist, the symlink is not created. I would expect an error during the creation of the image. [1] https://github.com/karo-electronics/poky/issues/3
Hi Alexander, Thanks for following up with the karo folks. Hopefully they'll see fit to send their alternatives-symlinks-relative change to oe-core/master. Last night I was wondering if I had resolved the defect too soon and thankfully you've followed up by making your last comment and explaining the remaining problem. Re-open. Do you plan to fix this and send a patch or are you willing to wait for someone else to take an interest and to find time to work on the bug?
Well, for the former, I locally use the following busybox_%.bbappend: > # Busybox installs its version of start-stop-daemon to base_sbindir, > # While dkpg installs its own version to sbindir. > # This causes conflicts when the path is relativized, and /sbin/start-stop-> daemon.dpkg cannot be found. > # After an attempt to fix this by modifying dpkg, we're just modifying busybox instead > do_install:append() { > sed -i "s:^/sbin/start-stop-daemon:/usr/sbin/start-stop-daemon:" ${D}${sysconfdir}/busybox.links.nosuid > } I can provide that as a patch if you like. Alternatively, we could patch dpkg to install to /sbin instead of /usr/sbin/. For the latter, opkg's update-alternatives appears to do absolutely no checks regarding whether the targets actually exist. It's called from a postinst script that's generated by the python task populate_packages_updatealternatives in update-alternatives.bbclass, but unfortunately, the information needed to determine this kind of issue is not available there. That leaves me with 2 options that I can see: add checks to update-alternatives, or add lines to the generated postinst script that check if the link actually exists and points to a file that exists.
I haven't taken time to confirm but it looks like you should send a patch the oe-core list to make the paths the same. I'm on vacation soon until Oct 15, so I won't reply again until then.
It took rather longer than I intended, but a patch has been submitted to the list. [1] [1] https://lists.openembedded.org/g/openembedded-core/topic/patch_busybox_change/110876352 I also have a local change to update-alternatives.bbclass, but I'm not sure that's the right approach.
Alexander, Your patch has been merged to master: https://git.openembedded.org/openembedded-core/commit/?id=9998d91f982cd323fa5da20edda8b1828bd4fb5d ❯ git branch -a --contains 9998d91f982cd323fa5da20edda8b1828bd4fb5d * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/master-next As is explained in our Contributor Guide, If your patches have not had any feedback in a few days, they may have already been merged. You can run git pull branch to check this. Note that many if not most layer maintainers do not send out acknowledgement emails when they accept patches. https://docs.yoctoproject.org/contributor-guide/submit-changes.html#tracking-the-status-of-patches Thanks for fixing the bug and for following up with Stephen Jolley!