unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / Atom feed
* bug#44898: [wishlist] Make the GRUB installation procedure smarter
@ 2020-11-26 23:15 guixuser6392 via Bug reports for GNU Guix
  2020-11-27 20:00 ` bug#44898: (No Subject) guixuser6392 via Bug reports for GNU Guix
  2021-09-05  1:27 ` bug#44898: [wishlist] Make the GRUB installation procedure smarter muradm
  0 siblings, 2 replies; 3+ messages in thread
From: guixuser6392 via Bug reports for GNU Guix @ 2020-11-26 23:15 UTC (permalink / raw)
  To: 44898

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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#44898: (No Subject)
  2020-11-26 23:15 bug#44898: [wishlist] Make the GRUB installation procedure smarter guixuser6392 via Bug reports for GNU Guix
@ 2020-11-27 20:00 ` guixuser6392 via Bug reports for GNU Guix
  2021-09-05  1:27 ` bug#44898: [wishlist] Make the GRUB installation procedure smarter muradm
  1 sibling, 0 replies; 3+ messages in thread
From: guixuser6392 via Bug reports for GNU Guix @ 2020-11-27 20:00 UTC (permalink / raw)
  To: 44898

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




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#44898: [wishlist] Make the GRUB installation procedure smarter
  2020-11-26 23:15 bug#44898: [wishlist] Make the GRUB installation procedure smarter guixuser6392 via Bug reports for GNU Guix
  2020-11-27 20:00 ` bug#44898: (No Subject) guixuser6392 via Bug reports for GNU Guix
@ 2021-09-05  1:27 ` muradm
  1 sibling, 0 replies; 3+ messages in thread
From: muradm @ 2021-09-05  1:27 UTC (permalink / raw)
  To: 44898


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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-09-05  1:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-26 23:15 bug#44898: [wishlist] Make the GRUB installation procedure smarter guixuser6392 via Bug reports for GNU Guix
2020-11-27 20:00 ` bug#44898: (No Subject) guixuser6392 via Bug reports for GNU Guix
2021-09-05  1:27 ` bug#44898: [wishlist] Make the GRUB installation procedure smarter muradm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).