Installing qemu-binfmt with support for emulating the host architecture breaks everything

  • Open
  • quality assurance status badge
Details
2 participants
  • J. Sims
  • Richard Sent
Owner
unassigned
Submitted by
J. Sims
Severity
normal
J
J
J. Sims wrote on 5 Mar 2023 19:33
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
fibQOMbqS2rsKtGIPO_6wzE48Nlx5gGEuTMGTPsuQPYzbu9rRPyrMVClxXSXxMdTjg3bxHXLYL3lZuxiul81cO86koC9fs1Z4mlbVk56_AU=@protonmail.com
Hey y'all,

I recently setup virtualization on my Guix machine (both libvirt and qemu, for different purposes). While configuring libvirt (via virt-manager), I got a bit confused about how to make things work and also installed qemu-binfmt for x86_64, the host architecture. Upon my next reboot, however, I reached a fully-booted TTY and was unable to do anything else. GDM was not launching, and if I attempted to login to the TTY itself, I was greeted by an error message like the following:

"cannot execute /gnu/store/path-to-something/bin/thing: Too many layers of symlinks"

After some misadventures, I have finally narrowed down that the cause of this issue was having x86_64 in the list of qemu-binfmt-configuration platforms while running on x86_64. I assume that including the host architecture in the list of platforms for qemu-binfmt will do this regardless of architecture, but cannot currently test this.

Here's what I believe to be a minimum reproducible example for x86_64:

```
(operating-system
...
(services (cons*
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "x86_64"))))
...)
...)
```

Good luck,
Juli
R
R
Richard Sent wrote on 23 May 20:21 +0200
qemu-binfmt-service-type should protect against adding platforms for target system
(address . 61986@debbugs.gnu.org)
87ttiov17x.fsf@freakingpenguin.com
Hi Guix!

I can confirm that this issue is still around and still causing
headaches! ;)

It's definitely a problem on the aarch64 architecture. It's probably
safe to say it's a problem on every platform.

Given how cryptic this error is and how easily it can sneak up in more
complicated system configurations ([1] and [2]), we should capture this
mistake sometime during the build process. Even if putting the target
system as a QEMU emulation platform doesn't make sense, a broken system
with no helpful diagnostics isn't a proportional consequence.


--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 61986@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 61986
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch