Use i386 qemu-user-static package in Dockerfile and update README

[hhromic]

At the moment, Buster images are broken when building with 64-bits Qemu.

As a workaround, we can build the image using Docker with an i386/debian base image that includes 32-bits Qemu binaries. Therefore this PR sets the base image to i386/debian for Docker builds.

Tested built Buster image using build-docker.sh under a 64-bits host in a real Raspberry Pi 3B+ device. In fact, this PR was fully created in the device itself :)

Updated: see comment #307 (comment)

[XECDesign]

As an alternative, maybe installing qemu-user-static:i386 is better, since it resolves the problem outside of docker as well?

[hhromic]

Thanks for the suggestion, is a good idea. I will be testing creating an image with that change instead, i.e. keep the image at 64 bits and install 32-bits qemu, and update the PR accordingly.
I will also update the main README file accordingly for non-Docker users.

[hhromic]

@XECDesign I tested now just using the qemu-user-static:i386 package instead of making the whole container distro run as i386. For this I built a Raspbian Buster Lite image and booted it in real hardware, and the image is working fine with the established test, i.e. using curl to retrieve an HTTPS website, and other regular use. All seems working fine.

Therefore I updated this PR now to keep the container image as a 64-bits Debian Buster and enable the i386 architecture inside to install the 32-bits version of Qemu: qemu-user-static:i386.

I also added a warning in the README with instructions on how to do the same on a regular Debian-based host for non-Docker users. Let me know if are okay or want some more changes.

[FelicianoTech]

For what I think is related, if I try to build a Lite image following the instructions here, it works. If I try to build the full desktop image, I get an error about Java certs as in this issue: #317

[hhromic]

Thanks for the report, I will look into it and check.

[hhromic]

After a long wait I completed a full build of latest Rasbian Buster with current pi-gen using Docker and the qemu-user-static:i386 package:

real    153m55.023s
user    0m1.278s
sys     0m2.023s
copying results from deploy/
total 4.0G
drwxr-xr-x  5 user user 4.0K Aug 22 22:37 .
drwxr-xr-x 13 user user 4.0K Aug 22 22:37 ..
drwxr-xr-x  2 user user 4.0K Aug 22 22:10 2019-08-22-raspbian-buster
drwxr-xr-x  2 user user 4.0K Aug 22 22:37 2019-08-22-raspbian-buster-full
-rw-r--r--  1 user user 273K Aug 22 22:24 2019-08-22-raspbian-buster-full.info
-rw-r--r--  1 user user 175K Aug 22 22:04 2019-08-22-raspbian-buster.info
drwxr-xr-x  2 user user 4.0K Aug 22 21:58 2019-08-22-raspbian-buster-lite
-rw-r--r--  1 user user  57K Aug 22 21:55 2019-08-22-raspbian-buster-lite.info
-rw-r--r--  1 user user  13K Aug 22 22:37 build.log
-rw-r--r--  1 user user 2.5G Aug 22 22:24 image_2019-08-22-raspbian-buster-full.zip
-rw-r--r--  1 user user 408M Aug 22 21:55 image_2019-08-22-raspbian-buster-lite.zip
-rw-r--r--  1 user user 1.1G Aug 22 22:04 image_2019-08-22-raspbian-buster.zip
pigen_work
Done! Your image(s) should be in deploy/

No build errors of any kind found. As @XECDesign suggested, try a clean build from scratch.

[FelicianoTech]

It was a clean build as it was my first time doing it. When I tried to delete the files in the work directory, I got a bunch of errors that don't looks so good. I'm going to reinstall my system, and try this again with a 64-bit Ubuntu in Vagrant/Virtualbox and see how that goes.

I did have success with Debian 10 (x86) in Vagrant/Virtualbox btw.

I'll report back on the different methods I try and what works and what doesn't.

[XECDesign]

Before removing the work directory, be sure to umount any filesystems there. pi-gen doesn't clean up after itself when it fails, so you may have sys and proc mounts there. Deleting those files can result in your system not working properly until reboot.

[FelicianoTech]

Deleting those files can result in your system not working properly until reboot.

That explains what happened then. Perhaps I'll submit a PR to get this added to the readme.

[FelicianoTech]

Here's the results of my limited testing thus far. These are the results on whether or not the three .img images are built successfully or if the build process fails:

Distro	Arch	Platform	qemu Package	Result
Ubuntu 18.04	amd64	real host	qemu-user-static:i386	Failed
Ubuntu 18.04	amd64	real host	qemu-user-static	Failed
Debian 10	amd64	Vagrant VM	qemu-user-static	Worked
Debian 10	i386	Vagrant VM	qemu-user-static (32bit by default)	Worked
Ubuntu 19.04	amd64	Vagrant VM	qemu-user-static:i386	failed
Ubuntu 19.04	amd64	Vagrant VM	qemu-user-static	failed

Note: The Vagrant VMs use Virtualbox as a backend. The images were from the Vagrant bento namespace.

[hhromic]

Closing this PR as it is now more than two years old.
As mentioned recently in the original issue, it seems that the problem lies somewhere else than the qemu package bitness.