I have just installed Guix on a computer using: https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz When I run `guix pull` I get this error message "guix pull: error: Git error: the SSL certificate is invalid".
Hello, Also trying to be helpful here, but, be careful anyways... ;-) On Sat, Apr 10, 2021 at 6:28 AM Bone Baboon <bone.baboon@disroot.org> wrote: > I have just installed Guix on a computer using: > https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz I did this 2 days ago on an old laptop, which had an old guix install (~1 year old). > When I run `guix pull` I get this error message "guix pull: error: Git > error: the SSL certificate is invalid". And I can guix pull & guix system reconfigure. I reinstalled because I saw that same error message, from the old guix install... So I don't know if this is helpful. But I remember having seen an (default checked) option to install certificates when choosing packages to install. Let me power it up and check... I have the "nss-certs" package installed from /etc/config.scm This may be what you're missing. -- Vincent Legoll
Vincent Legoll writes: > I remember having seen an (default checked) option > to install certificates when choosing packages to install. > I have the "nss-certs" package installed from /etc/config.scm > > This may be what you're missing. I reinstalled Guix on the laptop. During the graphical install I used the default checked option for the certificates. The only difference with the install on this computer was that at the end when it prompts for the install media to be removed and the reboot button used it went to a blue screen and did not power off. So I held the power button to turn the computer off. I was able to boot and sign in normally. With a working Ethernet connection `guix pull` gave the same error. However `sudo guix system reconfigure config.scm` worked fine and was able to download using the internet connection. `nss-certs` is in the system configuration file. `locate certificates` shows that `etc/ssl/certs/ca-certificates.crt` is in the store. `ls /run/current-system/profile/etc/ssl/certs/ | wc --lines` outputs 301.
On Sat, Apr 10, 2021 at 12:28:20AM -0400, Bone Baboon wrote:
> I have just installed Guix on a computer using:
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz
>
> When I run `guix pull` I get this error message "guix pull: error: Git
> error: the SSL certificate is invalid".
In what context did you run `guix pull`? Like, in a graphical terminal
emulator? A console? As root? If as root, how did you become root?
Is the bug reproducible? If so, please share the results of `env`,
`which guix`, and `guix describe`, in the same environment where you see
the bug.
On Sat, Apr 10, 2021 at 11:33:12AM +0200, Vincent Legoll wrote:
> But I remember having seen an (default checked) option
> to install certificates when choosing packages to install.
>
> Let me power it up and check...
>
> I have the "nss-certs" package installed from /etc/config.scm
`guix pull` uses its own certificate store, and it happens
automatically.
nss-certs is not used.
Leo Famulari writes: > In what context did you run `guix pull`? Like, in a graphical terminal > emulator? A console? As root? If as root, how did you become root? > > Is the bug reproducible? If so, please share the results of `env`, > `which guix`, and `guix describe`, in the same environment where you see > the bug. I can reproduce this after two separate install using this install image: https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz The output of `guix pull`: ``` Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix pull: error: Git error: the SSL certificate is invalid ``` I am running `guix pull` from a Linux console virtual terminal. I am running `guix pull` as a regular user (not root). `which guix` outputs "/run/current-system/profile/bin/guix". The output of `guix describe`: ``` guix describe: error: failed to determine origin hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.2.0rc2-1.0d4b1af. ``` The output of `env`: ``` SHELL=/gnu/store/ndjymgwsm5lyxphdgqwr5wf7j7xf29d4-bash-5.0.16/bin/bash XDG_CONFIG_DIRS=/home/user/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg BASH_LOADABLES_PATH=/run/current-system/profile/lib/bash LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules XCURSOR_PATH=/home/user/.icons:/home/user/.guix-profile/share/icons:/run/current-system/profile/share/icons GTK_DATA_PREFIX=/run/current-system/profile LOGNAME=user MANPATH=/run/current-system/profile/share/man:/home/user/.guix-profile/share/man:/run/current-system/profile/share/man GUILE_LOAD_PATH=/run/current-system/profile/share/guile/site/3.0 HOME=/home/user GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt LANG=en_US.utf8 SSL_CERT_DIR=/etc/ssl/certs GUILE_LOAD_COMPILED_PATH=/run/current-system/profile/lib/guile/3.0/site-ccache:/run/current-system/profile/share/guile/site/3.0 INFOPATH=/home/user/.config/guix/current/share/info:/run/current-system/profile/share/info:/home/user/.guix-profile/share/info:/run/current-system/profile/share/info DICPATH=/home/user/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell DBUS_FATAL_WARNINGS=0 TERM=linux USER=user TZDIR=/gnu/store/1cab1lwnz2af20xdhzsvzfcbzarp0m40-tzdata-2020a/share/zoneinfo SHLVL=1 GUIX_LOCPATH=/run/current-system/locale GST_PLUGIN_PATH=/home/user/.guix-profile/lib/gstreamer-1.0 SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt XDG_DATA_DIRS=/home/user/.guix-profile/share:/run/current-system/profile/share HUSHLOGIN=FALSE PATH=/run/setuid-programs:/home/user/.config/guix/current/bin:/home/user/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin _=/run/current-system/profile/bin/env ```
On Sat, Apr 10, 2021 at 09:54:18PM -0400, Bone Baboon wrote: > I can reproduce this after two separate install using this install > image: > https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz Okay. I have installed this ISO in a virtual machine, following the instructions in the manual section Installing Guix in a VM. > The output of `guix pull`: > ``` > Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... > guix pull: error: Git error: the SSL certificate is invalid > ``` I logged in as a regular user, ran `guix pull`, and it completed successfully. I also tried as root, and that worked too. > I am running `guix pull` from a Linux console virtual terminal. > I am running `guix pull` as a regular user (not root). Okay. > `which guix` outputs "/run/current-system/profile/bin/guix". Okay. > The output of `guix describe`: > ``` > guix describe: error: failed to determine origin > hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.2.0rc2-1.0d4b1af. > ``` This isn't quite right. It's expected that, before the first `guix pull`, the origin is not known. The per-user view of Guix, with provenance tracking, is created on the first `guix pull`. However, the version string should be 1.2.0. Something has gone wrong on your system and caused you to "go back in time" to an earlier release, the second release candidate of the 1.2.0 release.
On Sun, Apr 11, 2021 at 03:04:14PM -0400, Leo Famulari wrote: > It's expected that, before the first `guix pull`, the origin is not > known. The per-user view of Guix, with provenance tracking, is created > on the first `guix pull`. > > However, the version string should be 1.2.0. Something has gone wrong > on your system and caused you to "go back in time" to an earlier > release, the second release candidate of the 1.2.0 release. I don't think this is related to the TLS / SSL problem. That problem is being tracked at <https://bugs.gnu.org/46829>.
Leo Famulari writes:
>> The output of `guix describe`:
>> ```
>> guix describe: error: failed to determine origin
>> hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.2.0rc2-1.0d4b1af.
>> ```
>
> This isn't quite right.
>
> It's expected that, before the first `guix pull`, the origin is not
> known. The per-user view of Guix, with provenance tracking, is created
> on the first `guix pull`.
>
> However, the version string should be 1.2.0. Something has gone wrong
> on your system and caused you to "go back in time" to an earlier
> release, the second release candidate of the 1.2.0 release.
The steps I did after the install:
1) ping a website
2) guix pull (fails)
3) reconfigure system
4) guix describe
I think it is step 3 which caused the rollback to the release
candidate. I even received a warning that running a reconfigure before
running `guix pull` could downgrade the system.
Leo Famulari writes:
> On Sun, Apr 11, 2021 at 03:04:14PM -0400, Leo Famulari wrote:
>> It's expected that, before the first `guix pull`, the origin is not
>> known. The per-user view of Guix, with provenance tracking, is created
>> on the first `guix pull`.
>>
>> However, the version string should be 1.2.0. Something has gone wrong
>> on your system and caused you to "go back in time" to an earlier
>> release, the second release candidate of the 1.2.0 release.
>
> I don't think this is related to the TLS / SSL problem. That problem is
> being tracked at <https://bugs.gnu.org/46829>.
Thank you for sharing that link. It inspired several tests that I
conducted which helped me solve the problem. The issue was that the
date was significantly incorrect.
I was able to fix this with `sudo date --set='YYYY-MM-DD HH:MM:SS'`.
The changed date did not persist after a reboot and I had the same
error. To make the changed date persist after a reboot I used this
command `sudo hwclock --systohw`.
On Tue, Apr 13, 2021 at 08:26:32PM -0400, Bone Baboon wrote:
> Thank you for sharing that link. It inspired several tests that I
> conducted which helped me solve the problem. The issue was that the
> date was significantly incorrect.
>
> I was able to fix this with `sudo date --set='YYYY-MM-DD HH:MM:SS'`.
> The changed date did not persist after a reboot and I had the same
> error. To make the changed date persist after a reboot I used this
> command `sudo hwclock --systohw`.
You might look into using NTP to keep your clock set correctly, by
adding the ntp-service-type to your config.scm's services and
reconfiguring.