Re: [gentoo-user] UEFI booting again - FIXED

[Peter Humphrey]

On Monday, 19 October 2020 18:08:53 -00 Michael wrote:

> However, I don't think anyone would argue against empirical repeatable
> outcomes.  :-)

:)

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI booting again - FIXED

[Michael]

On Monday, 19 October 2020 17:10:57 BST Peter Humphrey wrote:
> On Monday, 19 October 2020 14:08:05 -00 Michael wrote:
> > Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu?
> 
> No, I'm saying that I appear to be able to create a BIOS entry using
> efibootmgr, but when I reboot and enter BIOS setup, the entry often isn't
> there. Or if it is, either the kernel won't boot, or it does but the
> resulting system is incomplete.
> 
> When I bought this system I failed entirely to install grub - I followed the
> instructions slavishly and received much help from those more knowledgeable
> on this list at the time, but never got the system to boot. Then, groping
> about trying to understand efibootmgr, bootctl and UEFI generally, I may
> have done some combination of things that prevented those tools from ever
> working again. For me. On this machine.
> 
> So the summary is: I can preserve the ESP using Windows's system image
> creation and recovery tool, but not with those two Linux tools.
> 
> I've wasted several months wrestling with this, and I've finished up with
> what I've described.

I see.  What you describe is interesting, because the UEFI firmware GUI, 
efibootmgr, and MSWindows are all meant to be accessing the *same* database of 
editable entries on the firmware, using the UEFI API.  I have not looked into 
bootctl more than once to know what it does with any clarity.

However, I don't think anyone would argue against empirical repeatable 
outcomes.  :-)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] UEFI booting again - FIXED

[Peter Humphrey]

On Monday, 19 October 2020 14:08:05 -00 Michael wrote:

> Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu? 

No, I'm saying that I appear to be able to create a BIOS entry using 
efibootmgr, but when I reboot and enter BIOS setup, the entry often isn't 
there. Or if it is, either the kernel won't boot, or it does but the resulting 
system is incomplete.

When I bought this system I failed entirely to install grub - I followed the 
instructions slavishly and received much help from those more knowledgeable on 
this list at the time, but never got the system to boot. Then, groping about 
trying to understand efibootmgr, bootctl and UEFI generally, I may have done 
some combination of things that prevented those tools from ever working again. 
For me. On this machine.

So the summary is: I can preserve the ESP using Windows's system image 
creation and recovery tool, but not with those two Linux tools.

I've wasted several months wrestling with this, and I've finished up with what 
I've described.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI booting again - FIXED

[Michael]

On Monday, 19 October 2020 13:08:35 BST Peter Humphrey wrote:
> On Sunday, 11 October 2020 23:21:49 -00 pe...@prh.myzen.co.uk wrote:
> > Can anyone please tell me precisely where 'efibootmgr -c ...' writes a
> > boot
> > record, or whatever it's called? My machine seems unable to store what I
> > give it, and I suspect that the BIOS ROM has failed. Big expense if so.
> 
> I have a bootable system again.
> 
> In one line: I need Windows as part of my system maintenance.
> 
> Yes, I did mean to write that. Let me explain.
> 
> Every attempt of mine to write bootable images failed. I still don't know
> why, but while I was trying everything I could think of, I ran Windows (on
> /dev/ sdb) to restore a system image (from /dev/sda; /root is on
> /dev/nvme0n1). On rebooting, lo! and behold! there was a boot menu! It was
> an old one, dating from when I created the system image in Windows, but
> after booting from USB and adding the right kernels and /boot/loader/
> structure, and running 'bootclt update', a reboot showed me the proper boot
> menu.
> 
> A kernel upgrade arrived today, so after installing it and updating the
> /boot/ loader config, I ran Windows again to create a new system image.
> 
> So on my machine, efibootmgr is no use. I have to use bootctl from
> systemd-boot to manage my bootable images. And Windows to preserve them.
> 
> I've attached a shot of the boot menu I've been referring to in this thread.
> It's not pretty, but there's only so much I can do with a curved screen and
> a hand-held phone.

I am confused ...

Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu?  o_O


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: [gentoo-user] UEFI booting again

[Peter Humphrey]

On Monday, 12 October 2020 17:43:04 BST Michael wrote:

> The UEFI firmware contains a number of variables in key/value pairs, stored
> on NVRAM.  One of these is a table containing a Boot Menu within an
> editable area of the firmware, which can be manipulated with the EFI shell
> (efibootmgr) to set, rename, delete bootable .efi images.

[...etc]

Thanks Michael; more-or-less what I thought.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: [gentoo-user] UEFI booting again

[Michael]

On Monday, 12 October 2020 10:15:16 BST pe...@prh.myzen.co.uk wrote:
> On 2020-10-12 12:26 AM, "Jack"  wrote:
> > On 10/11/20 7:37 PM, Jude DaShiell wrote:
> > > If you followed the handbook /dev/sda2 would be where the boot record
> > > lives.> 
> > I don't think so, but the terminology is certainly confusing. Peter
> > asked where efibootmgr writes something.  What is on /dev/sda2 could be
> > grub.cfg if it were mounted at /boot, and the grub booting stub (I
> > forget the correct name, but grubx64.efi) might be on /dev/sda2 if it
> > were mounted at /boot/EFI.  However, efibootmgr doesn't mess with either
> > of those.  It deals with what is stored in the UEFI boot firmware.  That
> > entry, which is read by the UEFI at boot time, runs the entry in the EFI
> > disk partition (usually under /boot/EFI), which then runs the kernel
> > (and possibly initramfs) in /boot.  Unfortunately, "boot record" is
> > probably too general a term.
> 
> Yes, I meant the equivalent of that in an MBR system. Where the bootable
> kernel image lives is another matter.

