I have a bit of an odd issue with my Surface Pro 3, which is running Debian 12.
Occasionally (perhaps 1 in 15 to 20 boots) it fails to detect the keyboard properly (this is a genuine Microsoft keyboard cover that connects via the pins on the edge of the Surface, not one of the generic bluetooth ones you can get now). When that happens, the onscreen keyboard logo appears in the top right corner whilst the grub boot menu is displayed.
When it then tries to boot Debian, it throws some kind of Secure Boot error and displays this error message:
SbatLevel variable initialization failed
Something has gone seriously wrong: SbatLevel UEFI variable setting failed: Invalid Parameter
I then have to force it to power off and then try booting again. Usually it works the next time around.
This one’s got me stuck, as I don’t know much about the Secure Boot process and I’ve struggled to find any other references to this error online apart from this question on Reddit (which unfortunately didn’t resolve it).
I find it particularly odd that this error only seems to occur when there’s an issue with the physical keyboard, despite me being able to use the onscreen keyboard in grub. I can replicate this behaviour by detaching the keyboard and it consistently produces this error.
Apart from trying to address the intermittent keyboard issues, which I am looking into (I may need to buy a new one), I have no idea where to start with the Secure Boot issue. Any suggestions would be much appreciated. Thanks.
So based on @[email protected]’s advice, I had a look at RHEL and found this:
https://github.com/rhboot/shim/ https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt https://github.com/rhboot/shim/blob/main/SBAT.md#uefi-sbat-variable-content
Debian’s own shim repo (https://salsa.debian.org/efi-team/shim) seems to derive from this. Shim is apparently the bootloader application that is reporting the error I’m seeing.
Unfortunately still no idea what causes the issue (let alone why it’s correlated with the keyboard), but it makes me wonder if somehow the contents of the SbatLevel variable aren’t formatted correctly in the absence of the keyboard cover.
More digging required.
The shim is the secure boot key that slides under the Microsoft package key on your machine. There is a US department of defense PDF floating around that goes into how to set your own keys in UEFI but your bootloader form the OEM may not include all of the UEFI stuff to do this in the user interface. There is a way to boot into UEFI ad set keys manually. The tool is called Keytool. Gentoo has a guide but it is written for advanced competency (beyond mine).
As far as I am aware, only the base vanilla Ubuntu is signed under the shim key for Debian. All of the official Fedora distros are under their shim IIRC. The unofficials like Silverblue are not – again IIRC.
The shim is only available to the person that is the final package maintainer for the distro. They have a key signed by Microsoft so that you are literally using the Windows key to sign the bootable code of the distro. This comes with headaches as you will not be able to modify and run kernel bootable executable stuff, but that may not matter to you. In particular, it makes Nvidia stuff a pain in the ass if you need to freeze or alter the kernel module driver in some way.
The Microsoft key is the second level key, sorry I forget the names of the levels. I know one is called the Package Key but I forget the other and which level is higher by name. The higher level key is the one from the manufacturer. They can send or possibly force updates to UEFI using this key. These keys are also compromised from time to time so there is that too. The fact you can boot into UEFI sounds scary AF to me and my paranoid ass but whatever. The MINIX system always running in the background of x86 is another (Intel ME/AMD has equivalent).
You don’t have to change your keys but you can if you wish, or you’re supposed to be able to. If you sign your own key at the highest level (manufacturer), then you can use a Microsoft website to get a new key at the OS level and use it. Then you fully control Secure Boot and your UEFI. I recommend looking up the PDF. If you search Lemmy I have talked about it with people a few times and linked it but I don’t have it bookmarked and am too lazy to go find it for you right now. That guide goes through the details in a very approachable way intended for competent people in general but not niche IT or CS grad level like how Arch or Gentoo tend to write, it was very RHEL level approachable.
i don’t know, but I’m typing on a SP3 right now, so saving this. I’ve seen the keyboard act up like this once in a while, though not on linux. otherwise it’s solid hardware, which is good, because it seems impossible to repair.
Look up Gentoo, Arch, and RHEL for documentation. You can also reference linux-hardware.org to potentially check what others are running. Scan and uploaded your stuff to share with others too. It is easy and only takes a minute.
UEFI is a can of worms. I don’t know enough to be more helpful. When messing with SB keys, Gentoo had good info when I needed it. Fedora uses the Anaconda system for SB stuff and is quite advanced. That is another place to look for clues.
Thanks, I will check out those resources and see what I can find.
