Re: Mysteries of channel configuration during system reconfigure
Julien Lepiller writes: > guix system describe lists channels used to build your system, but > they can be different from the ones currently known to guix. That seems consistent with what I have observed. > Does your /etc/channels.scm list the extra channels? At this point it does not. I "restored" a backup from my old computer into my home directory. Now I have several more channels than I had configured in generation one. Unfortunately, now my shepherd is broken just like on my old computer. I wish I understood how to experiment with e.g. virtual machines to better understand this process. However, there seems to be quite a large knowledge barrier. I also don't feel comfortable with my current capabilities exploring the Guix codebase to see what the relevant procedures are. There is a lot to learn! > "guix describe" will be more accurate about what channels your current > guix knows about. It's not clear to me what "your current guix" even is in my case. Does the latest pull define the current guix? On my old computer guix system describe shows a slightly older revision of Guix channels than guix describe. Meanwhile, the root user's guix describe shows just the one Guix channel with yet another commit. As a naive user, I'm understandably more scared that my computer will fail to boot if I upgrade, so I tend to run guix system reconfigure less frequently than guix pull. > If you type "type guix" and "which guix", they should agree it's > ~/.config/guix/current/bin/guix, not something else like > ~/.guix-profile or ~/.guix-home or even /run/current-system I had never heard of the type command! I noticed type and which give different results for "type cd" and "which cd". I also noticed that which --all guix shows two lines: the latter being /run/current-system. I have to admit I'm not still sure what general insight I should be gleaning from your statement, however it sounds like it is pretty neat. > If you reconfigure as the root user, you should pull as the root > user. If you use sudo, which is recommended, make sure that the above > works properly with sudo too. I'm curious to learn more about your rationale for this statement as I was successful at building a second generation only once I used the "sudo" path with my non-root user. Thanks for your help!
Re: Too many levels of symbolic links
Hi Roman, On Fri, Mar 10, 2023 at 7:32 AM Roman Scherer wrote: > > Right now I rolled back to generation 53, which is still > working. Great! > Is it correct to look for the problematic files in the directory to > which system-54-link links to? Yes, probably. Unfortunately, profiles are large bundles of symbolic links, so finding the offending cycle may not be easy. > Generation 54 is the broken one, which does boot up, but > logging in fails with the too many levels of symbolic link issue. Since the issue occurs at login, there may also be a bad interaction with your user profile. What if you log in as another user? > I run the problematic commands from that directory and they seem to run > from the non-broken system My prime list of suspects include something like a system-wide Bash profile (or whichever shell you use). > I'm thinking of re-installing my system completely. Please don't do that. It is not necessary. Instead, you can delete generation 54 and try again. Make sure to 'guix pull' before reconfiguring again. > Do I have any other option, even an unsupported one? Please post the config.scm for your generation 53, plus a diff to generation 54. You find copies via 'guix system describe'. It may also be helpful to attach your home.scm, if you use Guix Home. Together with the changes in Guix since the commit on which generation 53 is based, we will find the issue. The process is more or less deterministic. Please keep up hope. All needed software is already installed. Guix has extraordinary ways to recover—even though they can be hard to figure out. Kind regards Felix
Re: Too many levels of symbolic links
Hi Tobias and Felix, the posix file was actually pointing to the correct parent directory (my bad) and as Felix mentioned probably not the root of my issue. The `guix gc --verify=contents,repair` unfortunatly did not help either. I looked a bit around and found this in /var/guix/profiles drwxr-xr-x 4 root root 4096 Jan 21 16:28 per-user/ lrwxrwxrwx 1 root root 14 Mar 8 16:20 system -> system-53-link lrwxrwxrwx 1 root root 50 Feb 12 14:58 system-49-link -> /gnu/store/r048wnvv5wb792d0h29147j4q2m874d0-system lrwxrwxrwx 1 root root 50 Mar 8 15:17 system-50-link -> /gnu/store/99kgb2jh7jdjcvqac81dj0gd2nkhanmw-system lrwxrwxrwx 1 root root 50 Feb 20 12:30 system-51-link -> /gnu/store/cwk04xkh3zf7vb5bg3cpjr8jyviv5b2f-system lrwxrwxrwx 1 root root 50 Feb 25 14:16 system-52-link -> /gnu/store/aqxlpw468wvnardbb8dmyxj1qghv68ah-system lrwxrwxrwx 1 root root 50 Mar 3 16:33 system-53-link -> /gnu/store/1xdmrafzscrpi34rynag71my6nw3w8w2-system lrwxrwxrwx 1 root root 50 Mar 8 15:53 system-54-link -> /gnu/store/cjdabnlk74irjh3xwqh9d31kza3c78a0-system Right now I rolled back to generation 53, which is still working. Generation 54 is the broken one, which does boot up, but logging in fails with the too many levels of symbolic link issue. Is it correct to look for the problematic files in the directory to which system-54-link links to? I run the problematic commands from that directory and they seem to run from the non-broken system I'm thinking of re-installing my system completely. Do I have any other option, even an unsupported one? Thanks again for your help, Roman. Tobias Geerinckx-Rice writes: > [[PGP Signed Part:Undecided]] > Hi Roman, > > Roman Scherer 写道： >> >> /gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo/posix >> >> links to itself. > > FYI, it should link to its parent: > > /gnu/store/097dmm40lhcf777acqh5i660j4i09k85-tzdata-2022a/share/zoneinfo > > (So, yes, you could …/posix/posix/posix/posix/… all night long.) > >> Since I read I should not mess with the store, any >> ideas how to get rid of that file system loop in a safe way? > > You could try > > # guix gc --verify=contents,repair > > and Guix should detect the mismatch and refresh tzdata from a > substitute server. > > The unsupported alternative would be to bind-mount /gnu/store > somewhere and manually relink the file. > >> I already tried re-installing it, but that had no effect. > > It wouldn't. > > Kind regards, > > T G-R > > [[End of PGP Signed Part]] signature.asc Description: PGP signature
Re: Mysteries of channel configuration during system reconfigure
guix system describe lists channels used to build your system, but they can be different from the ones currently known to guix. Does your /etc/channels.scm list the extra channels? "guix describe" will be more accurate about what channels your current guix knows about. If you type "type guix" and "which guix", they should agree it's ~/.config/guix/current/bin/guix, not something else like ~/.guix-profile or ~/.guix-home or even /run/current-system If you reconfigure as the root user, you should pull as the root user. If you use sudo, which is recommended, make sure that the above works properly with sudo too. Le 9 mars 2023 03:50:29 GMT+01:00, Kyle Andrews a écrit : > >Dear Guix, > >I am trying (and failing) to setup a new computer with Guix. I managed >to get through the installation process with a configuration that boots >into GNOME. However, the keyboard is messed up (I made a typo) and I >don't yet have the desktop environment up and running I actually feel >productive using. GNOME places too many extraneous demands on my >attention. There is a lot going on and I find all the beeping >unsettling. So I am typing this email on my old computer with Guix. > >One of the selling points in Guix marketing for me is that the system >configuration should be self contained within /etc/config.scm and >channels.scm. However, this appears to not be the case. There seems a >third element hidden away which prevents me from running: > >``` >guix system reconfigure /etc/config.scm >``` > >This command errors out: > >``` >failed to load '/etc/config.scm' >... >no code for module ... >``` > >At the moment since I am still very early in setting up my new computer, >I have to type everything so I'm not going to go into more detail than >that. Suffice to say it doesn't see the modules I need from the extra >channel. It did see them during the installation otherwise my computer >would be in a far less usable state than it is. > >When I run the following command: > >``` >guix system describe >``` > >The addition channel gets listed. How can it be listed yet be unknown to >the `guix system reconfigure` command? > >During the installation of my new computer I used guix pull -C >/etc/channels.scm. I was struggling with the official documentation, so >this was kind of an improvisation. Could doing this nonstandard action >have lead to this nonstandard state? Can it be fixed? > >I tried running the commands with the root user and with prefixing >sudo. Neither variat produces the desired result: a new configuration >with the correct keymap and my next steps towards setting up my desktop >environment. > >Thanks in advance for your help! > >Cheers, >Kyle >
Re: bad use of syntactic keyword
You have an extra closing parenthesis at the end of this line:
(extra-options (list "--gc-keep-derivations=yes" "--gc-keep-outputs=yes")
Remove one and adjust next lines if needed :)
Le 9 mars 2023 17:49:43 GMT+01:00, Gottfried a écrit :
>Hi,
>
>after adding: "service redshift" to my config.scm
>
>running
>
>sudo guix system configure /etc/config.scm
>
>it says:
>
>guix system: Fehler: _: bad use of '_' syntactic keyword
>
>german Fehler = mistake
>
>I don’t know where is my mistake.
>
>here my config.scm:
>
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-package-modules cups scanner)
>(use-service-modules cups desktop networking ssh xorg virtualization)
>
>(operating-system
> (locale "de_DE.utf8")
> (timezone "Europe/Berlin")
> (keyboard-layout (keyboard-layout "de"))
> (host-name "Tuxedo")
> (users (cons* (user-account
> (name "gfp")
> (comment "Gfp")
> (group "users")
> (home-directory "/home/gfp")
> (supplementary-groups
>'("wheel" "netdev" "audio" "video" "libvirt")))
>%base-user-accounts))
> (packages
>(append
> (list (specification->package "nss-certs"))
> %base-packages))
> (services
>(append
> (list (service mate-desktop-service-type)
>(service enlightenment-desktop-service-type)
> (service cups-service-type
> (cups-configuration
> (web-interface? #t)
> (extensions (list cups-filters
> hplip
> (service openssh-service-type)
>(service tor-service-type)
>(set-xorg-configuration
> (xorg-configuration
> (keyboard-layout keyboard-layout)))
>(service libvirt-service-type
> (libvirt-configuration
> (unix-sock-group "libvirt")
> (tls-port "16555")))
>(service virtlog-service-type
> (virtlog-configuration
> (max-clients 1000)))
>(service home-redshift-service-type
> (home-redshift-configuration
> (location-provider 'manual)
> (latitude 52.5);northern hemisphere
> (longitude 13.5))) ;Berlin
>(modify-services %desktop-services
> (guix-service-type
> config => (guix-configuration
> (inherit config)
> (extra-options (list "--gc-keep-derivations=yes"
> "--gc-keep-outputs=yes")
> (sane-service-type _ => sane-backends
>
> (bootloader
>(bootloader-configuration
> (bootloader grub-efi-bootloader)
> (targets (list "/boot/efi"))
> (keyboard-layout keyboard-layout)))
> (swap-devices
> (list (swap-space
> (target (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")
> (file-systems
>(cons* (file-system
> (mount-point "/boot/efi")
> (device (uuid "BB77-FE3B" 'fat32))
> (type "vfat"))
> (file-system
> (mount-point "/")
> (device
> (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
> 'ext4))
> (type "ext4"))
> %base-file-systems))
> (initrd-modules (cons "virtio_scsi"; Needed to find the disk
>%base-initrd-modules)))
>
>
>Thanks for help
>
>Kind regards
>
>Gottfried
>
