Denna nätverkstråd från november 2025 handlar inte om ett vanligt fall där ”ZimaOS saknar nätverk”. Servern var online, hade en DHCP-adress och överförde trafik via ett Intel I226-V-Ethernetgränssnitt, men Inställningar > Nätverk visade ett tomt avsnitt för Anslutning och erbjöd inget sätt att konfigurera en statisk IP-adress. Maskinen hade dessutom två I226-V-portar för 2,5 GbE och två Intel X710 SFP+-gränssnitt, vilket gjorde den till ett mer komplext system med flera nätverkskort än den maskinvara som ZimaOS ursprungligen hade optimerat sitt nätverksgränssnitt för.
Källtråden gick vidare genom routerreservationer, portbyten, omstarter, ETHS konfigurationsexperiment, API-testning och slutligen ett fel som fick en teammedlem att misstänka lshw parsning. Den offentliga konversationen avslutades efter att användaren skickat maskinvaruinformation privat, så det finns ingen publicerad slutgiltig lösning.
Sidan Nätverk var tom trots att servern var nåbar
Denna åtskillnad är avgörande. Problemet var inte ”ingen Ethernet-drivrutin” i enkel bemärkelse, eftersom minst ett Ethernet-gränssnitt var aktivt och överförde trafik.
Servern hade fyra fysiska nätverksportar
Källans maskinvara omfattade:
- två Intel I226-V 2,5 GbE-gränssnitt;
- två Intel X710 SFP+-gränssnitt;
- en AMD Ryzen 7 PRO 8845HS-plattform;
- flera NVMe-enheter och planerade stor HDD-lagring.
Användaren anslöt först via en av 2,5 GbE-portarna och fick en DHCP-adress omkring 192.168.1.125.
En routerreservation var inte grundorsaken
Zima-Giorgio frågade hur användaren hade fått adressen. Användaren förklarade att DHCP tilldelade den och att routern sedan reserverade den IP-adressen.
De tog senare bort reservationen enligt önskemål. ZimaOS fick en annan DHCP-adress, vilket bevisade att gränssnittet fortfarande kunde kommunicera med routern, men sidan Nätverk förblev tom.
Detta negativa resultat är viktigt: det saknade gränssnittet i gränssnittet återkom inte enbart genom att ta bort routerns reservation av en fast adress.
Att växla mellan de två I226-V-portarna löste inte problemet i gränssnittet
Användaren undrade om anslutningen till det andra 2,5 GbE-gränssnittet i stället för det första förvirrade ZimaOS. De flyttade kabeln till den andra I226-V-porten, startade om maskinen genom att bryta och återställa strömmen och fick även där en fungerande adress.
Inställningar > Nätverk visade fortfarande inget gränssnitt.
ifconfig bekräftade ett aktivt Ethernet-gränssnitt
Källan publicerade senare utdata som visade eth0 som:
- UPPE och IGÅNG;
- tilldelad IPv4-adress
192.168.1.123; - tog emot och skickade paket;
- rapporterade noll bärarfel.
Det är ett starkt tecken på att Linux-nätverksgränssnittet fungerade medan ZimaOS-administrationslagret inte lyckades räkna upp det korrekt.
Tråden övergick sedan till ZimaOS ETHS-konfiguration
Den interna zimaos.conf filen visade ETHS = tom. Svar från communityn och personer nära teamet experimenterade sedan med att ange PCI-adresser i det fältet och starta om ZimaOS-tjänsterna.
Dessa ändringar återställde inte nätverkssidan för användaren.
Ett ETHS-försök riktades mot fel gränssnitt
Användaren lade märke till att de först föreslagna PCI-adresserna motsvarade SFP+-portarna i stället för 2,5 GbE-gränssnitten. Därefter provade användaren i stället PCI-adresserna för I226-V.
Även efter att målenheterna korrigerats och tjänsterna startats om visade inställningssidan fortfarande inte gränssnitten. Detta är ytterligare en anledning att inte framställa ETHS redigera det till en bevisad lösning.
Tråden avslöjade en historisk gräns för hårdvaruantaganden
Ett svar angav att tidigare arbete med kompatibilitet för mesh och skärmar främst hade riktats mot ZimaCube-enheter och att annan hårdvara kunde behöva uttrycklig PCI-information. Kommentaren bidrar till att förklara varför en generell mini-server med fyra nätverkskort kunde aktivera en kodväg som enklare hårdvara inte gjorde.
Det ska inte tolkas som ett aktuellt krav på att all ZimaOS-hårdvara från tredje part måste använda manuell ETHS konfigurationen.
Det lokala API:et för nätverksgränssnitt returnerade ett fel
Efter att konfigurationsändringarna misslyckats testade tråden det lokala ZimaOS-nätverks-API:et:
curl http://127.0.0.1/v2/zimaos/network/interfacesDet returnerade felet flyttade utredningen från konfigurationen av statiska IP-adresser till tjänsten som ansvarade för att upptäcka eller serialisera hårdvaruinformation.
Den slutliga offentliga diagnosen pekade mot lshw-tolkningen
Ett senare svar angav att API-felet tydde på ett problem med tolkningen av lshw information och bad användaren samla in en fullständig hårdvarulista i /DATA/lshw.log. Användaren skickade sedan resultatet privat.
Eftersom den offentliga tråden slutar där får sidan inte hitta på något tekniskt resultat. Det senaste underbyggda påståendet är att teamet misstänkte problem med tolkningen av hårdvaruinformation och flyttade den detaljerade felsökningen till privata meddelanden.
Begäran om Intel X710-drivrutin var ett separat ämne
Användaren ville också få de två X710 SFP+-portarna stödda och hoppades så småningom kunna använda länkaggregering. Zima-Giorgio sade att begäran om drivrutinsintegrering skulle vidarebefordras för granskning.
Den begäran ska inte förväxlas med det fungerande I226-V-gränssnitt som redan bar ZimaOS-hanteringsanslutningen.
Lös inte ett saknat gränssnitt i användargränssnittet genom att omedelbart tvinga fram nmcli
Användaren övervägde att tilldela en statisk IP-adress via nmcli eftersom gränssnittet saknades. Det kan konfigurera Linux-nätverk, men det åtgärdar inte varför ZimaOS inte kan identifiera gränssnittet, och senare ZimaOS-versioner tillhandahåller stödda kontroller för statiska IP-adresser i Inställningar.
På ett aktuellt system använder du det aktuella nätverksbeteendet i ZimaOS som referens för vad som ska visas i Inställningar.
Aktuella ZimaOS bör visa fysiska Ethernetportar
Enligt aktuell nätverksvägledning ska fysiska Ethernetgränssnitt visas med gränssnittsnamn, länkstatus, förhandlad hastighet och tilldelad IP-adress. Om Linux har ett fungerande gränssnitt men nätverkssidan är tom ska du samla in diagnostik för hanteringstjänsten i stället för att upprepade gånger ändra routern.
Vad du ska samla in för ett liknande aktuellt fall
- den exakta ZimaOS-versionen;
-
lspci -nnför alla nätverksstyrenheter; - utdata för aktuellt gränssnitt och aktuell adress;
- länkstatus för varje fysisk port;
- skärmbild av nätverkssidan;
- resultat från relevanta ZimaOS-nätverks-API:er eller loggar när supporten begär det;
- en maskinvaruinventering som
lshwom uppräkningsservicen verkar ha slutat fungera.
Vad tråden faktiskt bevisar
Servern kunde kommunicera över nätverket via ett Intel I226-V-gränssnitt medan ZimaOS-inställningarna inte visade det. Borttagning av routerreservationen, byte mellan I226-V-portarna, omstarter och manuella ETHS ändringar löste inte visningsproblemet. Undersökningen slutade med en misstanke om lshw parsningproblem med privat uppföljning.
Vanliga frågor om saknat nätverksgränssnitt
Var servern faktiskt frånkopplad?
Nej. Den hade en DHCP-adress och det aktiva Ethernetgränssnittet överförde trafik.
Löste det problemet med nätverkssidan att ta bort routerreservationen?
Nej. Servern fick en ny DHCP-adress, men gränssnittskontrollerna saknades fortfarande.
Löste det problemet att byta till den andra I226-V-porten?
Nej.
Löste manuella ETHS-ändringar problemet?
Ingen offentlig lösning bekräftades utifrån dessa experiment.
Vilken var den senaste offentliga diagnostiska ledtråden?
Ett API-fel ledde diskussionen mot en möjlig lshw problem med informationsparsning.
