Realtek RTL8125 Ubuntu 24.04 Ethernet Fix -- r8125 new driver; purge r8125-dkms

Support and Help
1

Fix for Realtek RTL8125 Not Getting IP Address on Ubuntu 24.04+

I ran into a frustrating issue where my Realtek RTL8125 2.5GbE interface wouldn’t work under Ubuntu 24.04. After lots of trial and error (and help from others and even ChatGPT), I found a method that finally worked. I’m sharing here in hopes it saves someone else the same pain. I’m sorry this writing is kinda rough, but I have to post it before it loses its usefulness to others.

Fix Guide for Realtek RTL8125 (r8125) on Ubuntu 24.04+

This guide helps resolve issues where the onboard 2.5GbE Realtek RTL8125 network interface is present but fails to get an IP address via DHCP or cannot connect to the network.

Tested and confirmed on: Ubuntu 24.04 Noble Numbat, kernel 6.11.0-21-generic.

:fire: Critical Prerequisite: Remove Any DKMS Version

If you’ve previously installed a version of the driver via a package like r8125-dkms (often recommended on forums or from PPAs), you must remove it first, or the manually installed Realtek driver will not take effect.

Run this command to fully remove it:

sudo apt purge r8125-dkms

Then reboot:

sudo reboot

:white_check_mark: Step-by-Step Fix

Note: I think this original “fix” method requires that Secure Boot be turned off/disabled, else Ubuntu will not load the “foreign”/unsigned driver. Others have mentioned in this Topic a more sophisticated method, including signing the new driver before attempting to boot with it. Failing to do at least one of these might cause your system to boot with no Ethernet and I don’t know if it would tell you why. Please see the posts below.

  1. Download the official driver from Realtek:
  1. Extract and install:
cd ~/Downloads
unzip r8125-9.015.00.zip
cd r8125-9.015.00
sudo ./autorun.sh

Ignore any warnings about System.map or BTF unless they stop the install.

  1. Reboot the system:
sudo reboot
  1. Check that the driver version loaded is correct:
sudo ethtool -i enp1s0

Look for this line:

driver: r8125
version: 9.014.01-NAPI  # Or later, depending on Realtek release

Note: Despite the Realtek site listing version 9.015.00, the compiled driver may report as 9.014.01. This appears to be normal in Realtek’s source packaging.

To confirm which file is being used:

sudo modinfo r8125 | grep -i filename

It should show:

filename: /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8125.ko.zst
and/or
filename: /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8125.ko

If all is well, your Ethernet port should now work normally, and DHCP should succeed.

:hammer_and_wrench: If It Still Doesn’t Work

Make sure:

  • Your switch/router port and Ethernet cable are known to work
  • carrier is 1 :
cat /sys/class/net/enp1s0/carrier
  • The interface is up:
sudo ip link set enp1s0 up
  • Try DHCP again manually:
sudo dhclient -v enp1s0

If that still fails, try assigning a static IP for testing:

sudo ip addr add 192.168.1.155/24 dev enp1s0
ping -c 4 192.168.1.1

If you now get responses, it confirms the driver is working.

:safety_pin: Important Note About Kernel Upgrades

If you update your kernel (via apt full-upgrade, or as part of a system upgrade), this fix may stop working. That’s because the compiled driver is not persistent across kernels.

To restore functionality, re-run the install script:

cd ~/Downloads/r8125-9.015.00
sudo ./autorun.sh
sudo reboot

Alternatively, a DKMS-based version of this driver could make the fix persistent, but I don’t know (yet) how to do that (contributions are always welcome).

:memo: Notes

  • If you’re passing along parts of this guide, I think it’s important to say r8125-dkms must be purged first or the system will continue to load the old DKMS driver, even if you’ve compiled/installed a newer one.
  • Realtek driver version numbers in their archives, and what shows via ethtool, may differ slightly — don’t worry if it says 9.014.01-NAPI .
  • Thanks very much to so many who posted parts of this solution, in several Topics in this forum and elsewhere; I believe asking the right questions and sharing information is a very important part of getting a solution.

Jim

3 Likes
2

Thank you for sharing this with the community.

2 Likes
3

There is lots of detail at the Ubuntu/Launchpad Bug Report WWW page linked below. You may decide to just follow the advice of those who say the fix is included in Ubuntu 25.04, and forego adhering to an LTS release.

