[gentoo-user] Verify uefi installation

[gentoo-user] Verify uefi installation

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

After updating the BIOS on my motherboard, the system will no longer boot.
The NVME drive is still recognised in the BIOS and set to the the primary
boot device. However, when i originally installed the system (and assuming
I remember correctly) the boot order setting in the BIOS showed something
about the operating system as part of the M2 drive entry, which it doesn't
now. The original BIOS is not available for download, so I tried a couple
of others, including the oldest available, but no change.

I can boot from a usb drive and mount the vfat /dev/nvme0n1p1 partition.
The usual kernel files are there, as is EFI/gentoo/grubx64.efi

What can I do to verify the OS installation?

[-- Attachment #2: Type: text/html, Size: 781 bytes --]

Re: [gentoo-user] Verify uefi installation

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Sunday, 22 September 2019 05:22:02 BST Adam Carter wrote:
> After updating the BIOS on my motherboard, the system will no longer boot.
> The NVME drive is still recognised in the BIOS and set to the the primary
> boot device. However, when i originally installed the system (and assuming
> I remember correctly) the boot order setting in the BIOS showed something
> about the operating system as part of the M2 drive entry, which it doesn't
> now. The original BIOS is not available for download, so I tried a couple
> of others, including the oldest available, but no change.
> 
> I can boot from a usb drive and mount the vfat /dev/nvme0n1p1 partition.
> The usual kernel files are there, as is EFI/gentoo/grubx64.efi
> 
> What can I do to verify the OS installation?

The UEFI menu will present you with a list of bootable devices.  The UEFI 
firmware will probe connected devices to find anything which can provide 
booting (from hard drives, to USB devices, to network ports) and list them.  
Among those the grubx64.efi ought to be listed as an available option.

If not, you can use the efibootmgr to set it as a bootable image in the UEFI 
firmware.  Boot with a Live-USB and follow this page:

https://wiki.gentoo.org/wiki/Efibootmgr

Of course, grubx64.efi will only boot OS kernels it has been configured to 
boot with.  So, make sure while you're in the Live-USB environment and have 
chrooted into your installation, you run 'grub-mkconfig -o /boot/grub/
grub.cfg' or what is appropriate for your boot filesystem.

HTH.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Verify uefi installation

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Sun, Sep 22, 2019 at 10:56 PM Mick <michaelkintzios@gmail.com> wrote:

> The UEFI menu will present you with a list of bootable devices.  The UEFI
> firmware will probe connected devices to find anything which can provide
> booting (from hard drives, to USB devices, to network ports) and list
> them.
> Among those the grubx64.efi ought to be listed as an available option.
>

Ok that's what I remembered.


> If not, you can use the efibootmgr to set it as a bootable image in the
> UEFI
> firmware.  Boot with a Live-USB and follow this page:
>
> https://wiki.gentoo.org/wiki/Efibootmgr


Done, and it now boots.

When i ran the efibootmgr command it reports "GUID partition table header
signature is wrong" so i'll look at that next.

Thanks

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: [gentoo-user] Verify uefi installation

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

Follow on question; what does efibootmgr actually modify? Is it writing to
motherboard EEPROM values similar what happens when you write changes in
the BIOS setup pages?
If you, does mean I may have been able to fix this issue in the BIOS?

[-- Attachment #2: Type: text/html, Size: 287 bytes --]

Re: [gentoo-user] Verify uefi installation

[J. Roeleveld]

On 23 September 2019 07:33:44 CEST, Adam Carter <adamcarter3@gmail.com> wrote:
>Follow on question; what does efibootmgr actually modify? Is it writing
>to
>motherboard EEPROM values similar what happens when you write changes
>in
>the BIOS setup pages?
>If you, does mean I may have been able to fix this issue in the BIOS?

It updates something in the CMOS, however, not all UEFI bioses support manually editing this.
I haven't found a decent option for this on any system I own yet, apart from efibootmgr.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Verify uefi installation

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Mon, Sep 23, 2019 at 3:38 PM J. Roeleveld <joost@antarean.org> wrote:

> On 23 September 2019 07:33:44 CEST, Adam Carter <adamcarter3@gmail.com>
> wrote:
> >Follow on question; what does efibootmgr actually modify? Is it writing
> >to
> >motherboard EEPROM values similar what happens when you write changes
> >in
> >the BIOS setup pages?
> >If you, does mean I may have been able to fix this issue in the BIOS?
>
> It updates something in the CMOS, however, not all UEFI bioses support
> manually editing this.
> I haven't found a decent option for this on any system I own yet, apart
> from efibootmgr.
>

Ok thanks.

Looks like the setting gets cleared with every BIOS update. I assume this
is due to shitty coding by the MB manufacturer and not a limitation of UEFI.

Anyway i'm running the '1.0.0.3 ABBA' BIOS fine with my Zen2 now.

[-- Attachment #2: Type: text/html, Size: 1313 bytes --]

Re: [gentoo-user] Verify uefi installation

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Monday, 23 September 2019 08:43:52 BST Adam Carter wrote:
> On Mon, Sep 23, 2019 at 3:38 PM J. Roeleveld <joost@antarean.org> wrote:
> > On 23 September 2019 07:33:44 CEST, Adam Carter <adamcarter3@gmail.com>
> > 
> > wrote:
> > >Follow on question; what does efibootmgr actually modify? Is it writing
> > >to
> > >motherboard EEPROM values similar what happens when you write changes
> > >in
> > >the BIOS setup pages?
> > >If you, does mean I may have been able to fix this issue in the BIOS?
> > 
> > It updates something in the CMOS, however, not all UEFI bioses support
> > manually editing this.
> > I haven't found a decent option for this on any system I own yet, apart
> > from efibootmgr.
> 
> Ok thanks.
> 
> Looks like the setting gets cleared with every BIOS update. I assume this
> is due to shitty coding by the MB manufacturer and not a limitation of UEFI.

An update of the firmware flashes the UEFI EEPROM and as far as I have 
experienced no settings are retained.  A fresh probe of MoBo devices at first 
boot re-lists anything bootable.

Desktop/workstation UEFI firmware have more features, which allow tweaking 
boot lists.  Some also offer a back up/restore facility for settings from a 
file.

Laptop UEFI boot menus are more sparce, in which case efibootmgr, or with 
systemd-boot the bootctl command allow managing UEFI boot entries.  I believe 
MSWindows have their own applications to do the same.

Regarding the message "GUID partition table header signature is wrong", this 
is probably indicative of an MBR partition table - but I'm not sure.  Have you 
installed some OS on an MBR partition schema?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Verify uefi installation

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

>
> > Looks like the setting gets cleared with every BIOS update. I assume this
> > is due to shitty coding by the MB manufacturer and not a limitation of
> UEFI.
>
> An update of the firmware flashes the UEFI EEPROM and as far as I have
> experienced no settings are retained.


A backward step from older MBR / BIOS functionality then. I guess that
indicates that code and configuration are not separated.


> A fresh probe of MoBo devices at first boot re-lists anything bootable.
>

Do you find that the re-generated list only finds devices, not the .efi
files on those devices? (and therefore efibootmgr is still required?)


> Desktop/workstation UEFI firmware have more features, which allow tweaking
> boot lists.  Some also offer a back up/restore facility for settings from
> a
> file.
>
> Laptop UEFI boot menus are more sparce, in which case efibootmgr, or with
> systemd-boot the bootctl command allow managing UEFI boot entries.  I
> believe
> MSWindows have their own applications to do the same.
>

Ok thanks for the info.


> Regarding the message "GUID partition table header signature is wrong",
> this
> is probably indicative of an MBR partition table - but I'm not sure.  Have
> you
> installed some OS on an MBR partition schema?
>

# gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
<snip>
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1955839   954.0 MiB   EF00  boot
   2         1955840       976771071   464.8 GiB   8300  root

Not sure where the 'MBR: protective' came from as the system has been linux
only from the start. I guess its either the default or I made an error
during the build. AFAIK this is still a valid configuration, so I assume
the signature message is not related to that.

I guess i could just try re-writing the partition table to see if that
clears it.

[-- Attachment #2: Type: text/html, Size: 3005 bytes --]

Re: [gentoo-user] Verify uefi installation

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Tue, 24 Sep 2019 09:31:08 +1000, Adam Carter wrote:

> > An update of the firmware flashes the UEFI EEPROM and as far as I have
> > experienced no settings are retained.  
> 
> A backward step from older MBR / BIOS functionality then. I guess that
> indicates that code and configuration are not separated.

I recently updated a firmware and all worked as before, so I think this
is implementation-dependent.

> # gdisk -l /dev/nvme0n1
> GPT fdisk (gdisk) version 1.0.4
> 
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: present
> <snip>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048         1955839   954.0 MiB   EF00  boot
>    2         1955840       976771071   464.8 GiB   8300  root
> 
> Not sure where the 'MBR: protective' came from as the system has been
> linux only from the start. I guess its either the default or I made an
> error during the build. AFAIK this is still a valid configuration, so I
> assume the signature message is not related to that.
> 
> I guess i could just try re-writing the partition table to see if that
> clears it.

I've just checked a couple of systems that have never used MBR and they
say the same. I'd ignore that.


-- 
Neil Bothwick

If at first you don't succeed, you'll get a lot of free advice from
folks who didn't succeed either.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]