Hi!

I've recently opted for enabling secure boot on all my computers, and success came easy with all of them save my primary (the R5E). In that box, I kept getting blocked by a failure to enroll an MOK in UEFI from Linux (Ubuntu Bionic) using mokutil.

The invocation to

mokutil --import ${mok_key_file}.der

would successfully request the passwords, but then fail miserably when trying to update the UEFI variables. Running an STrace on the process I'm able to see it create the MokNew variable, as expected, but then gets an EINVAL error when trying to unlink() the same "file" (in /sys/firmware/efi/efivars). As to why it's trying to unlink() a file it just created moments earlier, I don't know.

What I do know is that when I run an rm on the (empty, invalid) MokNew variable that failed to unlink earlier, everything is honkey dorey and I can remove the file.

So...

My first instinct is to think of an issue with mokutil, but then I realize that it worked flawlessly in 4 different computers with different hardware so far (I can only presume following the same create-then-unlink() pattern as is failing here).

Then I also realize that mokutil is also unable to alter the secure boot mode (

mokutil --enable-validation

or

mokutil --disable-validation

) with a similar issue (the error is "Failed to request new MokSB state"). Booting the kernel with efi_no_storage_paranoia was no help (I thought perhaps the UEFI NVRAM was running low).

So I ask you, oh R5E gods: any ideas?

I know I could try to import the certificate directly into the DB, but that's probably not the correct way to do the enrollment. Yes, it would work, but it's not consistent with how things SHOULD be done. And I'd very much like to keep the secure boot encryption stuff as kosher as possible.

So...thoughts?

Thanks!