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

[Mick]

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