On Tue, 1 Oct 2019 at 12:01, Peter Humphrey <pe...@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