The MBR's architecture is a bit different to UEFI.  Legacy BIOS in CMOS has a 
jump command to the MBR 'boot sector', stored @sector 0, which in the first 
446 bytes contains a bootstrap code and thereafter a partition table.  The 
bootstrap code signature is checked by BIOS and loaded in RAM where it is 
executed as a boot loader.  The bootstrap code (a.k.a. boot.img) contains a 
pointer to either Stage 1.5 or Stage 2.  Stage 1.5 starts on Sector 1 and has 
any filesystem drivers needed to access and read Stage 2.  Some boot loaders 
jump into a partition and load hardcoded sectors into RAM, which then run in 
order to load the rest of the OS boot image and execute it.  These are Stage 1 
boot loaders.  Other boot loaders like GRUB, load Stage 1 drivers and use 
these to access the stage 2 files in /boot, present a boot menu and load an OS 
kernel image.

With UEFI a lot of the above is stored in the much larger compared to CMOS 
UEFI firmware NVRAM.  The UEFI has its own bootstrap code, plus a boot 
manager, boot menu table and requisite device drivers, to access the ESP, or 
other bootable devices.

UEFI can load and execute any compatible UEFI applications from ESP, including 
OS boot loaders.


> I haven't been using grub, just efibootmgr to declare the image to the UEFI
> BIOS, and bootctl from systemd-boot to show a list of boot options.
> 
> I assume there's something like an EEPROM on the motherboard to contain
> pointers (what I called boot records) to the the bootable kernel images.
> That's what I was asking about. I'm pretty sure that that table doesn't
> live on the disk. (Followers of this tale may remember that I had a problem
> with the NVMe disk; it turned out to be faulty, and I've replaced it.
> Windows could still boot on another disk without any intervention by me.)
> 
> Can someone confirm or refute those ideas?

The UEFI firmware contains a number of variables in key/value pairs, stored on 
NVRAM.  One of these is a table containing a Boot Menu within an editable area 
of the firmware, which can be manipulated with the EFI shell (efibootmgr) to 
set, rename, delete bootable .efi images.

Upon a reboot the UEFI boot manager will scan the ESP and other similar VFAT 
partitions and bootable devices (CD/USB) for executable UEFI applications, to 
re-list any .efi bootable images it finds in its GUI boot menu.  If the 
previously configured boot menu order is lost/corrupted, a rescanned ESP may 
not arrive at the same order of bootable images.

As I understand it the concern of the OP here is the EEPROM chip may have 
corrupted its editable content.  Different OEMs have different solutions, with 
OOB hypervisors managing backup/restore functions, to using a secondary Boot 
Block found in the main Firmware chip, but at an alternate address location, 
to using two separate EEPROM chips and so on and using some jumper to restore 
from the backup.  If major firmware malfunction is suspected, then re-flashing 
the MoBo with the latest version of OEM firmware should hopefully restore 
sanity.  If the MoBo chip is faulty, or on its way out, then the failure mode 
will soon repeat itself.



signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: [gentoo-user] UEFI booting again

[peter]

On 2020-10-12 12:26 AM, "Jack"  wrote:
> On 10/11/20 7:37 PM, Jude DaShiell wrote:
> > If you followed the handbook /dev/sda2 would be where the boot record lives.
> 
> I don't think so, but the terminology is certainly confusing. Peter 
> asked where efibootmgr writes something.  What is on /dev/sda2 could be 
> grub.cfg if it were mounted at /boot, and the grub booting stub (I 
> forget the correct name, but grubx64.efi) might be on /dev/sda2 if it 
> were mounted at /boot/EFI.  However, efibootmgr doesn't mess with either 
> of those.  It deals with what is stored in the UEFI boot firmware.  That 
> entry, which is read by the UEFI at boot time, runs the entry in the EFI 
> disk partition (usually under /boot/EFI), which then runs the kernel 
> (and possibly initramfs) in /boot.  Unfortunately, "boot record" is 
> probably too general a term.

Yes, I meant the equivalent of that in an MBR system. Where the bootable kernel 
image lives is another matter. 

I haven't been using grub, just efibootmgr to declare the image to the UEFI 
BIOS, and bootctl from systemd-boot to show a list of boot options. 

I assume there's something like an EEPROM on the motherboard to contain 
pointers (what I called boot records) to the the bootable kernel images. That's 
what I was asking about. I'm pretty sure that that table doesn't live on the 
disk. (Followers of this tale may remember that I had a problem with the NVMe 
disk; it turned out to be faulty, and I've replaced it. Windows could still 
boot on another disk without any intervention by me.)

Can someone confirm or refute those ideas? 

