This November 2025 network thread is not a normal “ZimaOS has no network” case. The server was online, had a DHCP address, and transferred traffic through an Intel I226-V Ethernet interface, yet Settings > Network showed an empty Connection section and offered no way to configure a static IP. The machine also had two I226-V 2.5GbE ports and two Intel X710 SFP+ interfaces, making it a more complex multi-NIC system than the hardware ZimaOS had originally optimized its network UI around.
The source thread progressed through router reservations, port swapping, reboots, internal ETHS configuration experiments, API testing, and finally an error that led a team member to suspect lshw parsing. The public conversation ended after the user sent hardware information privately, so there is no published final fix.
The Network Page Was Empty While the Server Was Reachable
This distinction is essential. The problem was not “no Ethernet driver” in the simple sense because at least one Ethernet interface was up and carrying traffic.
The Server Had Four Physical Network Ports
The source hardware included:
- two Intel I226-V 2.5GbE interfaces;
- two Intel X710 SFP+ interfaces;
- an AMD Ryzen 7 PRO 8845HS platform;
- multiple NVMe drives and planned large HDD storage.
The user initially connected through one of the 2.5GbE ports and received a DHCP address around 192.168.1.125.
A Router Reservation Was Not the Root Cause
Zima-Giorgio asked how the user obtained the address. The user explained that DHCP assigned it and the router then reserved that IP.
They later removed the reservation as requested. ZimaOS received a different DHCP address, proving the interface could still communicate with the router, but the Network page remained empty.
This negative result is important: the missing UI was not fixed merely by removing the router's fixed-address reservation.
Switching Between the Two I226-V Ports Did Not Fix the UI
The user wondered whether being connected to the second 2.5GbE interface rather than the first was confusing ZimaOS. They moved the cable to the other I226-V port, power-cycled the machine, and received a working address there as well.
Settings > Network still did not show an interface.
ifconfig Confirmed a Live Ethernet Interface
The source later posted output showing eth0 as:
- UP and RUNNING;
- assigned IPv4 address
192.168.1.123; - receiving and transmitting packets;
- reporting zero carrier errors.
That is strong evidence that the Linux network interface was functioning while the ZimaOS management layer failed to enumerate it correctly.
The Thread Then Moved into ZimaOS ETHS Configuration
The internal zimaos.conf file showed ETHS = blank. Community and team-adjacent replies then experimented with inserting PCI addresses into that field and restarting ZimaOS services.
Those edits did not restore the Network page for the user.
One ETHS Attempt Targeted the Wrong Interfaces
The user noticed that the first suggested PCI addresses corresponded to the SFP+ ports rather than the 2.5GbE interfaces. They then tried the I226-V PCI addresses instead.
Even after correcting the target devices and restarting services, the settings page still did not expose the interfaces. This is another reason not to package the ETHS edit as a proven solution.
The Thread Revealed a Historical Hardware-Assumption Boundary
One reply said that earlier mesh/display compatibility work had primarily targeted ZimaCube devices and that other hardware might need explicit PCI information. That comment helps explain why a generic four-NIC mini server could exercise a path that simpler hardware did not.
It should not be read as a current requirement that all third-party ZimaOS hardware needs manual ETHS configuration.
The Local Network Interfaces API Produced an Error
After the configuration edits failed, the thread tested the local ZimaOS network API:
curl http://127.0.0.1/v2/zimaos/network/interfacesThe returned error shifted the investigation away from static-IP configuration and toward the service responsible for discovering or serializing hardware information.
The Final Public Diagnosis Pointed Toward lshw Parsing
A later reply said the API error suggested a problem parsing lshw information and asked the user to collect a full hardware listing into /DATA/lshw.log. The user then sent the result privately.
Because the public thread stops there, the page must not invent the engineering outcome. The last supported statement is that the team suspected hardware-information parsing and moved detailed diagnosis to private messages.
The Intel X710 Driver Request Was a Separate Topic
The user also wanted the two X710 SFP+ ports supported and eventually hoped to use link aggregation. Zima-Giorgio said the driver-integration request would be forwarded for review.
That request should not be confused with the working I226-V interface that already carried the ZimaOS management connection.
Do Not Solve a Missing Interface UI by Immediately Forcing nmcli
The user considered applying a static IP through nmcli because the UI was missing. That can configure Linux networking, but it does not repair why ZimaOS fails to enumerate the interface, and later ZimaOS versions provide supported static-IP controls in Settings.
On a current system, use the current ZimaOS Network behavior as the baseline for what should appear in Settings.
Current ZimaOS Should List Physical Ethernet Ports
Current networking guidance says physical Ethernet interfaces should appear with interface name, link state, negotiated speed, and assigned IP address. If Linux has a working interface but the Network page is empty, collect diagnostics for the management service rather than repeatedly changing the router.
What to Collect for a Similar Current Case
- the exact ZimaOS version;
-
lspci -nnfor all network controllers; - current interface and address output;
- link state for each physical port;
- the Network page screenshot;
- results from relevant ZimaOS network APIs or logs when requested by support;
- a hardware inventory such as
lshwif the enumeration service appears to fail.
What the Thread Actually Proves
The server could network through an Intel I226-V interface while ZimaOS Settings failed to show it. Router reservation removal, switching between I226-V ports, power cycles, and manual ETHS edits did not fix the display. The investigation ended at a suspected lshw parsing problem with private follow-up.
Missing Network Interface FAQ
Was the server actually offline?
No. It had a DHCP address and the active Ethernet interface carried traffic.
Did removing the router reservation fix the Network page?
No. The server received a new DHCP address but the interface controls remained missing.
Did switching to the other I226-V port fix it?
No.
Did manual ETHS edits solve the problem?
No public solution was confirmed from those experiments.
What was the last public diagnostic clue?
An API error led the discussion toward a possible lshw information-parsing problem.
