ZimaOS Realtek 2.5GbE Has No Network During Install: Driver Troubleshooting

This November 2025 installation case is valuable because the user performed unusually strong cross-testing before asking for help. The onboard Realtek 2.5GbE controller on an ASUS TUF Gaming B850M-PLUS WIFI7 worked normally under Proxmox, Unraid, and Kubuntu on the same machine, cable, switch ports, and NVMe. Only ZimaOS failed to bring the interface up during the second stage of installation.

That evidence shifts the troubleshooting target away from the router or cable and toward the exact NIC revision, kernel driver binding, or installer environment. The source thread did not reach an IceWhale engineering root cause, however, so the driver explanation must remain a community diagnosis.

The Hardware and Failure Were Highly Specific

The reported machine used an AMD Ryzen 7 8700G, 64 GB DDR5, a 512 GB NVMe system disk, and the motherboard's onboard Realtek 2.5Gb Ethernet. The first USB-booted stage of ZimaOS installation completed normally and copied the system to the NVMe.

The failure happened only after the installer asked the user to remove the USB stick and boot from the installed NVMe. At that point the second-stage environment needed networking to finish provisioning, but the Ethernet interface did not obtain carrier or a DHCP lease.

What the User Observed During the Second Stage

• The router never showed a DHCP lease for the ZimaOS installation.
• The machine could not be pinged and no ZimaOS web interface appeared.
• A subnet scan found no new server address.
• ip a showed either only loopback or an Ethernet-style interface without carrier and without an IPv4 address.
• Repeated fresh installer USBs produced the same result.

These symptoms are different from a working interface that merely has the wrong static IP. The link itself was not becoming usable in the installed ZimaOS environment.

Why the Other Operating Systems Matter

The same onboard NIC immediately worked under Proxmox, Unraid, and Kubuntu. The router assigned DHCP addresses, link LEDs behaved normally, and the machine was reachable without additional driver installation.

That does not prove ZimaOS has a generic Realtek bug. It does prove the physical NIC, cabling, and switch path were capable of working, which makes repeated cable swapping less useful after those controls have already passed.

The r8169 vs r8125 Theory Came from the Community

A community responder suspected that this particular Realtek 2.5GbE implementation needed r8125 while ZimaOS was binding it to r8169, or otherwise failing to bind the expected driver during second-stage boot.

That is plausible for some Realtek revisions, but no IceWhale employee in the public thread confirmed the device ID, loaded module, or kernel regression. Avoid rewriting the theory as “ZimaOS uses the wrong driver” without the actual diagnostic output.

The Three Read-Only Checks Requested by the Community

The responder asked for:

lspci -nn | grep -i ethernet
ip a
dmesg | grep -i -e r8169 -e r8125 -e realtek

These commands are useful because they do not modify the installation. Together they reveal the PCI device ID, which network interfaces Linux created, and whether relevant Realtek drivers reported probe or link errors.

For a current system, also compare the interface with the current ZimaOS Network panel's expected Ethernet state. If the kernel never creates a usable interface, the problem is earlier than Web UI configuration.

A Family-Level Compatibility Listing Is Not a Guarantee for Every Revision

The original poster was understandably frustrated because the Realtek 2.5GbE family appeared on IceWhale's compatibility information and that influenced the motherboard purchase. Network controllers sold under similar marketing names can still differ in PCI IDs, silicon revisions, firmware, PHY components, or board wiring.

A high-quality compatibility report should therefore include the exact lspci -nn identifier, not only “Realtek 2.5GbE.”

The Only Confirmed Outcome Was an Intel X540-T1 Workaround

Six days later, the original user reported buying an Intel X540-T1 NIC and said that it got around the problem. That is the only outcome confirmed by the person experiencing the failure.

The workaround proves that ZimaOS could continue installation when another compatible NIC supplied networking. It does not identify the exact reason the onboard Realtek device failed.

What This Thread Does Not Establish

• It does not prove every RTL8125-class NIC fails on ZimaOS.
• It does not prove DHCP was the root cause.
• It does not confirm a specific missing kernel module.
• It does not show that the user's lifetime license affected hardware support.
• It does not contain a final official IceWhale driver fix.

A Better Troubleshooting Path Today

1. Record the exact NIC PCI ID.
2. Confirm link LEDs and router port behavior.
3. Check whether Linux creates an Ethernet interface.
4. Inspect driver messages for the exact controller.
5. Compare behavior with another recent Linux image if necessary.
6. If a second known-compatible NIC lets ZimaOS finish installation, preserve the failed-controller diagnostics for a compatibility report rather than repeatedly reinstalling.

Realtek 2.5GbE Install FAQ

Was the onboard NIC physically defective?

The cross-tests argue against that. It worked immediately under several other operating systems.

Was r8169 definitely the wrong driver?

No. That was a community theory that the public thread never confirmed with the requested output.

What workaround was confirmed?

The original user installed an Intel X540-T1 network card and was able to get around the installation problem.

Should I replace my NIC before collecting logs?

If possible, collect the PCI ID, interface state, and relevant driver messages first. Those details are much more useful for determining whether a current ZimaOS build still has the same compatibility gap.