> 
> Jack
> 
> > On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote:
> >
> >> Date: Sun, 11 Oct 2020 19:21:49
> >> From: pe...@prh.myzen.co.uk
> >> Reply-To: gentoo-user@lists.gentoo.org
> >> To: gentoo-user@lists.gentoo.org
> >> Subject: [gentoo-user] UEFI booting again
> >>
> >> I'm still wrestling with my system and its not booting.
> >>
> >> Can anyone please tell me precisely where 'efibootmgr -c ...' writes a 
> >> boot record, or whatever it's called? My machine seems unable to store 
> >> what I give it, and I suspect that the BIOS ROM has failed. Big expense if 
> >> so.
> >>
> >> TiA.
> 

Re: [gentoo-user] UEFI booting again

[Jack]

On 10/11/20 7:37 PM, Jude DaShiell wrote:

If you followed the handbook /dev/sda2 would be where the boot record lives.


I don't think so, but the terminology is certainly confusing. Peter 
asked where efibootmgr writes something.  What is on /dev/sda2 could be 
grub.cfg if it were mounted at /boot, and the grub booting stub (I 
forget the correct name, but grubx64.efi) might be on /dev/sda2 if it 
were mounted at /boot/EFI.  However, efibootmgr doesn't mess with either 
of those.  It deals with what is stored in the UEFI boot firmware.  That 
entry, which is read by the UEFI at boot time, runs the entry in the EFI 
disk partition (usually under /boot/EFI), which then runs the kernel 
(and possibly initramfs) in /boot.  Unfortunately, "boot record" is 
probably too general a term.


Jack


On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote:


Date: Sun, 11 Oct 2020 19:21:49
From: pe...@prh.myzen.co.uk
Reply-To: gentoo-user@lists.gentoo.org
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] UEFI booting again

I'm still wrestling with my system and its not booting.

Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot 
record, or whatever it's called? My machine seems unable to store what I give 
it, and I suspect that the BIOS ROM has failed. Big expense if so.

TiA.

Re: [gentoo-user] UEFI booting again

[Jude DaShiell]

In gentoo in order to make a uefi system is it necessary to use douefi as
a boot parameter when starting the install?  If so, it wasn't in the
handbook I read.  If not, my guess would be gentoo discovers this
information for itself.



--

Re: [gentoo-user] UEFI booting again

[Jude DaShiell]

If you followed the handbook /dev/sda2 would be where the boot record
lives. On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote:

> Date: Sun, 11 Oct 2020 19:21:49
> From: pe...@prh.myzen.co.uk
> Reply-To: gentoo-user@lists.gentoo.org
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] UEFI booting again
>
> I'm still wrestling with my system and its not booting.
>
> Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot 
> record, or whatever it's called? My machine seems unable to store what I give 
> it, and I suspect that the BIOS ROM has failed. Big expense if so.
>
> TiA.
>
>
>
>
>
>
>

-- 

Re: [gentoo-user] UEFI booting again

[Bhaskar Chowdhury]

On 23:21 Sun 11 Oct 2020, pe...@prh.myzen.co.uk wrote:

I'm still wrestling with my system and its not booting.

Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot 
record, or whatever it's called? My machine seems unable to store what I give 
it, and I suspect that the BIOS ROM has failed. Big expense if so.

TiA.


You might give it a shot like this :

https://github.com/unixbhaskar/UEFI_Linux_Boot_Process_From_Userland


Good luck!









signature.asc
Description: PGP signature

[gentoo-user] UEFI booting again

[peter]

I'm still wrestling with my system and its not booting.

Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot 
record, or whatever it's called? My machine seems unable to store what I give 
it, and I suspect that the BIOS ROM has failed. Big expense if so.

TiA.

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Sunday 28 Aug 2016 10:26:15 Mike Gilbert wrote:
> On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey  
wrote:
--->8
> > ... part of the output of "bootctl status":
> > 
> > Boot Loader Binaries:
> >   ESP:
> >   /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
> >  
> >  File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
> >  File: └─/EFI/BOOT/BOOTX64.EFI
> > 
> > Those binaries have been built on my system: by what process?
> 
> When you run bootctl install, it copies
> /usr/lib/systemd/boot/efi/systemd-bootx64.efi to
> /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI.

Ah, so when one of those is started, all it does (for present purposes) is 
to load the kernel specified in the appropriate /boot/loader/entries entry.

> BOOTX64.EFI is only there as a fallback; if your EFI variables get
> reset for some reason, most EFI firmwares will look for a file by that
> name as a failsafe.

I think I'd more-or-less inferred that, but thanks for the confirmation.

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Mike Gilbert]

On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey  wrote:
> On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote:
>> On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote:
>> > I'd still like to know where the directory /usr/lib64/systemd/boot/efi
>> > came from though.
>>
>> Surely it's from systemd-boot, it is installed by systemd here. What does
>> qfile tell you?
>>
>> $ qfile /usr/lib/systemd/boot/efi
>
> Yes, it is. I was puzzling over the wrong thing. Here's part of the output
> of "bootctl status":
>
> Boot Loader Binaries:
>   ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
>  File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
>  File: └─/EFI/BOOT/BOOTX64.EFI
>
> Those binaries have been built on my system: by what process?

When you run bootctl install, it copies
/usr/lib/systemd/boot/efi/systemd-bootx64.efi to
/boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI.

