How to work on a bootloader in the REPL?
Hi Guix, what is the best way to work on a bootloader in the REPL? Say, I make changes to the grub-efi-bootloader and want to test if it is working. I think I know how to do it with guix system on the command line, but I wonder how I would do this in Scheme in the REPL, to have a faster feedback cycle. How would you do it? Thanks, Roman. signature.asc Description: PGP signature
Re: Too many levels of symbolic links
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. signature.asc Description: PGP signature
Re: updating restic: go-build-system trying to resolve host names with nonexistent dnscache at [::1]:53
Am 13.03.23 um 01:26 schrieb Martin Castillo> Now the build fails trying to download dependencies: Ok, naturally, we don't want go to access the internet to get the dependencies. I tried adding (inputs (list go-github-com-minio-sha256-simd)) to the package, but go still tries to get that. Go doesn't care about the symlinked package at src/github.com/minio/sha256-simd. (Someone added that symlinking to go-build-system once, so it may have worked with earlier (<1.18) go versions? https://issues.guix.gnu.org/50493 references https://issues.guix.gnu.org/50227 , which I don't understand, but seems to try to get rid of the symlinking and replace it with something better?) If I run go run build.go manually in the failed dir, the dependencies get downloaded to [...] /pkg/mod/cache/download/google.golang.org/genproto /pkg/mod/cache/download/google.golang.org/grpc /pkg/mod/cache/download/google.golang.org/protobuf /pkg/mod/cache/download/go.opencensus.io /pkg/mod/cache/download/gopkg.in/ /pkg/mod/cloud.google.com /pkg/mod/github.com /pkg/mod/golang.org /pkg/mod/google.golang.org /pkg/mod/go.opencensus.io@v0.24.0 /pkg/mod/gopkg.in etc. and not to /src/github.com/ or such, where inputs get symlinked at. My conclusion: go-build-system needs to be updated to account for the new way go handles dependencies. Is this correct? And is this issue 50227? Martin Looks like go trys using ipv6 for the dns lookup. But /etc/resolv.conf says nameserver 10.0.2.3 I don't have a nameserver running on ::1. And this inside qemu, where I didn't set up anything specifically for ipv6. I have only site and link local ipv6 addresses. Why does go-build-system try to resolve the host names at [::1]:53? Martin Castillo
Re: Too many levels of symbolic links
Roman, Nice. > I still don't know which symlink was causing this issue, though. Don't take unix error messages seriously, they probably weren't intended that way. The #define for the error string you saw is ELOOP, so that should answer your question. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
Re: Too many levels of symbolic links
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. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Newbie: Why executing "guix home reconfigure" requires an Internet connection?
Am Wed, Mar 15, 2023 at 08:38:52AM +0200 schrieb Saku Laesvuori: > If you have not changed the packages referenced in your configuration or > ran `guix pull` after the last `guix home reconfigure`, I'd think it > shouldn't require an internet connection. And then you should be able to add the "--no-substitutes" flag, so that it does not try to connect to the build farms. Andreas
Re: Newbie: Why executing "guix home reconfigure" requires an Internet connection?
On Tue, Mar 14, 2023 at 11:49:41PM -0500, Rodrigo Morales wrote: > Table of Contents > _ > > 1. The context > 2. The questions > > > 1 The context > = > > Currently, the only way I know how to make my laptop connect to the > Internet is via Ethernet, because the Wi-fi card of my laptop requires > nonfree firmware. > > Today, I had to use my laptop without Ethernet (i.e. no connection to > the Internet). While I was using it, I decided to run `guix home > reconfigure' because I thought that in contrast to installing a > package, `guix home reconfigure' seems to only act in local > files. However, it threw an error and it seemed it tried to connect to > the Internet. The following code block shows the error message. While `guix home reconfigure` does create local symlinks, it still has to build the packages it references and building packages requires an internet connection for fetching substitutes or sources. If you have not changed the packages referenced in your configuration or ran `guix pull` after the last `guix home reconfigure`, I'd think it shouldn't require an internet connection. signature.asc Description: PGP signature
