On 18.05.2026 12:25, Niels Möller wrote:
...
Next, I wanted qemu-user. Just running apt-get install qemu-user also
installs the recommended qemu-user-binfmt package. Since I didn't want
to get the binfmt magic, I instead ran apt-get install qemu-user
qemu-user-binfmt- (note trailing -). Then apt-get decided to install
the additional package qemu-user-binfmt:s390x, and I accepted that
and pressed ENTER without realizing the bad consequences.
Here's the most interesting part. Why apt (?) insisted on installing
qemu-user-binfmt? I don't think apt will do that just due to Recommends.
Is there maybe something else which *depends* on qemu-user-binfmt?
Do you have old qemu-user-static package installed?
* What was the outcome of this action?
I could no longer execute *any* native (x86_64) binaries, no ls, no
Yes, that'd definitely do that, because qemu-binfmt:s390x installed
binfmt for x86_64 too, which, obviously, broke your native system.
qemu-user-binfmt:foreign package needs to "conflict" with native
architecture. I dunno how to express this in dpkg/apt terms, especially
having in mind vague definition of "native" (which is the architecture
of dpkg binary, which might actually be foreign on the CPU!), and all
the multi-arch fun which you observe here.
dpkg, no apt-get... Everything failed, and as far as I understand this
broken state, my shell got a ENOEXEC error from the exec syscall. My
computer was closed to bricked. (Luckily, I still had an open root
bash shell, and I could use the *builtin* printf command like printf
"" > /usr/lib/binfmt.d/qemu-x86_64.conf, reboot using the power
button, and get back to a working state where I could run apt-get
remove qemu-user-binfmt:s390x).
Yes that'd be a recovery process. You did well here!
/mjt
