repair broken boot record

repair broken boot record

[Thomas Danckaert]

Hello guix-help,

my system does not boot anymore after a guix pull and system reconfigure 
(which did show a warning, see below).  It does not even enter the GRUB 
stage, I get a "Reboot and Select proper Boot device" instead.  I think 
the MBR might not have been written correctly (just a hunch, I'm no 
expert...).

During reconfigure, I did get a warning that my bootloader configuration 
used 'target', which is apparently deprecated in favor of 'targets'.  I 
wasn't paying too much attention, and ignored the warning.... I don't 
know if that could be the cause of a missing or incorrect boot record?  
(In that case, I suggest this warning should be an ERROR ;-) )

I checked using a live USB, and it seems the whole system is still there 
on the hard drive.  Is there a way to restore my system, keeping the 
existing /gnu/store?  Or do I have to reinstall from scratch, remove the 
existing /gnu/store and rebuild everything (shouldn't be too much work 
using Guix, but way less elegant :) )

Thank you!

Thomas

Re: repair broken boot record

[pelzflorian (Florian Pelz)]

On Thu, Sep 30, 2021 at 09:43:18AM +0200, Thomas Danckaert wrote:
> Hello guix-help,
> 
> my system does not boot anymore after a guix pull and system reconfigure
> (which did show a warning, see below).  It does not even enter the GRUB
> stage, I get a "Reboot and Select proper Boot device" instead.  I think the
> MBR might not have been written correctly (just a hunch, I'm no expert...).

If this system uses no old grub-bootloader but instead EFI
(grub-efi-bootloader), maybe writing the bootloader to the mainboard
failed (it is not only written to disk), perhaps because the mainboard
NVRAM is full and needs to be cleaned with efibootmgr/efivar/such
utilities.


> During reconfigure, I did get a warning that my bootloader configuration
> used 'target', which is apparently deprecated in favor of 'targets'.  I
> wasn't paying too much attention, and ignored the warning.... I don't know
> if that could be the cause of a missing or incorrect boot record?  (In that
> case, I suggest this warning should be an ERROR ;-) )

No, the old target would fall back to targets.  The warning is only a
warning that you should switch to (targets (list "…")).



> I checked using a live USB, and it seems the whole system is still there on
> the hard drive.  Is there a way to restore my system, keeping the existing
> /gnu/store?  Or do I have to reinstall from scratch, remove the existing
> /gnu/store and rebuild everything (shouldn't be too much work using Guix,
> but way less elegant :) )
> 
> Thank you!
> 
> Thomas

I search on Duckduckgo for “site:lists.gnu.org guix chroot”, you
should read there how to chroot into your system so you can
reconfigure.

Regards,
Florian

Re: repair broken boot record

[Thomas Danckaert]

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 :) ).  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.

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?

Not sure if I need grub-efi, or if it might also work using grub-pc.  
Until now I've always used grub-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.)

thank you!

Thomas

On 2021-10-01 08:53, pelzflorian (Florian Pelz) wrote:
> On Thu, Sep 30, 2021 at 09:43:18AM +0200, Thomas Danckaert wrote:
>> Hello guix-help,
>> 
>> my system does not boot anymore after a guix pull and system 
>> reconfigure
>> (which did show a warning, see below).  It does not even enter the 
>> GRUB
>> stage, I get a "Reboot and Select proper Boot device" instead.  I 
>> think the
>> MBR might not have been written correctly (just a hunch, I'm no 
>> expert...).
> 
> If this system uses no old grub-bootloader but instead EFI
> (grub-efi-bootloader), maybe writing the bootloader to the mainboard
> failed (it is not only written to disk), perhaps because the mainboard
> NVRAM is full and needs to be cleaned with efibootmgr/efivar/such
> utilities.
> 
> 
>> During reconfigure, I did get a warning that my bootloader 
>> configuration
>> used 'target', which is apparently deprecated in favor of 'targets'.  
>> I
>> wasn't paying too much attention, and ignored the warning.... I don't 
>> know
>> if that could be the cause of a missing or incorrect boot record?  (In 
>> that
>> case, I suggest this warning should be an ERROR ;-) )
> 
> No, the old target would fall back to targets.  The warning is only a
> warning that you should switch to (targets (list "…")).
> 
> 
> 
>> I checked using a live USB, and it seems the whole system is still 
>> there on
>> the hard drive.  Is there a way to restore my system, keeping the 
>> existing
>> /gnu/store?  Or do I have to reinstall from scratch, remove the 
>> existing
>> /gnu/store and rebuild everything (shouldn't be too much work using 
>> Guix,
>> but way less elegant :) )
>> 
>> Thank you!
>> 
>> Thomas
> 
> I search on Duckduckgo for “site:lists.gnu.org guix chroot”, you
> should read there how to chroot into your system so you can
> reconfigure.
> 
> Regards,
> Florian

Re: repair broken boot record

[pelzflorian (Florian Pelz)]

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

Re: repair broken boot record

