Moduł WireGuard nie ładuje się po aktualizacji jądra? Sprawdź to

Twój tunel działał wczoraj, po aktualizacji maszyna uruchomiła się ponownie, a teraz interfejs nie wstaje. W systemie, w którym WireGuard jest budowany jako moduł zewnętrzny, zwykle przyczyną jest to, że moduł na dysku należy do innego wydania jądra niż to, które działa teraz. Nagłówki o podobnej nazwie na tej samej maszynie niczego nie dowodzą w kwestii tego dopasowania. Decyduje o tym tylko ciąg wydania.

Działające czy zainstalowane jądro

Aktualizacja instaluje nowy pakiet jądra, a stary zostawia na dysku, dopóki maszyna nie zostanie ponownie uruchomiona. Po ponownym uruchomieniu działające wydanie się zmienia, a każdy moduł zbudowany dla poprzedniego staje się bezużyteczny, mimo że jego pliki wciąż tam są. Ta luka wyjaśnia znane zgłoszenie o maszynie, która przed restartem była w porządku, a po nim się zepsuła, bez żadnej zmiany konfiguracji pomiędzy. Wyjaśnia też, dlaczego ponowna instalacja nagłówków czasami wydaje się rozwiązywać problem, a czasami nie.

Pakiet nagłówków, który instalujesz, może odpowiadać najnowszemu pakietowi jądra, a nie jądru, które faktycznie zostało uruchomione, i nic w nazwie pakietu nie odróżnia tych przypadków; robi to tylko ciąg wydania. Sprawdź, co działa, zanim sprawdzisz, co jest zainstalowane.

Trzy sprawdzenia przed ponowną kompilacją

Pierwsze sprawdzenie to, które jądro działa. Drugie to, czy istnieje moduł dla tego wydania i czy można go znaleźć. Trzecie to, czy jądro już go załadowało. Czwarte pytanie, czy można utworzyć interfejs, sprawdza uprawnienia, a nie moduł, więc należy po ponownej kompilacji, a nie do tej listy.

Poniższe polecenia odpowiadają na pierwsze trzy, niczego nie zmieniając. Przeczytaj każdy wynik przed przejściem dalej, ponieważ każda odpowiedź wyklucza inną naprawę.

uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard

Jeśli druga linia zgłasza, że ścieżka nie istnieje, brakuje środowiska budowania dla działającego jądra i nic, co skompilujesz, nie będzie do niego pasować. Jeśli modinfo zawiedzie, gdy ścieżka istnieje, moduł może w ogóle nie być zainstalowany, co jest normalne w jądrach dostarczających implementację w drzewie. Jeśli modinfo się powiedzie, a lsmod nic nie pokaże, moduł istnieje, ale nie jest załadowany, co jest problemem ładowania, a nie budowania. Każdy wynik prowadzi gdzie indziej, dlatego czytanie jest ważniejsze niż polecenia.

Buduj dla działającego wydania

Moduł zewnętrzny kompiluje się względem przygotowanego drzewa jądra, a przewodnik jądra po modułach zewnętrznych opisuje używanie katalogu budowania należącego do działającego jądra, a nie tego z najwyższym numerem wersji. Ten katalog budowania to dowiązanie symboliczne utrzymywane przez pakiet jądra, więc wskazuje drzewo wydania, które zostało właśnie uruchomione. Pośredniość jest tu właśnie sednem: usuwa wybór, który inaczej zrobiłbyś źle. Nazwanie go wprost czyni cel jednoznacznym.

Jeden szczegół ma znaczenie, gdy drzewo jest tylko przygotowane, a nie w pełni zbudowane. Cel przygotowania nie tworzy pliku wersjonowania symboli, którego potrzebują niektóre zewnętrzne budowania, więc drzewo pełne nagłówków nie jest automatycznie kompletnym środowiskiem budowania. Jeśli budowanie zawiedzie z powodu brakujących symboli, ten plik jest pierwszym miejscem do sprawdzenia.

sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a

Gdy pakowane nagłówki pozostają w tyle

W dystrybucjach i komputerach jednopłytkowych, które pakują własne jądra, nagłówki mogą tygodniami lub dniami pozostawać za wydaniem. Pakiet nagłówków może być poprawny z nazwy i starszy w treści, co daje budowanie, które się kompiluje, a potem zawodzi przy ładowaniu, a nie podczas kompilacji. Mieszanie źródeł pogarsza sprawę: jądro dystrybucji z nagłówkami z repozytorium firmy trzeciej albo jądro producenta z nagłówkami ogólnymi może się czysto skompilować i mimo to zostać odrzucone przez działające jądro, bo konfiguracja się różni. Same numery wersji tego nie rozstrzygają.

Jeśli maszyna podąża za eksperymentalnym kanałem jądra, świadomie zdecyduj, czy zostać przy nim z pasującymi artefaktami budowania, czy wrócić do wspieranego zestawu pakietów. Powtarzanie aktualizacji i nadzieja, że elementy się dopasują, nie jest planem, bo ta sama niezgodność powtarza się za każdym razem.

Zweryfikuj interfejs po ponownej kompilacji

Po udanej instalacji utworzenie interfejsu jest testem, który się liczy, a następnie odczytanie, co jądro faktycznie załadowało i co mówi dziennik, jeśli odmówiło. Moduł, który się ładuje, i interfejs, którego nie można utworzyć, to różne awarie o różnych przyczynach. Trzy poniższe polecenia je rozdzielają.

sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5

Jeśli moduł odmawia załadowania, dziennik jądra podaje przyczynę, a niezgodność wersji jest tylko jedną z możliwości. Przeczytaj tę linię przed ponowną kompilacją, bo drugie identyczne budowanie zajmuje te same dziesięć minut i daje tę samą odmowę. Potem usuń tymczasowy interfejs, aby następny test zaczął się od czystego stanu.