| Summary: | Not sure if it's opkg version 0.4.5 (libsolv 0.7.19) to blame. | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] opkg | Reporter: | Robert Berger <pokylinux> |
| Component: | opkg | Assignee: | Alex Stewart <alex.stewart> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | Undecided | ||
| Version: | 0.4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Robert Berger
2021-07-05 19:47:07 UTC
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. |