I am using poky-master this commit: commit be1cf223bf9c514ee81820ded5b13318458c0daf Author: Peter Bergin <peter@berginkonsult.se> Date: Fri Jul 2 13:59:00 2021 +0200 I build something like this: BB_VERSION = "1.51.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-resy-linux-gnueabi" MACHINE = "imx6q-phytec-mira-rdk-nand" DISTRO = "resy" DISTRO_VERSION = "3.3+snapshot-be1cf223bf9c514ee81820ded5b13318458c0daf" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "master:be1cf223bf9c514ee81820ded5b13318458c0daf" meta-multi-v7-ml-bsp-master = "master:a3ec5350eee588887306e81252dcc65f87c3a1ac" meta-u-boot-wic-bsp-master = "master:117c60a01a3bda39b397eb0ac510642b6eed3ec1" meta-resy-master = "master:24389add58c9e40df965e411efe17dc58ae320f3" meta-oe meta-networking meta-filesystems meta-python = "master:73d5cd5e8d9d8a922b6a8a9d90adf0470a99314e" meta-tig-master = "master:bebe6ca3dcc300e79e6f223f19f71a1fddf89921" This is the current version of my recipe: https://pastebin.com/nRhMAQ4S When I build an image with grafana it installs this: https://pastebin.com/hQ7s5M1B Please note that the md5sum is wrong and that it gives a segmentation fault. ... but ... if I copy manually the package over and install it: https://pastebin.com/tV85v7mw Please note, that now I don't have a segmentation fault and the md5sum is as it is supposed to be Is there a problem with opkg run on x86? Or is there something else magical which corrupts the binary? Apparently the packages gets into package correctly, since it seems to work when I install it manually on the target.
Even if I use rpm instead of ipk is the same problem. So it seems to be some more generic "magic" after? a package is installed while building an image on the host. Not sure what this is. I always thought that what's in the package actually ends up in the image.
You said that the md5sum on-image differed from the value you expected. But it isn't clear to me where you're getting the *correct* value from. It would be helpful to compare the md5sums of the daemon binary between: 1. your grafana_8.0.4 recipe WORKDIR 2. the grafana_8.0.4.ipk/.rpm in your deploy directory 3. the unpacked binary on target. ... to see where it changes. The OE build process creates an IPK[1] using the tools in opkg-utils[2]. It packs the compiled daemon binary (and other package content) into a data.tar.xz segement, and then composes the IPK using `ar`. You should be able to unpack the composed IPK by just reversing that process, and verify that the daemon binary is well-formed. [1] https://git.openembedded.org/openembedded-core/tree/meta/classes/package_ipk.bbclass#n12 [2] https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg-build >Is there a problem with opkg run on x86? Not that I'm aware of. >Or is there something else magical which corrupts the binary? In general, I think it is unlikely that opkg itself is mangling the daemon binary contents. It offloads most of the work of packing/unpacking package contents to system utilities (like tar), and mostly just handles the composed package archives. So it isn't surprising to me that you see the same behavior with RPM. I think its more likely that there is something strange with your OE/Bitbake environment. If you haven't already, cleaning the recipe workspace (`bitbake -c cleanall grafana`) or clearing then entire build/ directory, would be helpful to identify a polluted sstate situation. >Apparently the packages gets into package correctly, since it seems to work when I install it manually on the target. I wouldn't read too much into that. The `Init Failed` error that you get when you try to start the server daemon manually looks like there is some configuration error with how you're starting it. It seems likely to me that the package's postinst is starting it "correctly", and so the binary proceeds further, where it runs into a segfault. Further, segfaults are tricky in general. Can you try copying the grafana daemon to the system manually and verifying that you can get it running completely? That would help to point blame at the recipe, rather than the daemon itself.
Waiting for more info from rberger before classification.
It turned out that "prelink" is to blame, so you are off the hook ;) Looks like everything is fine with the package manager. ... but ... by default prelink modifies files in certain directories[1]. In this case in a way which makes the binaries crash ;) [1] https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/prelink/prelink/prelink.conf I guess we should move the bug elsewhere.
Ah; well good thing it isn't opkg doing something wacky. I'll go ahead and close this bug. I would guess that you should file against either poky or prelink itself, depending on the details of how the mangling is happening.