[gentoo-user] UEFI booting

[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                   201633        156     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

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

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                   201633        156     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

[microcai]

2015-08-17 20:59 GMT+08:00 Rod <Rod@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                   201633        156     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
>
>

[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     Size    File 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  ext4            rescuesys
 5      15.0GB  32.2GB  17.2GB  ext4            gentoo
 6      32.2GB  36.5GB  4295MB  ext4            var
 7      36.5GB  45.1GB  8590MB  ext4            home
[...]

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

[Mick]

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

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     Size    File 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  ext4            rescuesys
>  5      15.0GB  32.2GB  17.2GB  ext4            gentoo
>  6      32.2GB  36.5GB  4295MB  ext4            var
>  7      36.5GB  45.1GB  8590MB  ext4            home
> [...]
> 
> 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

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

Re: [gentoo-user] UEFI booting

[Neil Bothwick]

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

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-3333-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
   1            2048         2099199   1024.0 MiB  EF00  boot
   2         2099200        18876415   8.0 GiB     8200  swap
   3        18876416       250069646   110.2 GiB   8300  root


-- 
Neil Bothwick

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

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

Re: [gentoo-user] UEFI booting

[Mike Gilbert]

On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey <peter@prh.myzen.co.uk> 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

[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     Size    File 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  ext4            rescuesys
> >  5      15.0GB  32.2GB  17.2GB  ext4            gentoo
> >  6      32.2GB  36.5GB  4295MB  ext4            var
> >  7      36.5GB  45.1GB  8590MB  ext4            home
> > 
> > [...]
> > 
> > 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

[Peter Humphrey]

On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote:
> On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey <peter@prh.myzen.co.uk> 
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

[Mick]

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

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     Size    File 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  ext4            rescuesys
> > >  5      15.0GB  32.2GB  17.2GB  ext4            gentoo
> > >  6      32.2GB  36.5GB  4295MB  ext4            var
> > >  7      36.5GB  45.1GB  8590MB  ext4            home
> > > 
> > > [...]
> > > 
> > > 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

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

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 <peter@prh.myzen.co.uk> 
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

[Peter Humphrey]

On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote:
> On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey <peter@prh.myzen.co.uk> 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

[Neil Bothwick]

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

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.

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

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

[Mike Gilbert]

On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey <peter@prh.myzen.co.uk> 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:26:15 Mike Gilbert wrote:
> On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey <peter@prh.myzen.co.uk> 
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