Ubuntu

Ubuntu Dektop goes armhf after install qemu-user

Asked by Marcos Fabio Jardini

I've reached a weird bug and I admit I'm lost how to collect reports for this.

My system is default installation of Ubuntu 20.04, with latest updates. Have VSCode, GCC, Docker and many other tools installed for building applications for embedded.

As of recently I'm trying the tutorial in https://www.boulderes.com/resource-library/building-raspberry-pi-disk-images-with-docker-a-case-study-in-software-automation

So I've installed qemu-user-static and, make the docker image with raspbian and worked with it all day.

Next day, after turn system on, and put my credentials, the screen flash and goes back to (graphic) login. After some time I switched to a terminal (CTRL-ALT-F2) and any command throw an error asking for ld-linux-armhf.so.3

Rebooting into Recovery mode and dropping to the console, all back to normal.

I'm clueless. Can somehow Gnome/Snap bringing up the system do ARM because of qemu-user?

The damage was done, even after uninstall qemu-user the system keep the architecture changed and the error now is incompatible binary.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Marcos Fabio Jardini
Solved:
Last query:
Last reply:
Revision history for this message
Manfred Hampl (m-hampl) said : 		#1

Very strange.

Can you please provide the full output of a failing command
What is the output (in a virtual terminal) of

ls
echo $PATH

Revision history for this message
Marcos Fabio Jardini (mfjardini) said : 		#2

For reference, this is the output from Recovery Mode:
$echo $PATH
>/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
 $ uname -a
> Linux XPS-8500 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 $ldd --version
> ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31

This is the output of term2 (Ctrl-Alt-F2 @login screen) with qemu-user-static installed:
$ ls
> /lib/ld-linux-armhf.so.3: No such file or directory
 $echo $PATH
>/home/developer/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
 $uname -a
> /lib/ld-linux-armhf.so.3: No such file or directory
 $ldd --version
> ldd (Debian GLIBC 2.31-13+rpt2+rpi1) 2.31

This is the output of term2 (Ctrl-Alt-F2 @login screen) without qemu-user-static:
$ ls
> -bash: /home/developer/bin/ls: cannot execute binary file: Exec format error
 $echo $PATH
>/home/developer/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
 $uname -a
> -bash: /home/developer/bin/uname: cannot execute binary file: Exec format error
 $ldd --version
> ldd (Debian GLIBC 2.31-13+rpt2+rpi1) 2.31

Looking at it, the Docker build, while processing the Dockerfile, leaked the raspbian rootfs tarball into the user USER HOME and because of the PATH the USER HOME bin takes precedence and causing the mess.

It was possible to clean the mess done by Docker build trough the recovery console.

Thank you Manfred!