Modulul WireGuard nu se încarcă după o actualizare de kernel? Verificați asta

Tunelul dumneavoastră funcționa ieri, mașina s-a repornit după o actualizare, iar acum interfața nu mai urcă. Pe un sistem unde WireGuard este compilat ca modul extern, cauza obișnuită este că modulul de pe disc aparține unei alte versiuni de kernel decât cea care rulează acum. Antetele cu nume similar pe aceeași mașină nu dovedesc nimic despre acea potrivire. Doar șirul versiunii decide acest lucru.

Kernel care rulează sau kernel instalat

O actualizare instalează un pachet nou de kernel și îl lasă pe cel vechi pe disc până când mașina se repornește. După repornire versiunea care rulează se schimbă, iar orice modul compilat pentru cea anterioară devine inutilizabil, deși fișierele sale sunt încă acolo. Acea diferență explică raportul cunoscut despre o mașină care era în regulă înainte de repornire și defectă după, fără nicio schimbare de configurație între ele. Explică și de ce reinstalarea antetelor pare uneori că rezolvă problema, iar alteori nu.

Pachetul de antete pe care îl instalați poate corespunde celui mai recent pachet de kernel și nu kernelului care a pornit de fapt, iar nimic din numele pachetului nu distinge aceste cazuri; doar șirul versiunii o face. Verificați ce rulează înainte de a verifica ce este instalat.

Trei verificări înainte de recompilare

Prima verificare este ce kernel rulează. A doua este dacă există un modul pentru acea versiune și dacă poate fi găsit. A treia este dacă kernelul l-a încărcat deja. A patra întrebare, dacă interfața poate fi creată, testează privilegiile și nu modulul, așa că își are locul după recompilare și nu în această listă.

Comenzile de mai jos răspund la primele trei fără a schimba nimic. Citiți fiecare rezultat înainte de a continua, pentru că fiecare răspuns exclude o altă reparație.

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

Dacă a doua linie raportează că calea nu există, mediul de compilare pentru kernelul care rulează lipsește și nimic din ce compilați nu se va potrivi. Dacă modinfo eșuează în timp ce calea există, modulul poate să nu fie instalat deloc, ceea ce este normal la kernelurile care livrează implementarea în arbore. Dacă modinfo reușește și lsmod nu arată nimic, modulul există dar nu este încărcat, ceea ce este o problemă de încărcare și nu de compilare. Fiecare rezultat vă trimite altundeva, de aceea citirea contează mai mult decât comenzile.

Compilați pentru versiunea care rulează

Un modul extern se compilează împotriva unui arbore de kernel pregătit, iar ghidul kernelului pentru module externe descrie folosirea directorului de compilare care aparține kernelului care rulează și nu a celui cu cel mai mare număr de versiune. Acest director de compilare este o legătură simbolică întreținută de pachetul de kernel, deci indică arborele versiunii care este pornită acum. Indirecția este exact ideea: elimină o alegere pe care altfel ați face-o greșit. Numirea lui explicită face ținta lipsită de ambiguitate.

Un detaliu contează atunci când arborele este doar pregătit și nu complet compilat. Ținta de pregătire nu produce fișierul de versiune a simbolurilor de care au nevoie unele compilări externe, așa că un arbore plin de antete nu este automat un mediu de compilare complet. Dacă o compilare eșuează din cauza simbolurilor lipsă, acel fișier este primul loc unde trebuie privit.

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

Când antetele împachetate rămân în urmă

Pe distribuții și computere cu o singură placă care își împachetează propriile kerneluri, antetele pot rămâne zile sau săptămâni în urma versiunii. Pachetul de antete poate fi corect ca nume și mai vechi ca conținut, ceea ce produce o compilare care compilează și apoi eșuează la încărcare, nu în timpul compilării. Amestecarea surselor înrăutățește situația: un kernel de distribuție cu antete dintr-un depozit terț, sau un kernel de producător cu antete generice, poate compila curat și totuși să fie respins de kernelul care rulează pentru că configurația diferă. Numerele de versiune singure nu rezolvă asta.

Dacă mașina urmează un canal experimental de kernel, decideți conștient dacă rămâneți acolo cu artefacte de compilare potrivite sau reveniți la setul de pachete acceptat. Repetarea actualizării și speranța că piesele se aliniază nu este un plan, pentru că aceeași nepotrivire se repetă de fiecare dată.

Verificați interfața după recompilare

După o instalare reușită, crearea interfeței este testul care contează, urmat de citirea a ceea ce a încărcat kernelul efectiv și a ceea ce spune jurnalul dacă a refuzat. Un modul care se încarcă și o interfață care nu poate fi creată sunt eșecuri diferite cu cauze diferite. Cele trei comenzi de mai jos le separă.

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

Dacă modulul refuză să se încarce, jurnalul kernelului indică motivul, iar o nepotrivire de versiune este doar una dintre posibilități. Citiți acea linie înainte de a recompila, pentru că o a doua compilare identică consumă aceleași zece minute și dă același refuz. Apoi eliminați interfața temporară, astfel încât următorul test să pornească dintr-o stare curată.