GNU bug report logs - #44898
[wishlist] Make the GRUB installation procedure smarter

Previous Next

To reply to this bug, email your comments to 44898 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: guixuser6392 <guixuser6392 <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: [wishlist] Make the GRUB installation procedure smarter
Date: Thu, 26 Nov 2020 23:15:58 +0000

Every time the operating system is instantiated the GRUB boot-loader is inexplicitly re-installed. This behaviour leads to unsolicited changes to the user's boot configuration on UEFI systems; and leads to unnecessary write operations on the ESP, and/or the MBR, which, in case they are abruptly aborted during the building of the install-bootloader derivation, can leave the system in an unbootable state. Futhermore, frequent writes to the platform's NV-RAM may negatively impact its lifespan.

NixOS stores the GRUB derivation as well as boot parameters in a state file, and only re-installs the boot-loader if the computed state is different from the stored state: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl#L626. However, unless I am mistaken, that alone will not prevent GRUB from altering the user's boot configuration in a scenario, in which we want GRUB to be re-installed because it has received an update.

To summarize, I think that consecutive grub-install invocations should not be allowed to modify the user's boot configuration on UEFI systems, and that we should teach Guix to only re-install the boot-loader if the boot parameters has been changed and/or the GRUB package has been upgraded.

Although other boot-loaders are not in the scope of this wish, brining their installation procedures to the same high standard would be beneficial, too.

Message #8 received at 44898 <at> debbugs.gnu.org (full text, mbox):

From: guixuser6392 <guixuser6392 <at> protonmail.com>
To: "44898 <at> debbugs.gnu.org" <44898 <at> debbugs.gnu.org>
Subject: (No Subject)
Date: Fri, 27 Nov 2020 20:00:52 +0000

I would like to clarify that whenever I wrote "boot parameters", I meant installation arguments passed to grub-install.

Message #11 received at 44898 <at> debbugs.gnu.org (full text, mbox):

From: muradm <mail <at> muradm.net>
To: 44898 <at> debbugs.gnu.org
Subject: RE: [wishlist] Make the GRUB installation procedure smarter
Date: Sun, 05 Sep 2021 04:27:25 +0300

First I was using Guix on Lenovo Carbon X1 in parallel with Arch. 
Few times I experiences "NVRAM full" or similar problem, I don't 
recall now. Solution was to reset NVRAM by some procedure. Half a 
year now, I moved to System76 Lemur Pro, where I have only Guix 
alone. Here I have another problem, sometimes it simply does not 
boot, then I have to plug USB, and run grub-install manually to 
recover.

As per discussion on IRC today, I would suggest the folowing 
regarding grub efi, I'm not using other bootloaders, but I suppose 
same logic may apply.

There are two things about grub:

1) /boot/efi/EFI/Guix/grubx64.efi & NVRAM - these are changing 
very very rarely, only when grub version change, boot partition 
change.

2) /boot/grub/* - these are changing only when grub version change 
or new guix generation is created, then grub.cfg is getting 
updated.

Currently, as far as I understand, both of them are getting 
installed with one script from this derivation:
/gnu/store/...-install-bootloader.scm.drv

It could be split into two, one which runs grub-install, i.e. #1 
above, the other which covers #2 above, let's say 
bootloader-phase-1-install and bootloader-phase-2-install 
respectively.

Then, each script can be executed only when derivation is 
changing. With the following exceptions:
- must be executed anyway on "guix system init ..."
- must be executed only if "guix system reconfigure 
 --force-bootloader ..."

Scripts them selves store grub version (via absolute path), thus 
if grub updated, derivations will change.

If for some reason, grub and/or nvram getting broken on boot, user 
has to boot with some kind recovery media anyway.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.