OS image made using Pi-Gen lacks JPEG support in GTK

Question

I recently started using Pi-Gen to generate customized prebuilt Raspberry OS images for use with a RaspberryPI 4. I use the build-docker.sh script on a Linux Mint VM.

However, in a test run with minimal changes (the config file only sets the IMG_NAME variable), which should have created a "vanilla" image almost identical to the official one available for download from raspberrypi.org, I ended up with a desktop where no pictures were displayed (i.e. the background is grey, and all taskbar icons are replaced by the "broken document" symbol).

The files themselves (JPEG images, e.g. in /usr/share/rpd-wallpaper/) are present, but when I try to open one with gpicview I get an error message stating

Couldn't recognize the image file format for file "/usr/share/rpd-wallpaper/temple.jpg"

although displaying the file in the web-browser works fine

I do not have that problem when using the OS image downloaded from the official location instead.

Some googling showed that this happened even with the official image some time ago, and that the libgdk-pixbuf2, specifically the JPEG support, may be the problem.

But in my case the libgdk-pixbuf2 is already the latest version (so reinstalling, as suggested in one post, wouldn't help), and actually the very same as present on the official OS image:

• $ apt-cache show libgdk-pixbuf2.0-0 gives the same output on both images:

  Package: libgdk-pixbuf2.0-0
  Source: gdk-pixbuf
  Version: 2.38.1+dfsg-1
  Architecture: armhf
  Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
  Installed-Size: 471
  Depends: libc6 (>= 2.11), libglib2.0-0 (>= 2.48.0), libjpeg62-turbo (>= 1.3.1), libpng16-16 (>= 1.6.2-1), libtiff5 (>= 4.0.3), libx11-6, shared-mime-info, libgdk-pixbuf2.0-common (= 2.38.1+dfsg-1)
  Recommends: libgdk-pixbuf2.0-bin
  Multi-Arch: same
  

• $ apt-cache policy libgdk-pixbuf2 shows that the installation status is the same on both images.

Note that an attempt to manually uninstall and reinstall the libgdk-pixbuf2.0-0 failed with apt stating

# apt-get -f purge libgdk-pixbuf2.0-0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 konqueror : Depends: dolphin but it is not going to be installed
 libkf5baloowidgets-bin : Depends: libkf5baloowidgets5 (>= 15.08.0) but it is not going to be installed
 libkf5khtml5 : Depends: phonon4qt5 but it is not going to be installed
 libkf5notifications5 : Depends: phonon4qt5 but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

(and unfortunately, having to perform "manual after-work" would conflict with the reasons for using Pi-Gen in the first place).

So, does anyone know why the Pi-Gen might end up with a setting where GDK (apparently) lacks JPEG support, and what to do about it?

Answer 1

A desktop devoid of all images and icons sounds very much like a known issue with running on 64-bit hosts. qemu needs to be 32-bits for correct emulation and a proper build.

The fixes that worked for me is to run pi-gen directly on the Raspberry Pi 4 (it's a bit slow) or on Ubuntu 16.04 which is 32-bit.

Here is more info: https://github.com/RPi-Distro/pi-gen/tree/master#64-bit-systems

And a good discussion on potential workarounds: https://github.com/RPi-Distro/pi-gen/issues/271

Answer 2

To give more insight into the issue, it appears to be a bug in 64-bit qemu emulating a 32-bit machine, which won't use the host's 32-bit libraries in a readdir() call, so the host kernel feed it with 64-bit offsets, which qemu passes to the emulated 32-bit system, which then reports an overflow. This leads to random missing files in the build.

One workaround is to make sure the qemu itself is 32-bit, which is indeed the case on a 32-bit host (the Pi itself, or an x86 computer). It should also be possible to install a 32-bit qemu on a 64-bit host using multilib, but the details will of course depend on the host OS. On my Debian laptop I could simply do something like

dpkg --add-architecture i386
apt install qemu-user-static:i386

You'll have to find out what it takes on your OS to get a 32-bit package installed. AFAIK some OS (such as latest Ubuntu) already dropped support for x86, so it may not be possible on those OS. Debian buster seems to still provide x86 packages.

Answer 3

In the end, I took the following steps to solve the problem, based on the answers by myka and Dmitry Grigoryev:

1. Set up a virtual machine with the 32-bit desktop version of Ubuntu 16.04 (which at the time of writing is one of two OS versions the Pi-Gen maintainers declare as supporting the Pi-Gen).
2. Install the docker.io package in addition to the dependencies necessary for the Pi-Gen itself, and perform the docker-based build using the build-docker.sh-script.

This resulted in a "correct" SD-card image.

Answer 4

Try doing a sudo apt purge libgdk-pixbuf-2.0-0, rebooting, and then sudo apt install libgdk-pixbuf-2.0-0. This will wipe some (most) of the package configuration, and might fix the problem.