BOOTX64.EFI is only there as a fallback; if your EFI variables get
reset for some reason, most EFI firmwares will look for a file by that
name as a failsafe.

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote:
> On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote:
> > I'd still like to know where the directory /usr/lib64/systemd/boot/efi
> > came from though.
> 
> Surely it's from systemd-boot, it is installed by systemd here. What does
> qfile tell you?
> 
> $ qfile /usr/lib/systemd/boot/efi

Yes, it is. I was puzzling over the wrong thing. Here's part of the output 
of "bootctl status":

Boot Loader Binaries:
  ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
 File: └─/EFI/BOOT/BOOTX64.EFI

Those binaries have been built on my system: by what process?

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Neil Bothwick]

On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote:

> I'd still like to know where the directory /usr/lib64/systemd/boot/efi 
> came from though.

Surely it's from systemd-boot, it is installed by systemd here. What does
qfile tell you?

$ qfile /usr/lib/systemd/boot/efi


-- 
Neil Bothwick

I get enough exercise just pushing my luck.


pgpYREJBNQBOP.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote:
> On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey  wrote:
> > In my search for a suitable boot method, I'm trying Mike G's
> > systemd-boot
> > ebuild. I've installed it with no problem, and now I reach the heart-in-
> > mouth stage of actually replacing gummiboot with it. But first, the
> > backup, including dd of what used to be called the MBR (what is it
> > now?).
> It should be basically a drop-in replacement, with a slightly
> different name. It should not require any modification to your disk
> layout.

I've learned a few things over the last day, and now I have systemd-boot
installed and gummiboot gone (late and somewhat lamented).

# bootctl status
System:
 Firmware: UEFI 2.31 (American Megatrends 5.09)
  Secure Boot: disabled
   Setup Mode: setup

Loader:
  Product: systemd-boot 231
Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Boot Loader Binaries:
  ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
 File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
   ID: 0x0001
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Title: UEFI OS
   ID: 0x000C
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
 File: └─/EFI/BOOT/BOOTX64.EFI

I'd still like to know where the directory /usr/lib64/systemd/boot/efi 
came from though.

https://wiki.archlinux.org/index.php/systemd-boot was the last link I
needed; I hadn't realised until then that bootctl uses the same
/boot/loader/... arrangement as gummiboot, Mike's "drop-in replacement"
comment notwithstanding. I suggest that the Gentoo docs could use a version
of this web page.

> Also, you should be able to configure your firmware to load either
> gummiboot or systemd-boot, so you have a fallback if the new code
> fails.

I did that, but now I'm happy with bootctl I've removed gummiboot.

I took the opportunity of changing the partition layout somewhat. When I
restored all my backups I found errors from polkit and dbus, which were
preventing KDE from running properly. I assume this was because the
partitions had new UUIDs. A quick "emerj -1av $(eix -cI# polkit)" and ditto
dbus fixed it.

alias emerj='sudo emerge --jobs=24 --load-average=48 --keep-going --nospinner'

So thanks to Mike I now have a stable, maintainable system that suits me.

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote:
> On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey  
wrote:
> > In my search for a suitable boot method, I'm trying Mike G's
> > systemd-boot
> > ebuild. I've installed it with no problem, and now I reach the heart-in-
> > mouth stage of actually replacing gummiboot with it. But first, the
> > backup, including dd of what used to be called the MBR (what is it
> > now?).
> It should be basically a drop-in replacement, with a slightly
> different name. It should not require any modification to your disk
> layout.

After running "bootctl install" I now have
bootctl the binary from the systemd-boot package,
gummiboot   the binary from the gummiboot package.

They each install a loader called "Linux Boot Loader" into the EFI 
variables, as you can see from this:

# bootctl status
System:
 Firmware: UEFI 2.31 (American Megatrends 5.09)
  Secure Boot: disabled
   Setup Mode: setup

Loader:
  Product: systemd-boot 231
Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8
 File: └─/EFI/Boot/bootx64.efi

Boot Loader Binaries:
  ESP: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8
 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
 File: └─/EFI/BOOT/bootX64.efi (systemd-boot 231)

Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
   ID: 0x0002
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8
 File: └─/EFI/GUMMIBOOT/GUMMIBOOTX64.EFI

Title: Linux Boot Manager
   ID: 0x0005
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8
 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Title: UEFI OS
   ID: 0x0007
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8
 File: └─/EFI/BOOT/BOOTX64.EFI

This makes identifying them a matter of informed guesswork. Mike, if you 
intend to keep a version of gummiboot around, it might be helpful if it used 
a different entry title.

> Also, you should be able to configure your firmware to load either
> gummiboot or systemd-boot, so you have a fallback if the new code
> fails.

It does appear to have worked so far, though I can't be sure which loader I 
started since they both showed the same list of gummiboot loader entries. I 
think. Another question is where the directory /usr/lib64/systemd/boot/efi 
came from, which bootctl reads from to get its binaries for efivars.

My next step is to create a new partition layout and populate it from 
backups, apart from /boot/EFI and /boot/loader, and omitting gummiboot.

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Mick]

On Saturday 27 Aug 2016 10:19:48 Peter Humphrey wrote:
> On Friday 26 Aug 2016 12:33:47 Mick wrote:
> > On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote:
> > > In my search for a suitable boot method, I'm trying Mike G's
> > > systemd-boot ebuild. I've installed it with no problem, and now I reach
> > > the heart-in-mouth stage of actually replacing gummiboot with it. But
> > > first, the backup, including dd of what used to be called the MBR (what
> > > is it now?).
> > > 
> > > # parted -l
> > > Model: Unknown (unknown)
> > > Disk /dev/nvme0n1: 256GB
> > > Sector size (logical/physical): 512B/512B
> > > Partition Table: gpt
> > > Disk Flags:
> > > 
> > > Number  Start   End SizeFile system Name   Flags
> > > 
> > >  1  1049kB  3146kB  2097kB  uefi   bios_grub
> > >  2  3146kB  144MB   141MB   fat32   boot   boot, esp
> > >  3  144MB   4504MB  4360MB  linux-swap(v1)  swap
> > >  4  4504MB  15.0GB  10.5GB  ext4rescuesys
> > >  5  15.0GB  32.2GB  17.2GB  ext4gentoo
> > >  6  32.2GB  36.5GB  4295MB  ext4var
> > >  7  36.5GB  45.1GB  8590MB  ext4home
> > > 
> > > [...]
> > > 
> > > That start block of the uefi partition looks odd to me.
> > 
> > The 'Name' of the 1st partition is the label you have provided when you
> > created it. It is NOT the type of the partition, which is shown under the
> > 'Flags' column as 'bios_grub'.
> 
> Yes, I know that of course. I called the first partition "uefi" because
> that's what the wiki used, and nothing more suitable suggested itself.
> 
> > The 1st partition was created to accommodate Grub's boot code.
> 
> Now that I didn't know. Well, I was hazy about it anyway.
> 
> > It starts on the first cylinder (change the units in parted to cyl and
> > you'll see it starts at '0 cyl') and has no fs on it.
> 
> Indeed, except that parted doesn't want to use cylinders in its list output.

Run parted:

parted /dev/sda

then set the units e.g. to "MiB", or sectors "s", or cylinders "cyl":

(parted) unit MiB
(parted) p

to see the result.  Then q to quit without changing the table.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote:
> On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey  
wrote:
> > In my search for a suitable boot method, I'm trying Mike G's
> > systemd-boot
> > ebuild. I've installed it with no problem, and now I reach the heart-in-
> > mouth stage of actually replacing gummiboot with it. But first, the
> > backup, including dd of what used to be called the MBR (what is it
> > now?).
> It should be basically a drop-in replacement, with a slightly
> different name. It should not require any modification to your disk
> layout.

No, just the risk of failing to boot. (I'm not paranoid - they really are 
out to get me!)

> Also, you should be able to configure your firmware to load either
> gummiboot or systemd-boot, so you have a fallback if the new code
> fails.

Ah, so I can have both at the same time for testing. That makes me feel less 
nervous.   :)

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Peter Humphrey]

On Friday 26 Aug 2016 12:33:47 Mick wrote:
> On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote:
> > In my search for a suitable boot method, I'm trying Mike G's
> > systemd-boot ebuild. I've installed it with no problem, and now I reach
> > the heart-in-mouth stage of actually replacing gummiboot with it. But
> > first, the backup, including dd of what used to be called the MBR (what
> > is it now?).
> > 
> > # parted -l
> > Model: Unknown (unknown)
> > Disk /dev/nvme0n1: 256GB
> > Sector size (logical/physical): 512B/512B
> > Partition Table: gpt
> > Disk Flags:
> > 
> > Number  Start   End SizeFile system Name   Flags
> > 
> >  1  1049kB  3146kB  2097kB  uefi   bios_grub
> >  2  3146kB  144MB   141MB   fat32   boot   boot, esp
> >  3  144MB   4504MB  4360MB  linux-swap(v1)  swap
> >  4  4504MB  15.0GB  10.5GB  ext4rescuesys
> >  5  15.0GB  32.2GB  17.2GB  ext4gentoo
> >  6  32.2GB  36.5GB  4295MB  ext4var
> >  7  36.5GB  45.1GB  8590MB  ext4home
> > 
> > [...]
> > 
> > That start block of the uefi partition looks odd to me.
> 
> The 'Name' of the 1st partition is the label you have provided when you
> created it. It is NOT the type of the partition, which is shown under the
> 'Flags' column as 'bios_grub'.

Yes, I know that of course. I called the first partition "uefi" because 
that's what the wiki used, and nothing more suitable suggested itself.

> The 1st partition was created to accommodate Grub's boot code.

Now that I didn't know. Well, I was hazy about it anyway.