Note: Some of the detail is obsolete/not-applicable, and some (including some of my posts) was probably always wrong or depending on each specific situation, and only some of those were corrected later, so one is advised to read the whole thing carefully and try to decide what to use for your own situation.

4

What an adventure this was. Thanks for all this @jimbobstpaul. I was about to roll back to 22.04 until I found this post. This worked for me entirely, but I wanted to turn on module validation at boot with secure boot.

I did the following to get this to work with secure boot.

You need the following packages (they were in the base install for me):

openssl
mokutil
kmod

  1. Create a directory for your keys
mkdir -p ~/module-signing/
cd ~/module-signing/
  1. Generate your signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Your Name/"
  1. Register your key with the UEFI secure boot system
sudo mokutil --import MOK.der

Add a password. You need this when you reboot into the MOK management screen on your next reboot
4. Reboot
When the system reboots, you’ll enter the MOK management screen. Select “Enroll Mok” then “Continue,” enter the password you created, and select “Yes” to enroll the key. My prompt asked me to also find the location on the drive, but MOK manager was not giving me file system accesss that I needed. In the end, it didn’t seem to matter. When I rebooted, my cert was added properly.
Reboot

To verify your keys, run:
sudo mokutil --list-enrolled

You should see your cert listed

sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der

Output:

/var/lib/shim-signed/mok/MOK.der is already enrolled

  1. Sign the driver you downloaded from Realtek
    I know it is not ideal to sign other people’s code, but I got the module from a trusted source (Realtek’s official release). I am going to run the driver regardless of signing, and I want to continue to use secure boot to verify other modules as well. So I felt this was ok to do.

Sign with the following command:

sudo kmodsign sha512 \
/var/lib/shim-signed/mok/MOK.priv \
/var/lib/shim-signed/mok/MOK.der \
/path/to/your/r8125.ko

Verify the signature with modinfo

sudo modinfo r8125

You should see the signing info from your cert signer attached to the module.

  1. Turn on MOK validation
    I had to turn validation to off to run the unsigned driver. Now that I have created certs and signed the driver. You need to turn validation back on to get secure boot to validate signatures on boot.
    To turn validation on, run:

mokutil --enable-validation

It will prompt you for a password, on your next restart you will again go to the MOK management console, follow the password prompt, and choose the enable validation option.

On your next restart, you should have everything working with signed and validated drivers.

Thanks again to @jimbobstpaul

1 Like
5

If you follow the commands to make that MOK file anything made using dkms will automatically be signed. You can go into the r8125-9.015.00/src directory, then in terminal make clean then create a file named dkms.conf and enter the following

MAKE="'make' modules KVER=${kernelver}"
CLEAN="make clean"
BUILT_MODULE_NAME=r8125
DEST_MODULE_NAME="r8125"
DEST_MODULE_LOCATION="/updates"
PACKAGE_NAME=r8125
PACKAGE_VERSION=4.2
AUTOINSTALL=yes

Save and exit then in terminal, while still in r8125-9.015.00/src run in terminal sudo dkms add . and then sudo dkms install r8125/4.2 and it should automatically build and sign a new module whenever there is a kernel update

2 Likes
6

Thanks for your kind words and sharing, and for further guidance, @soylent-snacks and @Jeremy31. I’m glad I could help, and maybe, someday, I will be up for yet another adventure, and encouraged by your notes on stuff that apparently actually works and has no downside, I will try those too, but I will probably not have the time for such a significant project (to me) before November.

Best wishes,

Jim

7

I read somewhere something like, “Ubuntu prefers to use the r8125.ko.zst compressed file”, and in your discussion you only mentioned signing the r8125.ko. Does that mean that your particular setup would just go ahead and use the unsigned compressed version, and do you care, or do I not understand how it actually works?

8

It seems that I should have added a note at the beginning of my “original fix” to be sure that Secure Boot is turned off, because otherwise Ubuntu/Linux won’t load a “foreign” driver; correct? If yes, would one of you please modify my “fix” to include that?

Never mind – I just learned I can edit it myself, so I did. :grin:

9

