[Nursie]

Thanks, yeah I think I came across sbctl when I was playing around with it. Haven't tried it yet... it got a little confusing when I was reading various guides to try to achieve what I've been trying to achieve, and they started referring to various different tool sets!

I'll have a go with it to enroll some keys and see if they persist. mokutil, and then rebooting into shim to persist them, has failed me. It all seems to go OK and then they're just not there on the next boot.

On hibernation, that makes sense. I hadn't read into the reasoning, just got as far as "MS allows it in secure boot mode, linux devs consider it insecure by design" or some such thing.

[Operative0198]

You don't need any other tools sets when using sbctl to enroll and sign your keys. It's a one-stop shop for creating UKI bundles and signing them. I use systemd-boot with UKIs created by it and it has no issues detecting the UKIs. Maybe your problem is holding on to grub(legacyware IMO) which has poor support for what you are trying to accomplish.

Hibernation support in lockdown has nothing do with the MS politics around secure boot. You can generate and use your own keys to use with secureboot. The issue is that "accessible" unencrypted hibernation files invalidate secureboot when you can break into RAM and modify system images/files.

[Nursie]

> Maybe your problem is holding on to grub(legacyware IMO)

My problem is that I can't enroll keys, going through the enroll procedure (which doesn't involve grub) results in ... nothing.

I'm not specifically wedded to grub, and a UKI signed with a key is a fine idea if I can get a key installed. As such, I'll try sbctl but I have no particular reason to think it will work where shim/mokmanager fail if there's a motherboard issue of some sort.

There may well be challenges using grub down the line, but right now I'm not even getting far enough for that to be an issue.