> It starts on the first cylinder (change the units in parted to cyl and
> you'll see it starts at '0 cyl') and has no fs on it.

Indeed, except that parted doesn't want to use cylinders in its list output.

> > I'm pretty sure I didn't specify a start position to parted when I was
> > constructing the partition layout six months ago, preferring to let the
> > program choose a value itself.
> 
> Parted and friends will create this partition for Grub at the very start
> of the disk, when you use GPT.

Quite so.

> > I do remember, though, that parted had a strange idea of what
> > 2MB meant: it's turned out to be 2097kB.
> 
> You are mixing decimal and binary.  2MiB = 2 x 1024^2 = 2,097,152

Well, it isn't me who's mixing them, but parted. I was operating in MiB 
throughout, as far as I could tell.

> > My question for the panel is whether I need to do anything about that
> > partition layout. What do you think?
> 
> You don't have to do something about it, if you want to retain the ability
> to use Grub.  If you will no longer use grub then you probably do not
> need the first grub-specific partition.

I hope I never have to look at grub-2 again. All the same, 2MiB is a small 
enough price to pay for flexibility.

> As shown above the second partition is your EFI partition. 141MB may not
> be enough to store many kernel images, but it depends on how many kernel
> images and initramfs you keep in there at any time.

I expect to hold two or three kernels in the boot partition: the latest, a 
recent known-working one and perhaps a long-term one. I haven't needed an 
initramfs yet.

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting

[Mike Gilbert]

On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey  wrote:
> In my search for a suitable boot method, I'm trying Mike G's systemd-boot
> ebuild. I've installed it with no problem, and now I reach the heart-in-
> mouth stage of actually replacing gummiboot with it. But first, the backup,
> including dd of what used to be called the MBR (what is it now?).

It should be basically a drop-in replacement, with a slightly
different name. It should not require any modification to your disk
layout.

Also, you should be able to configure your firmware to load either
gummiboot or systemd-boot, so you have a fallback if the new code
fails.

Re: [gentoo-user] UEFI booting

[Neil Bothwick]

On Fri, 26 Aug 2016 12:33:47 +0100, Mick wrote:

> You don't have to do something about it, if you want to retain the
> ability to use Grub.  If you will no longer use grub then you probably
> do not need the first grub-specific partition.  

You don't need to anyway. You only need that partition when using GPT on
a non-UEFI system. GRUB will boot from the UEFI ESP quite happily,
although not on Peter's system for some reason.

This is how I have partitioned my NVMe drive for UEFI booting (using
bootctl, which is the same as systemd-boot)

GPT fdisk (gdisk) version
1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 0EB51C66--494C-80F3-9ACB1D95325D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)End (sector)  Size   Code  Name
   12048 2099199   1024.0 MiB  EF00  boot
   2 209920018876415   8.0 GiB 8200  swap
   318876416   250069646   110.2 GiB   8300  root


-- 
Neil Bothwick

Never ask a geek why, just nod your head and slowly back away


pgpWTKnEPhaVh.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] UEFI booting

[Mick]

On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote:
> Hello list,
> 
> In my search for a suitable boot method, I'm trying Mike G's systemd-boot
> ebuild. I've installed it with no problem, and now I reach the heart-in-
> mouth stage of actually replacing gummiboot with it. But first, the backup,
> including dd of what used to be called the MBR (what is it now?).
> 
> # parted -l
> Model: Unknown (unknown)
> Disk /dev/nvme0n1: 256GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start   End SizeFile system Name   Flags
>  1  1049kB  3146kB  2097kB  uefi   bios_grub
>  2  3146kB  144MB   141MB   fat32   boot   boot, esp
>  3  144MB   4504MB  4360MB  linux-swap(v1)  swap
>  4  4504MB  15.0GB  10.5GB  ext4rescuesys
>  5  15.0GB  32.2GB  17.2GB  ext4gentoo
>  6  32.2GB  36.5GB  4295MB  ext4var
>  7  36.5GB  45.1GB  8590MB  ext4home
> [...]
> 
> That start block of the uefi partition looks odd to me. 

The 'Name' of the 1st partition is the label you have provided when you 
created it.  It is NOT the type of the partition, which is shown under the 
'Flags' column as 'bios_grub'.  The 1st partition was created to accommodate 
Grub's boot code.   It starts on the first cylinder (change the units in parted 
to cyl and you'll see it starts at '0 cyl') and has no fs on it.

> I'm pretty sure I
> didn't specify a start position to parted when I was constructing the
> partition layout six months ago, preferring to let the program choose a
> value itself. 

Parted and friends will create this partition for Grub at the very start of 
the disk, when you use GPT.  If you stay with a conventional msdos partition 
table, then the first partition starts at cylinder 63 allowing enough space for 
MBR to store its boot code in the unallocated cylinders 0 to 62.


> I do remember, though, that parted had a strange idea of what
> 2MB meant: it's turned out to be 2097kB.

You are mixing decimal and binary.  2MiB = 2 x 1024^2 = 2,097,152


> My question for the panel is whether I need to do anything about that
> partition layout. What do you think?

You don't have to do something about it, if you want to retain the ability to 
use Grub.  If you will no longer use grub then you probably do not need the 
first grub-specific partition.  


As shown above the second partition is your EFI partition. 141MB may not be 
enough to store many kernel images, but it depends on how many kernel images 
and initramfs you keep in there at any time.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] UEFI booting

[Peter Humphrey]

Hello list,

In my search for a suitable boot method, I'm trying Mike G's systemd-boot 
ebuild. I've installed it with no problem, and now I reach the heart-in-
mouth stage of actually replacing gummiboot with it. But first, the backup, 
including dd of what used to be called the MBR (what is it now?).

