Unable to determine system origin when configuration stored in guix channel

  • Open
  • quality assurance status badge
Details
2 participants
  • Collin J. Doering
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Collin J. Doering
Severity
normal
C
C
Collin J. Doering wrote on 30 Mar 2022 04:03
(address . bug-guix@gnu.org)
87k0cc2o1q.fsf@rekahsoft.ca
Hi,

I recently converted my guix configuration to be stored in a channel, primarily to allow me to reference files in the repository but yet still have a self-contained configuration. It also allows me to easily build packages and images from my local guix instance. I also like how the specification of my system (or home) is precisely defined by a set of channels, and an expression which evaluates to the operating-system (or home-configuration) that I'm deploying.

As per the guix manual:

Toggle snippet (3 lines)
If you want configuration.scm to be self-contained, we recommend that modules or files it refers to be part of a channel.

This all being said, I noticed an issue in that I'm unable to determine the provenance of a system when my configuration is stored in a guix channel.

Specifically, if I have a guix channel that contains two modules, each of which exports a %system variable of type operating-system, I cannot tell which one was used to instantiate the system. This is due to two issues. The first is because when `-e|--expression` arguments are used, `configuration-file` is set to `#f` in the generations provenance file but the expression itself is not stored in the provenance file, and is not listed in `guix system describe`, `guix system list-generations`, etc.. commands.

Toggle snippet (3 lines)
sudo -i guix system reconfigure -e '(@ (my config system-a) %system)'

Toggle snippet (19 lines)
? guix system describe
Generation 30 Mar 28 2022 22:50:55 (current)
file name: /var/guix/profiles/system-30-link
canonical file name: /gnu/store/886xwflic0dnf86d460yf7n5wg3jng7w-system
label: GNU with Linux 5.16.16
bootloader: grub-efi
root device: label: "root"
kernel: /gnu/store/44hi9qg3mrp6c6cb1rqwx47xhg1663d9-linux-5.16.16/bzImage
channels:
guix:
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e584a093f943be216fdc93895281fde835836b8d
my-config-channel:
repository URL: https://not-yet-on-the-internet.com
branch: master
commit: 918a3bf799038a019c7394cda480ee67db8a0009

Change the system to 'system-b':

Toggle snippet (3 lines)
sudo -i guix system reconfigure -e '(@ (my config system-b) %system)'

Toggle snippet (19 lines)
? guix system describe
Generation 31 Mar 28 2022 23:10:01 (current)
file name: /var/guix/profiles/system-31-link
canonical file name: /gnu/store/jpkxxyh6zi3gh8pbml3r9l1iccibw5mk-system
label: GNU with Linux 5.16.16
bootloader: grub-efi
root device: label: "root"
kernel: /gnu/store/jpkxxyh6zi3gh8pbml3r9l1iccibw5mk-linux-5.16.16/bzImage
channels:
guix:
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e584a093f943be216fdc93895281fde835836b8d
my-config-channel:
repository URL: https://not-yet-on-the-internet.com
branch: master
commit: 918a3bf799038a019c7394cda480ee67db8a0009

Notice how there is no way to see which configuration was used to create the system.


The second issue is that when `-L|--load-path` is used along with either a file or expression to specify the operating-system or home-configuration, it essentially 'tarnishes' the provenance of the system, in that the following deployment is not differentiable from the preceding one/s, despite them being different.

Toggle snippet (3 lines)
sudo -i guix system reconfigure -L my-local-channel-but-with-changes -e '(@ (my config system-a) %system)'

Toggle snippet (19 lines)
? guix system describe
Generation 32 Mar 28 2022 23:10:01 (current)
file name: /var/guix/profiles/system-32-link
canonical file name: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-system
label: GNU with Linux 5.16.16
bootloader: grub-efi
root device: label: "root"
kernel: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-linux-5.16.16/bzImage
channels:
guix:
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e584a093f943be216fdc93895281fde835836b8d
my-config-channel:
repository URL: https://not-yet-on-the-internet.com
branch: master
commit: 918a3bf799038a019c7394cda480ee67db8a0009

L
L
Liliana Marie Prikler wrote on 30 Mar 2022 07:56
cc441b07385814f555d6894aaa0d2e06b360a6d9.camel@ist.tugraz.at
Am Dienstag, dem 29.03.2022 um 22:03 -0400 schrieb Collin J. Doering:
Toggle quote (3 lines)
> [...]
> Notice how there is no way to see which configuration was used to
> create the system.
The key here is that you're using a configuration expression rather
than a file. Were you to write those files to disk in let's say
config-a.scm and config-b.scm respectively and refer to them on the
command line like that, you'd have a configuration file guix could
refer to.

Alternatively, Guix could take the expression specified via -e and
write it to disk. Note that some configuration files are meaningless
even if written to disk, for example...

Toggle quote (32 lines)
> The second issue is that when `-L|--load-path` is used along with
> either a file or expression to specify the operating-system or home-
> configuration, it essentially 'tarnishes' the provenance of the
> system, in that the following deployment is not differentiable from
> the preceding one/s, despite them being different.
>
> --8<---------------cut here---------------start------------->8---
> sudo -i guix system reconfigure -L my-local-channel-but-with-changes
> -e '(@ (my config system-a) %system)'
> --8<---------------cut here---------------end--------------->8---
>
> --8<---------------cut here---------------start------------->8---
> ? guix system describe       
> Generation 32   Mar 28 2022 23:10:01    (current)
>   file name: /var/guix/profiles/system-32-link
>   canonical file name: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-
> system
>   label: GNU with Linux 5.16.16
>   bootloader: grub-efi
>   root device: label: "root"
>   kernel: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-linux-
> 5.16.16/bzImage
>   channels:
>     guix:
>       repository URL: https://git.savannah.gnu.org/git/guix.git
>       branch: master
>       commit: e584a093f943be216fdc93895281fde835836b8d
>     my-config-channel:
>       repository URL: https://not-yet-on-the-internet.com
>       branch: master
>       commit: 918a3bf799038a019c7394cda480ee67db8a0009
> --8<---------------cut here---------------end--------------->8---
LOAD_PATH tweaking should be considered harmful and void your
provenance, at least w.r.t. channels. There's no sane way for guix to
check whether the load paths you added still exist after
reconfiguration, other than placing the entire directory in the store.

Cheers
C
C
Collin J. Doering wrote on 30 Mar 2022 10:13
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 54631@debbugs.gnu.org)
87bkxn3ktv.fsf@rekahsoft.ca
Hi Liliana,

Thank you for your response :)

Toggle quote (3 lines)
> Alternatively, Guix could take the expression specified via -e and
> write it to disk.

I think this would be the best way to resolve this issue. Also, thanks for your explanation.

Toggle quote (5 lines)
> LOAD_PATH tweaking should be considered harmful and void your
> provenance, at least w.r.t. channels. There's no sane way for guix to
> check whether the load paths you added still exist after
> reconfiguration, other than placing the entire directory in the store.

I agree! However, I think it would be nice if `guix system describe`, `guix system list-generations`, `guix home list-generations`, etc.. indicated when a generation was created with the `-L|--load-path` argument specified. As you said, it 'voids you provenance', so I think its something that should be visually indicated to the user.

Regards

--
Collin J. Doering

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 54631@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54631
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch