Daniel Stender

Fixing ppc64el chroots for Sbuild

Currently there are some problems with using ppc64el chroots for Sbuild.
I’ve came across this trying to perform some local test builds for libvigraimpex/1.10.0+git20160120.803d5d4-11.
Actually, ppc64el2 could be emulated with Qemu which makes it possible to easily set up a foreign arch base system chroot for the use with the builder Sbuild.
But at present there are some bugs in some members of the toolchain which is used for that, which need some workaround to get it running.

Base system chroots for Sbuild resp. Schroot3 – the chroot tool which is used by Sbuild – are set up with the tool sbuild-createchroot.
And with that chroot creation tool foreign arch chroots could be easily created by employing qemu-debootstrap4.
This tools wraps around debootstrap5, which is the default bootstrapper of sbuild-createchroot.
qemu-debootstrap conveniently automatically performs a multi-stage operation with debootstrap for setting up any wanted Debian supported foreign arch chroot6:

The log in /tmp/tmp.HP6CzLphi7/debootstrap/debootstrap.log doesn’t recorded anything on this failure7.
This problem has been already reported to the bug tracker8, twice9, and concerns any emulated architectures.
Downgrading helps with this, I’ve got myself 1.0.75 from the Debian snapshot, build and installed it10.

So, that’s fixed!

But currrently there is a another problem in the way for things running smoothly.
There is a problem with Qemu’s ppc64le emulation11 in the foreign chroot, which has been set up by Debootstrap, so that the second stage processing wouldn’t proceed, either:

I’ve reported this problem today12, and very quick got great replies including an explanation where this failure comes from (great support!).
I’m very happy that there’s an easy workaround available in just exporting resp. setting the QEMU_CPU environment variable the right way:

However, isn’t that easy to integrate this fix into the workflow with sbuild-createchroot because to my experience just exporting QEMU_CPU doesn’t work well for the somewhat higher leveled Sbuild tools13.
The best way seems to be to take a root folder which has been created with bare Debootstrap like described above, and to integrate it into the Sbuild/Schroot setup manually.
It takes a little work, but runs cleanly afterwards.

First of all, the root folder which has been created should be copied to the side of the other chroots which are already available for Sbuild in /var/lib/sbuild (being either tarballs or directories, file/folder names doesn’t play a role).
After that, a proper configuration file is needed in /etc/schroot/chroot.d, you can call it unstable-ppc64el-sbuild or whatever:

The “injection” of the needed environment variable QEMU_CPU could be done with a shell script running from the host, like it’s used for employing Ccache in Sbuild chroots.
For that, first it’s needed to make the folder on the host where the script is going to be stored available for the chroot(s).
If you want e.g. /usr/local/bin, you need to add this to /etc/schroot/sbuild/fstab:

To use that script as command prefix for everything running inside the chroot it’s needed to give that also to the configuration in /etc/schroot/chroot.d.
Finally, Overlayfs could be set as union-type for the chroot to boost the performance a bit (the emulator remains being a bootleneck, though):