Community Solution

ZimaOS Stuck on 'Searching for Network Address' with RTL8125D

A December 2025 installation on a Gigabyte X870I board stalled at network discovery. The community suspected missing RTL8125D support in that installer build and suggested temporary USB Ethernet.

If the ZimaOS installer remains on “Searching for network address” and never receives an IP address, first determine whether the Ethernet controller is detected and linked at all. In this December 2025 case, a Gigabyte X870I Aorus Pro Ice system used a Realtek RTL8125D 2.5GbE controller and the installer never progressed to a usable network address.

A community responder attributed that specific failure to driver support in the installer build available at the time and suggested temporary USB Ethernet. The thread did not include an IceWhale engineering confirmation or a later test on current ZimaOS, so it should not be converted into a permanent claim that RTL8125D is unsupported.

The Installer Had No Address to Display

The user reached the installation stage that searches for an address but did not receive an IP. That is different from a browser failing to open ZimaOS after the host already obtained a valid DHCP lease.

Check the physical link first: cable, switch or router port, and link LEDs. Then look at the router's DHCP client list. If the machine never appears, the failure sits below the browser and may involve NIC detection, driver binding, DHCP, or the physical network path.

The RTL8125D Explanation Was a Community Diagnosis

The source user identified the onboard controller as Realtek RTL8125D. A community reply stated that the ZimaOS installer kernel being used in late 2025 did not include working support for that controller and said the driver could not simply be injected into the running installer.

That explanation fit the symptom, but the thread did not show kernel logs, lspci -k, or an official compatibility statement. It also predates later ZimaOS releases. Use it as a historical diagnosis pattern, not as proof about the current image.

The current ZimaOS documentation describes x86-64 hardware broadly, but it does not provide an exhaustive NIC compatibility table. If you have the same controller today, test the latest installer before assuming the old limitation still applies.

A Temporary USB Ethernet Adapter Can Isolate the Problem

The practical workaround proposed in the thread was to install through a supported USB Ethernet adapter. The reply mentioned common USB NIC families such as RTL8153 and AX88179. The original poster ordered an adapter, but did not return with a final installation result.

A temporary adapter is valuable because it separates network-controller compatibility from the rest of the installation. If ZimaOS obtains an address and completes setup through USB Ethernet, the onboard NIC path becomes the main suspect. If the USB adapter also gets no DHCP lease, investigate the switch, router, cabling, VLAN, and DHCP service before blaming the onboard controller.

Retest with the Current Installer Before Applying an Old Driver Conclusion

ZimaOS has continued to add and revise network drivers. For example, ZimaOS 1.7.1 explicitly added be2net support for certain Emulex NICs and improved Docker networking, showing that network support changes between releases. The 1.7.1 changelog does not specifically claim an RTL8125D fix.

Current ZimaOS 1.7.1 release notes are a better version boundary than relying on a December 2025 forum assumption.

What to Capture If the Latest Installer Still Fails

If the same problem occurs on a current build, record the motherboard model and revision, exact NIC controller, ZimaOS image version, whether link LEDs appear, whether the router issues a lease, and whether a known-good USB Ethernet adapter works.

If you can reach a shell, capture lspci -nnk, ip link, and relevant kernel messages without modifying drivers. Those outputs can distinguish “device not detected,” “driver not bound,” “link down,” and “DHCP failed,” which are very different failures even though the installer may show the same waiting screen.