# parted -l
Model: Unknown (unknown)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system Name   Flags
 1  1049kB  3146kB  2097kB  uefi   bios_grub
 2  3146kB  144MB   141MB   fat32   boot   boot, esp
 3  144MB   4504MB  4360MB  linux-swap(v1)  swap
 4  4504MB  15.0GB  10.5GB  ext4rescuesys
 5  15.0GB  32.2GB  17.2GB  ext4gentoo
 6  32.2GB  36.5GB  4295MB  ext4var
 7  36.5GB  45.1GB  8590MB  ext4home
[...]

That start block of the uefi partition looks odd to me. I'm pretty sure I 
didn't specify a start position to parted when I was constructing the 
partition layout six months ago, preferring to let the program choose a 
value itself. I do remember, though, that parted had a strange idea of what 
2MB meant: it's turned out to be 2097kB.

My question for the panel is whether I need to do anything about that 
partition layout. What do you think?

-- 
Rgds
Peter

Re: [gentoo-user] UEFI booting [solved]

[Rod]

On 08/17/2015 11:37 PM, Jeremi Piotrowski wrote:

On Mon, 17 Aug 2015, Rod wrote:

 Hi list,

Hi


 I'm trying to figure out how to make my boot partition to boot from UEFI,
I have grub2 installed, but I keep getting a error when I ask it to install
the boot information.

First things first, are you installing gentoo from an UEFI booted
installation media? From what I know the gentoo minimal install cd does
not allow for this, and I will assume you are using that.

If you're using some other installation method, check whether the
directory /sys/firmware/efi/efivars has any content, try to mount efivarfs
following the instructions in this link:

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

and then check again.


# efibootmgr
efibootmgr: EFI variables are not supported on this system.


# grub2-install --target=x86_64-efi /dev/sdc
Installing for x86_64-efi platform.
efibootmgr: EFI variables are not supported on this system.
efibootmgr: EFI variables are not supported on this system.
Installation finished. No error reported.

In your case it seems that the system is not in an UEFI-booted state. But
we can work around this by using a nice part of the UEFI specification,
details below.


mount
/dev/sdc1   201633156 201478   1% /boot/efi

 I have the /boot/efi part mounted ok..

Before we go further make sure that the partition is a valid EFI boot
partition: code EF00 (gdisk), partition flags boot/esp (for parted).


 How can I get this UEFI be become bootable without media to make it boot
in to that mode to begin with ?

It's actually much easier than it may seem, and it's outlined here:

https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location

Basically, for all sorts of removable media there must be a way to tell
UEFI what to boot without having to hardcode the entries into NVRAM (like
efibootmgr does). Therefore UEFI firmware is supposed to check for the
first ESP partition on a drive and boot \EFI\boot\bootx64.efi from it.
This also works for harddrives, and since you can access a FAT partition
even when booted in bios mode you just put grub there.

Now this works perfectly well for a linux kernel with efi stub and cmdline
built-in, but grub may have trouble finding it's configuration files, I do
not know. So I suggest you try it. Find grubx64.efi in /boot/efi and copy
it to /boot/efi/EFI/BOOT/BOOTX64.EFI. Voila, should boot just fine.

On my first UEFI install I did not know about this, efibootmgr did not
work, but the handbook says to place the kernel at /EFI/boot/bootx64.efi
and it just magically worked.

Generally you will find that provided the UEFI implementation of your
vendor is not complete shit (lots of them exist) UEFI makes it generally
easier to handle booting. One partition and the EFI variables and you can
boot anything, no more hidden sectors.


Ok, thnks for your help, all was checked out as you said, the boot 
partition was correct, boot, esp which was a good thing.



Just found a slight problem, my .efi program that the system was 
trying to boot was /boot/efi/EFI/gentoo/grubx64.efi


copying the .efi to /boot/efi/EFI/BOOT changed nothing, I filed to 
notice that the name was incorrect, as installing the UEFI with the 
bootloader (without the efivar loaded) resulted in a file named 
grubx86.efi which doesn't work when copied in to the BOOT directory :(


Renaming this file-  mv grubx86.efi bootx86.efi

System now happily boots in UEFI mode, I guess I didn't read Find 
grubx64.efi in /boot/efi and copy it to /boot/efi/EFI/BOOT/BOOTX64.EFI 
correctly :P


during this time, the original sda drive I was using failed (SMART 
was reporting that I should replace it soon) and I guess it was slightly 
too soon, but I did have the chance to rsync the filesystem across :P


Thanks heaps for your help :)

--
---

  Regards,
   
  Rod Smart

  0417 513 286

Re: [gentoo-user] UEFI booting

[microcai]

2015-08-17 20:59 GMT+08:00 Rod r...@rods.id.au:
 Hi list,

 I'm trying to figure out how to make my boot partition to boot from
 UEFI, I have grub2 installed, but I keep getting a error when I ask it to
 install the boot information.

 mount
 /dev/sdc1   201633156 201478   1% /boot/efi

 I have the /boot/efi part mounted ok..

 # efibootmgr
 efibootmgr: EFI variables are not supported on this system.


 # grub2-install --target=x86_64-efi /dev/sdc
 Installing for x86_64-efi platform.
 efibootmgr: EFI variables are not supported on this system.
 efibootmgr: EFI variables are not supported on this system.
 Installation finished. No error reported.

 I have this disk as my 1st boot drive in BIOS, the 2nd is the normal
 drive.

 Boot order is EFI then Legacy  (EFI only tells me Insert boot disk and
 hit Enter)