[Thomas Danckaert]

On 2021-10-05 13:04, pelzflorian (Florian Pelz) wrote:
> On Tue, Oct 05, 2021 at 11:28:50AM +0200, Thomas Danckaert wrote:
>> 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.

The full message is:

guix system: error: 
'/gnu/store/v77n5m....grub-efi-2.06/sbin/grub-install --boot-directory 
//boot --bootloader-id=Guix --efi-directory=/boot/efi' exited with 
status 1; output follows:

   /gnu/store/.../grub-install: error: 
/gnu/store/.../lib/grub/i386-pc/modinfo.sh doesn't exist.  Please 
specify --target or --directory'

Note that the grub-install command doens't contain '--target' or 
'--directory'.  (Also: my system is x64, and this seems to be for i386.  
Should there be a --target=x64_86-efi somewhere?)

> 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.

I have in my config 'target /boot/efi'.  My EFI partition is /dev/sda1.  
If I mount it like
# mount /dev/sda1 /mnt2
(/mnt2 because I already have my /dev/sda3 partition with guix at /mnt)
I find the following layout:

/mnt2/EFI/
           EFI
           grub
           Guix

what would be the correct bind mount?  I tried
# mount --bind /mnt2/EFI /boot/efi
so I now have
/boot/efi/
           EFI
           grub
           Guix

Any idea if that is the desired layout?

thanks!

Thomas

Re: repair broken boot record

[pelzflorian (Florian Pelz)]

On Wed, Oct 06, 2021 at 10:23:38AM +0200, Thomas Danckaert wrote:
> On 2021-10-05 13:04, pelzflorian (Florian Pelz) wrote:
> > On Tue, Oct 05, 2021 at 11:28:50AM +0200, Thomas Danckaert wrote:
> > > 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.
> 
> The full message is:
> 
> guix system: error: '/gnu/store/v77n5m....grub-efi-2.06/sbin/grub-install
> --boot-directory //boot --bootloader-id=Guix --efi-directory=/boot/efi'
> exited with status 1; output follows:
> 
>   /gnu/store/.../grub-install: error:
> /gnu/store/.../lib/grub/i386-pc/modinfo.sh doesn't exist.  Please specify
> --target or --directory'
> 
> Note that the grub-install command doens't contain '--target' or
> '--directory'.  (Also: my system is x64, and this seems to be for i386.
> Should there be a --target=x64_86-efi somewhere?)

Sorry, I was wrong about --target being used; looking in the Guix
source at gnu/bootloader/grub.scm
<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/bootloader/grub.scm>,
--target is only for traditional BIOS boot and not EFI boot.

Your command is correct. I checked and have used exactly the same
command successfully (I checked the install-bootloader.scm file after
reconfigure on an EFI PC), and it should install, but for you it does
not.  It is good to see the full message though.

Note that you can run exactly the same command manually, but the
result would likely be the same.


> > 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.
> 
> I have in my config 'target /boot/efi'.  My EFI partition is /dev/sda1.  If
> I mount it like
> # mount /dev/sda1 /mnt2
> (/mnt2 because I already have my /dev/sda3 partition with guix at /mnt)
> I find the following layout:
> 
> /mnt2/EFI/
>           EFI
>           grub
>           Guix
> 
> what would be the correct bind mount?  I tried
> # mount --bind /mnt2/EFI /boot/efi
> so I now have
> /boot/efi/
>           EFI
>           grub
>           Guix
> 
> Any idea if that is the desired layout?

From outside the chroot, you should

# mount /dev/sda3 /mnt
# mount /dev/sda1 /mnt/boot/efi

Regards,
Florian

Re: repair broken boot record

[Thomas Danckaert]

Hi Florian,

I think I still owed a final response in this thread, especially 
after all your effort to help out.

In the end, I reinstallled Guix from scratch (luckily, I had a full 
backup of my /home, and Guix makes it easy to restore your system 
exactly as it was...), and switched to '(bootloader 
grub-bootloader)'.  That did the trick.  I couldn't get the chroot 
approach to work properly (maybe with more time, ...).

Looking back at the history of my system config, I used to have

(bootloader (grub-configuration (target "/dev/sda")))

for a long time.   I don't actually remember how I ever ended up with 
grub-efi-bootloader (little Guix time lately, I mostly just update 
and check my e-mail these days), maybe I just copied from the manual 
without thinking/ reading properly...

Thanks for your help, I still learned a few things, even though I 
couldn't get it to work properly...

Thomas

Re: repair broken boot record

[pelzflorian (Florian Pelz)]

Thank you Thomas for the post-mortem.

> In the end, I reinstallled Guix from scratch […] I couldn't get the
> chroot approach to work properly (maybe with more time, ...).

Though there is little difference betweem reconfigure and reinstall if
the chroot is set up properly, I should better have adviced to avoid
the trouble and reinstall.  Imitating a booted system with chroot has
too individual requirements.  Anyway.

Good your system is working again now. :)

Regards,
Florian