https://packages.debian.org/sid/linux-i ... d64-signedThe kernel image and modules are signed for use with Secure Boot.
I will try this out this weekend and report back!
https://packages.debian.org/sid/linux-i ... d64-signedThe kernel image and modules are signed for use with Secure Boot.
Code: Select all
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0006,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.w. .r.o.o.t.f.l.a.g.s.=.s.u.b.v.o.l.=.s.i.d. .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.
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)
As far as I can ascertain, the kernel image is signed but it requires a package equivilent to Ubuntu's grub-efi-$arch-signed for it to boot sucessfully.tomazzi wrote:1. The UEFI/SecureBoot is fully documented - so actually where's the problem?
I have had my Debian jessie system booting with Secure Boot enabled for over a year now, we don't actually need Ubuntu's solution at all...2. Apparently the Ubuntu already works with SecureBoot enabled -> solution already exists -> there's nothing to invent.
The subject of this thread is getting Debian to work with Secure Boot enabled, please start a new thread in off-topic for ramblings of this nature.Since the SecureBoot doesn't offer any real improvement of the OS security and the UEFI implementation allows to easily brick the motherboard, the obvious, but rethorical question is: Where's that "gain"?
Personally, I would try an alternative EFI boot manager, like rEFInd.Head_on_a_Stick wrote:I am slightly confused though as to why the kernel image will not boot directly without a bootloader (taking advantage of CONFIG_EFI_STUB) when Secure Boot is enabled.
Do you have any ideas why this may be the case?
Thanks for the suggestion but rEFInd is simply an abstraction for the EFI_STUB booting process which I have already tried (without the abstraction).tomazzi wrote: I would try an alternative EFI boot manager, like rEFInd.
I already use btrfs:tomazzi wrote:maybe it likes to be kick-started directly from a native fs partition (like btrfs)
Code: Select all
root@sid:~# wipefs /dev/sda3
offset type
----------------------------------------------------------------
0x1fe dos [partition table]
0x10040 btrfs [filesystem]
UUID: 347fcad5-6e39-4c73-ab69-710b4077051f
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.