[gentoo-user] UEFI data corruption?

[gentoo-user] UEFI data corruption?

[Peter Humphrey]

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

Morning all,

Yesterday I found I couldn't boot this box. I use bootctl from systemd-boot to 
manage my boot partition (nothing else of systemd, though), and when I ran 
'bootctl install' after compiling a new kernel, I got strange error messages, 
and a new directory under /boot with (I think) a 24-digit hex number as a 
name. I brought efibootmgr up and found I had 30 entries in the boot list 
(from 00 to 1D), including several apparent duplicates of genuine entries.

The only way I found to clear up the mess was to write a new gpt partition 
table, re-create all the partitions and restore from backup.

Any idea what could have cause this? I've attached a gparted diagram of the 
disk layout in case it helps.

And is there a good way to clear the efi system partition, short of dd-ing a 
load of zeroes into it? Would that even have helped?

-- 
Regards,
Peter.

[-- Attachment #2: gparted.png --]
[-- Type: image/png, Size: 118092 bytes --]

Re: [gentoo-user] UEFI data corruption?

[Mick]

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

On Sunday, 15 September 2019 09:36:53 BST Peter Humphrey wrote:
> Morning all,
> 
> Yesterday I found I couldn't boot this box. I use bootctl from systemd-boot
> to manage my boot partition (nothing else of systemd, though), and when I
> ran 'bootctl install' after compiling a new kernel, I got strange error
> messages, and a new directory under /boot with (I think) a 24-digit hex
> number as a name. I brought efibootmgr up and found I had 30 entries in the
> boot list (from 00 to 1D), including several apparent duplicates of genuine
> entries.

What are/were the contents of the 24-digit hex named directory?  I don't use 
systemd-boot or bootctl to have first hand experience of what it does, but I 
thought I does not create new hex named directories to dump its files in.  It 
first goes to the ESP partition's mountpoint, typically /boot and copy in 
there /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI.  I 
don't know if it requires the ESP partition to have been mounted at the time, 
or if it is clever enough to auto-probe and mount it itself.  It also creates 
/boot/loader/loader.conf, copied from /usr/share/systemd/bootctl/loader.conf 
and finally /boot/loader/entries/*.conf for all the boot menu items.  I 
understand it will create configuration files for MSWindows boot loader(s) and 
for any Linux OS installations as long as it finds linux kernels listed under 
/boot/EFI/Linux/.  All of this is unnecessarily complicated for my use cases, 
TBH it even makes GRUB2 look simple, which is why I have avoided this 
particular systemd component and use efibootmgr manually to configure the boot 
menu.

Do you see any difference in the bootable kernels listed between 'bootctl 
list' and 'efibootmgr -v'

What do you see in the / filesystem when the ESP partition is *not* mounted?


> The only way I found to clear up the mess was to write a new gpt partition
> table, re-create all the partitions and restore from backup.

Were your partitions messed up, or only the ESP?  If the latter you could have 
recreated that alone and copied files over from a back up.


> Any idea what could have cause this? I've attached a gparted diagram of the
> disk layout in case it helps.

It may be the systemd-boot auto-magic does not detect an unmounted partition 
and it proceeds with spewing its goodness all over the / partition's 
filesystem - but I don't know much about systemd or its components.

> And is there a good way to clear the efi system partition, short of dd-ing a
> load of zeroes into it? Would that even have helped?

I would first run 'fsck.vfat -v /dev/nvme0n1p2' with the partition not mounted 
to see if there is any fs corruption.  If there is something wrong with its 
filesystem, I would simply reformat the partition with 'mkfs.vfat -v /dev/
nvme0n1p2' and rsync the contents back from a back up.

HTH.
-- 
Regards,

Mick

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

Re: [gentoo-user] UEFI data corruption?

[Peter Humphrey]

On Sunday, 15 September 2019 10:29:13 BST Mick wrote:

> What are/were the contents of the 24-digit hex named directory?

It was empty. Actually it was 32 digits.

> I don't use systemd-boot or bootctl to have first hand experience of what it
> does, but I thought I does not create new hex named directories to dump its
> files in.  It first goes to the ESP partition's mountpoint, typically /boot
> and copy in there /boot/EFI/systemd/systemd-bootx64.efi and
> /boot/EFI/BOOT/BOOTX64.EFI.  I don't know if it requires the ESP partition
> to have been mounted at the time, or if it is clever enough to auto-probe
> and mount it itself.  It also creates /boot/loader/loader.conf, copied from
> /usr/share/systemd/bootctl/loader.conf and finally
> /boot/loader/entries/*.conf for all the boot menu items.  I understand it
> will create configuration files for MSWindows boot loader(s) and for any
> Linux OS installations as long as it finds linux kernels listed under
> /boot/EFI/Linux/.  All of this is unnecessarily complicated for my use
> cases, TBH it even makes GRUB2 look simple, which is why I have avoided
> this particular systemd component and use efibootmgr manually to configure
> the boot menu.

Now you see, there seem to be two ways to arrange the esp and boot partitions. 
The gentoo wiki says to leave a small unpartitioned space for esp data, then 
create a vfat partition for /boot. That's what I did. Other people seem to 
have both functions served by the /boot partition. I think I tried that once 
but got snarled up somewhere.

> Do you see any difference in the bootable kernels listed between 'bootctl
> list' and 'efibootmgr -v'

I don't think so.

> What do you see in the / filesystem when the ESP partition is *not* mounted?

The ESP space is not a partition here.

> > The only way I found to clear up the mess was to write a new gpt partition
> > table, re-create all the partitions and restore from backup.
> 
> Were your partitions messed up, or only the ESP?  If the latter you could
> have recreated that alone and copied files over from a back up.

The ESP, plus one file in /boot:

# cat /boot/loader/loader.conf
#timeout 3
#console-mode keep
default 45b3c9f27eedd9ca60997b555d46f90d-*

It should have been this:

# cat boot/loader/loader.conf
default 30-gentoo-4.19.72
timeout 15

> > Any idea what could have cause this? I've attached a gparted diagram of
> > the disk layout in case it helps.
> 
> It may be the systemd-boot auto-magic does not detect an unmounted partition
> and it proceeds with spewing its goodness all over the / partition's
> filesystem - but I don't know much about systemd or its components.
> 
> > And is there a good way to clear the efi system partition, short of dd-ing
> > a load of zeroes into it? Would that even have helped?
> 
> I would first run 'fsck.vfat -v /dev/nvme0n1p2' with the partition not
> mounted to see if there is any fs corruption.  If there is something wrong
> with its filesystem, I would simply reformat the partition with 'mkfs.vfat
> -v /dev/ nvme0n1p2' and rsync the contents back from a back up.

First I need to decide which ESP and /boot arrangement to use from now on. 
Meanwhile, as I said before, I wrote a new GPT label, then created the 
partitions again and restored them from backup.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption?

[Neil Bothwick]

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

On Sun, 15 Sep 2019 23:26:47 +0100, Peter Humphrey wrote:

> Now you see, there seem to be two ways to arrange the esp and boot
> partitions. The gentoo wiki says to leave a small unpartitioned space
> for esp data, then create a vfat partition for /boot. That's what I
> did. Other people seem to have both functions served by the /boot
> partition. I think I tried that once but got snarled up somewhere.

I was under the impression that the ESP had to be a FAT partition. The
small unpartitioned space is for when you are using a GPT
partition table with a non-EFI bootloader. Well, it's really unformatted,
it is a partition.

That's how I do it on non-EFI systems, on UEFI machines, I always make
/boot a FAT partition and use it as the ESP too.


-- 
Neil Bothwick

[unwieldy legal disclaimer would go here - feel free to type your own]

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

Re: [gentoo-user] UEFI data corruption?

[Peter Humphrey]

On Monday, 16 September 2019 08:41:34 BST Neil Bothwick wrote:
> On Sun, 15 Sep 2019 23:26:47 +0100, Peter Humphrey wrote:
> > Now you see, there seem to be two ways to arrange the esp and boot
> > partitions. The gentoo wiki says to leave a small unpartitioned space
> > for esp data, then create a vfat partition for /boot. That's what I
> > did. Other people seem to have both functions served by the /boot
> > partition. I think I tried that once but got snarled up somewhere.
> 
> I was under the impression that the ESP had to be a FAT partition. The
> small unpartitioned space is for when you are using a GPT
> partition table with a non-EFI bootloader. Well, it's really unformatted,
> it is a partition.

Ah. I didn't appreciate that. Looks like I misinterpreted the wiki page (and I 
used to be able to read quite well, too.)

> That's how I do it on non-EFI systems, on UEFI machines, I always make
> /boot a FAT partition and use it as the ESP too.

I'll try that. Thanks Neil.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption?

[Mick]

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

On Sunday, 15 September 2019 23:26:47 BST Peter Humphrey wrote:
> On Sunday, 15 September 2019 10:29:13 BST Mick wrote:

> > What do you see in the / filesystem when the ESP partition is *not*
> > mounted?
> The ESP space is not a partition here.

I think we are confusing terms.  Your screenshot definitely shows a partition, 
/dev/nvme0n1p2 which is your ESP partition and is flagged as such by parted.  
The "small unpartitioned space" at the beginning of the disk is not a 
partition and should be left well alone. (see my next email response on a 
disambiguation of these two items).


> > > The only way I found to clear up the mess was to write a new gpt
> > > partition
> > > table, re-create all the partitions and restore from backup.
> > 
> > Were your partitions messed up, or only the ESP?  If the latter you could
> > have recreated that alone and copied files over from a back up.
> 
> The ESP, plus one file in /boot:
> 
> # cat /boot/loader/loader.conf
> #timeout 3
> #console-mode keep
> default 45b3c9f27eedd9ca60997b555d46f90d-*
> 
> It should have been this:
> 
> # cat boot/loader/loader.conf
> default 30-gentoo-4.19.72
> timeout 15
> 
> > > Any idea what could have cause this? I've attached a gparted diagram of
> > > the disk layout in case it helps.

OK, it seems the systemd-boot decided to create a directory 
45b3c9f27eedd9ca60997b555d46f90d-* within your ESP partition and expect to 
find the default OS kernel in this path.  I have no idea why it would do this.

It could be a bug related to systemd-boot, or something you ran, but some 
systemd user or dev should chime in as to what might have caused it.  My 
exposure to systemd is limited, I continue to find it awkward/unpleasant to 
use on binary distros.

-- 
Regards,

Mick

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

Re: [gentoo-user] UEFI data corruption?

[Wols Lists]

On 16/09/19 08:50, Peter Humphrey wrote:
>> > I was under the impression that the ESP had to be a FAT partition. The
>> > small unpartitioned space is for when you are using a GPT
>> > partition table with a non-EFI bootloader. Well, it's really unformatted,
>> > it is a partition.

> Ah. I didn't appreciate that. Looks like I misinterpreted the wiki page (and I 
> used to be able to read quite well, too.)
> 
Umm no ...

aiui, Macs don't have FAT partitions, but they still use EFI.

I had this discussion with someone who knew what they were talking
about, and the spec says that FAT is the "least common denominator" -
all EFI bootloaders must understand FAT. They can understand more, so if
a loader understands ext4 you could use that, but you know for certain
that if you use (a certain version of) FAT32, then things will work.

Macs understand HFS or whatever it is they use, so they don't need FAT.

Cheers,
Wol

Re: [gentoo-user] UEFI data corruption?

[Mick]

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

On Monday, 16 September 2019 08:50:37 BST Peter Humphrey wrote:
> On Monday, 16 September 2019 08:41:34 BST Neil Bothwick wrote:
> > On Sun, 15 Sep 2019 23:26:47 +0100, Peter Humphrey wrote:
> > > Now you see, there seem to be two ways to arrange the esp and boot
> > > partitions. The gentoo wiki says to leave a small unpartitioned space
> > > for esp data, then create a vfat partition for /boot. That's what I
> > > did. Other people seem to have both functions served by the /boot
> > > partition. I think I tried that once but got snarled up somewhere.

The "small unpartitioned space" starts at LBA 0 of the disk and is used to 
store an MBR table, which lists a single large partition for the whole disk 
starting at LBA 1.  By "large" I mean as large as an MBR can recognise, which 
is up to 2TB.  This "small unpartitioned space" is called and functions as a 
'GPT Protective MBR'.  Its purpose is to stop legacy disk partitioning tools, 
which have no concept of GPT partitioning schemes, from over-writing 
unknowingly the GPT partitioning tables and data.  Without this GPT Protective 
MBR, old disk partitioning tools would see an empty disk and proceed to 
partition it without warning.  With the GPT Protective MBR they will at least 
seek confirmation to delete one large partition of unknown type.

Unlike a 'GPT Protective MBR' which is not a partition, in the sense of not 
being specified anywhere in a partition table, the 'EFI System Partition' 
(ESP) is a ... partition.  :-)

It is specified along with other GPT partitions with a start and an end within 
the GUID Partition Table (GPT) of the disk.

So, the two items "small unpartitioned space" and ESP are not the same.  I'm 
not sure if they could be combined, but if they were, the GPT table which 
starts at LBA 1 will be referring to an ESP (partition) which is found 
somewhere within LBA 0, after the MBR table stored in there.  This sounds 
messy to me, from a logical perspective at least.


> > I was under the impression that the ESP had to be a FAT partition. The
> > small unpartitioned space is for when you are using a GPT
> > partition table with a non-EFI bootloader. Well, it's really unformatted,
> > it is a partition.
> 
> Ah. I didn't appreciate that. Looks like I misinterpreted the wiki page (and
> I used to be able to read quite well, too.)

Neil is partly right, the EFI System Partition (ESP) is a partition typically 
formatted with a FAT32 filesystem, where all the OS kernels and optionally 
boot loader files/firmware/microcode/drivers can be stored.  However, it is 
not a FAT32 partition *type*, or in GPT terminology a 'Microsoft Basic Data 
Partition', but an ESP partition type.  Upon its creation the ESP is set as 
partition type 'esp' (parted), or 'EFI System' (fdisk), or 'ef00' (gptfdisk).  
The partition type label for ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B.  On 
Linux it is mounted under the /boot mountpoint.

NOTE: On a disk which has been configured with a MBR partitioning scheme the 
ESP partition will be shown as partition type 'ef EFI (FAT-12/16/32)'


> > That's how I do it on non-EFI systems, on UEFI machines, I always make
> > /boot a FAT partition and use it as the ESP too.
> 
> I'll try that. Thanks Neil.

Hmm ... I think we're saying the same thing, but I may have lost the thread:

On non-UEFI systems I use an MBR partition table, create a partition and set 
it as Linux type (82), format it with ext2 and mount it under the /boot 
mountpoint.  Then drop my kernels in there and install the boot manager files 
(GRUB).  

On UEFI systems I create an ESP partition type, format it with a VFAT 
filesystem, then mount it under the /boot mountpoint.  Then drop my kernels in 
there (I use the efi kernel stub to boot directly these kernels, rather than a 
boot manager like GRUB).

Thinking about it, on legacy BIOS MoBos I've always used MBR partition tables, 
but I haven't installed one of those for some years now.  All current versions 
of linux disk managers use 4k sectors and leave the first sector empty, where 
the GPT Protective MBR table will be stored.  I think they will do the same, 
leave the first 4k sector empty, on a MBR partition scheme too and store the 
MBR partition table in there.  The older disk management tools used 512 byte 
sectors and only the first 512 bytes was used for the MBR tables.  So with a 
4K sector most of it will be left empty.

Anyway, I'm no authority on the above topics, just sharing my understanding.  
Please point out any errors as you find them.
-- 
Regards,

Mick

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

Re: [gentoo-user] UEFI data corruption?

[Neil Bothwick]

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

On Mon, 16 Sep 2019 13:05:23 +0100, Mick wrote:

> > > That's how I do it on non-EFI systems, on UEFI machines, I always
> > > make /boot a FAT partition and use it as the ESP too.  
> > 
> > I'll try that. Thanks Neil.  
> 
> Hmm ... I think we're saying the same thing, but I may have lost the
> thread:
> 
> On non-UEFI systems I use an MBR partition table, create a partition
> and set it as Linux type (82), format it with ext2 and mount it under
> the /boot mountpoint.  Then drop my kernels in there and install the
> boot manager files (GRUB).  

I use a GPT table even on non-EFI systems, because it is inherently more
robust than a DOS partition table, thanks to the backup copy of the table
stored on the disk. That in turn requires the protective MBR layer.
 
> On UEFI systems I create an ESP partition type, format it with a VFAT 
> filesystem, then mount it under the /boot mountpoint.  Then drop my
> kernels in there (I use the efi kernel stub to boot directly these
> kernels, rather than a boot manager like GRUB).

Same here for the first part, but I do use a boot manager because it
makes it easier to, well, manage the boot. I use the systemd boot
manager, I previously used it in its standalone incarnation, but I can't
remember the name right now. This is a simple boot manager, a 2 line
default config file and another 3 lines for each kernel (fewer if you
don't use an initramfs). All it does is manage the kernels, it is not a
full-blown bootloader like GRUB.


-- 
Neil Bothwick

Life is a sexually transmitted disease and the mortality rate is 100%.

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

Re: [gentoo-user] UEFI data corruption?

[Peter Humphrey]

On Monday, 16 September 2019 12:37:15 BST Mick wrote:
> On Sunday, 15 September 2019 23:26:47 BST Peter Humphrey wrote:
> > On Sunday, 15 September 2019 10:29:13 BST Mick wrote:
> > > What do you see in the / filesystem when the ESP partition is *not*
> > > mounted?
> > 
> > The ESP space is not a partition here.
> 
> I think we are confusing terms.  Your screenshot definitely shows a
> partition, /dev/nvme0n1p2 which is your ESP partition and is flagged as
> such by parted. The "small unpartitioned space" at the beginning of the
> disk is not a partition and should be left well alone. (see my next email
> response on a disambiguation of these two items).

You're right, of course. It is a partition, just left empty. My mistake.

--->8

> OK, it seems the systemd-boot decided to create a directory
> 45b3c9f27eedd9ca60997b555d46f90d-* within your ESP partition and expect to
> find the default OS kernel in this path.  I have no idea why it would do
> this.

Me neither.

> It could be a bug related to systemd-boot, or something you ran, but some
> systemd user or dev should chime in as to what might have caused it.  My
> exposure to systemd is limited, I continue to find it awkward/unpleasant to
> use on binary distros.

I'm sure I didn't do anything to the efi. I was rebooting after a daily update 
that needed restarts of several boot and sysinit services. I was surprised 
when, instead of showing the efi boot menu, the system launched into some kind 
of kernel that didn't have the necessary drivers, and stopped in a panic. 
That's when the fun began.

The only initramfses are early_ucode.cpio and intel-uc.img.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [SOLVED, mostly]

[Peter Humphrey]

On Tuesday, 17 September 2019 07:23:10 BST Peter Humphrey wrote:

Well, it seems to be working now - mostly.

The fix was to write a new gpt label, create all the partitions and build a 
new system: no use of earlier packages. User data came from backups.

Meanwhile, I used bootctl and efibootmgr to create and delete boot entries in 
the efi data until I finished up with this arrangement:

# bootctl
systemd-boot not installed in ESP.		<---- Note 1
System:
     Firmware: UEFI 2.31 (American Megatrends 5.09)
  Secure Boot: disabled
   Setup Mode: user

Current Boot Loader:
      Product: systemd-boot 243
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
          ESP: /dev/disk/by-partuuid/95b0a3f6-eae2-445c-b098-3c8174588948
         File: └─/EFI/BOOT/BOOTX64.EFI

Random Seed:
 Passed to OS: no
 System Token: not set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/95b0a3f6-eae2-445c-
b098-3c8174588948)
         File: └─/EFI/BOOT/bootX64.efi (systemd-boot 243)

Boot Loaders Listed in EFI Variables:
        Title: EFI Stub			<---- Note 2
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/95b0a3f6-eae2-445c-b098-3c8174588948
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/95b0a3f6-eae2-445c-
b098-3c8174588948)

Default Boot Loader Entry:
        title: Gentoo Linux 4.19.72		<---- Note 3
           id: 30-gentoo-4.19.72
       source: /boot/loader/entries/30-gentoo-4.19.72.conf
        linux: /vmlinuz-4.19.72-gentoo
      options: root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0

Note 1:	I still can't 'bootctl install' without causing the damage I've 
described already. The system does boot though.

Note 2:	I've tried to change this with 'efibootmgr -b 00 -L "Gentoo Linux"', 
to no avail. It does nothing I can see.

Note 3:	This title comes from the file named two lines later; it has nothing 
to do with the Title of Note 2.

Furthermore, when the default entry starts, I see 'SHA256 verified' in the 
upper left corner of the EFI BIOS display area, until the kernel takes the 
terminal over.

Oh, and I deleted the unused directory (by me) /boot/EFI/systemd.

So: solved, mostly. I still don't know what has changed though.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [SOLVED, mostly]

[Mick]

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

On Wednesday, 18 September 2019 09:43:11 BST Peter Humphrey wrote:
> On Tuesday, 17 September 2019 07:23:10 BST Peter Humphrey wrote:
> 
> Well, it seems to be working now - mostly.
> 
> The fix was to write a new gpt label, create all the partitions and build a
> new system: no use of earlier packages. User data came from backups.

This sounds too drastic a repair procedure, unless the GPT table entries 
themselves were corrupted, but ... whatever works.  :-)


> Meanwhile, I used bootctl and efibootmgr to create and delete boot entries
> in the efi data until I finished up with this arrangement:
> 
> # bootctl
> systemd-boot not installed in ESP.		<---- Note 1
> System:
>      Firmware: UEFI 2.31 (American Megatrends 5.09)
>   Secure Boot: disabled
>    Setup Mode: user

If you are not using systemd-boot, is bootctl of any use vis-à-vis the 
efibootmgr command?


> Current Boot Loader:
>       Product: systemd-boot 243
>      Features: ✓ Boot counting
>                ✓ Menu timeout control
>                ✓ One-shot menu timeout control
>                ✓ Default entry control
>                ✓ One-shot entry control
>                ✓ Support for XBOOTLDR partition
>                ✓ Support for passing random seed to OS
>           ESP: /dev/disk/by-partuuid/95b0a3f6-eae2-445c-b098-3c8174588948
>          File: └─/EFI/BOOT/BOOTX64.EFI
> 
> Random Seed:
>  Passed to OS: no
>  System Token: not set
>        Exists: yes
> 
> Available Boot Loaders on ESP:
>           ESP: /boot (/dev/disk/by-partuuid/95b0a3f6-eae2-445c-
> b098-3c8174588948)
>          File: └─/EFI/BOOT/bootX64.efi (systemd-boot 243)
> 
> Boot Loaders Listed in EFI Variables:
>         Title: EFI Stub			<---- Note 2
>            ID: 0x0000
>        Status: active, boot-order
>     Partition: /dev/disk/by-partuuid/95b0a3f6-eae2-445c-b098-3c8174588948
>          File: └─/EFI/BOOT/BOOTX64.EFI
> 
> Boot Loader Entries:
>         $BOOT: /boot (/dev/disk/by-partuuid/95b0a3f6-eae2-445c-
> b098-3c8174588948)
> 
> Default Boot Loader Entry:
>         title: Gentoo Linux 4.19.72		<---- Note 3
>            id: 30-gentoo-4.19.72
>        source: /boot/loader/entries/30-gentoo-4.19.72.conf
>         linux: /vmlinuz-4.19.72-gentoo
>       options: root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
> 
> Note 1:	I still can't 'bootctl install' without causing the damage I've
> described already. The system does boot though.

Perhaps bootctl is now meant to operate (without breaking things) with 
systemd-boot fully installed and configured.  If you're not using systemd-boot 
it tries to be too clever by half.


> Note 2:	I've tried to change this with 'efibootmgr -b 00 -L "Gentoo 
Linux"',
> to no avail. It does nothing I can see.

I think --label can only be specified when you --create a new entry in the 
UEFI boot menu.  If there is an entry already present, I think you cannot 
modify it.  When I get things wrong at menu entry creation time, I delete the 
whole entry and reconstitute it afresh.


> Note 3:	This title comes from the file named two lines later; it has 
nothing
> to do with the Title of Note 2.

Hmm ... I wonder what bootctl reads to populate its "title:" field.  Would you 
care to share the output of:

efibootmgr -v

-- 
Regards,

Mick

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

Re: [gentoo-user] UEFI data corruption? [SOLVED, mostly]

[Peter Humphrey]

On Wednesday, 18 September 2019 14:20:11 BST Mick wrote:
> On Wednesday, 18 September 2019 09:43:11 BST Peter Humphrey wrote:
> > On Tuesday, 17 September 2019 07:23:10 BST Peter Humphrey wrote:
> > 
> > Well, it seems to be working now - mostly.
> > 
> > The fix was to write a new gpt label, create all the partitions and build
> > a new system: no use of earlier packages. User data came from backups.
> 
> This sounds too drastic a repair procedure, unless the GPT table entries
> themselves were corrupted, but ... whatever works.  :-)

Yes, it is, but by this time I had no confidence in my ability to patch over 
the holes, nor in the system doing as I expected. It seemed time for drastic 
measures.

> > Meanwhile, I used bootctl and efibootmgr to create and delete boot entries
> > in the efi data until I finished up with this arrangement:
> > 
> > # bootctl
> > systemd-boot not installed in ESP.		<---- Note 1
> > 
> > System:
> >      Firmware: UEFI 2.31 (American Megatrends 5.09)
> >   Secure Boot: disabled
> >    Setup Mode: user
> 
> If you are not using systemd-boot, is bootctl of any use vis-à-vis the
> efibootmgr command?

It's simpler to operate, I think, and it's been good enough for me up to now.

--->8

> Perhaps bootctl is now meant to operate (without breaking things) with
> systemd-boot fully installed and configured.  If you're not using
> systemd-boot it tries to be too clever by half.

But I haven't seen any version changes in anything relevant to this.

> > Note 2:	I've tried to change this with 'efibootmgr -b 00 -L "Gentoo
> Linux"',
> 
> > to no avail. It does nothing I can see.
> 
> I think --label can only be specified when you --create a new entry in the
> UEFI boot menu.  If there is an entry already present, I think you cannot
> modify it.  When I get things wrong at menu entry creation time, I delete
> the whole entry and reconstitute it afresh.

Ah, now why would the man page not say this?

> > Note 3:	This title comes from the file named two lines later; it has
> nothing to do with the Title of Note 2.
> 
> Hmm ... I wonder what bootctl reads to populate its "title:" field.  Would
> you care to share the output of:
> 
> efibootmgr -v

Taken just now, at 16:25 GMT:

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002
Boot0000* EFI Stub      HD(1,GPT,95b0a3f6-eae2-445c-
b098-3c8174588948,0x800,0x7f800)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0001* CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........o.T.S.S.T.c.o.r.p. 
.C.D.D.V.D.W. .S.N.-.
2.0.8.F.B....................A...........................>..Gd-.;.A..MQ..L.
1.S.3.2.Y.6.G.B.0.C.B.0.G.K. . . . . . ........BO
Boot0002* Hard Drive    BBS(HD,,0x0)..GO..NO........o.C.T.1.0.0.0.B.X.
1.0.0.S.S.D.
1....................A...........................>..Gd-.;.A..MQ..L.
5.1.4.0.0.F.2.0.8.3.4.6. . . . . . . . ........BO..NO........o.C.T.
1.0.0.0.B.X.1.0.0.S.S.D.
1....................A...........................>..Gd-.;.A..MQ..L.
5.1.4.0.0.F.2.0.8.3.F.8. . . . . . . . ........BO..NO..........S.A.M.S.U.N.G. 
.M.Z.V.P.V.2.5.6.H.D.G.L.-.
0.0.0.0.0....................A.......................................J..Gd-.;.A..MQ..L.S.A.M.S.U.N.G. 
.M.Z.V.P.V.2.5.6.H.D.G.L.-.0.0.0.0.0........BO

Is that the sort of thing you were expecting? I can't say it means much to me.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [SOLVED, mostly]

[Mick]

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

On Wednesday, 18 September 2019 17:26:25 BST Peter Humphrey wrote:
> On Wednesday, 18 September 2019 14:20:11 BST Mick wrote:

> > I think --label can only be specified when you --create a new entry in the
> > UEFI boot menu.  If there is an entry already present, I think you cannot
> > modify it.  When I get things wrong at menu entry creation time, I delete
> > the whole entry and reconstitute it afresh.
> 
> Ah, now why would the man page not say this?

Indeed.  I could be wrong how the 'efibootmgr --bootnum' is meant to work, but 
I share your experience with it, namely it doesn't seem to work with '--
label', but works with '--delete-bootnum'.


> > Hmm ... I wonder what bootctl reads to populate its "title:" field.  Would
> > you care to share the output of:
> > 
> > efibootmgr -v
> 
> Taken just now, at 16:25 GMT:
> 
> # efibootmgr -v
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000,0001,0002
> Boot0000* EFI Stub      HD(1,GPT,95b0a3f6-eae2-445c-
> b098-3c8174588948,0x800,0x7f800)/File(\EFI\BOOT\BOOTX64.EFI)

Boot0000 above is the first menu entry.

"EFI Stub" is the label of this entry.

Thereafter you can see the path of the bootable entry:

HD - it is a hard drive
1  - on the first partition
GTP - using a GPT partitioning schema
95b0a3f6-* - the UUID of the partition (not the fs)
0x800,0x7f800 - start-end of the partition in hex
File - the filesystem path of the bootable image.


> Boot0001* CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........o.T.S.S.T.c.o.r.p.
> .C.D.D.V.D.W. .S.N.-.
> 2.0.8.F.B....................A...........................>..Gd-.;.A..MQ..L.
> 1.S.3.2.Y.6.G.B.0.C.B.0.G.K. . . . . . ........BO

Boot0001 is the second boot entry and is a CD/DVD drive.  It seems you have a 
CD in it, without it you would probably see something like this:

Boot0001* UEFI:CD/DVD Drive	BBS(129,,0x0)


> Boot0002* Hard Drive    BBS(HD,,0x0)..GO..NO........o.C.T.1.0.0.0.B.X.
> 1.0.0.S.S.D.
> 1....................A...........................>..Gd-.;.A..MQ..L.
> 5.1.4.0.0.F.2.0.8.3.4.6. . . . . . . . ........BO..NO........o.C.T.
> 1.0.0.0.B.X.1.0.0.S.S.D.
> 1....................A...........................>..Gd-.;.A..MQ..L.
> 5.1.4.0.0.F.2.0.8.3.F.8. . . . . . . .
> ........BO..NO..........S.A.M.S.U.N.G. .M.Z.V.P.V.2.5.6.H.D.G.L.-.
> 0.0.0.0.0....................A.......................................J..Gd-.
> ;.A..MQ..L.S.A.M.S.U.N.G. .M.Z.V.P.V.2.5.6.H.D.G.L.-.0.0.0.0.0........BO

Boot0002 is the final entry by the looks of it refers to a Samsung SSD.


> Is that the sort of thing you were expecting? I can't say it means much to
> me.

Yes, from what I see above there is only one label, "EFI Stub", corresponding 
to the first bootable entry of the menu.  You can contact me off-list if you 
want help stringing the efibootmgr syntax, to create/delete entries in your 
boot menu.  It may help future recovery exercises of your ESP in the future, 
without having to recreate partition tables, partitions and filesystems.
-- 
Regards,

Mick

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

Re: [gentoo-user] UEFI data corruption? [SOLVED, mostly]

[Peter Humphrey]

On Wednesday, 18 September 2019 19:31:10 BST Mick wrote:

> > # efibootmgr -v
> > BootCurrent: 0000
> > Timeout: 1 seconds
> > BootOrder: 0000,0001,0002
> > Boot0000* EFI Stub      HD(1,GPT,95b0a3f6-eae2-445c-
> > b098-3c8174588948,0x800,0x7f800)/File(\EFI\BOOT\BOOTX64.EFI)
> 
> Boot0000 above is the first menu entry.
> 
> "EFI Stub" is the label of this entry.

And it's the label I wanted to change to something more descriptive.

> Thereafter you can see the path of the bootable entry:
> 
> HD - it is a hard drive
> 1  - on the first partition
> GTP - using a GPT partitioning schema
> 95b0a3f6-* - the UUID of the partition (not the fs)
> 0x800,0x7f800 - start-end of the partition in hex
> File - the filesystem path of the bootable image.
> 
> > Boot0001* CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........o.T.S.S.T.c.o.r.p.
> > .C.D.D.V.D.W. .S.N.-.
> > 2.0.8.F.B....................A...........................>..Gd-.;.A..MQ..L
> > .
> > 1.S.3.2.Y.6.G.B.0.C.B.0.G.K. . . . . . ........BO
> 
> Boot0001 is the second boot entry and is a CD/DVD drive.  It seems you have
> a CD in it, without it you would probably see something like this:
> 
> Boot0001* UEFI:CD/DVD Drive	BBS(129,,0x0)
> 
> > Boot0002* Hard Drive    BBS(HD,,0x0)..GO..NO........o.C.T.1.0.0.0.B.X.
> > 1.0.0.S.S.D.
> > 1....................A...........................>..Gd-.;.A..MQ..L.
> > 5.1.4.0.0.F.2.0.8.3.4.6. . . . . . . . ........BO..NO........o.C.T.
> > 1.0.0.0.B.X.1.0.0.S.S.D.
> > 1....................A...........................>..Gd-.;.A..MQ..L.
> > 5.1.4.0.0.F.2.0.8.3.F.8. . . . . . . .
> > ........BO..NO..........S.A.M.S.U.N.G. .M.Z.V.P.V.2.5.6.H.D.G.L.-.
> > 0.0.0.0.0....................A.......................................J..Gd
> > -. ;.A..MQ..L.S.A.M.S.U.N.G.
> > .M.Z.V.P.V.2.5.6.H.D.G.L.-.0.0.0.0.0........BO

Actually, there was no CD in the drive.

> Boot0002 is the final entry by the looks of it refers to a Samsung SSD.

Yes, it's the NVMe drive where the system resides. There are two other SSDs, 
but I deleted their entries because they weren't required to boot.

--->8

Many thanks Mick.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Peter Humphrey]

...

Right. After spending most of the last 10 days and some nights wrestling with 
the beast, I've got it fixed at last.

The Gentoo Handbook says to create a small unformatted partition at the 
beginning of the (primary?) disk, then to create a FAT-32 partition for /boot, 
then whatever other partitions are required.

Neil said above that he doesn't do that; he omits the unformatted partition, 
and I believe that's quite popular. I tried following the same scheme, but 
that's what caused the difficulties I started this thread with: on this system 
I need both those partitions. The system will not boot without both of them. 
[1]

The screen-shot of gparted I posted above shows the current layout once again.

The handbook's description of partition creation on a UEFI system says to set 
the bios_grub flag on partition 1 and the boot flag on partition 2. I tried 
setting them both on the combined partition I was trying to get working, but 
the second one to be set cleared the first one, or else it just hid it from 
display. Either way, no boot.

I found several other apparently authoritative pages detailing other /boot 
directory structures and file names; guessing which of them might work in any 
given case is not straightforward. Googling for "Gentoo EFI" or similar 
returns a list of them.

For the record, this motherboard is an Asus X99-A, with UEFI BIOS 2.16.1242.

It's interesting that, whenever the system failed to boot (and that often 
happened without showing me the boot selection menu) apparently the BIOS 
started the kernel stored in its data area, but it didn't find /boot/loader/ 
with its config files, so it didn't know where to look for the real kernel 
image.

I still don't know what started this whole adventure (to coin a phrase); my 
DVI KVM switch came under suspicion at one stage, so I'll keep a wary eye on 
it.

One remaining question: does it matter what kernel image is stored in UEFI 
data? I'm tempted to think not: it just has to get the initial boot step 
started. After that, /sbin/init "pivots" (whatever that means) to the real 
kernel under /boot.

1.   I remember, dimly, that while commissioning this machine from new, I had 
trouble installing and running grub:2. I knew even less about UEFI systems 
then, so if I were to try it again now I might find a way. But I hate the damn 
thing, so as long as I don't need it it's not getting near my machines.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Neil Bothwick]

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

On Tue, 24 Sep 2019 09:50:44 +0100, Peter Humphrey wrote:

> The Gentoo Handbook says to create a small unformatted partition at the 
> beginning of the (primary?) disk, then to create a FAT-32 partition for
> /boot, then whatever other partitions are required.
> 
> Neil said above that he doesn't do that; he omits the unformatted
> partition, and I believe that's quite popular. I tried following the
> same scheme, but that's what caused the difficulties I started this
> thread with: on this system I need both those partitions. The system
> will not boot without both of them. [1]

[snip]

> 1.   I remember, dimly, that while commissioning this machine from new,
> I had trouble installing and running grub:2. I knew even less about
> UEFI systems then, so if I were to try it again now I might find a way.
> But I hate the damn thing, so as long as I don't need it it's not
> getting near my machines.

I thought you were using systemd-boot, not GRUB? GRUB may need the
protected MBR space, but I only use GRUB on non-UEFI systems, where the
blank partition is needed with GPT partitioning.


-- 
Neil Bothwick

It may be that your sole purpose in life is simply to serve as a
warning to others.

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Peter Humphrey]

On Tuesday, 24 September 2019 19:01:27 BST Neil Bothwick wrote:
> On Tue, 24 Sep 2019 09:50:44 +0100, Peter Humphrey wrote:

> > 1.   I remember, dimly, that while commissioning this machine from new,
> > I had trouble installing and running grub:2. I knew even less about
> > UEFI systems then, so if I were to try it again now I might find a way.
> > But I hate the damn thing, so as long as I don't need it it's not
> > getting near my machines.
> 
> I thought you were using systemd-boot, not GRUB? GRUB may need the
> protected MBR space, but I only use GRUB on non-UEFI systems, where the
> blank partition is needed with GPT partitioning.

Indeed I am not using grub. This reference was an aside - a literal footnote - 
a memory from 3.5 years ago when I was setting up a new machine and trying to 
get it to boot. And failing, with grub. Since then, no grub on UEFI systems 
here.

-- 
Regards,
Peter.

[gentoo-user] Re: UEFI data corruption? [FIXED]

[Ian Zimmerman]

On 2019-09-24 09:50, Peter Humphrey wrote:

> The Gentoo Handbook says to create a small unformatted partition at
> the beginning of the (primary?) disk, then to create a FAT-32
> partition for /boot, then whatever other partitions are required.

Does /boot really have to be a FAT partition, and not ext[234]?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [EXTERNAL] [gentoo-user] Re: UEFI data corruption? [FIXED]

[Laurence Perkins]

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



On Wed, 2019-09-25 at 11:19 -0700, Ian Zimmerman wrote:
> On 2019-09-24 09:50, Peter Humphrey wrote:
> 
> > The Gentoo Handbook says to create a small unformatted partition at
> > the beginning of the (primary?) disk, then to create a FAT-32
> > partition for /boot, then whatever other partitions are required.
> 
> Does /boot really have to be a FAT partition, and not ext[234]?
> 
No.  But it can simplify things.

The UEFI standard requires that boards support FAT32.  They may or may
not support other filesystems at the manufacturer's discretion.

You can have /boot be one partition and /boot/efi be a different one if
you want.  But whatever you're using for an EFI partition needs to be a
filesystem that your board's firmware can read.  FAT32 is part of the
spec, some boards will also read NTFS.  I haven't personally seen any
that will read the ext family, but that doesn't mean they don't exist.

LMP

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Peter Humphrey]

On Tuesday, 24 September 2019 09:50:44 BST I wrote:

> The Gentoo Handbook says to create a small unformatted partition at the
> beginning of the (primary?) disk, then to create a FAT-32 partition for
> /boot, then whatever other partitions are required.

Another question answered: yes, it has to be the primary disk. I installed a 
small test system on another disk. It has its own FAT-32 /boot partition, in 
which I set up a similar directory structure to the main system's. Efibootmgr 
still insisted on adding the UEFI entry to the main set, in spite of my 
telling it to use the secondary disk. And the BIOS couldn't see the image on 
the secondary disk.

The conclusion is that, at least on this motherboard, there is precisely one 
set of UEFI boot images, and it lives on the primary disk of the system. Well, 
I haven't yet worked out how much of it is on the disk and how much in BIOS 
storage. The point remains, however, that I can't spread boot images over 
several disks.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Adam Carter]

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

>
> > The Gentoo Handbook says to create a small unformatted partition at the
> > beginning of the (primary?) disk, then to create a FAT-32 partition for
> > /boot, then whatever other partitions are required.
>
> Another question answered: yes, it has to be the primary disk. I installed
> a
> small test system on another disk. It has its own FAT-32 /boot partition,
> in
> which I set up a similar directory structure to the main system's.
> Efibootmgr
> still insisted on adding the UEFI entry to the main set, in spite of my
> telling it to use the secondary disk. And the BIOS couldn't see the image
> on
> the secondary disk.
>

I found my BIOS didn't recognise the UEFI setup until it was
specified/setup by efibootmgr, so that checks out. What was the efibootmgr
command you were using for the second disk?

The conclusion is that, at least on this motherboard, there is precisely
> one
> set of UEFI boot images, and it lives on the primary disk of the system.
> Well,
> I haven't yet worked out how much of it is on the disk and how much in
> BIOS
> storage. The point remains, however, that I can't spread boot images over
> several disks.
>

That's pretty poor.

What does efibootmgr show?

I got the impression that I would be able to UEFI boot from multiple
different devices, eg a USB drive with UEFI as well as the hard disk.

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Adam Carter]

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

>
> I got the impression that I would be able to UEFI boot from multiple
> different devices, eg a USB drive with UEFI as well as the hard disk.
>

FYI, after rebooting with the USB drive in;

 # efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0001,0003,0002
Boot0000* Gentoo <- this is the UEFI booted OS
Boot0001* Hard Drive <- this the same drive as Boot0000, but IIRC fails to
boot
Boot0002* Network Card
Boot0003* USB HDD <- this is the same device as Boot0004
Boot0004* UEFI:  Patriot Memory PMAP, Partition 1

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Peter Humphrey]

On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote:
> > > The Gentoo Handbook says to create a small unformatted partition at the
> > > beginning of the (primary?) disk, then to create a FAT-32 partition for
> > > /boot, then whatever other partitions are required.
> > 
> > Another question answered: yes, it has to be the primary disk. I installed
> > a small test system on another disk. It has its own FAT-32 /boot
> > partition, in which I set up a similar directory structure to the main
> > system's. Efibootmgr still insisted on adding the UEFI entry to the main
> > set, in spite of my telling it to use the secondary disk. And the BIOS
> > couldn't see the image on the secondary disk.
> 
> I found my BIOS didn't recognise the UEFI setup until it was
> specified/setup by efibootmgr, so that checks out. What was the efibootmgr
> command you were using for the second disk?

efibootmgr -c -p 3 -d /dev/sda -L "TestSys" -l '\EFI\BOOT\bootX64.efi'

> > The conclusion is that, at least on this motherboard, there is precisely
> > one set of UEFI boot images, and it lives on the primary disk of the
> > system. Well, I haven't yet worked out how much of it is on the disk and
> > how much in BIOS storage. The point remains, however, that I can't spread
> > boot images over several disks.
> 
> That's pretty poor.

It isn't what I expected either.

> What does efibootmgr show?

# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0005,0001,0002,0003,0006,0007,0008,0009,000A,000B
Boot0000* Gentoo Linux
Boot0001* UEFI:CD/DVD Drive
Boot0002* UEFI:Removable Device
Boot0003* UEFI:Network Device
Boot0004* CD/DVD Drive 
Boot0005  Hard Drive 
Boot0006* UEFI:CD/DVD Drive
Boot0007* UEFI:Removable Device
Boot0008* UEFI:Network Device
Boot0009* UEFI:CD/DVD Drive
Boot000A* UEFI:Removable Device
Boot000B* UEFI:Network Device

I'll delete all those duplicates. I don't know what's creating them. It's 
happened a few times since this mess started, but I never saw it once before 
then.

> I got the impression that I would be able to UEFI boot from multiple
> different devices, eg a USB drive with UEFI as well as the hard disk.

Oh yes, removable devices can be booted, but not secondary, internal hard 
drives. Apparently. On this system. Today.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Mick]

On Thu, 26 Sep 2019 at 15:47, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote:
> > > > The Gentoo Handbook says to create a small unformatted partition at the
> > > > beginning of the (primary?) disk, then to create a FAT-32 partition for
> > > > /boot, then whatever other partitions are required.

Strictly speaking the FAT32 partition is the ESP, which is typically
mounted under /boot and it should be marked with the corresponding ESP
GUID.  As I mentioned before, the initial disk space (rather than
partition) starting at LBA0 contains either a legacy MBR with its time
honoured 4 partition table, or a Protective MBR containing a fake
single whole-disk partition in its table.  Either the legacy MBR or
Protective MBR blocks are not processed by the UEFI firmware, which
goes to LBA1 and reads the GPT tables to find the ESP.  Therefore, it
is not clear to me why a small empty partition might be necessary at
the start of the disk, unless earlier versions of partitioning tools
were not as clever and started at LBA0, or some some weird UEFI
firmware implementations were devised by some OEMs.


> > > Another question answered: yes, it has to be the primary disk. I installed
> > > a small test system on another disk. It has its own FAT-32 /boot
> > > partition, in which I set up a similar directory structure to the main
> > > system's. Efibootmgr still insisted on adding the UEFI entry to the main
> > > set, in spite of my telling it to use the secondary disk. And the BIOS
> > > couldn't see the image on the secondary disk.

I believe you'll need a bootloader to jump to different disks.  I
don't think the UEFI firmware in its current version can handle more
than one ESP in any number of drives.  Some OS auto-scripted
installation media will fail if the same disk has two FAT32 partitions
marked as ESP (e.g. Windows 7).


> > I found my BIOS didn't recognise the UEFI setup until it was
> > specified/setup by efibootmgr, so that checks out. What was the efibootmgr
> > command you were using for the second disk?
>
> efibootmgr -c -p 3 -d /dev/sda -L "TestSys" -l '\EFI\BOOT\bootX64.efi'

Did you try specifying the disk device before the partition?

efibootmgr -c -d /dev/sdXX -p 3 .....

to see if it is recognised then?


> > > The conclusion is that, at least on this motherboard, there is precisely
> > > one set of UEFI boot images, and it lives on the primary disk of the
> > > system. Well, I haven't yet worked out how much of it is on the disk and
> > > how much in BIOS storage. The point remains, however, that I can't spread
> > > boot images over several disks.
> >
> > That's pretty poor.
>
> It isn't what I expected either.

The UEFI firmware implementation (should) follow its specification,
which has evolved over time. The specification mentions OS boot
loaders, or kernels, or EFI applications, should be stored within EFI/
subdirectories, one per vendor.  The EFI/ directory itself must be at
the root of the ESP filesystem.  Each OS subdirectory must contain
only one bootable image, or the boot behaviour for the system won't be
deterministic. [1]

There may be an EFI/BOOT/ subdirectory in which a recovery bootable
image can be stored.  This will be used if other OS' images fail to
boot.

With removable media the directory structure is slightly different.
All bootable images (one per supported arch) should be stored under
EFI/BOOT/.  This will ensure the removable device will boot
automatically.  Additional UEFI executables must be in directories
other than BOOT/.

The moment you start deviating from the above you need to manually
edit the boot menu with e.g. efibootmgr.  It used to be the case only
the primary disk was used/usable by the UEFI firmware and only one
ESP.  Later versions of the specification say they may cater for more
flexible ESP arrangements in the future.  The older the OEM UEFI
implementation the less flexible it would be.

> > What does efibootmgr show?
>
> # efibootmgr
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000,0004,0005,0001,0002,0003,0006,0007,0008,0009,000A,000B
> Boot0000* Gentoo Linux
> Boot0001* UEFI:CD/DVD Drive
> Boot0002* UEFI:Removable Device
> Boot0003* UEFI:Network Device
> Boot0004* CD/DVD Drive
> Boot0005  Hard Drive
> Boot0006* UEFI:CD/DVD Drive
> Boot0007* UEFI:Removable Device
> Boot0008* UEFI:Network Device
> Boot0009* UEFI:CD/DVD Drive
> Boot000A* UEFI:Removable Device
> Boot000B* UEFI:Network Device
>
> I'll delete all those duplicates. I don't know what's creating them. It's
> happened a few times since this mess started, but I never saw it once before
> then.

The UEFI firmware can also use the Simple File System Protocol, if the
disk supports it.  In this case, it will scan the GPT, jump to the
root of a partition and read bootable files on it.  Then it will
populate its boot menu with them.  Presently this will only work with
FAT(12/16/32) fs formats.  Some of the duplicates may have been
created in this fashion.


> > I got the impression that I would be able to UEFI boot from multiple
> > different devices, eg a USB drive with UEFI as well as the hard disk.

I may be wrong, but I don't think this is possible (yet?).  You could
use a secondary bootloader, e.g. GRUB, other than the UEFI firmware to
load OS kernels wherever they might be positioned on the system.

> Oh yes, removable devices can be booted, but not secondary, internal hard
> drives. Apparently. On this system. Today.
>
> --
> Regards,
> Peter.


[1] https://uefi.org/specifications

-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Peter Humphrey]

On Thursday, 26 September 2019 16:44:10 BST Mick wrote:
> On Thu, 26 Sep 2019 at 15:47, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote:

[Snip interesting stuff]

> > > I got the impression that I would be able to UEFI boot from multiple
> > > different devices, eg a USB drive with UEFI as well as the hard disk.
> 
> I may be wrong, but I don't think this is possible (yet?).  You could
> use a secondary bootloader, e.g. GRUB, other than the UEFI firmware to
> load OS kernels wherever they might be positioned on the system.

But see next:

> > Oh yes, removable devices can be booted, but not secondary, internal hard
> > drives. Apparently. On this system. Today.

I can boot from USB or CD drives by entering the UEFI BIOS at boot and 
selecting the one I want to boot from - and this BIOS dates from 2014. I doubt 
this is unusual.

> [1] https://uefi.org/specifications

I'll go and look - thanks Mick.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Mick]

On Fri, 27 Sep 2019 at 09:13, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Thursday, 26 September 2019 16:44:10 BST Mick wrote:
> > On Thu, 26 Sep 2019 at 15:47, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > > On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote:
>
> [Snip interesting stuff]
>
> > > > I got the impression that I would be able to UEFI boot from multiple
> > > > different devices, eg a USB drive with UEFI as well as the hard disk.
> >
> > I may be wrong, but I don't think this is possible (yet?).  You could
> > use a secondary bootloader, e.g. GRUB, other than the UEFI firmware to
> > load OS kernels wherever they might be positioned on the system.
>
> But see next:
>
> > > Oh yes, removable devices can be booted, but not secondary, internal hard
> > > drives. Apparently. On this system. Today.
>
> I can boot from USB or CD drives by entering the UEFI BIOS at boot and
> selecting the one I want to boot from - and this BIOS dates from 2014. I doubt
> this is unusual.

Sorry, my mistake - the following is what I meant to write, but in a
rush I failed to do so:

As long as you structure the ESP filesystem as per UEFI specification,
a sympathetic OEM UEFI firmware implementation will process the first
ESP on the first hard disk and list OS kernels it finds in its boot
manager menu for you to select from.  The latest UEFI specification
does not restrict the number of ESPs, or their location.  It is
unlikely the UEFI firmware will process additional ESPs on the same,
or other hard disks, or partitions which have anything other than
FAT(12,16,32) filesystems.  I seem to recall earlier OEM
implementations explicitly excluded more than one ESP on the primary
disk.  In the future the UEFI specification may evolve to include more
than one ESP or FAT partitions, perhaps even with/without the ESP GUID
being set.

Removable devices with an ESP structured as per UEFI specification
will also be probed and their primary (default) bootable kernel listed
by the UEFI firmware.  Selecting a listed removable device from within
the UEFI boot menu will boot it, as you observed.

If you want more than one kernel per OS subdirectory to be listed in
the UEFI boot manager's menu, you will need to add them in the desired
order using the efibootmgr command.  Otherwise, the UEFI firmware will
not behave predictably in which of these kernels it selects to list in
its boot menu.

As I understand it, 'bootctl --update' can be used to update
systemd-boot boot manager's menu and it is looking for bootable
kernels by scanning /efi, /boot, and /boot/efi, or the directory set
by passing the '--path' option to it.  Manual addition of bootable
kernels must be set via /loader/entries/*.conf (one file per kernel
image) and then setting the default kernel to be booted in
/loader/loader.conf.  I find all this to be unnecessary complication
for maintaining a boot manager manually, compared to using say
efibootmgr.  However, it is handy to be able to press 'e' to edit the
default entry at boot time, or if new kernels are always stored where
expected by the scripts of binary distros.

For Peter's use case, OS and kernel resides on secondary disk, the
solutions I can think are:

1. Use GRUB.  The UEFI firmware will load the GRUB efi image, which
will load the desired kernel and OS wherever it might reside.
Secondary disks and non-FAT filesystems are not a problem, because
GRUB has various fs drivers and will probe additional devices.
Following installation maintenance is minimal compared to other
options.

2. Use systemd-boot.  Copy each kernel from the secondary disk to
/boot/EFI/ creating the corresponding /loader/entries/*.conf, adding
the kernel .conf name and the OS root partition's path on the
secondary disk.  The root path can also/instead be included in the
kernel itself (CONFIG_CMDLINE).

3. Use some other boot manager (e.g. rEFInd, ELILO).

4. Use efibootmgr after you copy the kernel from the secondary disk to
the ESP in a corresponding OS subdirectory.  The root path should be
included in the kernel.

I hope the above clarifies my previous post.
--
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Neil Bothwick]

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

On Sun, 29 Sep 2019 11:59:00 +0100, Mick wrote:

> As I understand it, 'bootctl --update' can be used to update
> systemd-boot boot manager's menu and it is looking for bootable
> kernels by scanning /efi, /boot, and /boot/efi, or the directory set
> by passing the '--path' option to it.  Manual addition of bootable
> kernels must be set via /loader/entries/*.conf (one file per kernel
> image) and then setting the default kernel to be booted in
> /loader/loader.conf.  I find all this to be unnecessary complication
> for maintaining a boot manager manually, compared to using say
> efibootmgr.  However, it is handy to be able to press 'e' to edit the
> default entry at boot time, or if new kernels are always stored where
> expected by the scripts of binary distros.
> 
> For Peter's use case, OS and kernel resides on secondary disk, the
> solutions I can think are:
> 
[snip GRUB bit]

> 2. Use systemd-boot.  Copy each kernel from the secondary disk to
> /boot/EFI/ creating the corresponding /loader/entries/*.conf, adding
> the kernel .conf name and the OS root partition's path on the
> secondary disk.  The root path can also/instead be included in the
> kernel itself (CONFIG_CMDLINE).

That's not how the systemd boot manager works. It is a bootable image
which then reads the config from /boot/loader and presents a boot menu.
As far as the firmware is concerned, it is always booting the same image.

The loader files are analogous to grub.cfg, but a thousand times simpler
(I may be understating that in my desire to avoid hyperbole). For
example, loader.conf here is

timeout 3
default 00-*

This never needs to be modified, it simply boots the first entry after 3
seconds. That entry here is

title	Desktop
version	5.3.1-gentoo
linux	/vmlinuz-5.3.1-gentoo
options	root=LABEL=yooden rd.luks.uuid=luks-d879a686-39f3-4331-b35e-7744468b5ce3 rootfstype=btrfs rootflags=rw,noatime,ssd,space_cache rd.shell net.ifnames=0 init=/lib/systemd/systemd
initrd	/intel-uc.img
initrd	/initramfs-5.3.1-gentoo.img

As you can see, the only vaguely complex part is the list of kernel
options, and most of that is options for the root filesystem which the
kernel would need for any bootloader.

Incidentally, I use a short shell script to regenerate the menu entries
after a kernel change, like grub-update but the predictable orders of
magnitude shorter, so even that is trivial.

I have tried reFind and AFAIR it works in a similar way, although I
stopped using it as I wasn't interested in the fancy graphical boot menu.


-- 
Neil Bothwick

Why is bra singular and pants plural?

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Mick]

On Sun, 29 Sep 2019 at 13:25, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> On Sun, 29 Sep 2019 11:59:00 +0100, Mick wrote:
>
> > As I understand it, 'bootctl --update' can be used to update
> > systemd-boot boot manager's menu and it is looking for bootable
> > kernels by scanning /efi, /boot, and /boot/efi, or the directory set
> > by passing the '--path' option to it.  Manual addition of bootable
> > kernels must be set via /loader/entries/*.conf (one file per kernel
> > image) and then setting the default kernel to be booted in
> > /loader/loader.conf.  I find all this to be unnecessary complication
> > for maintaining a boot manager manually, compared to using say
> > efibootmgr.  However, it is handy to be able to press 'e' to edit the
> > default entry at boot time, or if new kernels are always stored where
> > expected by the scripts of binary distros.
> >
> > For Peter's use case, OS and kernel resides on secondary disk, the
> > solutions I can think are:
> >
> [snip GRUB bit]
>
> > 2. Use systemd-boot.  Copy each kernel from the secondary disk to
> > /boot/EFI/ creating the corresponding /loader/entries/*.conf, adding
> > the kernel .conf name and the OS root partition's path on the
> > secondary disk.  The root path can also/instead be included in the
> > kernel itself (CONFIG_CMDLINE).
>
> That's not how the systemd boot manager works. It is a bootable image
> which then reads the config from /boot/loader and presents a boot menu.
> As far as the firmware is concerned, it is always booting the same image.

Thanks Neil, I bow to your superior knowledge on systemd-boot - I've
only come across it on binary distros and did not have to interfere
with its settings.  I think we're saying the same thing.  I understand
that using a predictable naming convention for *.conf files will load
the corresponding kernel images in turn, but the default kernel can be
overwritten in loader.conf instead of using a wildcard which will pick
up the first *.conf file in line.  Also, these .conf files will not be
created with 'bootctl --update' unless all requisite OS kernel images
have been stored in the ESP.

> The loader files are analogous to grub.cfg, but a thousand times simpler
> (I may be understating that in my desire to avoid hyperbole). For
> example, loader.conf here is
>
> timeout 3
> default 00-*
>
> This never needs to be modified, it simply boots the first entry after 3
> seconds.

Right, but if the OP wants to boot some other kernel (which happens to
be on his second disk) systemd-boot's image picking up the first
*.conf file won't be of use.  He'll need to select another kernel from
the menu or set this in the loader.conf as a semi-permanent solution.
Please correct as necessary if I got this wrong.


> Incidentally, I use a short shell script to regenerate the menu entries
> after a kernel change, like grub-update but the predictable orders of
> magnitude shorter, so even that is trivial.

Yes, I expect Peter will also need to use some script of sorts if he
wishes to automate this process, or manage it manually.

-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Tuesday, 24 September 2019 09:50:44 BST Peter Humphrey wrote:

> Right. After spending most of the last 10 days and some nights wrestling
> with the beast, I've got it fixed at last.

Except that I was wrong: I hadn't fixed it. I've just spent another two days 
with an unbootable system finding a real fix.

When this all started, a couple of weeks ago or so, bootctl remove & install 
threw a wobbler. It created two empty directories:
	/boot/4eec63dc92f83de25e1e2e485d7f6536
	/boot/EFI/Linux
then wailed about not finding some data file and stopped.

Ever since then I've been trying to force the system back into the directory 
structure that used to work, and getting stung over and again.

This morning I decided to bend with the wind. I let bootctl create those 
directories again, then copied the latest kernel image into /boot/EFI/Linux/. 
On running bootctl install again, everything worked as expected. All I had to 
do was to adjust the boot order with efibootmgr.

I suspect I have a hardware problem, because the UEFI BIOS boot menu doesn't 
always show an entry I've just added, and it sometimes inserts a blank entry 
among the real ones.

For the record, here's the layout of /boot now:

# tree /boot            
/boot
├── 4eec63dc92f83de25e1e2e485d7f6536
├── config-4.19.72-gentoo
├── config-4.19.72-gentoo-rescue
├── config-4.19.72-gentoo-testsys
├── early_ucode.cpio
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   ├── Linux
│   │   └── bzImage-4.19.72.efi
│   ├── systemd
│   │   └── systemd-bootx64.efi
│   └── TestSys
│       └── BOOT
│           └── bootX64.efi
├── intel-uc.img
├── loader
│   ├── entries
│   │   ├── 08-gentoo-4.19.66-rescue.conf
│   │   ├── 09-gentoo-4.19.66-rescue.nonet.conf
│   │   ├── 30-gentoo-4.19.72.conf
│   │   ├── 32-gentoo-4.19.72.nox.conf
│   │   ├── 34-gentoo-4.19.72.nonet.conf
│   │   ├── 40-gentoo-4.19.66.conf
│   │   ├── 42-gentoo-4.19.66.nox.conf
│   │   ├── 44-gentoo-4.19.66.nonet.conf
│   │   ├── 90-testsys-4.19.72.conf
│   │   └── 92-testsys-4.19.72.nonet.conf
│   ├── loader.conf
│   └── random-seed
├── System.map-4.19.72-gentoo
├── System.map-4.19.72-gentoo-rescue
├── System.map-4.19.72-gentoo-testsys
├── vmlinuz-4.19.72-gentoo
├── vmlinuz-4.19.72-gentoo-rescue
└── vmlinuz-4.19.72-gentoo-testsys

9 directories, 27 files

Here's hoping I won't have to go through that pain again for a while...

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Neil Bothwick]

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

On Mon, 30 Sep 2019 11:06:17 +0100, Peter Humphrey wrote:

> This morning I decided to bend with the wind. I let bootctl create
> those directories again, then copied the latest kernel image into
> /boot/EFI/Linux/. On running bootctl install again, everything worked
> as expected. All I had to do was to adjust the boot order with
> efibootmgr.
> 
> I suspect I have a hardware problem, because the UEFI BIOS boot menu
> doesn't always show an entry I've just added, and it sometimes inserts
> a blank entry among the real ones.
> 
> For the record, here's the layout of /boot now:
> 
> # tree /boot            
> /boot
> ├── 4eec63dc92f83de25e1e2e485d7f6536
> ├── config-4.19.72-gentoo
> ├── config-4.19.72-gentoo-rescue
> ├── config-4.19.72-gentoo-testsys
> ├── early_ucode.cpio
> ├── EFI
> │   ├── BOOT
> │   │   └── BOOTX64.EFI
> │   ├── Linux
> │   │   └── bzImage-4.19.72.efi
> │   ├── systemd
> │   │   └── systemd-bootx64.efi
> │   └── TestSys
> │       └── BOOT
> │           └── bootX64.efi
> ├── intel-uc.img
> ├── loader
> │   ├── entries
> │   │   ├── 08-gentoo-4.19.66-rescue.conf
> │   │   ├── 09-gentoo-4.19.66-rescue.nonet.conf
> │   │   ├── 30-gentoo-4.19.72.conf
> │   │   ├── 32-gentoo-4.19.72.nox.conf
> │   │   ├── 34-gentoo-4.19.72.nonet.conf
> │   │   ├── 40-gentoo-4.19.66.conf
> │   │   ├── 42-gentoo-4.19.66.nox.conf
> │   │   ├── 44-gentoo-4.19.66.nonet.conf
> │   │   ├── 90-testsys-4.19.72.conf
> │   │   └── 92-testsys-4.19.72.nonet.conf
> │   ├── loader.conf
> │   └── random-seed
> ├── System.map-4.19.72-gentoo
> ├── System.map-4.19.72-gentoo-rescue
> ├── System.map-4.19.72-gentoo-testsys
> ├── vmlinuz-4.19.72-gentoo
> ├── vmlinuz-4.19.72-gentoo-rescue
> └── vmlinuz-4.19.72-gentoo-testsys
> 
> 9 directories, 27 files
> 
> Here's hoping I won't have to go through that pain again for a while...

Are you setting UEFI to boot from systemd-bootx64.efi or from the kernel
image? If the former, you don't need a copy of the kernel in the ESP.


-- 
Neil Bothwick

WinErr 00A: Promotional literature overflow - Mailbox full

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

Re: [gentoo-user] UEFI data corruption? [FIXED]

[Neil Bothwick]

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

On Mon, 30 Sep 2019 10:02:58 +0100, Mick wrote:

> > The loader files are analogous to grub.cfg, but a thousand times
> > simpler (I may be understating that in my desire to avoid hyperbole).
> > For example, loader.conf here is
> >
> > timeout 3
> > default 00-*
> >
> > This never needs to be modified, it simply boots the first entry
> > after 3 seconds.  
> 
> Right, but if the OP wants to boot some other kernel (which happens to
> be on his second disk) systemd-boot's image picking up the first
> *.conf file won't be of use.  He'll need to select another kernel from
> the menu or set this in the loader.conf as a semi-permanent solution.
> Please correct as necessary if I got this wrong.

That's right which is why you have a boot menu. The only time I change
the default in loader.conf is when wanting to use a different kernel on a
headless system, where I don't have access to the menu.

The "default 00-*" setting I use is the equivalent of GRUB's "set
default=0". It's just easier to see as it is 50% of the config file
rather that 0.5% ;-)


-- 
Neil Bothwick

Top Oxymorons Number 19: Passive aggression

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

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Monday, 30 September 2019 21:01:28 BST Neil Bothwick wrote:

> Are you setting UEFI to boot from systemd-bootx64.efi or from the kernel
> image? If the former, you don't need a copy of the kernel in the ESP.

I could run some tests to find out, but after throwing so much time and effort 
into reaching a stable setup (so far), I don't wish to do anything to it but 
use it, thanks all the same.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Neil Bothwick]

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

On Tue, 01 Oct 2019 10:05:23 +0100, Peter Humphrey wrote:

> > Are you setting UEFI to boot from systemd-bootx64.efi or from the
> > kernel image? If the former, you don't need a copy of the kernel in
> > the ESP.  
> 
> I could run some tests to find out, but after throwing so much time and
> effort into reaching a stable setup (so far), I don't wish to do
> anything to it but use it, thanks all the same.

You appear to have set up two alternative boot methods. While they don't
conflict, you are adding potential confusion when trying to find out what
is wrong.


-- 
Neil Bothwick

If at first you do succeed, try to hide your astonishment.

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

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Tuesday, 1 October 2019 10:47:59 BST Neil Bothwick wrote:
> On Tue, 01 Oct 2019 10:05:23 +0100, Peter Humphrey wrote:
> > > Are you setting UEFI to boot from systemd-bootx64.efi or from the
> > > kernel image? If the former, you don't need a copy of the kernel in
> > > the ESP.
> > 
> > I could run some tests to find out, but after throwing so much time and
> > effort into reaching a stable setup (so far), I don't wish to do
> > anything to it but use it, thanks all the same.
> 
> You appear to have set up two alternative boot methods. While they don't
> conflict, you are adding potential confusion when trying to find out what
> is wrong.

All right, I've deleted the systemd directory and the system boots more-or-
less as expected. The differences from a few months ago are (i) the BIOS 
spends a few seconds flickering the cursor around the screen before showing my 
boot menu; (ii) after I've chosen the image to boot, I see 'SHA256 verified' 
at the top-left of the BIOS's part of the screen, until the kernel takes it 
over. I don't know what to make of those.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Mick]

On Tue, 1 Oct 2019 at 12:01, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Tuesday, 1 October 2019 10:47:59 BST Neil Bothwick wrote:
> > On Tue, 01 Oct 2019 10:05:23 +0100, Peter Humphrey wrote:
> > > > Are you setting UEFI to boot from systemd-bootx64.efi or from the
> > > > kernel image? If the former, you don't need a copy of the kernel in
> > > > the ESP.
> > >
> > > I could run some tests to find out, but after throwing so much time and
> > > effort into reaching a stable setup (so far), I don't wish to do
> > > anything to it but use it, thanks all the same.
> >
> > You appear to have set up two alternative boot methods. While they don't
> > conflict, you are adding potential confusion when trying to find out what
> > is wrong.
>
> All right, I've deleted the systemd directory and the system boots more-or-
> less as expected.

The whole idea of a boot manager is that the UEFI firmware loads the
boot manager's .efi executable from the ESP and the boot manager then
provides a list of bootable images and boots them as selected.  Unlike
the UEFI boot manager which can only process ESP/FAT partitions, the
boot manager of choice is able to load kernels from various different
filesystems.  In your use case where additional kernel(s) reside on a
secondary disk, the use of systemd-boot's .efi binary would make
sense.  The UEFI firmware will not be able to load them on its own.

BTW, I am not sure if bootctl will throw a wobbly when the systemd
directory is missing ...  :-/


> The differences from a few months ago are (i) the BIOS
> spends a few seconds flickering the cursor around the screen before showing my
> boot menu;

Could it be the systemd-boot binary is looking for some of its files
and not finding them where expected?  Or, it may be related to some
Secure Boot checks.


> (ii) after I've chosen the image to boot, I see 'SHA256 verified'
> at the top-left of the BIOS's part of the screen, until the kernel takes it
> over. I don't know what to make of those.

When using Secure Boot the UEFI firmware check the binaries to be
loaded have been signed by Microsoft.  The 'SHA256 verified' message
indicates the systemd-boot binary is signed using a key which is
ultimately signed by Microsoft and is contained in the whitelist
(MokList).  If the verification failed I think it would spit something
back to allow you to enrol a valid hash or key.
-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Mick]

On Tue, 1 Oct 2019 at 13:18, Mick <michaelkintzios@gmail.com> wrote:

> When using Secure Boot the UEFI firmware check the binaries to be
> loaded have been signed by Microsoft.  The 'SHA256 verified' message
> indicates the systemd-boot binary is signed using a key which is
> ultimately signed by Microsoft and is contained in the whitelist
> (MokList).  If the verification failed I think it would spit something
> back to allow you to enrol a valid hash or key.

Scratch that - the message itself is a debug message following an
early SHA-256 implementation self-test[1] before the systemd provided
random seed file is loaded.  All the Secure Boot signature checks that
follow will utilise the random seed file systemd provides.

[1] https://github.com/systemd/systemd/blob/4c858c6fd5d588b30d9851bb576520e74b041739/src/boot/efi/random-seed.c#L172

-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Tuesday, 1 October 2019 15:32:27 BST Mick wrote:
> On Tue, 1 Oct 2019 at 13:18, Mick <michaelkintzios@gmail.com> wrote:
> > When using Secure Boot the UEFI firmware check the binaries to be
> > loaded have been signed by Microsoft.  The 'SHA256 verified' message
> > indicates the systemd-boot binary is signed using a key which is
> > ultimately signed by Microsoft and is contained in the whitelist
> > (MokList).  If the verification failed I think it would spit something
> > back to allow you to enrol a valid hash or key.
> 
> Scratch that - the message itself is a debug message following an
> early SHA-256 implementation self-test[1] before the systemd provided
> random seed file is loaded.  All the Secure Boot signature checks that
> follow will utilise the random seed file systemd provides.
> 
> [1]
> https://github.com/systemd/systemd/blob/4c858c6fd5d588b30d9851bb576520e74b0
> 41739/src/boot/efi/random-seed.c#L172

Okay, thanks.

[I hope I've been clear enough in what follows  :) ]

Yet another attempt. I've repartitioned the disk without the unformatted
partition, as in Neil's usual scheme; deleted all boot entries using
efibootmgr; allowed the UEFI BIOS to set itself up again; and run 'bootctl
update' to copy the latest kernel into place.

Then, bootctl status shows this:
Default Boot Loader Entry:
        title: Gentoo TestSys 4.19.72 (no network)
           id: 92-testsys-4.19.72.nonet
       source: /boot/loader/entries/92-testsys-4.19.72.nonet.conf
        linux: /vmlinuz-4.19.72-gentoo-testsys
      options: root=/dev/sda4 initrd=/intel-uc.img net.ifnames=0 softlevel=nonetwork

That's supposed to be a secondary entry, not the primary, so I tried to set a
different default. Man bootctl includes this:
       set-default ID, set-oneshot ID
           Sets the default boot loader entry. Takes a single boot loader entry ID
           string as argument. The set-oneshot command will set the default entry only
           for the next boot, the set-default will set it persistently for all future
           boots.

bootctl list output includes this entry:
        title: Gentoo Linux 4.19.72
           id: 30-gentoo-4.19.72
       source: /boot/loader/entries/30-gentoo-4.19.72.conf
        linux: /vmlinuz-4.19.72-gentoo
      options: root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0

That's the one I want to set as default, but then:
# bootctl set-default 30-gentoo-4.19.72
Failed to update EFI variable: Invalid argument

What is this ID supposed to be, if not the ID shown by bootctl list? Oh, and
efivars is mounted rw, of course.

Bootctl and efibootmgr seem to operate orthogonally, at least in some
respects, which doesn't help me to uderstand what's going on.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Mick]

On Tue, 1 Oct 2019 at 16:19, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Tuesday, 1 October 2019 15:32:27 BST Mick wrote:
> > On Tue, 1 Oct 2019 at 13:18, Mick <michaelkintzios@gmail.com> wrote:
> > > When using Secure Boot the UEFI firmware check the binaries to be
> > > loaded have been signed by Microsoft.  The 'SHA256 verified' message
> > > indicates the systemd-boot binary is signed using a key which is
> > > ultimately signed by Microsoft and is contained in the whitelist
> > > (MokList).  If the verification failed I think it would spit something
> > > back to allow you to enrol a valid hash or key.
> >
> > Scratch that - the message itself is a debug message following an
> > early SHA-256 implementation self-test[1] before the systemd provided
> > random seed file is loaded.  All the Secure Boot signature checks that
> > follow will utilise the random seed file systemd provides.
> >
> > [1]
> > https://github.com/systemd/systemd/blob/4c858c6fd5d588b30d9851bb576520e74b0
> > 41739/src/boot/efi/random-seed.c#L172
>
> Okay, thanks.
>
> [I hope I've been clear enough in what follows  :) ]
>
> Yet another attempt. I've repartitioned the disk without the unformatted
> partition, as in Neil's usual scheme; deleted all boot entries using
> efibootmgr; allowed the UEFI BIOS to set itself up again; and run 'bootctl
> update' to copy the latest kernel into place.
>
> Then, bootctl status shows this:
> Default Boot Loader Entry:
>         title: Gentoo TestSys 4.19.72 (no network)
>            id: 92-testsys-4.19.72.nonet
>        source: /boot/loader/entries/92-testsys-4.19.72.nonet.conf
>         linux: /vmlinuz-4.19.72-gentoo-testsys
>       options: root=/dev/sda4 initrd=/intel-uc.img net.ifnames=0 softlevel=nonetwork
>
> That's supposed to be a secondary entry, not the primary, so I tried to set a
> different default. Man bootctl includes this:
>        set-default ID, set-oneshot ID
>            Sets the default boot loader entry. Takes a single boot loader entry ID
>            string as argument. The set-oneshot command will set the default entry only
>            for the next boot, the set-default will set it persistently for all future
>            boots.
>
> bootctl list output includes this entry:
>         title: Gentoo Linux 4.19.72
>            id: 30-gentoo-4.19.72
>        source: /boot/loader/entries/30-gentoo-4.19.72.conf
>         linux: /vmlinuz-4.19.72-gentoo
>       options: root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0
>
> That's the one I want to set as default, but then:
> # bootctl set-default 30-gentoo-4.19.72
> Failed to update EFI variable: Invalid argument
>
> What is this ID supposed to be, if not the ID shown by bootctl list? Oh, and
> efivars is mounted rw, of course.

I admire your patience!  I would have moved on to some other boot
manager a long time ago.  :-)

As I understand it this ID must be the ID bootctl itself reports.
However, earlier bootctl versions do not have this set-default ID
subcommand.  If you run bootctl with no arguments does it show up?

> Bootctl and efibootmgr seem to operate orthogonally, at least in some
> respects, which doesn't help me to uderstand what's going on.

If you follow the UEFI spec and store one kernel per EFI/
subdirectory, the UEFI firmware will pick them up on its own and the
efibootmgr will list them.

I would think bootctl will also pick them up and add them in its own menu.

If you use a suitable alphanumeric nomenclature to elevate the
subdirectory of your kernel of choice, it should be selected as the
default (hopefully).

Meanwhile, assuming you have set the systemd-boot timeout to a value
greater than 0, you could try pressing 'd' after you move  the cursor
to the desired kernel image.  I think it sets the selected image as a
default, but I don't have a systemd-boot available to see if it merely
boots the existing default setting.
-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Tuesday, 1 October 2019 18:47:25 BST Mick wrote:

> As I understand it this ID must be the ID bootctl itself reports.
> However, earlier bootctl versions do not have this set-default ID
> subcommand.  If you run bootctl with no arguments does it show up?

No, it behaves the same as 'bootctl status'.

> > Bootctl and efibootmgr seem to operate orthogonally, at least in some
> > respects, which doesn't help me to uderstand what's going on.
> 
> If you follow the UEFI spec and store one kernel per EFI/
> subdirectory, the UEFI firmware will pick them up on its own and the
> efibootmgr will list them.
> 
> I would think bootctl will also pick them up and add them in its own menu.

My impression is that efibootmgr only picks up what it's written itself, and 
what the BIOS has filled in. Bootctl does do as you say, though.

> If you use a suitable alphanumeric nomenclature to elevate the
> subdirectory of your kernel of choice, it should be selected as the
> default (hopefully).

Nope:

# tree /boot/EFI
/boot/EFI
├── BOOT
│   └── BOOTX64.EFI
├── systemd
│   └── systemd-bootx64.efi
└── TestSys
    └── BOOT
        └── bootX64.efi

# ls /boot/loader/entries
08-gentoo-4.19.66-rescue.conf        40-gentoo-4.19.66.conf
09-gentoo-4.19.66-rescue.nonet.conf  42-gentoo-4.19.66.nox.conf
30-gentoo-4.19.72.conf               44-gentoo-4.19.66.nonet.conf
32-gentoo-4.19.72.nox.conf           90-testsys-4.19.72.conf
34-gentoo-4.19.72.nonet.conf         92-testsys-4.19.72.nonet.conf

Bootctl has picked the test system as its default (90-testsys-4.19.72), and 
the boot menu comes up with it selected; that's why I want to change bootctl's 
default selection. The two files bootx64.efi (modulo case) are identical 
kernel images except for CONFIG_LOCALVERSION="<...>".

> Meanwhile, assuming you have set the systemd-boot timeout to a value
> greater than 0, you could try pressing 'd' after you move  the cursor
> to the desired kernel image.  I think it sets the selected image as a
> default, but I don't have a systemd-boot available to see if it merely
> boots the existing default setting.

That's it! I didn't know about that - where is it documented? 

Thank you for your own patience, Mick.  :)

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Mick]

On Tue, 1 Oct 2019 at 22:38, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Tuesday, 1 October 2019 18:47:25 BST Mick wrote:
>
> > As I understand it this ID must be the ID bootctl itself reports.
> > However, earlier bootctl versions do not have this set-default ID
> > subcommand.  If you run bootctl with no arguments does it show up?
>
> No, it behaves the same as 'bootctl status'.

OK, 'bootctl --help' and 'man bootctl' ought to show if the installed
version comes with the full list of options or not.


> > If you follow the UEFI spec and store one kernel per EFI/
> > subdirectory, the UEFI firmware will pick them up on its own and the
> > efibootmgr will list them.
> >
> > I would think bootctl will also pick them up and add them in its own menu.
>
> My impression is that efibootmgr only picks up what it's written itself, and
> what the BIOS has filled in. Bootctl does do as you say, though.

The efibootmgr is just a userspace application which interacts with
the UEFI firmware's API to modify the UEFI NVRAM boot manager data.
Unless *you* run it explicitly to change or list the UEFI boot
entries, it will not do anything.

The probing and listing of boot entries is not performed by the
efibootmgr application, but by the UEFI boot manager itself.  The UEFI
boot manager probes the disks for an ESP and then reads and lists the
.efi files in the ESP, provided these were stored as per the UEFI
specification.

The systemd-boot/bootctl reads all /loader/entries/*.conf, and
populates its boot menu with these.  However, /loader/entries/*.conf
files can be generated automagically, as long as you follow the
systemd boot loader specification – yes, I know, yet another
specification!  According to this specification you can/must:

For NON-UEFI bootable images:

1. Drop in the ”$BOOT/loader/entries/ directory one or more
configuration snippets with the suffix “.conf one for each boot menu
item.
2. To differentiate between OS installations and a number of kernels
in each installation you may name each .conf file by including the
machine ID (/etc/machine-id or the D-Bus machine ID for OSes that lack
/etc/machine-id), the kernel version (as returned by uname -r) and an
OS identifier (The ID field of /etc/os-release).  These will be used
to prioritise menu entries.

For UEFI bootable images:

3. Add kernels, initrds, et al. in $BOOT/EFI/Linux/ – the bootable
image should have an .efi suffix.
4. It is recommended to place these files in a vendor and OS and
installation specific directory.

More and better detailed information can be found in the spec:

https://systemd.io/BOOT_LOADER_SPECIFICATION.html


> > If you use a suitable alphanumeric nomenclature to elevate the
> > subdirectory of your kernel of choice, it should be selected as the
> > default (hopefully).
>
> Nope:
>
> # tree /boot/EFI
> /boot/EFI
> ├── BOOT
> │   └── BOOTX64.EFI
> ├── systemd
> │   └── systemd-bootx64.efi
> └── TestSys
>     └── BOOT
>         └── bootX64.efi

The 'BOOT' subdirectory has a specific function, as I mentioned
before.  It is the fallback bootable image, when others fail.  I
suppose the first BOOT subdirectory will take precedence, but having
two of those might confuse matters during parsing of images.


> # ls /boot/loader/entries
> 08-gentoo-4.19.66-rescue.conf        40-gentoo-4.19.66.conf
> 09-gentoo-4.19.66-rescue.nonet.conf  42-gentoo-4.19.66.nox.conf
> 30-gentoo-4.19.72.conf               44-gentoo-4.19.66.nonet.conf
> 32-gentoo-4.19.72.nox.conf           90-testsys-4.19.72.conf
> 34-gentoo-4.19.72.nonet.conf         92-testsys-4.19.72.nonet.conf
>
> Bootctl has picked the test system as its default (90-testsys-4.19.72), and
> the boot menu comes up with it selected; that's why I want to change bootctl's
> default selection. The two files bootx64.efi (modulo case) are identical
> kernel images except for CONFIG_LOCALVERSION="<...>".

Right, I don't know why the bootctl parses the entries .conf files in
this particular order.  The spec suggests to use a naming convention
as per 2. above which *should* work with less effort.


> > Meanwhile, assuming you have set the systemd-boot timeout to a value
> > greater than 0, you could try pressing 'd' after you move  the cursor
> > to the desired kernel image.  I think it sets the selected image as a
> > default, but I don't have a systemd-boot available to see if it merely
> > boots the existing default setting.
>
> That's it! I didn't know about that - where is it documented?

Have you looked at the fine manual for 'systemd-boot'?  :-)

> Thank you for your own patience, Mick.  :)

Don't mention it - I'm a sucker for a challenge involving software
creations I care not use myself!  LOL!
-- 
Regards,
Mick

Re: [gentoo-user] UEFI data corruption? [FIXED-FIXED]

[Peter Humphrey]

On Wednesday, 2 October 2019 10:04:33 BST Mick wrote:
> On Tue, 1 Oct 2019 at 22:38, Peter Humphrey <peter@prh.myzen.co.uk> wrote:

> OK, 'bootctl --help' and 'man bootctl' ought to show if the installed
> version comes with the full list of options or not.

Neither of them says what should happen if an option is not supplied.

--->8

Now I'm getting this error in the output of bootctl (just the default entry 
shown here):

[...]
Image lacks .osrel section, refusing.
Default Boot Loader Entry:
        title: Gentoo Linux 4.19.72
           id: 30-gentoo-4.19.72
       source: /boot/loader/entries/30-gentoo-4.19.72.conf
        linux: /vmlinuz-4.19.72-gentoo
      options: root=/dev/nvme0n1p4 initrd=/intel-uc.img net.ifnames=0

If I copy the vmlinuz file to a bzImage, I get a second error output, so 
something must be wrong with the kernel image. Google doesn't help me with 
what, though. Sometimes the error appears as the very first line of output 
instead. I think that's because I'm seeing the interleaved output of $1 and 
$2.

Otherwise I can now boot and run whichever system I like. Apparently. On this 
system. Today.   ;)

-- 
Regards,
Peter.