I installed refind and ran `refind-install`tomazzi wrote:I would try an alternative EFI boot manager, like rEFInd
The system starts fine and shows a (working) rEFInd menu but fails to start with Secure Boot enabled.
I installed refind and ran `refind-install`tomazzi wrote:I would try an alternative EFI boot manager, like rEFInd
Nope, As You said (in previous posts), You've copied the kernel image to the EFI partition?? - or am I missing something?Head_on_a_Stick wrote:I already use btrfs:
This is a bit strange...Head_on_a_Stick wrote:I installed refind and ran `refind-install`
The system starts fine and shows a (working) rEFInd menu but fails to start with Secure Boot enabled.
Are you confused?tomazzi wrote:Nope, As You said (in previous posts), You've copied the kernel image to the EFI partition?? - or am I missing something?Head_on_a_Stick wrote:I already use btrfs:
What would this accomplish? Anyway, systemd has already fsck'd the ESPa) fsck the EFI partition
b) compare copies of files in the EFI partition with originals, f.e. using 'cmp' command (bit by bit)
Code: Select all
root@sid:~# efibootmgr -v
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0001,0000,0006,0007,0005
Boot0000* Debian sid HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\sid\vmlinuz)r.o.o.t.=./.d.e.v./.s.d.a.3. .r.o.o.t.f.l.a.g.s.=.s.u.b.v.o.l.=.s.i.d. .r.w. .q.u.i.e.t. .z.s.w.a.p...e.n.a.b.l.e.d.=.1. .e.l.e.v.a.t.o.r.=.n.o.o.p. .i.n.i.t.r.d.=./.s.i.d./.i.n.i.t.r.d...i.m.g.
Boot0001* rEFInd Boot Manager HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\refind\refind_x64.efi)
Boot0005* UEFI OS VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* UEFI OS HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* ubuntu HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\Ubuntu\grubx64.efi)
I think I'm not...Head_on_a_Stick wrote:Are you confused?
Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
Nope, this doesn't mean anything - even slightly modified image can be still able to boot, but it won't pass the checksum verification.Head_on_a_Stick wrote:The Debian kernel images that I have copied to the ESP boot just fine with Secure Boot disabled so clearly there is no corruption.
fsck is simply not checking the correctness of the files - it's just checking consistency of the file system - those are 2 different things.Head_on_a_Stick wrote:What would this accomplish? Anyway, systemd has already fsck'd the ESP
I'm sorry, I don't understand what you mean here.tomazzi wrote:Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
I'm talking about the possibility to boot the kernel directly off the btrfs partition.Head_on_a_Stick wrote:I'm sorry, I don't understand what you mean here.tomazzi wrote:Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
I suppose that one of trivial reasons for this bug can be that the kernel image file (or in fact any other file) has different physical representation under FAT and other filesystems, so buggy UEFI firmware has a lot of space for generating various errors, starting from wrong alignment of the image data in the memory (what will cause EFI loader to crash), ending up with wrong calculation of the file checksum -> SecureBoot will fail.To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
Interesting result when I tried to sign the Debian sid kernel image with my (self-generated) keys:Head_on_a_Stick wrote:I will try signing the Debian GRUB .efi loader and updating the key DB on my motherboard using the tools provided by Arch and report back...
Code: Select all
empty@Arch ~ % sudo sbsign --key db.key --cert db.crt /boot/sid/vmlinuz
Image was already signed; adding additional signature
Head_on_a_Stick wrote:Head_on_a_Stick wrote:
EDIT: It seems that the Secure Boot implementation on my MB is b0rked, I will have to try different hardware.
I read somewhere that Macs don't use the ESP for booting. The ESP is there but used as a staging area for firmware updates instead. So it's not a bug, but Apple's alternative implementation of UEFI, I guess.tomazzi wrote:This could be important factor, because UEFI has tons of bugs, and one of them is really interesting:
http://www.rodsbooks.com/refind/drivers.htmlTo the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
There's no such thing as an "alternative" implementation - the standard is clear. If Apple would implement "a bad/unexpected behaviour", then it's simply no longer a "secure boot" - it's "something else" - an unspecified proprietary "solution"...phenest wrote:Apple's alternative implementation of UEFI