Ten wątek sieciowy z listopada 2025 roku nie dotyczy typowego przypadku „ZimaOS nie ma sieci”. Serwer był online, miał adres DHCP i przesyłał dane przez interfejs Ethernet Intel I226-V, jednak Ustawienia > Sieć wyświetlały pustą sekcję Połączenie i nie oferowały możliwości skonfigurowania statycznego adresu IP. Komputer miał również dwa porty I226-V 2,5 GbE oraz dwa interfejsy Intel X710 SFP+, co czyniło go bardziej złożonym systemem wielointerfejsowym niż sprzęt, pod kątem którego ZimaOS pierwotnie zoptymalizowano interfejs sieciowy.
Wątek źródłowy rozwijał się od rezerwacji w routerze, przez zamianę portów i ponowne uruchamianie, ETHS eksperymentach konfiguracyjnych, testach API, a ostatecznie błędzie, który skłonił członka zespołu do podejrzenia lshw analizie składniowej. Publiczna rozmowa zakończyła się po tym, jak użytkownik przesłał prywatnie informacje o sprzęcie, dlatego nie ma opublikowanej ostatecznej poprawki.
Strona Sieć była pusta, mimo że serwer był dostępny
To rozróżnienie jest kluczowe. Problemem nie był po prostu „brak sterownika Ethernet”, ponieważ co najmniej jeden interfejs Ethernet działał i przesyłał dane.
Serwer miał cztery fizyczne porty sieciowe
Sprzęt źródłowy obejmował:
- dwa interfejsy Intel I226-V 2,5 GbE;
- dwa interfejsy Intel X710 SFP+;
- platformę z procesorem AMD Ryzen 7 PRO 8845HS;
- wiele dysków NVMe oraz planował dużą przestrzeń na dyskach HDD.
Użytkownik początkowo połączył się przez jeden z portów 2,5 GbE i otrzymał adres DHCP w okolicy 192.168.1.125.
Rezerwacja w routerze nie była przyczyną problemu
Zima-Giorgio zapytał, w jaki sposób użytkownik uzyskał adres. Użytkownik wyjaśnił, że został on przydzielony przez DHCP, a następnie router zarezerwował ten adres IP.
Później usunął rezerwację zgodnie z prośbą. ZimaOS otrzymał inny adres DHCP, co dowiodło, że interfejs nadal mógł komunikować się z routerem, ale strona Sieć pozostała pusta.
Ten negatywny wynik jest istotny: brakujący element interfejsu użytkownika nie pojawił się tylko wskutek usunięcia rezerwacji stałego adresu w routerze.
Przełączanie między dwoma portami I226-V nie naprawiło interfejsu użytkownika
Użytkownik zastanawiał się, czy podłączenie do drugiego interfejsu 2,5 GbE zamiast pierwszego nie powoduje problemów z ZimaOS. Przełożył kabel do drugiego portu I226-V, wyłączył i ponownie włączył urządzenie, po czym również otrzymał działający adres.
Ustawienia > Sieć nadal nie wyświetlały żadnego interfejsu.
ifconfig potwierdził działający interfejs Ethernet
W dalszej części źródło zawierało dane wyjściowe pokazujące, że eth0 jako:
- UP i DZIAŁAJĄCY;
- przypisany adres IPv4
192.168.1.123; - odbierając i wysyłając pakiety;
- zgłaszając zero błędów nośnika.
To mocny dowód na to, że linuksowy interfejs sieciowy działał, podczas gdy warstwa zarządzania ZimaOS nie potrafiła go prawidłowo wyliczyć.
Wątek następnie przeszedł do konfiguracji ETHS w ZimaOS
Wewnętrzny zimaos.conf plik pokazywał ETHS = puste. Następnie odpowiedzi społeczności i osób powiązanych z zespołem eksperymentowały z wpisywaniem adresów PCI w tym polu i ponownym uruchamianiem usług ZimaOS.
Zmiany te nie przywróciły użytkownikowi strony Sieć.
Jedna z prób ETHS dotyczyła niewłaściwych interfejsów
Użytkownik zauważył, że pierwsze sugerowane adresy PCI odpowiadały portom SFP+, a nie interfejsom 2.5GbE. Następnie wypróbował adresy PCI interfejsów I226-V.
Nawet po skorygowaniu docelowych urządzeń i ponownym uruchomieniu usług strona ustawień nadal nie wyświetlała interfejsów. To kolejny powód, aby nie przedstawiać ETHS edycji jako potwierdzonego rozwiązania.
Wątek ujawnił historyczną granicę założeń dotyczących sprzętu
W jednej z odpowiedzi stwierdzono, że wcześniejsze prace nad zgodnością z rozwiązaniami mesh i wyświetlaczami koncentrowały się głównie na urządzeniach ZimaCube, a inny sprzęt mógł wymagać jawnych informacji PCI. Ten komentarz pomaga wyjaśnić, dlaczego ogólny mini-serwer z czterema kartami sieciowymi mógł uruchomić ścieżkę, z którą prostszy sprzęt się nie spotykał.
Nie należy interpretować tego jako aktualnego wymogu ręcznego konfigurowania całego sprzętu ZimaOS innych firm ETHS konfiguracji.
Lokalne API interfejsów sieciowych zwróciło błąd
Po tym, jak zmiany konfiguracji nie przyniosły rezultatu, w wątku przetestowano lokalne API sieciowe ZimaOS:
curl http://127.0.0.1/v2/zimaos/network/interfacesZwrócony błąd przeniósł dochodzenie z konfiguracji statycznego adresu IP na usługę odpowiedzialną za wykrywanie lub serializowanie informacji o sprzęcie.
Ostateczna publiczna diagnoza wskazywała na analizowanie danych lshw
Późniejsza odpowiedź stwierdzała, że błąd interfejsu API sugerował problem z analizowaniem lshw informacje i poprosił użytkownika o zebranie pełnej listy sprzętu do /DATA/lshw.logNastępnie użytkownik przesłał wynik prywatnie.
Ponieważ publiczny wątek urywa się w tym miejscu, strona nie może wymyślać wyniku prac inżynieryjnych. Ostatnie potwierdzone stwierdzenie jest takie, że zespół podejrzewał problem z analizowaniem informacji o sprzęcie i przeniósł szczegółową diagnozę do prywatnych wiadomości.
Żądanie sterownika Intel X710 było odrębnym tematem
Użytkownik chciał również, aby obsługiwane były dwa porty X710 SFP+, i ostatecznie miał nadzieję korzystać z agregacji łączy. Zima-Giorgio powiedział, że prośba dotycząca integracji sterownika zostanie przekazana do weryfikacji.
Nie należy mylić tej prośby z działającym interfejsem I226-V, który już obsługiwał połączenie zarządzające ZimaOS.
Nie rozwiązuj problemu brakującego interfejsu w interfejsie użytkownika, od razu wymuszając użycie nmcli
Użytkownik rozważał ustawienie statycznego adresu IP za pomocą nmcli ponieważ interfejsu nie było w interfejsie użytkownika. To narzędzie może konfigurować sieć Linuksa, ale nie naprawia przyczyny, dla której ZimaOS nie wykrywa interfejsu, a nowsze wersje ZimaOS udostępniają obsługiwane ustawienia statycznego adresu IP w Ustawieniach.
W aktualnym systemie użyj bieżącego działania sieci w ZimaOS jako punktu odniesienia dla tego, co powinno być widoczne w Ustawieniach.
Obecna wersja ZimaOS powinna wyświetlać fizyczne porty Ethernet
Zgodnie z aktualnymi wskazówkami dotyczącymi sieci fizyczne interfejsy Ethernet powinny być wyświetlane wraz z nazwą interfejsu, stanem połączenia, wynegocjowaną prędkością i przypisanym adresem IP. Jeśli w systemie Linux działa interfejs, ale strona Sieć jest pusta, zbierz dane diagnostyczne usługi zarządzającej zamiast wielokrotnie zmieniać ustawienia routera.
Co zebrać w podobnym aktualnym przypadku
- dokładna wersja ZimaOS;
-
lspci -nndla wszystkich kontrolerów sieciowych; - bieżące dane wyjściowe interfejsu i adresu;
- stan połączenia każdego fizycznego portu;
- zrzut ekranu strony Sieć;
- wyniki odpowiednich interfejsów API sieci ZimaOS lub logi, gdy zażąda ich pomoc techniczna;
- inwentaryzacji sprzętu, takiej jak
lshwjeśli usługa enumeracji przestaje działać.
Co faktycznie wynika z wątku
Serwer mógł łączyć się z siecią przez interfejs Intel I226-V, podczas gdy Ustawienia ZimaOS nie wyświetlały tego interfejsu. Usunięcie rezerwacji routera, przełączanie między portami I226-V, cykle zasilania i ręczne ETHS edycje nie naprawiły wyświetlania. Dochodzenie zakończyło się podejrzeniem lshw problem z analizą po prywatnym dalszym kontakcie.
FAQ: brak interfejsu sieciowego
Czy serwer rzeczywiście był offline?
Nie. Serwer miał adres DHCP, a aktywny interfejs Ethernet przesyłał dane.
Czy usunięcie rezerwacji routera naprawiło stronę Sieć?
Nie. Serwer otrzymał nowy adres DHCP, ale elementy sterujące interfejsem nadal były niedostępne.
Czy przełączenie na drugi port I226-V rozwiązało problem?
Nie.
Czy ręczna edycja ETHS rozwiązała problem?
Na podstawie tych eksperymentów nie potwierdzono żadnego publicznego rozwiązania.
Jaka była ostatnia publiczna wskazówka diagnostyczna?
Błąd API skierował dyskusję w stronę możliwej lshw problem z analizą informacji.
