WireGuard-modulen blir ikkje lasta etter ei kjerneoppdatering? Sjekk dette

Tunnelen din verka i går, maskinen starta på nytt etter ei oppdatering, og no kjem grensesnittet ikkje opp. På eit system der WireGuard blir bygd som ein ekstern modul, er den vanlege årsaka at modulen på disken høyrer til ein annan kjerneversjon enn den som køyrer no. Headarar med eit liknande namn på same maskin bevisar ingenting om den samsvaret. Berre versjonsstrengen avgjer det.

Køyrande eller installert kjerne

Ei oppdatering installerer ein ny kjerne-pakke og lèt den gamle liggja på disken til maskinen startar på nytt. Etter omstarten blir den køyrande versjonen endra, og kvar modul som er bygd mot den førre, blir ubrukeleg sjølv om filene framleis er der. Det gapet forklarer den kjende rapporten om ein maskin som var i orden før ein omstart og øydelagd etterpå, utan noka konfigurasjonsendring imellom. Det forklarer òg kvifor reinstallasjon av headarar nokre gonger ser ut til å løysa problemet og nokre gonger ikkje.

Header-pakken du installerer, kan samsvara med den nyaste kjerne-pakken snarare enn med kjernen som faktisk vart starta, og ingenting i pakkenamnet skil desse tilfella; berre versjonsstrengen gjer det. Sjekk kva som køyrer før du sjekkar kva som er installert.

Tre sjekkar før du byggjer på nytt

Den første sjekken er kva kjerne som køyrer. Den andre er om det finst ein modul for den versjonen, og om han kan finnast. Den tredje er om kjernen allereie har lasta han. Det fjerde spørsmålet, om grensesnittet kan opprettast, testar privilegium og ikkje modulen, så det høyrer heime etter ombygginga og ikkje i denne lista.

Kommandøane nedanfor svarar på dei tre første utan å endra noko. Les kvar resultat før du går vidare, fordi kvart svar utelèt ein annan reparasjon.

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

Viss den andre lina rapporterer at stien ikkje finst, manglar byggjemiljøet for den køyrande kjernen, og ingenting du kompilerer vil passa til han. Viss modinfo feilar medan stien finst, er modulen kanskje ikkje installert i det heile, noko som er normalt på kjernar som leverer implementasjonen i treet. Viss modinfo lukkast og lsmod ikkje viser noko, finst modulen, men er ikkje lasta, noko som er eit lasteproblem og ikkje eit byggjeproblem. Kvart resultat sender deg ein annan stad, difor er lesinga viktigare enn kommandøane.

Bygg mot den køyrande versjonen

Ein ekstern modul blir kompilert mot eit førebudd kjernetre, og rettleiinga til kjernen for eksterne modular skildrar bruk av byggjemappa som høyrer til den køyrande kjernen, snarare enn mappa med det høgaste versjonsnummeret. Den byggjemappa er ei symbolsk lenkje som blir halden ved like av kjerne-pakken, så ho peikar til treet for versjonen som er starta no. Indireksjonen er nettopp poenget: han fjernar eit val du elles ville teke feil. Når du namngjev henne eksplisitt, blir målet eintydig.

Ein detalj betyr noko når treet berre er førebudd og ikkje fullt ut bygt. Førebuingmålet produserer ikkje symbolversjonsfila som nokre eksterne bygg treng, så eit tre fullt av headarar er ikkje automatisk eit komplett byggjemiljø. Viss eit bygg feilar på manglande symbol, er den fila den første staden å sjå.

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

Når pakka headarar ligg bak

På distribusjonar og enkeltkortdatamaskinar som pakkar sine eigne kjernar, kan headarar liggja dagar eller veker bak versjonen. Header-pakken kan vera riktig i namnet og eldre i innhaldet, noko som gir eit bygg som kompilerer og deretter feilar ved lasting i staden for under kompileringa. Å blanda kjelder gjer det verre: ein distribusjonskjerne med headarar frå eit tredjepartsarkiv, eller ein leverandørkjerne med generiske headarar, kan kompilera reint og likevel bli avvist av den køyrande kjernen fordi konfigurasjonen er ulik. Versjonsnummer åleine avgjer ikkje det.

Viss maskinen følgjer ein eksperimentell kjernekanal, bør du medvite avgjera om du vil bli der med samsvarande byggjeartefaktar eller gå tilbake til det støtta pakkesettet. Å gjenta oppdateringa og håpa at bitane passar saman er ikkje ein plan, fordi den same uoverensstemminga gjentek seg kvar gong.

Stadfest grensesnittet etter ombygginga

Etter ein vellukka installasjon er opprettinga av grensesnittet den testen som betyr noko, etterfølgt av å lesa kva kjernen faktisk lasta og kva loggen seier viss han nekta. Ein modul som blir lasta, og eit grensesnitt som ikkje kan opprettast, er ulike feil med ulike årsaker. Dei tre kommandøane nedanfor skil dei.

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

Viss modulen nektar å lasta, oppgir kjerneloggen årsaka, og ein versjonsuoverensstemming er berre éin av moglegheitene. Les den lina før du byggjer på nytt, fordi eit andre identisk bygg brukar dei same ti minutta og gir same avvising. Fjern deretter det mellombelse grensesnittet slik at neste test startar frå ein rein tilstand.