update-alternatives + absolute links

Hello!

I noticed that toybox's switch_root has problems handling /sbin/init -> /lib/systemd/systemd. Apparently it tries to check permissions with stat() before switching the root, and at that point resolving the symlink fails.

Are there reasons for preferring absolute paths as link target? Using relative paths would avoid the problem, and also make it easier to investigate the content of the rootfs on the build host.

Is that something that would have to be fixed in the different virtual/update-alternatives providers? I'm using opkg-utils at the moment.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Here's a proof-of-concept patch that modifies opkg-utils-native so that it calls lnr for turning the absolute link target into something relative. This turned out to be more complex than anticipated, so a proper patch instead of the sed mangling would be more appropriate now.

It is limited to opkg-utils-native and thus image creation. On the target it's harder: "ln --relative" only works for coreutils, lnr is not installed, and Python cannot be taken for granted either.

Not sure how to proceed. Perhaps its not worth changing after all.

index 1bc561c..4ea7132 100644
@@ -38,6 +38,12 @@ do_install_append_class-target() {
        fi
 }
 
+do_install_append_class-native() {
+       if [ -e "${D}${bindir}/update-alternatives" ]; then
+               sed -i ${D}${bindir}/update-alternatives -e 's!ln -snf .*!case "$path" in /*) realpath="$D$path"; rm -f $link \&\& lnr $realpath $link;; *) ln -snf $path $link;; esac!'
+       fi
+}
+
 PACKAGES =+ "update-alternatives-opkg"
 FILES_update-alternatives-opkg = "${bindir}/update-alternatives"
 RPROVIDES_update-alternatives-opkg = "update-alternatives update-alternatives-cworth"

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.