Gdy zwykła aktualizacja RouterOS nie wystarcza
Rutynowa aktualizacja RouterOS zwykle sprowadza się do sprawdzenia dostępnej wersji, pobrania pakietów i ponownego uruchomienia urządzenia. Inaczej wygląda sytuacja, gdy chcemy wykonać czystą instalację systemu albo router przestaje uruchamiać się w sposób pozwalający na normalne zarządzanie.
Do takich zadań służy Netinstall. Pozwala zainstalować RouterOS przez Ethernet po uruchomieniu urządzenia w trybie Etherboot. Dotychczas administrator najczęściej przygotowywał w tym celu komputer z narzędziem Netinstall dla Windows albo Linux. Teraz rolę serwera może pełnić sam router MikroTik.
Sprawdziliśmy to na dwóch fizycznych urządzeniach. hAP ax S pracował jako serwer Netinstall, a na hAP ax² przeprowadziliśmy reinstalację RouterOS. Poniżej pokazujemy nie tylko ustawienia, ale też komunikaty pojawiające się podczas operacji i wynik kontroli po restarcie.
Czym jest Netinstall Package?
Netinstall Package to dodatkowy pakiet RouterOS, dostępny od wersji 7.24beta1 dla obsługiwanych architektur z wyjątkiem SMIPS. Udostępnia usługę Netinstall bezpośrednio na urządzeniu MikroTik. Konfigurację można przygotować w WinBox, WebFig lub CLI, w menu Tools → Netinstall.
Urządzenie docelowe musi wejść w tryb Etherboot i komunikować się z serwerem w tym samym segmencie warstwy drugiej (L2). Serwer odpowiada na żądanie BOOTP, rozpoznaje architekturę urządzenia, przygotowuje pliki rozruchowe i instaluje wybraną wersję RouterOS. Podstawowy pakiet systemowy jest dobierany automatycznie, natomiast pakiety dodatkowe, takie jak sterownik Wi-Fi, trzeba wskazać osobno.
O czym pamiętać przed reinstalacją
- Netinstall formatuje pamięć systemową urządzenia docelowego. Zwykły reset konfiguracji nie zastępuje tego procesu.
- Opcja Keep Old Configuration dotyczy podstawowej konfiguracji, a nie zachowania plików użytkownika, kontenerów i podobnych danych.
- Netinstall nie usuwa licencji RouterOS ani ustawień RouterBOOT.
- Serwer potrzebuje miejsca na pliki cache. W zależności od urządzenia mogą być przechowywane w RAM albo pamięci trwałej.
- Najbezpieczniej przygotować osobny port lub segment L2, bez konkurencyjnych usług BOOTP i DHCP.
Przed wykonywaniem podobnej operacji na sprzęcie z istotną konfiguracją należy przygotować kopię zapasową i eksport ustawień. Nasz hAP ax² był urządzeniem testowym, dlatego w tym konkretnym doświadczeniu nie wykonywaliśmy backupu.
Laboratorium MWTC: serwer ARM, klient ARM64
Do próby wykorzystaliśmy dwa routery o różnych architekturach procesora. To celowy wybór: chcieliśmy sprawdzić, czy Netinstall uruchomiony na ARM poprawnie obsłuży instalację systemu na urządzeniu ARM64.
| Element | Serwer Netinstall | Urządzenie docelowe |
|---|---|---|
| Model | MikroTik hAP ax S | MikroTik hAP ax² |
| Rola | Udostępnienie Netinstall Package | Ponowna instalacja RouterOS |
| Architektura | ARM 32-bit | ARM64 |
| Pamięć RAM | 512 MiB | 1024 MiB |
| RouterOS w teście | 7.25 | Docelowo 7.25 |
| Pakiet Wi-Fi | wifi-mediatek | wifi-qcom |
| Połączenie testowe | ether4, 192.168.250.1/24 | ether1 w trybie Etherboot |
Na hAP ax S działał normalny RouterOS. Nie reinstalowaliśmy na nim systemu. Jedynym urządzeniem poddanym operacji Netinstall był hAP ax².
Instalacja Netinstall Package na hAP ax S
Zaczęliśmy od sprawdzenia parametrów serwera w System → Resources. hAP ax S pracował pod kontrolą RouterOS 7.25, miał 512 MiB RAM i 128 MiB pamięci NAND. Na tym etapie dostępnych było około 425 MiB wolnej pamięci RAM i 99 MiB wolnej pamięci urządzenia.
Pakiet instalowaliśmy bezpośrednio przez WinBox:
- Otworzyliśmy System → Packages i sprawdziliśmy dostępne pakiety.
- Na liście znaleźliśmy netinstall ze statusem Installed: no.
- Zaznaczyliśmy netinstall i wybraliśmy Enable.
- Zatwierdziliśmy Apply Changes i ponownie uruchomiliśmy router.
- Po restarcie sprawdziliśmy, czy netinstall widnieje jako zainstalowany w wersji 7.25.
Po instalacji w Tools pojawiła się nowa pozycja Netinstall z trzema zakładkami: Netinstall, Cache oraz Devices. Już na tym etapie można więc przygotowywać większość ustawień w interfejsie graficznym.
Jeśli pakiet nie pojawia się na liście, dokumentacja MikroTik dopuszcza także pobranie odpowiedniego pliku .npk ze strony producenta. Musi odpowiadać architekturze i wersji RouterOS zainstalowanej na serwerze.
Port i adresacja dla serwera Netinstall
Na hAP ax S przeznaczyliśmy port ether4 do połączenia z urządzeniem docelowym. W IP → Addresses przypisaliśmy mu adres 192.168.250.1/24. Na zrzucie widać także inny, prywatny adres przypisany do ether1; został zasłonięty w wersji publikacyjnej, ponieważ nie ma związku z doświadczeniem.
Dla przewidywalnego działania BOOTP warto odseparować port Netinstall od pozostałej sieci, w szczególności od istniejących serwerów DHCP i BOOTP. Sam widok IP → Addresses nie dowodzi, czy ether4 został usunięty z bridge. Przy odtwarzaniu testu trzeba sprawdzić to osobno w Bridge → Ports.
Połączenie fizyczne było proste: ether4 na hAP ax S łączył się z ether1 na hAP ax². Serwer miał także dostęp do internetu potrzebny do pobierania plików systemowych.
Konfiguracja reguły Netinstall w WinBox
W Tools → Netinstall dodaliśmy nową regułę. Na potrzeby testu wskazaliśmy konkretny MAC urządzenia docelowego, aby serwer nie obsługiwał przypadkowych żądań od innych routerów. W opublikowanym zrzucie ten identyfikator został zasłonięty.
| Opcja | Ustawienie w teście |
|---|---|
| Interface | ether4 |
| MAC Address | MAC portu Etherboot hAP ax² (ukryty na zrzucie) |
| IP Range | Zakres BOOTP z sieci 192.168.250.0/24 |
| Version | 7.25 |
| Extra Packages | wifi-qcom |
| Keep Old Configuration | Wyłączone |
| Apply Default Configuration | Włączone |
| Auto Reboot | Reboot after installation |
| Wait | Włączone |
| Allow Etherboot | Włączone |
| Allow FlashFig | Wyłączone |
| Install Once | Włączone |
Kluczowa była opcja Wait. Dzięki niej urządzenie po wykryciu pozostało w stanie waiting for user, a instalację mogliśmy uruchomić dopiero po sprawdzeniu parametrów. Włączyliśmy także Install Once, która zapobiega ponownej instalacji na tym samym MAC podczas bieżącej sesji Netinstall. Nie jest to trwała blokada reinstalacji na zawsze.
Nie zachowywaliśmy starej konfiguracji hAP ax². Zaznaczyliśmy zastosowanie konfiguracji domyślnej po instalacji. FlashFig pozostawiliśmy wyłączony, bo celem tego testu była reinstalacja RouterOS, a nie masowe wgrywanie konfiguracji.
Cache: przygotowanie pakietów dla ARM64
W zakładce Cache dodaliśmy wpis dla architektury arm64, RouterOS 7.25 oraz pakietu wifi-qcom. To istotne rozróżnienie: hAP ax S, który działał jako serwer, używa sterownika wifi-mediatek, natomiast docelowy hAP ax² wymaga wifi-qcom.
Na początku lista cache zawierała pliki linux.arm64, linux.arm64-uefi i wifi-qcom-7.25-arm64.npk. W widoku listy nie było jeszcze głównego pakietu routeros.
Nie oznaczało to błędu. Dokumentacja Netinstall Package wskazuje, że pakiet systemowy routeros jest dobierany i instalowany automatycznie. W naszym teście został pobrany po ręcznym rozpoczęciu instalacji. Ostateczny wydruk cache potwierdził status downloaded dla wszystkich czterech plików.
Uruchomienie hAP ax² w trybie Etherboot
Aby router docelowy został wykryty, trzeba uruchomić go w trybie BOOTP/Etherboot. Dla hAP ax² MikroTik opisuje m.in. tryb Backup Booter:
- Wyłącz zasilanie hAP ax².
- Podłącz przewód z portu ether4 serwera do ether1 urządzenia docelowego.
- Przytrzymaj RESET i podłącz zasilanie do hAP ax².
- Poczekaj na sekwencję diody: miganie, światło ciągłe i zgaśnięcie.
- Zwolnij RESET po zgaśnięciu diody i obserwuj kartę Devices na serwerze.
Jest to procedura opisana przez producenta. W samym materiale testowym potwierdziliśmy stan wykrycia urządzenia; nie mierzono czasu przytrzymywania przycisku ani przebiegu sygnalizacji LED.
hAP ax² pojawił się w Tools → Netinstall → Devices. Serwer rozpoznał architekturę arm64, interfejs ether4, wybraną wersję 7.25 i dodatkowy pakiet wifi-qcom. Stan urządzenia miał wartość waiting for user — dokładnie tak, jak zakładaliśmy przy włączonej opcji Wait.
Ręczne rozpoczęcie instalacji: różnica między dokumentacją a WinBox
Tutaj trafiliśmy na ciekawą różnicę względem opisu w dokumentacji. MikroTik wymienia akcję Install w menu Devices, ale w naszym WinBoxie, przy zaznaczonym urządzeniu i RouterOS 7.25, panel Actions pokazywał jedynie Clear. Nie ustalaliśmy, z czego wynika brak przycisku w tym konkretnym widoku.
Aby rozpocząć operację, użyliśmy terminala na serwerze hAP ax S. Najpierw sprawdziliśmy numer urządzenia:
/tool/netinstall/devices/print
W naszym teście docelowy hAP ax² miał numer 0, więc uruchomiliśmy reinstalację poleceniem:
/tool/netinstall/devices/install numbers=0
Parametr numbers wskazuje numer w bieżącej liście Devices. Przy innym zestawie urządzeń nie należy kopiować wartości 0 bez sprawdzenia wyniku print.
Po wydaniu polecenia urządzenie przeszło ze stanu waiting for user do waiting for package. W tym momencie serwer rozpoczął przygotowanie brakującego pakietu systemowego routeros-7.25-arm64.npk.
Instalacja zakończona: done, won’t reinstall
Po zakończeniu procesu Netinstall pokazał stan done, won’t reinstall. To potwierdzenie zakończenia reinstalacji i działania mechanizmu Install Once. W tym samym wydruku cache widoczne były cztery pozycje ze statusem downloaded: oba pliki rozruchowe ARM64, pakiet routeros-7.25-arm64.npk oraz wifi-qcom-7.25-arm64.npk.
Stan końcowy był także widoczny w WinBox, w zakładce Devices.
W kolumnie Last-State-Update widniał czas, jaki upłynął od ostatniej zmiany stanu. Nie należy go interpretować jako zmierzonego czasu całej reinstalacji. Takiego pomiaru nie prowadziliśmy.
Kontrola hAP ax² po restarcie
Najważniejsza kontrola odbyła się już na samym hAP ax². Po ponownym uruchomieniu zalogowaliśmy się do RouterOS i otworzyliśmy System → Resources. Urządzenie zgłaszało architekturę ARM64, 1024 MiB pamięci RAM i wersję RouterOS 7.25.
W System → Packages znajdowały się pakiety routeros i wifi-qcom, oba w wersji 7.25. To potwierdziło, że instalator przygotował właściwy zestaw pakietów dla urządzenia docelowego.
W sekcji WiFi widoczne były interfejsy wifi1 i wifi2. Miały jednak flagę X, co oznacza stan wyłączony, a pola SSID były puste. Nie testowaliśmy zestawiania połączeń bezprzewodowych ani przepustowości Wi-Fi. Obecność interfejsów jest potwierdzeniem wykrycia sprzętu przez system, ale sama w sobie nie dowodzi poprawnej transmisji radiowej.
Co potwierdził nasz test, a czego nie sprawdzaliśmy?
| Weryfikacja | Wynik |
|---|---|
| Netinstall Package na hAP ax S z RouterOS 7.25 | Potwierdzone: pakiet aktywny i widoczny w Tools |
| Obsługa klienta o innej architekturze | Potwierdzone: ARM → ARM64 |
| Wykrycie hAP ax² przez Etherboot | Potwierdzone: waiting for user |
| Uruchomienie instalacji z CLI | Potwierdzone: install numbers=0 |
| Automatyczne pobranie routeros dla ARM64 | Potwierdzone: plik downloaded w cache |
| Zakończenie reinstalacji | Potwierdzone: done, won’t reinstall |
| RouterOS i wifi-qcom po restarcie | Potwierdzone: oba pakiety w wersji 7.25 |
| Transmisja Wi-Fi, transfery, czas całej operacji | Nie testowano |
| Preboot Etherboot i odzyskiwanie bez dostępu fizycznego | Nie testowano |
Najczęstsze problemy i dobre praktyki
Urządzenie nie pojawia się w Devices
Zacznij od fizycznego połączenia, poprawnego portu Etherboot, zgodności segmentu L2 i trybu rozruchowego. Sprawdź też, czy w regule wpisano właściwy MAC oraz czy inny serwer BOOTP nie odpowiada w tej samej sieci. W trybie serwisowym najłatwiej ograniczyć liczbę elementów pośrednich.
Widać waiting for user, ale instalacja nie rusza
Przy włączonym Wait jest to oczekiwane zachowanie. W naszym WinBoxie 7.25 przycisku Install nie było w panelu Actions, dlatego użyliśmy /tool/netinstall/devices/install z numerem rozpoznanym w bieżącym wydruku Devices. To obserwacja konkretnego środowiska, a nie dowód, że GUI nigdy nie obsługuje tej operacji.
Pojawia się waiting for package
Sprawdź Netinstall → Cache lub polecenie /tool/netinstall/cache/print. W naszym teście Netinstall pobrał wtedy automatycznie główny pakiet systemowy. Jeżeli urządzenie długo pozostaje w tym stanie, w pierwszej kolejności warto sprawdzić połączenie serwera z internetem, DNS oraz ilość miejsca dostępnego na cache.
Po instalacji pozostaje aktywna reguła Netinstall
Po zakończeniu prac wyłącz regułę albo ogranicz jej działanie do przeznaczonego środowiska testowego. Producent wyraźnie ostrzega przed niezamierzoną reinstalacją podczas kolejnych uruchomień routerów, szczególnie w scenariuszach z Preboot Etherboot. Install Once nie zastępuje kontroli dostępu do serwera.
Czy Netinstall Package ma sens w codziennej pracy administratora?
Po tym teście odpowiedź jest prosta: tak, zwłaszcza gdy na miejscu jest już MikroTik, który można przeznaczyć do obsługi serwisowej. Na hAP ax S przygotowaliśmy regułę, wykryliśmy hAP ax² przez Etherboot, uruchomiliśmy instalację i otrzymaliśmy sprawny RouterOS 7.25 z odpowiednim pakietem sterownika Wi-Fi. Nie potrzebowaliśmy osobnego komputera jako serwera Netinstall.
Nie jest to narzędzie do codziennych aktualizacji ani zamiennik kopii zapasowych. Przydaje się do czystej reinstalacji, przygotowywania urządzeń i odzyskiwania systemu, o ile spełnione są warunki rozruchu oraz łączności warstwy drugiej. Największym ograniczeniem ujawnionym w naszym laboratorium była konieczność użycia jednej komendy CLI mimo konfiguracji wykonanej w WinBoxie.
W praktyce warto mieć przygotowany wydzielony port instalacyjny, sprawdzoną regułę Netinstall oraz procedurę wyłączenia usługi po zakończeniu prac. Dzięki temu reinstalacja kolejnego routera nie zaczyna się od szukania komputera i konfigurowania jego karty sieciowej.
Źródła
- MikroTik – Netinstall Package: https://manual.mikrotik.com/docs/getting-started/installation-and-upgrade/netinstall/netinstall-package/
- MikroTik – Netinstall i Etherboot: https://manual.mikrotik.com/docs/getting-started/installation-and-upgrade/netinstall/
- MikroTik – Packages: https://manual.mikrotik.com/docs/getting-started/installation-and-upgrade/packages/
- MikroTik – hAP ax S: https://manual.mikrotik.com/hardware/hap-ax-s/
- MikroTik – hAP ax²: https://manual.mikrotik.com/hardware/hap-ax-2/
- MikroTik – Wi-Fi i pakiety sterowników: https://manual.mikrotik.com/docs/wireless/wifi/
Stan informacji z dokumentacji producenta zweryfikowany 3 listopada 2026 r. Wyniki urządzeń i przebieg próby udokumentowano zrzutami z rzeczywistego laboratorium MWTC.