GNU bug report logs - #61986
Installing qemu-binfmt with support for emulating the host architecture breaks everything

Previous Next

To reply to this bug, email your comments to 61986 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J. Sims" <jtsims <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: Installing qemu-binfmt with support for emulating the host
 architecture breaks everything
Date: Sun, 05 Mar 2023 18:33:07 +0000

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

Message #8 received at 61986 <at> debbugs.gnu.org (full text, mbox):

From: Richard Sent <richard <at> freakingpenguin.com>
To: 61986 <at> debbugs.gnu.org
Subject: qemu-binfmt-service-type should protect against adding platforms
 for target system
Date: Thu, 23 May 2024 14:21:06 -0400

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.

[1]: https://lists.gnu.org/archive/html/help-guix/2023-03/msg00121.html
[2]: https://lists.gnu.org/archive/html/help-guix/2024-05/msg00160.html

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.