Mysteries of channel configuration during system reconfigure

Mysteries of channel configuration during system reconfigure

[Kyle Andrews]

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: Mysteries of channel configuration during system reconfigure

[Julien Lepiller]

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 <kyle@posteo.net> 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: Mysteries of channel configuration during system reconfigure

[Luis Felipe]

[-- Attachment #1.1: Type: text/plain, Size: 781 bytes --]

Hi Kyle,


On Thursday, March 9th, 2023 at 02:50, Kyle Andrews <kyle@posteo.net> wrote:

> [...]
> 

> 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 should be:

sudo guix system reconfigure /etc/config.scm

Also, the manual recommends the following:

"Note: It is highly recommended to run guix pull once before you run guix system reconfigure for the first time (see Invoking guix pull). Failing to do that you would see an older version of Guix once reconfigure has completed."

[-- Attachment #1.2: publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc --]
[-- Type: application/pgp-keys, Size: 1722 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Re: Mysteries of channel configuration during system reconfigure

[SeerLite]

Hi!

On 2023-03-09 03:50, Kyle Andrews wrote:
> 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.

`sudo guix system reconfigure` and any `guix package` command will (by 
default) use the generation shown in `guix describe`. On first boot, 
this generation _will_ be different from the one you had in the live 
system. This is because the generation is saved at 
~/.config/guix/current on every `guix pull` and that file will be gone 
together with the live system.

You have two options:

1. Get the channels you want correctly set up in 
~/.config/guix/channels.scm and run `guix pull` with your user in the 
running system. IIRC this takes a while because it'll download the whole 
Guix checkout again (the one used to install would have disappeared 
along with the rest of the live system).
2. Run guix pull -C /run/current-system/channels.scm. This will pull the 
exact generation used to build the system. This will also take time.

After either of these you should be able to `sudo guix system 
reconfigure ...` and get your system running as the channels will be 
available again to every guix subcommand.

Note that you could also copy /run/current-system/channels.scm to 
~/.config/guix/channels.scm but you have to be careful remove the commit 
lines, otherwise all your `guix pull`s will pull the exact same commits 
and you'll stay on an outdated system.

Maybe it could be clarified in the manual that another `guix pull` is 
needed after the first boot. Or maybe the installation could be 
optimized so that the checkout is copied from the live system to the 
installed system.

> 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?

Because it was indeed the channel and commit the system was built from. 
It has nothing to do with your "current powers". That all depends on 
what generation of Guix you're using AKA what comes up in `guix 
describe`

I hope my explanation was helpful!

SeerLite

Re: Mysteries of channel configuration during system reconfigure

[Luis Felipe]

[-- Attachment #1.1: Type: text/plain, Size: 1012 bytes --]

On Thursday, March 9th, 2023 at 15:12, Luis Felipe <luis.felipe.la@protonmail.com> wrote:

> Hi Kyle,
> 

> 

> On Thursday, March 9th, 2023 at 02:50, Kyle Andrews kyle@posteo.net wrote:
> 

> > [...]
> 

> > 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 should be:
> 

> sudo guix system reconfigure /etc/config.scm
> 

> Also, the manual recommends the following:
> 

> "Note: It is highly recommended to run guix pull once before you run guix system reconfigure for the first time (see Invoking guix pull). Failing to do that you would see an older version of Guix once reconfigure has completed."

Oops! Sorry I rushed to respond without reading the last part of your message :)

[-- Attachment #1.2: publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc --]
[-- Type: application/pgp-keys, Size: 1722 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Re: Mysteries of channel configuration during system reconfigure

[Kyle Andrews]

SeerLite <seerlite@disroot.org> writes:

> `sudo guix system reconfigure` and any `guix package` command will (by
> default) use the generation shown in `guix describe`. On first boot,
> this generation _will_ be different from the one you had in the live
> system. This is because the generation is saved at
> ~/.config/guix/current on every `guix pull` and that file will be gone
> together with the live system.

That behavior doesn't make sense to me, but I have accepted it for
now. As I tried to explain in my question, I *had* performed a guix pull
-C ... before attempting to reconfigure the system. However, I think I
only tried to do that from the /root user.

Since then I have tried to pull from the sudo. This did in fact allow
`guix system reconfigure` to run.

> You have two options:
>
> 1. Get the channels you want correctly set up in
> ~/.config/guix/channels.scm and run `guix pull` with your user in the
> running system. IIRC this takes a while because it'll download the
> whole Guix checkout again (the one used to install would have
> disappeared along with the rest of the live system).
> 2. Run guix pull -C /run/current-system/channels.scm. This will pull
> the exact generation used to build the system. This will also take
> time.

This /run/current-system folder is interesting. When I searched the Info
pages I saw also that it is related to files stored under
/var/guix. Unfortunately, I was not able to glean the overarching
rationale for these directories.

> Note that you could also copy /run/current-system/channels.scm to
> ~/.config/guix/channels.scm but you have to be careful remove the
> commit lines, otherwise all your `guix pull`s will pull the exact same
> commits and you'll stay on an outdated system.

I appreciate this tip.

> Maybe it could be clarified in the manual that another `guix pull` is
> needed after the first boot. Or maybe the installation could be
> optimized so that the checkout is copied from the live system to the
> installed system.

I think it needs to be clarified that this process has to be done from a
*normal* user account in the *wheel* group. It seems the root user
cannot perform this step.

>> 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?
>
> Because it was indeed the channel and commit the system was built
> from. It has nothing to do with your "current powers". That all
> depends on what generation of Guix you're using AKA what comes up in
> `guix describe`

This unnecessary tie in between the system state and a particular user's
software profile was really tripping me up.

> I hope my explanation was helpful!

Thanks!

Re: Mysteries of channel configuration during system reconfigure

[Kyle Andrews]

Julien Lepiller <julien@lepiller.eu> 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: Mysteries of channel configuration during system reconfigure

[Julien Lepiller]

Le 11 mars 2023 01:16:21 GMT+01:00, Kyle Andrews <kyle@posteo.net> a écrit :
>
>Julien Lepiller <julien@lepiller.eu> writes:
>
>> 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!

I'm not sure what manages /etc/channels.scm, but I don't think Guix creates it? In any case, you use that file when pulling, so at the time you pull, you should list all the channels you want to use in that file.

>
>> "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?

It should, but what I meant by that is "whatever your shell believes it should run when you type 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 it fails to boot, you should still be able to select an older, known to work, generation at the grub screen. That's the magic of Guix :)

>
>> 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.

cd is a builtin, so "type cd" should tell you that. "which" will only look for a binary in your $PATH, so it should report that it can't find it.

type itself is a builtin, and it will tell you what a binary is, according to the shell. Bash and other shells have a cache of command name to location. When you use "type guix" it should tell you where it finds guix, according to that cache. If it's different from "which guix", which only looks in $PATH, not in the shell cache, it means you should refresh that cache with "hash guix" (I think hash is also a builtin).

If which does not tell it's your pulled guix (ie. ~/.config/guix/current/bin/guix), it means your $PATH is not set properly.

A guix command could come from different locations in your system. At least one is installed with your system at /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.

Your user's and root's guix are different, as you noticed. So, I was just wondering whether you were doing something like su then reconfigure, or sudo guix. When you use su, you login as root, and use root's guix. When you sudo, you run the user program with root priviledges, which is quite different in that case.

With su, you run root's guix, so you should pull as root. With sudo, you run the user's guix, so you should pull as a user (don't pull with sudo, it will mess up rights in your home directory).

Also, I don't personnaly use the recommended way as I find sudo confusing. I wanted to make sure the above is correct, so does "guix describe" give you the same as "sudo guix describe"?

>
>Thanks for your help!