if you see Insert boot disk and hit Enter then you are not using EFI
mode. it is printed by MS DOS bootloader, aka , the MBR.


 I'm assuming the variables not supported is blocking the install.


 BIOS reports the 1st disk to boot is

 EFI: ST2000DM001-1ER1


 Mobo is a Gigabyte Z68X-UD3H-B3  (with the latest UEFI firmware)

 How can I get this UEFI be become bootable without media to make it boot
 in to that mode to begin with ?

 --
 ---

   Regards,
  Rod Smart
   0417 513 286

Re: [gentoo-user] UEFI booting

[Jeremi Piotrowski]

On Mon, 17 Aug 2015, Rod wrote:
 Hi list,

Hi

 I'm trying to figure out how to make my boot partition to boot from UEFI,
 I have grub2 installed, but I keep getting a error when I ask it to install
 the boot information.

First things first, are you installing gentoo from an UEFI booted 
installation media? From what I know the gentoo minimal install cd does 
not allow for this, and I will assume you are using that.

If you're using some other installation method, check whether the 
directory /sys/firmware/efi/efivars has any content, try to mount efivarfs 
following the instructions in this link: 

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

and then check again.

 # efibootmgr
 efibootmgr: EFI variables are not supported on this system.
 
 
 # grub2-install --target=x86_64-efi /dev/sdc
 Installing for x86_64-efi platform.
 efibootmgr: EFI variables are not supported on this system.
 efibootmgr: EFI variables are not supported on this system.
 Installation finished. No error reported.

In your case it seems that the system is not in an UEFI-booted state. But 
we can work around this by using a nice part of the UEFI specification, 
details below.

 mount
 /dev/sdc1   201633156 201478   1% /boot/efi
 
 I have the /boot/efi part mounted ok..

Before we go further make sure that the partition is a valid EFI boot
partition: code EF00 (gdisk), partition flags boot/esp (for parted).  

 How can I get this UEFI be become bootable without media to make it boot
 in to that mode to begin with ?

It's actually much easier than it may seem, and it's outlined here: 

https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location

Basically, for all sorts of removable media there must be a way to tell
UEFI what to boot without having to hardcode the entries into NVRAM (like
efibootmgr does). Therefore UEFI firmware is supposed to check for the
first ESP partition on a drive and boot \EFI\boot\bootx64.efi from it.
This also works for harddrives, and since you can access a FAT partition
even when booted in bios mode you just put grub there.

Now this works perfectly well for a linux kernel with efi stub and cmdline
built-in, but grub may have trouble finding it's configuration files, I do
not know. So I suggest you try it. Find grubx64.efi in /boot/efi and copy
it to /boot/efi/EFI/BOOT/BOOTX64.EFI. Voila, should boot just fine. 

On my first UEFI install I did not know about this, efibootmgr did not 
work, but the handbook says to place the kernel at /EFI/boot/bootx64.efi 
and it just magically worked.

Generally you will find that provided the UEFI implementation of your
vendor is not complete shit (lots of them exist) UEFI makes it generally
easier to handle booting. One partition and the EFI variables and you can
boot anything, no more hidden sectors.

Re: [gentoo-user] UEFI booting

[Alec Ten Harmsel]

On Mon, Aug 17, 2015 at 10:59:30PM +1000, Rod wrote:
  Hi list,
 
 # efibootmgr
 efibootmgr: EFI variables are not supported on this system.
 
 
 # grub2-install --target=x86_64-efi /dev/sdc
 Installing for x86_64-efi platform.
 efibootmgr: EFI variables are not supported on this system.
 efibootmgr: EFI variables are not supported on this system.
 Installation finished. No error reported.
 

I haven't done a UEFI install in a while, but the first thing that comes
to mind is that you haven't booted your install medium in UEFI mode.
What install media are you using and how did you boot it?

Alec

[gentoo-user] UEFI booting

[Rod]

Hi list,

I'm trying to figure out how to make my boot partition to boot from 
UEFI, I have grub2 installed, but I keep getting a error when I ask it 
to install the boot information.


mount
/dev/sdc1   201633156 201478   1% /boot/efi

I have the /boot/efi part mounted ok..

# efibootmgr
efibootmgr: EFI variables are not supported on this system.


# grub2-install --target=x86_64-efi /dev/sdc
Installing for x86_64-efi platform.
efibootmgr: EFI variables are not supported on this system.
efibootmgr: EFI variables are not supported on this system.
Installation finished. No error reported.

I have this disk as my 1st boot drive in BIOS, the 2nd is the 
normal drive.


Boot order is EFI then Legacy  (EFI only tells me Insert boot disk 
and hit Enter)



I'm assuming the variables not supported is blocking the install.


BIOS reports the 1st disk to boot is

EFI: ST2000DM001-1ER1


Mobo is a Gigabyte Z68X-UD3H-B3  (with the latest UEFI firmware)

How can I get this UEFI be become bootable without media to make it 
boot in to that mode to begin with ?


--
---

  Regards,
   
  Rod Smart

  0417 513 286