I am not sure “prefer” is the right word. It might suggest you use it to get a smaller kernel/shorter boot time. I used the build from the x64 live image. I don’t think much of the kernel, if any, is compressed. In any case, on my system it won’t matter too much. I might get a slightly faster boot, but that doesn’t matter all that much to me.
My system is loading the signed uncompressed r8125, because I do not have a compressed one. Since I turned on signature verification, an unsigned module, compressed or no, would not be able to load.

Any modern OS will not load unsigned drivers if secure boot is turned on. Secure boot doesn’t need to be turned off, but signature verification does need to be turned off. Secure Boot is managed by the BIOS/UEFI. You could turn it off there, but a simpler (if not simpler, then my preferred way) way is to use mokutil and MOK manager.

The cmd to add to your fix, would be:

mokutil --disable-validation

Restart the system, then upon reboot, the MOK manager will come up and you can turn off validation through the MOK manager menu.

or the other option as you suggested would be to go into your BIOS/UEFI and turn off secure boot.

** edited for grammar

1 Like
10

Probably a noob question, but I am struggling too. My X870E AORUS PRO ICE (rev. 1.0) is only working with wifi with Ubuntu server 24.10. Nic is not working because Kernel 6.11.
So I decided upgrade 25.04 Ubuntu server. At first glance my Nic was recognized and working. Yeah. But after a few minutes it is losing connection and my server crashes.
My question is: Does your work around make sense with kernel 6.14 or is my problem maybe not realtek RTL8125 / RTL8125B(G).
from ethtool-i:driver: r8169 version: 6.14.0-15-generic firmware-version: rtl8125d-1_0.0.7 10/15/24 expansion-rom-version: bus-info: 0000:11:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no

11

That definitely sounds like you have bigger non-wifi related issues here…

12

Yeah I agree, my server does not even pass post. I am very happy…not. Now i wish I only had to deal with Nic.

13

Do you have time before crash to run echo "blacklist r8169"|sudo tee /etc/modprobe.d/r8169.conf

14

If your target computer is failing POST, I think the first thing to do is rule out hardware issues. Here is how I would proceed:

On a separate real computer, download memtest:

https://www.memtest.org/

… and burn it on a thumb drive, and boot the target machine on that thumb drive after choosing Load Optimum Defaults in the BIOS/UEFI, and let memtest run for a couple hours, at least through two passes with thorough testing options. If that doesn’t pass, or you can’t even get the target machine running long enough to do those steps, then restart and choose Load Failsafe Defaults (or whatever your system’s terminology is). If that still doesn’t work, then power off the power supply (unplug the power cord if necessary), and make sure all of the removable parts, especially RAM sticks, are plugged in securely, snapped in, visually verified, etc. . If you actually do have a defective RAM stick, it might help to swap their positions, at least to get your machine to run long enough so that you can do the above tests. It might even matter if something like a fan cable is plugged in backwards or off-center, although this is rare. If the target machine still fails POST, then start replacing hardware until you have a computer that passes both POST and memtest.

Edit:
Of course, if your machine will run without all of its RAM sticks, you can do all of these steps without having another computer on which to first make a memtest thumb drive: put in just one RAM stick and then another (power-supply off each time, of course) and when it runs then do the rest of the steps on the target machine itself, including making the memtest thumbdrive. Would that then be a “compound bootstrap” method? :^)

Then go back to your original plan to load Linux server, etc. .

Does this help?

15

BTW, welcome to the forum, @groma45.

16

BTW, welcome to the forum, @soylent-snacks.

17

Thank you jimbobstpaul

18

Yeah, sorry for my late reply, was busy to completely clear cmos battery aka rebuilding entire PC thanks to Gigabyte X870Aorus motherboard. They really think you do not need to replace Cmos battery ever…anyway. Right now system runs stable again, updated BIOS to F4 as well. Fingers crossed. Thank you for your time and help.

19

@groma45,

OK, so do you think when you replaced the CMOS battery, you reset all Settings to the Factory Defaults, and that may have fixed the problem?

Or maybe you flexed the motherboard just enough to get a poorly-seated component, again most likely a RAM stick, to barely make contact everywhere, and it will eventually fail again due to “micro-vibration” or expansion and contraction with temperature? All of these have happened to me more than once, and none of the other IT Specialists on the team figured it out, I guess because until it’s been proved to them, they don’t believe it’s as common as does someone with more experience.

And you are very welcome to any help that I can give, or that I may have given.

And yeah, I know I really tend to leave no stone unturned; sorry if I’m wasting your time.