Use tmpfs in order to build arm/v7 and linux/386 images again

[JonasAlfredsson]

The details of the problem is discussed in more detail in issue #30, but to summarize we fail to build the pip package "cryptography" for the arm/v7 and linux/386 images. The error is somewhere in a low level library that fails when it tries to read from the filesystem when running inside a 32-bit environment that is emulated by QEMU running on a 64-bit host.

This is discussed further in the following threads:

• Value too large for defined data type docker/buildx#395
• Value too large for defined data type when cargo build on armv7 with qemu rust-lang/cargo#8719
• https://gitlab.com/qemu-project/qemu/-/issues/263

The previous workaround no longer works, since there is some package which now requests a newer version of the "cryptography" package, so we need to find a different solution.

What people seems to have done, in order to combat this issue, is to use a tmpfs in cargo's build folder (~/.cargo), but the solution in which a tmpfs is only applied to this folder requires Buildx which would then make life more difficult for users which just want to build the image using normal Docker.

I therefore researched this a bit more and saw that it is possible to create a tmpfs on the entire /var/lib/docker folder, in order to make everything build on such a filesystem instead of only rust/cargo. So with this knowledge I created a GitHub Action that configures the runner in the correct way for this trick to work.

The first test run was made here, and it was a success. I needed some tuning of the timeouts, but other than that it appears to be working really well!

[JonasAlfredsson]

After building the images i included a df -h printout, and it looks like this for the Debian and Alpine builds:

Debian

 Filesystem      Size  Used Avail Use% Mounted on
tmpfs           4.0G  1.9G  2.2G  47% /var/lib/docker
overlay         4.0G  1.9G  2.2G  47% /var/lib/docker/overlay2/7b36675853fbad6949dbfc1b458024102528d22c00d77e57186d636dabb55697/merged

Alpine

 Filesystem      Size  Used Avail Use% Mounted on
tmpfs           4.0G  1.2G  2.9G  28% /var/lib/docker
overlay         4.0G  1.2G  2.9G  28% /var/lib/docker/overlay2/05871bb04a4be62acbcd50da4dc6502509be4ca5875a1f432853f6f8c27d2a4d/merged

So I suppose it is about 2G for Debian and 1.3G for Alpine, however, if I lower the size of the tmpfs volume below 4G I ran into some "no space left on device" errors, so I guess more is needed during the unpacking and building phase.

[JonasAlfredsson]

It looks like both the Debian and Alpine builds take around 60 minutes to complete (it is the arm/v7 arch that takes this long), so I have set timeouts of 100 minutes on both of them. If it takes longer than that we can be quite confident in that something is stuck and will probably need a restart.