all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#61986: Installing qemu-binfmt with support for emulating the host architecture breaks everything
@ 2023-03-05 18:33 J. Sims via Bug reports for GNU Guix
  2024-05-23 18:21 ` bug#61986: qemu-binfmt-service-type should protect against adding platforms for target system Richard Sent
  0 siblings, 1 reply; 2+ messages in thread
From: J. Sims via Bug reports for GNU Guix @ 2023-03-05 18:33 UTC (permalink / raw)
  To: 61986

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#61986: qemu-binfmt-service-type should protect against adding platforms for target system
  2023-03-05 18:33 bug#61986: Installing qemu-binfmt with support for emulating the host architecture breaks everything J. Sims via Bug reports for GNU Guix
@ 2024-05-23 18:21 ` Richard Sent
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Sent @ 2024-05-23 18:21 UTC (permalink / raw)
  To: 61986

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.




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-05-23 18:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-05 18:33 bug#61986: Installing qemu-binfmt with support for emulating the host architecture breaks everything J. Sims via Bug reports for GNU Guix
2024-05-23 18:21 ` bug#61986: qemu-binfmt-service-type should protect against adding platforms for target system Richard Sent

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.