6

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 <[email protected]>
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?

Improve this question

4 Answers 4

Reset to default
7
+50

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

Improve this answer
0
5

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.

Improve this answer
3
  • 1
    Thank you for the reply. I'm doing this on an older version of Mint, so I would assume the steps are the same as for your Debian example. I will try and give feedback.
    – AdminBee
    Jul 8, 2020 at 8:46
  • 1
    @AdminBee Be sure to check for other i386 packages you may need (qemu?) which may not be installed automatically. It could also help if you remove the amd64 version of QEMU altogether while trying to run the 32-bit one, if you're not sure which one you end up running. Good luck.
    – Dmitry Grigoryev
    Jul 8, 2020 at 9:31
  • 1
    Thank you again for taking the time to answer. Ultimately, replacing (=deinstalling and reinstalling) the 64-bit version of qemu-user-static (as well as binfmt-support, although it was only a recommended dependency) by their i386 counterparts didn't help to solve the problem in my case. I had to resort to creating a virtual machine with 32-bit Ubuntu 16.04. Since tha approach of using a 32-bit OS was proposed by @myka first, I would consider it appropriate the chose that answer for the bounty, although your answer provided valuable insight into the situation.
    – AdminBee
    Jul 13, 2020 at 7:59
1

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.

Improve this answer
0

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.

Improve this answer
2
  • 1
    Thank you for the reply. I didn't clearly mention it in my post, but I had already tried uninstalling and reinstalling the libgdk-pixbuf2; unfortunately apt insists that uninstalling would lead to an unresolvable dependency conflict and wouldn't perform the operation (even with the -f flag). Attempding to upgrade didn't help either as it is already the latest version. Also, in the setting I intend to use the Pi-Gen mechanism, it is not feasible to perform "manual afterwork", so I am looking for a solution that prevents this from happening in the first place.
    – AdminBee
    Jul 6, 2020 at 13:57
  • 2
    The take-no-prisoners version of purge is apt-get purge $(apt-cache depends libgdk-pixbuf-2.0-0 | awk '{ print $2 }' | tr '\n' ' '). Not that I recommed purging half of your system, but there's always a way to force apt to do what you want.
    – Dmitry Grigoryev
    Jul 9, 2020 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.