update-alternatives + absolute links

update-alternatives + absolute links

[Patrick Ohly]

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.

Re: update-alternatives + absolute links

[Patrick Ohly]

On Tue, 2016-02-09 at 12:03 +0100, Patrick Ohly wrote:
> 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.

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.

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 1bc561c..4ea7132 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -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.