,

Kali Linux 2026.2: 3-krotne przyspieszenie bootowania VM i krytyczne aktualizacje wymagające restartu

Wydanie Kali Linux 2026.2 wprowadza drastyczne odchudzenie obrazów maszyn wirtualnych, co przekłada się na około trzykrotnie szybszy czas uruchamiania systemu. Dla zespołów Red Team i inżynierów bezpieczeństwa oznacza to mniejszy narzut infrastrukturalny, jednak wprowadzono również disruptywne pakiety, które wymuszają bezwzględne restarty środowisk po aktualizacji, aby uniknąć paraliżu operacyjnego.

Dlaczego instalacje w maszynach wirtualnych uruchamiają się teraz 3-krotnie szybciej?

Kali Linux 2026.2 eliminuje preinstalowane oprogramowanie układowe (firmware) dla układów graficznych NVidia, AMD oraz Intel w obrazach przeznaczonych dla maszyn wirtualnych. Dzięki usunięciu nieużywanych sterowników, rozmiar obrazu początkowego initrd (initramfs) zmniejszył się z 200 MB do zaledwie 60 MB. To optymalizacyjne cięcie redukuje czas bootowania środowisk VM, w tym QEMU, około trzykrotnie.

  • Instalatory systemu potrafią teraz automatycznie wykryć instalację w środowisku wirtualnym i na tej podstawie całkowicie pominąć instalację oprogramowania graficznego.
  • Użytkownicy instalacji baremetalowych (bezpośrednio na sprzęcie) nie odczują zmiany; ich obrazy initrd nadal zajmują 200 MB, oferując wsparcie dla wszystkich układów out-of-the-box.
  • Jedynym scenariuszem VM, w którym firmware pozostaje niezbędny, jest konfiguracja z włączonym GPU passthrough.

Jakie aktualizacje pakietów w Kali Linux 2026.2 paraliżują pracę bez restartu systemu?

Najnowsza aktualizacja wprowadza krytyczne, zakłócające zmiany w pakietach polkitd oraz xrdp w wersji 0.10, które bezwzględnie wymagają pełnego restartu systemu operacyjnego natychmiast po instalacji. Zignorowanie tego kroku po wykonaniu komendy apt full-upgrade skutkuje kryptograficznymi błędami podczas prób uruchamiania aplikacji graficznych z uprawnieniami roota oraz całkowitym zablokowaniem sesji zdalnych RDP.

  • Pakiet polkitd: Jeśli aplikacje graficzne nie działają jako root po restarcie, inżynierowie powinni zweryfikować, czy uruchomiona została powiązana usługa polkit-agent-helper.
  • Usługa xrdp (Hyper-V): Aktualizacja dotyka m.in. użytkowników Hyper-V pracujących w trybie Enhanced Session Mode. W przypadku utraty funkcjonalności xrdp należy skorzystać z narzędzia kali-tweaks, przejść do sekcji Virtualization, wyłączyć i ponownie włączyć tryb Enhanced Session Mode, a następnie zrestartować maszynę.

W jaki sposób zreorganizowano architekturę usług i repozytoriów APT?

Inżynierowie ustandaryzowali skrypty pomocnicze do zarządzania usługami, wprowadzając ujednolicone polecenia <tool>-start i <tool>-stop, które teraz sprawdzają status działania procesu, zapobiegają podwójnemu uruchomieniu, wyświetlają domyślne poświadczenia oraz automatycznie otwierają interfejsy webowe w przeglądarce. Równocześnie zdeprecjonowano klasyczny plik konfiguracji repozytoriów, wymuszając przejście na nowocześniejszy standard oparty na formacie z Debiana.

  • Tradycyjny i powszechnie znany plik /etc/apt/sources.list zostaje oficjalnie wycofany.
  • Nowe instalacje wykorzystują domyślnie format deb822-style w pliku /etc/apt/sources.list.d/kali.sources.
  • Starsze systemy zachowują wsteczną zgodność obu plików, jednak menedżer APT zacznie wyświetlać ostrzeżenia i sugerować modernizację.

Wnioski praktyczne

  • Zarządzanie kernelami: Jeśli wykorzystujesz sprzęt z kartami NVidia działającymi w oparciu o sterowniki DKMS, korzystaj z domyślnego jądra Linux 6.19. Jądro 7.0 wykazuje niekompatybilności z tymi układami i celowo przeniesiono je wyłącznie do repozytorium kali-experimental (oraz kali-rolling).
  • Provisioning systemów: Zaktualizuj skrypty automatyzujące (Ansible, Terraform) o nowy standard ścieżek dla menedżera APT (sources.list.d) przed wdrożeniem zautomatyzowanych testów.
  • Procedury utrzymaniowe: Dodaj krok wymuszonego restartu węzła w potokach CI/CD lub skryptach aktualizacyjnych po instalacji wydania 2026.2, aby uniknąć problemów z podnoszeniem uprawnień i przerwaniem połączeń zdalnych.
Przemysław Majdak

Przemysław Majdak · AI Automation Engineer

Założyciel Baluarte i wydawca BitBiz.pl. Członek ISSA Polska. Ekspert z 18-letnim stażem w branży IT — wdraża bezpieczne automatyzacje AI, systemy full-stack i zaawansowane procedury cyberbezpieczeństwa dla firm. Wszystkie artykuły autora →

2 odpowiedzi

💬 Kliknij tutaj, aby dodać komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

  1. Awatar Wiktor

    Fajnie, że w końcu podeszli do optymalizacji VM, bo to było irytujące, jak się czekało wieki na boota Kali w labie – trzy razy szybciej brzmi faktycznie jak game changer dla Red Teamu. Ale z drugiej strony, to „bezwzględne restarty po aktualizacji” to typowa deweloperska wpadka: rozwiązują jeden problem (narzut infrastrukturalny) i stwarzają drugi (paraliż operacyjny, jeśli nie zrestartujesz). Ciekawe, co to za disruptive pakiety, które wymagają restartu – wygląda, że ktoś zmodyfikował coś w initramfs albo jądrze tak głęboko, że bez rebootu system i tak by nie działał poprawnie. No ale w praktyce, jeśli pracujesz na zdalnym VM i nagle dostajesz info, że musisz go zresetować, to może zepsuć cały flow podczas testów.

  2. Awatar Marek.K

    No dobra, trzy razy szybsze bootowanie VM brzmi świetnie, ale to „bezwzględne restarty” po aktualizacji trochę zabija cały sens tej optymalizacji – bo jeśli musisz restartować środowisko w trakcie operacji, to te zaoszczędzone sekundy przy starcie i tak sobie odbijesz na przestoju. Ciekawe, czy twórcy Kali pomyśleli o tym, że Red Team często stawia tymczasowe maszyny na chwilę i właśnie na tym zyskuje, a nie na długotrwałym uptime’ie? No nic, przynajmniej widać, że ktoś w końcu zdiagnozował, czemu te obrazy były takie ciężkie.