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:
bossanova808 said:
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??
Click to expand...
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...!
 
And what should be the final follow up - because of this issue (and for the many other improvements) - this morning I decided to do the kernel upgrade to 6.17 as per:
https://forum.proxmox.com/threads/o...e-9-available-on-test-no-subscription.173920/

...and removed the DKMS driver too.

Bash: 
apt update
apt install proxmox-kernel-6.17
dkms status
dkms remove r8126/10.015.00 --all
reboot

System was back up less than a minute later with the kernel network driver working perfectly as far as I can see.
 
  • Like
Reactions: jaminmc and Kingneutron
bossanova808 said:
Bash: 
dkms remove r8126/10.015.00 --all

System was back up less than a minute later with the kernel network driver working perfectly as far as I can see.
Click to expand...
You may want to install the DKMS drivers for the older kernels, as 6.17 is a TEST kernel, and has bugs. So if yor run into any of the bugs, and need to boot a previous kernel, you don't have a network, as the drivers are missing on the old Kernels. you can reinstall the DKMS driver with a -k and specify what kernel to install it... But if you didn't do a proxmox-boot-tool refresh before rebooting, you might still be using the DKMS driver and if an update comes out that trigers a refresh, you may loose network on reboot.
 
@jaminmc Thanks for this info.

From lspci -k I 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 driver in use: r8169
        Kernel modules: r8169

Previously, this said: Kernel modules: r8126 so I am pretty sure it's not still using the DKMS driver. But for good measure I ran proxmox-boot-tool refresh and then rebooted again, to be extra sure, with the same output as above after that. And dkms status returns nothing.

But I definitely take your point about if I needed to roll back etc, and will (attempt to!) follow your advice to make sure it is available for eventualities, but this time for just kernels in the 6.14 range.

I ran dkms install -m r8126 -v 10.015.00 -k 6.14.11-4-pve (as using only 6.14 did not work)

I now have dkms status showing:

Code: 
r8126/10.015.00, 6.14.11-4-pve, x86_64: installed

...which I think indicates it is there and would be loaded, should I need that previous kernel? Does that look right to you?

I did see a DKMS about not being able to load or similar during the reboot, but I can't now find anything in dmesg. (And I suspect that I'd run in to MOK signing type errors if I actually did reboot with this kernel (which I don't even know how to do!). I should probably do a defensive test run reboot on the older kernel to see what happens, while at the console.

My question at the end of this becomes - what would have been the right thing to do here? I presumed it was best to do a dkms remove but perhaps I should not have...but that install was not limited to a kernel (perhaps that was my mistake way back then...?)

As is obvious, I'm not very experienced with kernel stuff...

Again, thanks for your input.
 
So I did the test reboot in to the older kernel using: proxmox-boot-tool kernel pin 6.14.11-4-pve --next-boot

Networking came up and showed the r8126 driver was in use (dkms) and networking was working. No need to re-sign with MOK or similar, just worked again as before.

Rebooted back in to the current kernel and also have working networking. So overall, all appears to be working with either kernel, however:

Code: 
> dkms status
r8126/10.015.00, 6.14.11-4-pve, x86_64: installed
r8126/10.015.00, 6.17.1-1-pve, x86_64: installed

...surprises me, as I thought I had limited it explicitly via dkms install -m r8126 -v 10.015.00 -k 6.14.11-4-pve ..?

In any case, with lspci -k I now see both are loaded but the newer kernel driver is actually used:

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

So I suppose no harm in leaving the dkms one there, even if it is (somehow?) not actually limited to 6.14. But I definitely find that odd.

(Kernel 6.17 is all going fine apart from a bunch of spurious apparmor logs in dmesg so I suspect I'll be ok to stay with 6.17...)
 
You must log in or register to reply here.
Top Bottom