How to keep the Microsoft UEFI keys?

My long learning curve with IncusOS installation continues.

I am using a Lenovo P350 Tiny. I have an RTL-8127 card which I know is supported in the Zabbly kernel. However, after I clear the keys in the BIOS and the IncusOS install USB adds its keys, once I turn Secure Boot back on and boot the IncusOS installer it won’t find my NIC. In fact, the card won’t show up in the BIOS boot selector menu for PXE either. Once I reset the keys to the factory defaults, the card reappears.

I have the Microsoft UEFI key option enabled in the BIOS.

Now I know there must be a sequence I can use which will allow IncusOS to install its keys and let me keep enough other keys for the UEFI BIOS to see the card. This is because about seven or eight install attempts ago when it was failing much earlier and going into emergency mode, and I could see the card recognised. I also see a couple of other posts from folks using the card.

I did read the entry specifically about Lenovo installs in the instructions but my BIOS doesn’t have the options it lists. Should I clear the TPM?

Any hints as to a sequence which might let me have both IncusOS and the necessary UEFI keys for the card to work? Is manual key entry the best option here?

If your BIOS lets you enroll keys without having to rely on setup mode, then a factory reset of the secureboot keys should get the Microsoft keys back in, then you can add the IncusOS keys on top of that. If it dosn’t and it only lets you do setup mode, then you’re going to be a bit out of luck there short of using a UEFI shell and some custom .efi binaries to load exactly what you want in there.

That said, while the lack of Microsoft keys would definitely explain your NIC disappearing from the boot options, it shouldn’t prevent the Linux kernel from detecting and loading its driver.

@hereisjames if you had a way to get the system online on a different NIC, it would be useful to get the incus admin os debug output.

My current theory is that it’s simply missing firmware that’s causing the issue.

Thanks Stéphane. I agree it not showing in the boot menu shouldn’t stop the kernel seeing it, but it feels like it’s more than that.

Before I restored the factory MS keys, I booted a standard Ubuntu 24.04 Live USB (kernel 6.17, so after the card drivers were added) with Secure Boot enabled. Running lspci showed absolutely nothing in the PCIe slot (only the onboard Intel NIC appeared). If lspci can’t even see the hardware it seems like the Lenovo is somehow blocking or not initialising the card before the kernel even gets a chance to look for it.

I have now tried manually adding the IncusOS keys and the 10G card does not appear. I really need the 10G card on this node to work so I’m very disappointed (plus I’ve wasted days on this) but I’ll have to go back to standard Incus on Ubuntu.

Ah yeah, it missing from lspci is definitely quite weird… Maybe they do some very odd initialization through their firmware option ROM, but that would be very unusual as those ROMs are optional.

Note that you could probably get things working by disabling Secureboot and downloading an IncusOS image that allows running without Secureboot (degraded boot security under the Advanced options on the website).

For completeness I also did a no secure boot install, but IncusOS was still not able to see the NIC.

Dunno if it’s a problem specific to Lenovo Tinys (I tried another unit, same result) or the card.

Can you get the incus admin os system resources show in that scenario?

As I said, there are firmware files that may be needed for those NICs, so assuming that it’s now showing up on the PCI bus, we should be getting a kernel error complaining about firmware files, at which point we can trivially fix that in a new image.

No, it doesn’t complete the seeding so as far as I can tell the environment isn’t up. I didn’t remove the problem card from the seed and do yet another install I’m afraid - after days of trying to troubleshoot I needed to get the system reinstated. If I can find another opportunity to take the system offline I’ll see what I can get.

Is it useful to try your kernel against the card under Ubuntu? That’s much quicker and easier.

Edited to add - I got this from the Ubuntu Live environment which confirms your hypothesis..

ubuntu@ubuntu:~$ sudo dmesg -T | grep -iE ‘01:00.0|enp1s0|r8169|realtek’
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: [10ec:8127] type 00 class 0x020000 PCIe Endpoint
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: BAR 0 [io 0x3000-0x30ff]
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: BAR 2 [mem 0x9fa00000-0x9fa3ffff 64bit]
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: BAR 4 [mem 0x9fa60000-0x9fa63fff 64bit]
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: ROM [mem 0x9fa40000-0x9fa5ffff pref]
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: supports D1 D2
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[Sat Apr 4 21:56:34 2026] pci 0000:01:00.0: Adding to iommu group 10
[Sat Apr 4 21:56:34 2026] r8169 0000:01:00.0: can’t disable ASPM; OS doesn’t have ASPM control
[Sat Apr 4 21:56:34 2026] r8169 0000:01:00.0 eth0: RTL8127A, 1c:86:0b:39:90:cd, XID 6c9, IRQ 136
[Sat Apr 4 21:56:34 2026] r8169 0000:01:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]
[Sat Apr 4 21:56:34 2026] r8169 0000:01:00.0 enp1s0: renamed from eth0
[Sat Apr 4 21:57:02 2026] r8169 0000:01:00.0: Unable to load firmware rtl_nic/rtl8127a-1.fw (-2)
[Sat Apr 4 21:57:02 2026] Realtek Internal NBASE-T PHY r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)
[Sat Apr 4 21:57:02 2026] r8169 0000:01:00.0 enp1s0: Link is Down
[Sat Apr 4 22:35:08 2026] r8169 0000:01:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM
ubuntu@ubuntu:~$

Right, so yeah, that’s a firmware issue. That’s pretty easy for us to fix on our end, I’ll send a PR.

Thanks. I’ll give it another go when I get a window.