You are not logged in.
I have Dell XPS 8700, and I can't figure out which file extension for keys is acceptable. After a few tries of enrolling PKs, the PC won't boot at all, so I have to reset BIOS setup. The local Dell technical support said it doesn't work with software (I mean, it isn't software, huh?)
Offline
what does "the PC won't boot at all" mean?
what did you do exactly to enroll PKs in the bios, can you provide screen shots? in what order?
did you also sign your bootloader (or whatever you boot).
secure-boot is not trivial, and your question is missing a lot of details, so try to be as elaborate as you can.
Offline
what does "the PC won't boot at all" mean?
what did you do exactly to enroll PKs in the bios, can you provide screen shots? in what order?
did you also sign your bootloader (or whatever you boot).secure-boot is not trivial, and your question is missing a lot of details, so try to be as elaborate as you can.
You know the situation when you turn on your PC and the screen doesn't change from black? It doesn't show anything.
So first I copied all my key files to an external storage, reboot, goto key management, clear everything. Setup the keys in this order: DB, KEK, PK (I bet I enrolled .auth files, can't say precisely). Reboot, BAM - black screen.
About bootloader... I didn't think this is also a step for secure boot activation (must be grubx64.efi and vmlinuz-linux, am I right?), none of wikis actually pointed that out clearly.
UPD: hope these'll fit for "screenshots": https://imgur.com/a/5qFDMgL
Pic #2: I cleared them at that moment
Pic #5: here I picked "db.key", and when chose "Uefi Secure Variable", the Pic #6 follows
Last edited by xt1zer (2019-01-21 14:07:48)
Offline
You know the situation when you turn on your PC and the screen doesn't change from black? It doesn't show anything.
If you don't see any BIOS / EFI splash screen and / or POST messages, you most likely have a hardware issue, probably with your mainboard.
Offline
xt1zer wrote:You know the situation when you turn on your PC and the screen doesn't change from black? It doesn't show anything.
If you don't see any BIOS / EFI splash screen and / or POST messages, you most likely have a hardware issue, probably with your mainboard.
Yes, sir. And this happens after I clear the PK.
Offline
You know the situation when you turn on your PC and the screen doesn't change from black? It doesn't show anything.
Did you try enabling boot menu in the bios,typically it's F12. What does it show.
Setup the keys in this order: DB, KEK, PK (I bet I enrolled .auth files, can't say precisely).
that's the correct order. and yes, the .auth files need to be enrolled.
now, once you do that, secure boot is enabled, and your PC won't boot any uefi executable that's not signed with your key (with the db.key).
paste the output of efibootmgr -v
Offline
Did you try enabling boot menu in the bios,typically it's F12. What does it show.
Nothing. Just nothing. Void. Emptiness. Hollow. Black hole.
yes, the .auth files need to be enrolled.
Is this definitely applicable for every single UEFI supported motherboard in the cruel world? What if my firmware can't really define if .auth is the right file? As said in the OP, it will accept, but not boot afterwards, until I take my PC apart and reset BIOS completely. I don't want to repeat it, because then I'll have to boot from bootable Arch image and setup the efi entries once again.
now, once you do that, secure boot is enabled, and your PC won't boot any uefi executable that's not signed with your key (with the db.key).
If so, I'll need to sign the kernel first (and proprietary driver modules, such as Nvidia), am I right?
Before I do anything else, here's my efibootmgr output:
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0003,0000,0001
Boot0000* P0: ST1000DM003-1CH162 BBS(17,,0x0)
Boot0001* P1: MATSHITA DVD+/-RW SW830 BBS(19,,0x0)
Boot0003* Windows Boot Manager HD(5,GPT,6086c89f-d64a-48b1-9126-113fcf0b3171,0x5bf519b8,0x113000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0005* GRUB HD(5,GPT,6086c89f-d64a-48b1-9126-113fcf0b3171,0x5bf519b8,0x113000)/File(\EFI\GRUB\grubx64.efi)
UPD: forgot to mention, I dual boot with Win10
Also, no article in the world describes any action with dbx. Shall it remain empty or default for my board?
UPD1: this is hella confusing. The Arch wiki says the kernel and bootloader describes signing with .crt files with the following example here. Does it mean .auth still stays for enrollment, just as agreed?
Last edited by xt1zer (2019-01-22 10:10:01)
Offline
Okay, I figured something out, but I sacrificed about an hour on this again, because the BIOS messed up after I pushed the wrong PK file. So I successfully enrolled the .auth keys and the OS is bootable again. Previously the kernel, bootloader (\EFI\Grub\grubx64.efi) and boot-thing (\EFI\Boot\bootx64.efi) were signed with the db.key and db.crt, just like it's told in the guide mentioned above. Still, the similar message appeared:
http://helpadmins.ru/wp-content/uploads/2017/06/1.jpg
After that, I don't really know what to do, except enrolling the keys by software.
Last edited by 2ManyDogs (2019-01-22 14:32:36)
Offline
Please read the Code of Conduct and post only thumbnails or links to images, and use [ code ] tags for output.
Moving to Newbie Corner.
How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.
Offline
.auth files are what UEFI firmwares understand, and those are the files that you enroll.
.key and .crt are standard PEM format files that most Linux tools work with.
ps.
you can test secure boot in qemu/kvm too, just run a VM with the -bios /usr/share/ovmf/x64/OVMF_CODE.fd option
Last edited by damjan (2019-01-22 17:29:03)
Offline
Hey, if you care to read, I've posted the issue in reddit: https://www.reddit.com/r/linuxquestions … =8&depth=9
Thought to share it instead of rewriting all updates, since it's more active
Offline
first of all, are you sure you're using the same keys to sign /EFI/Grub/grubx64.efi as the one that you enrolled?
next, make sure it didn't already have a signature, my BIOS for example, doesn't like it when I sign an already signed .efi file, so:
sbattach --remove grubx64.efi
sbsign --key .. --cert ... grubx64.efi -o grubx64.efi.signed
mv grubx64.efi.signed grubx64.efi
Offline
first of all, are you sure you're using the same keys to sign /EFI/Grub/grubx64.efi as the one that you enrolled?
next, make sure it didn't already have a signature, my BIOS for example, doesn't like it when I sign an already signed .efi file, so:sbattach --remove grubx64.efi sbsign --key .. --cert ... grubx64.efi -o grubx64.efi.signed mv grubx64.efi.signed grubx64.efi
If "sbverify --list" doesn't lie, then all loaders are empty. Also, yes, I checked twice that I use the same files to sign both grubx64.efi and vmlinuz-linux, which are db.key and db.crt
Offline