[Buildroot] libfakeroot problem - solved

Peter Korsgaard peter at korsgaard.com
Mon May 15 21:39:21 UTC 2017


>>>>> "Steve" == Steve Kenton <skenton at ou.edu> writes:

Hi,

 > OK, I found it. It was leakage from the build host. Testing something
 > for the embedded system I had run getcap to give /bin/tar some
 > capabilities and did not remove them afterwards. Somehow that
 > interacted badly with libfakeroot and the creation of
 > output/images/rootfs.tar at the end of the build. The reason I did not
 > see it on the 32-bit builds is that being intended for recovery and
 > reinstall they used initramfs linked into the kernel for the rootfs
 > instead of the  rootfs.tar file. When the libfakeroot issue
 > manifested, root did not own the root filesystem files in rootfs.tar
 > when it was expanded with "sudo tar xf  rootfs.tar ....." Which
 > resulted in a system which was bootable but would not run properly
 > because of the file ownership/permission problems.

Hmm, we've relatively recent had issues with filesystem capabilities /
acls and fakeroot, but I thought this was fixed (unless you did part of
your build with the old BR version):

https://git.buildroot.net/buildroot/commit/?id=2a222446b4614a38b4042df54b68b69b96939708

 > This was clearly a self inflicted problem, but the fact that tar is
 > not included in the output/host/* tools and thus the build system
 > /bin/tar was used certainly make it "interesting" to find.

Well, it is a bit of chicken and egg issue - Most package sources are
available in tarballs, so we need SOME utilities from the host (like gcc
and make), and we try to only add host packages when really needed
(E.G. uncommon SW or we need special versions, ..).

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list