Re: repair broken boot record

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

On Tue, Oct 05, 2021 at 11:28:50AM +0200, Thomas Danckaert wrote:
> Hello Florian,
> 
> thank you for your help.  I managed to chroot into my system, and re-run
> 'guix system reconfigure' (very useful mailing list discussion on chrooting,
> I also vote for including it in documentation :) ).

I’m glad it helped so far, although I don’t know all the details about
chroot nor EFI.  (For example which directories from the live system
should be mounted in the chroot and why.)  So I won’t attempt to write
documentation.


> In one of the final
> steps, where guix tries to install the bootloader, I get the error:
> 
> /gnu/store/.../grub/i386-pc/modinfo.sh doesn't exist. Please specify
> --target or --directory.

This is strange.  When you reconfigure, Guix should print the
grub-install command that was used, which should include both --target
and --directory.

However, perhaps the chroot is at fault: Before chrooting to, let’s
say, /mnt with chroot /mnt, you need to have mounted the /dev/sdXy
file system with EFI on it (that which is declared in your config.scm)
to /mnt/boot/efi.

What I write below you will probably not need; you can ignore it if
the above works:

> Indeed my system uses grub-efi.  Could that be related?  Can you point me to
> some specific instructions on how to check/solve efivar issues?

If you have made available efivar (by installing it or by `guix
environment --ad-hoc efivar` or similar), and if you have booted from
an EFI bootloader, then you can run `efivar -l` to see all variables
stored on your motherboard/mainboard.  The motherboard NVRAM can
become full.  However I’m not sure how to delete such variables; I
think the program efibootmgr can do it.  Hopefully and likely it will
not be necessary.


> Not sure if I need grub-efi, or if it might also work using grub-pc.  Until
> now I've always used grub-efi.

Some systems need EFI (and others don’t work with EFI).  It is
probably better to stick with EFI.


> (Another thing I noticed (maybe a side effect of chroot?): when I re-run
> 'guix system reconfigure' it tries to rebuild derivations that are already
> there in the store from last time, I think.)

Maybe they just have the same package name but are different versions,
so a rebuild is necessary.  But maybe also the running guix-daemon is
the one from the live USB and not from the installed system.

guix-daemon stores information about what is installed in a sqlite
database.  Now I wonder if the chroot can make changes to the wrong
database and interfere with the already installed guix-daemon, making
the store inconsistent.  Anyway, this should not cause trouble with
reconfiguring and if some inconsistency in the installed system causes
trouble later on, guix gc --verify can fix it.  It is not important now.

Hope it helps.

Regards,
Florian