@zubairlk / all, a bit of an update on the overall progress:
I’ve run into three different issues with this route, all caused by and semi-solved by the same thing.
Issue 1: balena-healthcheck
See above for details.
Issue 2: networkmanager
The cleanup for do_install() of networkmanager_1.18.0 failed because it couldn’t find usr/lib64/NetworkManager/conf.d.
| rmdir: failed to remove '/code/balena-amd/build/tmp/work/dbfp5-poky-linux/networkmanager/1.18.0-r0/image/usr/lib64/NetworkManager/conf.d': No such file or directory
| WARNING: /code/balena-amd/build/tmp/work/dbfp5-poky-linux/networkmanager/1.18.0-r0/temp/run.do_install.1856:1 exit 1 from 'rmdir /code/balena-amd/build/tmp/work/dbfp5-poky-linux/networkmanager/1.18.0-r0/image/usr/lib64/NetworkManager/conf.d'
| ERROR: Function failed: do_install (log file is located at /code/balena-amd/build/tmp/work/dbfp5-poky-linux/networkmanager/1.18.0-r0/temp/log.do_install.1856)
ERROR: Task (/code/balena-amd/build/../layers/meta-balena/meta-balena-common/recipes-connectivity/networkmanager/networkmanager_1.18.0.bb:do_install) failed with exit code '1'
Issue 3: plymouth
The do_install step for plymouth was trying to remove something in usr/lib64/. Sadly I didn’t save the exact logs for this.
All of these issues appear to be caused by v1000 setting BASE_LIB_tune-dbfp5 to lib64 rather than lib. It looks like genericx86-64 sets BASE_LIB to lib rather than lib64 (though I am somewhat confused exactly how as it looks like it should be lib64 based on my understanding of the tune files).
The following patch resolves all of these issues, though I don’t believe it is the correct final solution, just a stopgap that proves the issue and allows builds to progress in the meantime:
diff --git a/meta-amd-bsp/conf/machine/include/tune-v1000.inc b/meta-amd-bsp/conf/machine/include/tune-v1000.inc
index 1c481cd3..d062fb5b 100644
--- a/meta-amd-bsp/conf/machine/include/tune-v1000.inc
+++ b/meta-amd-bsp/conf/machine/include/tune-v1000.inc
@@ -10,6 +10,7 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "dbfp5", " - march=znver1",
# Extra tune selections
AVAILTUNES += "dbfp5"
TUNE_FEATURES_tune-dbfp5 = "m64 dbfp5"
-BASE_LIB_tune-dbfp5 = "lib64"
+//BASE_LIB_tune-dbfp5 = "lib64"
+BASE_LIB_tune-dbfp5 = "lib"
TUNE_PKGARCH_tune-dbfp5 = "dbfp5"
PACKAGE_EXTRA_ARCHS_tune-dbfp5 = "${TUNE_PKGARCH_tune-dbfp5}"
The BASE_LIB is used by poky to set libdir, which causes a few issues when it is lib64 rather than lib.
I wasn’t able to track down the exact issue for plymouth or balena-healthcheck (though I have suspicions/assumptions). However, I was able to track down the issue with networkmanager.
The file that causes the issue is layers/meta-balena/meta-balena-common/recipes-connectivity/networkmanager/networkmanager_%.bbappend, lines 54 & 55. Specifically it uses libdir rather than nonarch_libdir. Changing lines 54 and 55 from:
rmdir ${D}${libdir}/NetworkManager/conf.d
rmdir ${D}${libdir}/NetworkManager/VPN
to
rmdir ${D}${nonarch_libdir}/NetworkManager/conf.d
rmdir ${D}${nonarch_libdir}/NetworkManager/VPN
rmdir ${D}${nonarch_libdir}/NetworkManager
rmdir ${D}${nonarch_libdir}
allows the networkmanager do_install to successfully complete. I believe this is the correct (or close to the correct fix) based on a commit 0b8be3760 for layers/meta-balena/meta-balena-common/recipes-connectivity/networkmanager/networkmanager_1.18.0.bb. I’ve included the relative snippet here:
tree 5d476e7825c73344e9eb3851c166eacbca24f8c0
parent 21a7866000f444850b7a73272a7b0d33f7376bec
author Zubair Lutfullah Kakakhel <zubair@balena.io> Wed Dec 12 17:02:00 2018 +0000
committer Zubair Lutfullah Kakakhel <zubair@balena.io> Thu Dec 13 10:43:43 2018 +0000
encoding
networkmanager: Bump recipe to v1.14.4
Update recipe from upstream meta-openembedded
http://cgit.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/networkmanager?id=331b717b862e3599b99942acb64c1d6b03806042
Difference in size ~ +400K
Change-type: minor
Changelog-entry: Bump network manager from v1.12.2 to v1.14.4
Signed-off-by: Zubair Lutfullah Kakakhel <zubair@balena.io>
diff --git a/meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.12.2.bb b/meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
similarity index 74%
rename from meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.12.2.bb
rename to meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
index af221d62..870a5281 100644
--- a/meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.12.2.bb
+++ b/meta-resin-common/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
@@ -97,24 +104,24 @@ FILES_${PN}-adsl = "${libdir}/NetworkManager/libnm-device-plugin-adsl.so"
FILES_${PN} += " \
${libexecdir} \
- ${libdir}/pppd/*/nm-pppd-plugin.so \
${libdir}/NetworkManager/${PV}/*.so \
- ${libdir}/NetworkManager/VPN \
- ${libdir}/NetworkManager/conf.d \
+ ${nonarch_libdir}/NetworkManager/VPN \
+ ${nonarch_libdir}/NetworkManager/conf.d \
${datadir}/polkit-1 \
${datadir}/dbus-1 \
- ${base_libdir}/udev/* \
+ ${noarch_base_libdir}/udev/* \
${systemd_unitdir}/system \
"
RRECOMMENDS_${PN} += "iptables \
- ${@bb.utils.contains('PACKAGECONFIG', 'dnsmasq', 'dnsmasq', '', d)} \
+ ${@bb.utils.filter('PACKAGECONFIG', 'dnsmasq', d)} \
"
RCONFLICTS_${PN} = "connman"
FILES_${PN}-dev += " \
${datadir}/NetworkManager/gdb-cmd \
${libdir}/pppd/*/*.la \
+ ${libdir}/NetworkManager/*.la \
${libdir}/NetworkManager/${PV}/*.la \
"
Based on this change (using nonarch_libdir), I am assuming that networkmanager_%.bbappend should also be using that. The modification to nonarch_libdir I specified above does allow the build to continue successfully.
Note: As these changes are in the meta-amd and meta-balena submodules, they aren’t pushed in any branches of balena-amd. The branch that was used for this within balena-amd was meta-amd-warrior-from-scratch. meta-amd-warrior runs into an additional issue with a kernel patch not applying correctly and I wanted to remove that from the possible causes for these issues.
Just for completeness of anyone following along, changing BASE_LIB_tune-dbfp5 to lib allows the build to complete until 99% when the following error gets hit:
ERROR: resin-image-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['libglib-2.0-0', 'udev-hwdb']
ERROR: resin-image-1.0-r0 do_rootfs:
ERROR: resin-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /code/balena-amd/build/tmp/work/v1000-poky-linux/resin-image/1.0-r0/temp/log.do_rootfs.12053
ERROR: Task (/code/balena-amd/build/../layers/meta-balena/meta-balena-common/recipes-core/images/resin-image.bb:do_rootfs) failed with exit code '1'
ERROR: resin-image-flasher-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['libglib-2.0-0', 'udev-hwdb']
ERROR: resin-image-flasher-1.0-r0 do_rootfs:
ERROR: resin-image-flasher-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /code/balena-amd/build/tmp/work/v1000-poky-linux/resin-image-flasher/1.0-r0/temp/log.do_rootfs.12057
ERROR: Task (/code/balena-amd/build/../layers/meta-balena/meta-balena-common/recipes-core/images/resin-image-flasher.bb:do_rootfs) failed with exit code '1'
Which if you look into the log files gives a bit more info:
NOTE: Installing complementary packages ...
NOTE: Running ['oe-pkgdata-util', '-p', '/code/balena-amd/build/tmp/pkgdata/v1000', 'glob', '/tmp/installed-pkgsh5xcnptp', '']
NOTE: Running intercept scripts:
NOTE: If an image is being built, the postinstalls for the following packages will be postponed for first boot: udev-hwdb
NOTE: > Executing update_gio_module_cache intercept ...
NOTE: Exit code 1. Output:
+ '[' False = False -a qemuwrapper-cross '!=' nativesdk-qemuwrapper-cross ']'
+ echo 'qemuwrapper: qemu usermode is not supported'
qemuwrapper: qemu usermode is not supported
+ exit 1
NOTE: The postinstall intercept hook 'update_gio_module_cache' could not be executed due to missing qemu usermode support, details in /code/balena-amd/build/tmp/work/v1000-poky-linux/resin-image/1.0-r0/temp/log.do_rootfs
NOTE: If an image is being built, the postinstalls for the following packages will be postponed for first boot: libglib-2.0-0
This is caused by qemuwrapper not being enabled as that prevents the various systemd_241.bb files from running their pkg_postinst_udev-hwdb lines in emulation and not being able to on first boot because resin-image has read-only-rootfs set.
AMD disables qemu-usermode in layers/meta-amd-bsp/conf/machine/include/amd-common-configurations.inc:
# QEMU does not support some of the enhanced instructions available
MACHINE_FEATURES_remove = "qemu-usermode"
Adding back in qemu-usermode causes a number of other build issues that we’re currently looking at.
