All the sudden the following error showed up:
Mar 18 17:54:21 erlangen kernel: Couldn't get size: 0x800000000000000e
Mar 18 17:54:21 erlangen kernel: MODSIGN: Couldn't get UEFI db list
Mar 18 17:54:21 erlangen kernel: Couldn't get size: 0x800000000000000e
This affects Tumbleweed, but also a native install of Xubuntu. I never made a change to the latter. Any idea?
Yes, I see that. It only happens with a 5.0 kernel (and presumably later), and it only happens on UEFI machines where you are not using secure-boot.
It looks to me as if the kernel is looking to check signatures on modules, using the key structure from booting with secure-boot. And if you did not use secure-boot, that key structure is not there. The message seems to be telling you that.
I’m not a kernel internals person. But my conclusion is that this can be ignored. It’s probably just for debugging.
My research suggests that nrickert’s summary is right (as he usually is…)
Yes it occurred the first time after upgrading to 5.0.1-1-default. However there is a puzzling effect: Xubuntu has kernel 4.15.0-45-generic This install now also displays the error message (it didn’t before):
Mar 18 17:52:41 xubuntu-test kernel: Loading compiled-in X.509 certificates
Mar 18 17:52:41 xubuntu-test kernel: Loaded X.509 cert 'Build time autogenerated kernel key: e3b8f44ffaaceef3e3a84cfaebd8e5a9acebeaad'
Mar 18 17:52:41 xubuntu-test kernel: Couldn't get size: 0x800000000000000e
Mar 18 17:52:41 xubuntu-test kernel: MODSIGN: Couldn't get UEFI db list
Mar 18 17:52:41 xubuntu-test kernel: Couldn't get size: 0x800000000000000e
Mar 18 17:52:41 xubuntu-test kernel: MODSIGN: Couldn't get UEFI MokListRT
Mar 18 17:52:41 xubuntu-test kernel: zswap: loaded using pool lzo/zbud
Mar 18 17:52:41 xubuntu-test kernel: Key type big_key registered
Mar 18 17:52:41 xubuntu-test kernel: Key type trusted registered
Mar 18 17:52:41 xubuntu-test kernel: Key type encrypted registered
I also think it can be ignored. But 4.20 had a flicker-free boot. 5.0 has flicker again due to the message being displayed. 
Maybe a back port in Xubuntu kernel???
I only get the one line of the message:
Couldn’t get size (with numbers either side)
But I am using EFI and have secure boot switched off.
Those messages come from kernel integrity checker that attempts to import UEFI certificates for module signature verification. Certificates are stored in UEFI variables. Error 0x800000000000000e means “The item was not found”, so the variable does not exist. If you run with Secure Boot disabled this can be ignored (still the very fact kernel attempts to import non-existing certificates is not nice). If you do have Secure Boot enabled something is wrong and bug report can be considered.
Upstream kernel has these patches since 5.0. It is quite possible that SUSE included them earlier.
It’s a well known bug: https://bugzilla.redhat.com/show_bug.cgi?id=1497559 and it can be pretty awkward. When it got activated in Xubunbtu kernel loading time increased from 2 to 33 seconds!
erlangen:~ # journalctl -b 0 --directory /Xubuntu/var/log/journal/|grep userspace
Mar 19 14:19:50 xubuntu-test systemd[1]: Startup finished in 33.049s (kernel) + 5.829s (userspace) = 38.879s.
erlangen:~ #
Fedora 29 has it fixed. It does not show up on my machine.
Getting the same messages:
2.330097] MODSIGN: Couldn't get UEFI db list 2.330250] Console: switching to colour frame buffer device 320x90
2.335031] Couldn't get size: 0x800000000000000e
2.335032] Couldn't get UEFI MokListRT
2.339985] Couldn't get size: 0x800000000000000e
2.339987] Couldn't get UEFI dbx list
Tumbleweed, 5.0.2-1-default #1 SMP Thu Mar 14 08:29:17 UTC 2019 (d1f1d19) x86_64 x86_64 x86_64 GNU/Linux.
…running all latest updates. Just started happening…does make boot time a little slower, and things DO work, but concerning nonetheless. Anyone have thoughts?
Excellent, thanks!! Glad to know it’s not just my system.
I’m running on an iMac (single boot, Tumbleweed only), and have had zero problems. This message was troubling, though, since
Mac’s can be…finicky…
“The 0x800000000000000e is EFI_NOT_FOUND. It’s harmless. I will send my efi_status_to_str() patch to mainline to improve EFI log.”
I installed Tumbleweed and get these messages when booting:
Couldn’t get size: 0x800000000000000e
MODSIGN: Couldn’t get UEFI db list
Couldn’t get size: 0x800000000000000e
Good to know, that this is harmless. Will it be fixed? Or is it already fixed and I need to install/configure something?
I don’t think anything is actually broken.
I only see this when I am booting with UEFI but secure-boot is disabled. Where secure-boot is enabled, I do not see these messages.
FWIW, I would like to add to this. You all agree that this error is harmless - okay. But nevertheless, the kernel seems to be doing something in UEFI bootmode with Secure Boot OFF that it shouldn’t be doing or at least shouldn’t report on.
Nevertheless, I did try a little thing on my machine. It is a 2013 HP EliteBook 8570w, normally booted in UEFI mode (incl. CSM) with Secure Boot OFF. With such BIOS/UEFI settings, both Tumbleweed and Manjaro had been installed in dual boot on the internal SSD. Remark: The CSM is needed since I can boot alternatively from an eSATA SSD in BIOS boot mode.
Tumbleweed has been throwing this MODSIGN error since about the same time reported in the first post here. Manjaro has never done this; I checked its journalctl.
Normally, Tumbleweed throws these lines:
Okt 01 12:39:01 susytmblwdke8570 kernel: **Couldn't get size: 0x800000000000000e**
Okt 01 12:39:01 susytmblwdke8570 kernel: **MODSIGN: Couldn't get UEFI db list**
Okt 01 12:39:01 susytmblwdke8570 kernel: **Couldn't get size: 0x800000000000000e**
Okt 01 12:39:01 susytmblwdke8570 kernel: Couldn't get UEFI MokListRT
Okt 01 12:39:01 susytmblwdke8570 kernel: **Couldn't get size: 0x800000000000000e**
Okt 01 12:39:01 susytmblwdke8570 kernel: Couldn't get UEFI dbx list
as taken from journalctl, with the bold lines showing up on screen during boot.
I wanted to test what happens when I interim-wise put a Windows (8.1-64 in my case) system in UEFI boot mode with Secure Boot ON onto the machine. I did this with a spare SSD of mine. Windows installed all fine, and I rebooted a couple of times in Secure Boot.
Returning to my Linux SSD with Tumbleweed and Manjaro, it would not boot with Secure Boot ON - of course, boot image not authenticated. I switched the BIOS/UEFI back to the UEFI+CSM and Secure Boot OFF settings, both Linux’s boot fine again. Now Tumbleweed shows only one error line on screen while booting
Couldn't get size: 0x800000000000000e
and journalctl has messages now that differ from the above:
Okt 02 12:52:31 susytmblwdke8570 kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 12:52:31 susytmblwdke8570 kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: ...snip...>
Okt 02 12:52:31 susytmblwdke8570 kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 12:52:31 susytmblwdke8570 kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: ...snip...>
Okt 02 12:52:31 susytmblwdke8570 kernel: Couldn't get size: 0x800000000000000e
Okt 02 12:52:31 susytmblwdke8570 kernel: Couldn't get UEFI MokListRT
So I have two messages wrt this TW error on my HP machine in UEFI (+CSM) boot mode with Secure Boot OFF:
This has changed somewhat since if first started happening.
My current experience:
If using legacy BIOS booting, then these lines do not show up.
If using UEFI booting, then it depends.
If “grub.cfg” loads the kernel with:
linuxefi kernel-path options
initrdefi initrd-path
then those lines do not show up, whether or not secure-boot is being used.
However, if “grub.cfg” uses
linux kernel-path options
initrd initrd-path
then those lines will show up. Oh, and secure-boot will not work. You have to be using “linuxefi” for secure-boot to work.
If I try a recent Ubuntu, I always get some of those lines. That’s presumably because Ubuntu always uses “linux” rather than “linuxefi”. But secure-boot does work with Ubuntu, because Ubuntu appears to be skipping the verification of the kernel signature.
Returning to my Linux SSD with Tumbleweed and Manjaro, it would not boot with Secure Boot ON - of course, boot image not authenticated.
You need to change “grub.cfg” to use “linuxefi” and “initrdefi” for it to boot with secure-boot on.
Hmm, my experience today remains different. I am using UEFI booting, and I have
# Uncomment to use boot commands linuxefi instead of linux and initrdefi instead of initrd
GRUB_USE_LINUXEFI="true"
in my /etc/default/grub, so that it uses linuxefi and initrdefi in the script-generated grub.cfg. I checked that I had this in grub at least since April this year, never changed it. With Secure Boot OFF, TW boots and throws the one line I reported two posts up. Going to Secure Boot ON now, my machine doesn’t boot, “image not authenticated”. So back to Secure Boot OFF, and I don’t care for that one line left in TW …
BTW, whatever that might mean, Manjaro doesn’t use linuxefi and initrdefi, just linux and initrd in its grub.cfg. And no MODSIGN errors …
FWIW, seems to be hard to get a consistent picture of what the various Linux distros and various installs of one distro are doing…
Thank you very much for visiting this old thread again and for all your help.
Interesting, but different from my experience.
As best I recall, that was what I saw with a 5.1 kernel. But it changed with a 5.2 kernel (and now we have 5.3).
BTW, whatever that might mean, Manjaro doesn’t use linuxefi and initrdefi, just linux and initrd in its grub.cfg. And no MODSIGN errors …
I’m not sure what Manjaro is doing.
Some Ubuntu documenation claimed that they (Ubuntu) were actually using “linuxefi” where appropriate, even though the “grub.cfg” says “linux”. Supposedly some internal code changed booting. But the evidence does not support this claim. However, perhaps Manjaro is doing that.
My Tumbleweed systems on UEFI boxes do not give that boot message, even when I turn secure-boot off. But there’s one exception. I have Tumbleweed on a KVM virtual machine using 32-bit EFI booting. So “linuxefi” won’t work for that (the kernel is built as a 64-bit EFI binary, not as a 32-bit EFI binary). So I have to use “linux” in the grub.cfg, and I always get those messages on that VM.
That’s correct. In Ubuntu grub internally redirects from linux to linuxefi loader if Secure Boot is active.
But the evidence does not support this claim.
Well, I do not have “linuxefi” in grub.cfg on Ubuntu 18.04, I boot with Secure Boot enabled and attempt to boot unsigned kernel using “linux” command fails. I do not know what evidence you refer to.
That’s definitely not true for 18.04. It verifies kernel signature if secure boot is enabled and rejects kernel without signature. Care to show any evidence that Ubuntu grub can boot unsigned kernel?
You do understand implications of your accusation?