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