bug#74711: Is grub broken and breaking Guix ?

bug#74711: Is grub broken and breaking Guix ?

[ngraves]

Hi Guix,

I've had a low-level btrfs failing issue once again on my main computer, 
but this time I'm almost unable to recover from it.

On my backup computer, I tried updating Guix before generating an 
installable image, and that broke my backup computer. I'm unable to 
install Guix that I broke due to the following error :
https://savannah.gnu.org/bugs/?64406

This error also breaks the possibility to roll-back, I have the exact 
same error with earlier Guix system profiles, thus I am stuck trying to 
reinstall a working system profile on my backup computer.

I'm able to build everything, but it fails when running grub-install.

I use a single LUKS device, with btrfs on top, and a carefully selected 
btrfs layout.

I'm able to fix the grub-install invocation using the prefixed 
GRUB_ENABLE_CRYPTODISK=y and running the command by hand, but utimately, 
it doesn't fix the underlying error. I'm not able to run it with this 
prefix using grub 2.06.

I've also been experiencing extremely annoying git and guile-git SSL 
certificates issues, despites the SSL_CERT_DIR and SSL_CERT_FILE being 
set properly. For some reason, I was not able to `guix pull` even on the 
official installation device on tuesday but without changing anything, 
but was able to do that on wednesday.

Here I am, 4 days later, still trying to get a proper up-to-date Guix 
working, even with 3-4 years of Guix experience. There's still some 
progress ahead ;)

I'm quite stuck now, I'll happily take any advice.

Nicolas

bug#74711: Sharing some progress

[ngraves]

I've found the reason behind the extremely annoying SSL certification 
refusals.

When I use an installation image, the date is not necessarily set at the 
real date.  In my case, `date` was set in 2019, and triggered the SSL 
verification refusal (not yet valid).

I don't know why it sometimes doesn't happen.  If we can't fix/automate 
it at the time we boot in the installation medium, we should probably 
add a warning in the manual / a hint in guix pull / a proper error in 
guile-git (that could provide more information than just Git failing) ?

WDYT ?

Best regards,
Nicolas

bug#74711: Sharing some progress

[ngraves]

Le 07.12.2024 10:45, ngraves@ngraves.fr a écrit :
> 
> WDYT ?

By the way, guix install did work perfectly fine despite SSL 
certificates failing, does that mean that it doesn't do any SSL 
certificate verification ? Is that considered safe? How about 
man-in-the-middle and data-tampering attacks? Are they impossible due to 
sha checksums in Guix, or is that a vulnerability ?

Nicolas

bug#74711: Certificate issues with ‘guix pull’ when system clock is in the past

[Ludovic Courtès]

Hi,

ngraves@ngraves.fr skribis:

> I've found the reason behind the extremely annoying SSL certification
> refusals.
>
> When I use an installation image, the date is not necessarily set at
> the real date.  In my case, `date` was set in 2019, and triggered the
> SSL verification refusal (not yet valid).

Could it be that the clock battery of that computer is dead?  Otherwise
it’s not supposed to happen.

> I don't know why it sometimes doesn't happen.  If we can't
> fix/automate it at the time we boot in the installation medium, we
> should probably add a warning in the manual / a hint in guix pull / a
> proper error in guile-git (that could provide more information than
> just Git failing) ?

The error I see is:

--8<---------------cut here---------------start------------->8---
$ guix shell libfaketime -- faketime 2019-01-01 guix pull -p /tmp/p
Updating channel 'shepherd' from Git repository at 'https://git.savannah.gnu.org/git/shepherd.git'...
guix pull: error: Git error: the SSL certificate is invalid
--8<---------------cut here---------------end--------------->8---

I agree it could give more details, but that’s all we get from libgit2 I
believe.  Worth investigating how this can be improved.

That said, what we could/should do is add a ‘--no-check-certificate’
option to ‘pull’ and ‘time-machine’; it would be handy in emergency
situations like you described.

It should be possible to implement that with the ‘certificate_check’
callback in ‘git_remote_callbacks’.  I’ll see what can be done in this
area.

Thanks,
Ludo’.

bug#74711: Is grub broken and breaking Guix ?

[Ludovic Courtès]

ngraves@ngraves.fr skribis:

> By the way, guix install did work perfectly fine despite SSL
> certificates failing, does that mean that it doesn't do any SSL
> certificate verification ? Is that considered safe? How about
> man-in-the-middle and data-tampering attacks? Are they impossible due
> to sha checksums in Guix, or is that a vulnerability ?

The error with ‘guix pull’ comes from libgit2 when talking to
https://git.sv.gnu.org.

‘guix install’ does not do that.  When it downloads substitutes, it
authenticates them (narinfos are signed) and checks their integrity once
the download is complete.

X.509 certificates do not matter at all here and are explicitly ignored;
see #:verify-certificate? in (guix scripts substitutes).

Ludo’.

bug#74711: Is grub broken and breaking Guix ?

[Ludovic Courtès]

Hi,

ngraves@ngraves.fr skribis:

> On my backup computer, I tried updating Guix before generating an
> installable image, and that broke my backup computer. I'm unable to
> install Guix that I broke due to the following error :
> https://savannah.gnu.org/bugs/?64406

The error at boot time is:

  error: symbol `grub_is_shim_lock_enabled` not found when trying to boot image

Is that right?

I don’t think this has been reported before.  Is there a chance it has
to do specifically with the Btrfs/LUKS setup you describe?

Had this machine been upgraded and reconfigured recently?

Ludo’.

bug#74711: Is grub broken and breaking Guix ?

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

> That said, what we could/should do is add a ‘--no-check-certificate’
> option to ‘pull’ and ‘time-machine’; it would be handy in emergency
> situations like you described.

See <https://issues.guix.gnu.org/74776>.