Good to know about that unspoken rule. :) Should we do something about that? I thought about adding a note to the manual. Or even not allowing the user to re-configure in such a case? WDYT? Efraim Flashner writes: > [[PGP Signed Part:Undecided]] > On Tue, Mar 14, 2023 at 08:16:52PM +0100, Roman Scherer wrote: >> >> Felix, I'm back on track! I found what triggered this horrible problem :) >> >> At some point I added the qemu-binfmt-service-type to my system. I >> copied a snipped from the manual and finally "adjusted" it to this: >> >> ``` >> (define %qemu-service >> (service qemu-binfmt-service-type >> (qemu-binfmt-configuration >> (platforms (lookup-qemu-platforms "aarch64" "x86_64"))))) >> ``` >> >> I don't know much about quem and I thought, well let's choose the >> "aarch64" and "x86_64" qemu platforms on which I run Guix, and maybe >> re-use this service on multiple machines. >> >> My Guix system runs on the aarch64 architecture. It turns out that >> having "aarch64" in lookup-qemu-platforms causes the "Too many levels of >> symbolic links" error. As soon as I remove it, everything is good again. >> >> Now, maybe it does not even makes sense to add "aarch64" to that list, >> but I think it should not fail that catastrophical. I still don't know >> which symlink was causing this issue, though. >> >> That's where I am. Just happy that I survived my first serious Guix >> crash. :) >> >> Thanks for your help so far, >> >> Roman > > I'm surprised that it worked for you. One of the unspoken rules of qemu > binfmt emulation is you don't emulate your own hardware. I'm also > surprised because in the past I tried to enable binfmt emulation on my > pinebook pro and the qemu-binfmt-service-type was the difference between > booting and not booting.