- sstate causing stripped kernel vs symbols mismatch
Re: sstate causing stripped kernel vs symbols mismatch
toggle quoted messageShow quoted text
The kernel doesn’t have reproducible builds by default because of a handful of variables (including timestamps). If you rebuild, you get a different binary every time.
Those can be changed and overridden so that you get consistent binary output (see here:
https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html) but that hasn’t been done on the linux-yocto recipe yet.
I assume that it’s planned because there are efforts going in to making things 100% reproducible for poky, but I don’t know what the status of everything is (although I know that the kernel at least isn’t reproducible as of 22.0.2)
Since this can theoretically happen to any package that doesn’t have a reproducible build process, it seemed worth asking the question globally too.
On Behalf Of
Tuesday, April 7, 2020 12:11 PM
McKay, Sean <sean.mckay@...>
Re: [yocto] sstate causing stripped kernel vs symbols mismatch
If you’re interested, this is quite easy to reproduce – these are my repro steps
Check out a clean copy of zeus (22.0.2)
Add kernel-image to core-image-minimal in whatever fashion you choose (I just dumped it in the RDEPENDS for packagegroup-core-boot for testing)
bitbake -c clean core-image-minimal linux-yocto (or just wipe your whole build dir, since everything should come from sstate now)
Delete the sstate object(s) for linux-yocto’s deploy task.
Compare the BuildID hashes for the kernel in the two locations using file (you’ll need to use the kernel’s extract-vmlinux script to get it out of the bzImage)
./tmp/work-shared/qemux86-64/kernel-source/scripts/extract-vmlinux tmp/deploy/images/qemux86-64/bzImage > vmlinux-deploy && file vmlinux-deploy
The kernel is still re-built from the same source, so why is this causing issues?
Join firstname.lastname@example.org to automatically receive all group messages.