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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
