Gentoo's default busybox config: module dependencies not correctly resolved (undefined symbols)
tbart opened this issue · comments
I include i915 in my initramfs. However - although the building process correctly evaluates the dependencies and pulls in intel_gtt (and drm etc. if they are modular as well), I get several undefined symbol errors during the modprobe step of the initramfs.
I found (https://e2e.ti.com/support/embedded/linux/f/354/t/593147) that the "Simplified modutils - Build smaller (~1.5 kbytes), simplified module tools." option of busybox may cause errors like these. The menuconfig's help text indicates it should work nevertheless, but be slower. It does not here, however.
Gentoo's default busybox config sets
CONFIG_MODPROBE_SMALL=y
If I configure busybox to not build small modprobe, the undefined symbol errors are gone and everything works as expected. An existing /etc/portage/savedconfig/sys-apps/busybox-* may also affect this (e.g. it could work if this is configured locally/at your test setup)
Here is a patch that unconditionally disables this feature:
--- /usr/share/mkinitramfs-ll/scripts/busybox.sh.org 2018-02-16 23:19:35.321250918 +0100
+++ /usr/share/mkinitramfs-ll/scripts/busybox.sh 2018-02-16 23:20:54.626462712 +0100
@@ -59,7 +59,9 @@
cd ${PORTDIR:-/usr/portage}/sys-apps/busybox
mkdir -p "${usrdir}"/bin
USE=static ebuild ${pkg}.ebuild clean || die "clean failed"
-USE=static ebuild ${pkg}.ebuild unpack || die "unpack failed"
+USE=static ebuild ${pkg}.ebuild configure || die "configure failed"
+# Small modprobe is not able to properly resolve dependencies, though it should
+sed -i "s/CONFIG_MODPROBE_SMALL=y/# CONFIG_MODPROBE_SMALL is not set/" "${PORTAGE_TMPDIR:-/var/tmp}"/portage/sys-apps/${pkg}/work/${pkg}/.config
USE=static ebuild ${pkg}.ebuild compile || die "compile failed"
cp "${PORTAGE_TMPDIR:-/var/tmp}"/portage/sys-apps/${pkg}/work/${pkg}/busybox \
"${usrdir}"/bin/ || die
btw: The unpack step is unnecessary anyway.
For those that need a quick fix, here's an updated ebuild that incorporates a fix for this and #50 as well:
Thanks for reporting. This issue should be fixed.