this post was submitted on 30 Jun 2025
10 points (100.0% liked)

Linux Questions

2108 readers
10 users here now

Linux questions Rules (in addition of the Lemmy.zip rules)

Tips for giving and receiving help

Any rule violations will result in disciplinary actions

founded 2 years ago
MODERATORS
possiblylinux127@lemmy.zip
10
Weird Secure Boot Issue on Surface Pro 3 (might be related to keyboard cover) (fedia.io)
submitted 18 hours ago by Australis13@fedia.io to c/linuxquestions@lemmy.zip
4 comments fedilink hide all child comments
 

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.

top 4 comments
sorted by: hot top controversial new old
[–] Australis13@fedia.io 1 points 2 hours ago

So based on @j4k3@lemmy.world'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.

[–] unemployedclaquer@sopuli.xyz 2 points 10 hours ago

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.

[–] j4k3@lemmy.world 2 points 17 hours ago (1 children)

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.

[–] Australis13@fedia.io 2 points 13 hours ago

Thanks, I will check out those resources and see what I can find.