Driver missing: Intel® Killer™ E5000 5Gbps LAN and Intel® Killer™ BE1750x Wi-Fi 7

Couldn't get Debian 13 to recognize it either so not sure how that guy got it working
 
Have just run in to this same issue. Looks like Kernel 6.15 is required: https://www.phoronix.com/news/Intel-Killer-E5000-Linux-6.15

It's apparently a one line kernel patch as the 'Intel' NIC is actually just a rebranded Realtek NIC so it's really just a device ID thing.

For now I guess I will use a USB ethernet dongle. It seems like an easy thing to 'backport' but I have no idea if that is the sort of thing Proxmox generally does? Or are we basically stuck with this until perhaps an opt-in newer kernel comes along??
 
Last edited:
Have just run in to this same issue. Looks like Kernel 6.15 is required: https://www.phoronix.com/news/Intel-Killer-E5000-Linux-6.15

It's apparently a one line kernel patch as the 'Intel' NIC is actually just a rebranded Realtek NIC so it's really just a device ID thing.

For now I guess I will use a USB ethernet dongle. It seems like an easy thing to 'backport' but I have no idea if that is the sort of thing Proxmox generally does? Or are we basically stuck with this until perhaps an opt-in newer kernel comes along??
Intel Killer 5000 is just rebranded realtek RTL8126 NIC. Download the driver at https://www.realtek.com/Download/List?cate_id=584

I have mine working as expected.
 
  • Like
Reactions: news
Thanks - very helpful. I am not yet very experienced with Linux drivers/kernel stuff. Without your pointing out it was possible I would have got stuck.

I tried to get the downloaded driver to work (on Proxmox 9). Using this download from there:
5G Ethernet LINUX driver r8126 for kernel up to 6.15

When I run the ./autorun.sh I get:

Code:
Check old driver and unload it.
Build the module and install
make[2]: *** No rule to make target 'clean'.  Stop.
make[1]: *** [Makefile:202: clean] Error 2
make: *** [Makefile:48: clean] Error 2

Further searching led me to an alternate approach: https://github.com/awesometic/realtek-r8126-dkms

From there, I had trouble with the .deb install approach...I had errors about the Kernel headers not being installed, even though I have installed pve-headers

Output of: apt-cache policy pve-headers

Code:
pve-headers:
  Installed: 9.0.0
  Candidate: 9.0.0
  Version table:
 *** 9.0.0 500
        500 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Output of: dpkg -i realtek-r8126-dkms_10.015.00-1_amd64.deb

Code:
(Reading database ... 87369 files and directories currently installed.)
Preparing to unpack realtek-r8126-dkms_10.015.00-1_amd64.deb ...
Deleting module realtek-r8126/10.015.00 completely from the DKMS tree.
Unpacking realtek-r8126-dkms (10.015.00-1) over (10.015.00-1) ...
Setting up realtek-r8126-dkms (10.015.00-1) ...
Loading new realtek-r8126/10.015.00 DKMS files...
Building for 6.14.8-2-pve
Building for architecture amd64

Module build for kernel 6.14.8-2-pve was skipped since the
kernel headers for this kernel do not seem to be installed.


The ppa listed is for Ubuntu, so I tried the third option:
https://github.com/awesometic/realtek-r8126-dkms?tab=readme-ov-file#dkms-installsh

I again had errors about the Kernel headers not being installed...ergh!

I solved this by (from https://askubuntu.com/questions/714874/how-to-point-dkms-to-kernel-headers):
ln -s /usr/src/linux-headers-$(uname -r) /lib/modules/$(uname -r)/build

Then dkms_install.sh worked without errors, and subsequently using lspci -k could see:

Code:
83:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 5000 (rev 04)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7e32
        Kernel modules: r8126

After all that, the interface still wouldn't show after a reboot with ip a

I saw this issue: https://github.com/awesometic/realtek-r8126-dkms/issues/3

And thus followed the instructions to get SecureBoot to accept the changes:
https://wiki.debian.org/SecureBoot#DKMS_and_Secure_Boot

...and then, finally, I could see my interface in the output of ip a

So then, at last, it was just modifying /etc/network/interfaces to swap the device name there and then finally systemctl restart networking

NIC is up, negotiates correct speed, and is still there after a reboot. (And being DKMS, should be there after a kernel change too, I believe...)
 
I think i ended up doing something very similar. I used the same git, and secure boot being on made me have to reinstall proxmox, after turning secure boot off. I get errors when updating proxmox because of the driver, but all seems good so far. I only have 2.5gb to pull from it and I get pretty much the full speed (~2.4). It's working very well with 5 VMs rn for me, so no complaints other than the mess getting it to work.

Only thing I worry about is I have no idea how to remove it once the kernal gets updated and natively supports it. :rolleyes: Guess I'll worry about that later. I actually went with proxmox 9 because I thought it would be natively supported, but it at least it natively supports the wifi card, just had to get dhcp working. (Much nicer experience than when I was trying to use proxmox 8 and couldn't even access the webgui).
 
As I understand it, with the DKMS approach, you can 'dkms uninstall' very simply at such a time. But I agree, the kernel side of things is hard to feel on top of!

I don't feel confident this solution will stay working following a kernel upgrade. I guess time will tell but I am irritated that this stupid re-branding thing results in one teeny tiny kernel line that makes the whole thing feel...brittle.
 
Just a further follow up - I had repeated issues with the NIC not being available after boot. Turns out this was because my BIOS was reverting to Secure Boot being on - thanks to an issue with this motherboard. Turns out if AC power was completely lost, then the BIOS was losing all settings and reverting to defaults. I wasn't really noticing this as the default settings were working ok except for this NIC issue.

There is a firmware (nb firmware, NOT BIOS) fix for this issue here: https://www.msi.com/Motherboard/MAG-Z890-TOMAHAWK-WIFI/support#firmware ('eSIO FW: Fixed "BIOS settings were reset to default values" message on bootup after AC power lost.'). With that applied all issues are gone and BIOS setttings are maintained at all times. (Pretty nasty/confusing firmware bug, really, especially for a machine I am essentially using headless so one doesn't see the messages easily when things go awry...)

(This also explained why my initial attempts with signing the DKMS MOK key was not working consistently - I presume the secure boot 'key' was changing after each of these BIOS wipe events...).

With the fixed firmware, all is good - I did the DMKS MOK signing thing, and now have a fully working NIC with Secure Boot still on, and it survives total power loss just fine.

Still a it nervous about updated kernels but I guess will cross that bridge when the time comes...!