WireGuard-modul indlæses ikke efter en kerneopdatering? Tjek dette

Din tunnel virkede i går, maskinen genstartede efter en opdatering, og nu kommer grænsefladen ikke op. På et system, hvor WireGuard bygges som et eksternt modul, er den sædvanlige årsag, at modulet på disken hører til en anden kerneversion end den, der kører nu. Headers med et lignende navn på samme maskine beviser intet om det match. Kun versionsstrengen afgør det.

Kørende eller installeret kerne

En opdatering installerer en ny kernelpakke og lader den gamle ligge på disken, indtil maskinen genstarter. Efter genstarten ændres den kørende version, og ethvert modul, der er bygget mod den forrige, bliver ubrugeligt, selv om dets filer stadig er der. Det gab forklarer den velkendte rapport om en maskine, der var i orden før en genstart og i stykker efter, uden nogen konfigurationsændring imellem. Det forklarer også, hvorfor geninstallation af headers nogle gange ser ud til at løse problemet og nogle gange ikke.

Den header-pakke, du installerer, svarer måske til den nyeste kernelpakke snarere end til den kerne, der faktisk blev startet, og intet i pakkenavnet skelner de tilfælde; kun versionsstrengen gør det. Tjek, hvad der kører, før du tjekker, hvad der er installeret.

Tre tjek før du genopbygger

Det første tjek er, hvilken kerne der kører. Det andet er, om der findes et modul til den version, og om det kan findes. Det tredje er, om kernen allerede har indlæst det. Det fjerde spørgsmål, om grænsefladen kan oprettes, tester privilegier snarere end modulet, så det hører efter genopbygningen og ikke på denne liste.

Kommandoerne nedenfor besvarer de første tre uden at ændre noget. Læs hvert resultat, før du går videre, fordi hvert svar udelukker en anden reparation.

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

Hvis den anden linje rapporterer, at stien ikke findes, mangler byggemiljøet til den kørende kerne, og intet af det, du kompilerer, vil passe til den. Hvis modinfo fejler, mens stien findes, er modulet måske slet ikke installeret, hvilket er normalt på kerner, der leverer implementeringen i træet. Hvis modinfo lykkes, og lsmod intet viser, findes modulet, men er ikke indlæst, hvilket er et indlæsningsproblem snarere end et byggeproblem. Hvert resultat sender dig et andet sted hen, og derfor er læsningen vigtigere end kommandoerne.

Byg mod den kørende version

Et eksternt modul kompileres mod et forberedt kernetræ, og kernens vejledning til eksterne moduler beskriver brug af den byggemappe, der hører til den kørende kerne, snarere end den mappe, der har det højeste versionsnummer. Den byggemappe er et symbolsk link, som kernelpakken vedligeholder, så det peger på træet for den version, der aktuelt er startet. Indirektionen er netop pointen: den fjerner et valg, du ellers ville træffe forkert. Når du navngiver den eksplicit, bliver målet entydigt.

En detalje betyder noget, når træet kun er forberedt og ikke fuldt bygget. Forberedelsesmålet fremstiller ikke den symbolversionsfil, som nogle eksterne builds har brug for, så et træ fuld af headers er ikke automatisk et komplet byggemiljø. Hvis en build fejler på manglende symboler, er den fil det første sted at kigge.

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 pakkede headers sakker bagud

På distributioner og single-board-computere, der pakker deres egne kerner, kan headers sakke dage eller uger bag versionen. Header-pakken kan være korrekt i navnet og ældre i indholdet, hvilket giver en build, der kompilerer og derefter fejler ved indlæsning snarere end under kompileringen. At blande kilder gør det værre: en distributionskerne med headers fra et tredjepartsarkiv eller en leverandørkerne med generiske headers kan kompilere rent og alligevel blive afvist af den kørende kerne, fordi konfigurationen er forskellig. Versionsnumre alene afgør ikke det.

Hvis maskinen følger en eksperimentel kernekanal, så beslut bevidst, om du vil blive der med matchende byggeartefakter eller vende tilbage til det understøttede pakkesæt. At gentage opdateringen og håbe på, at delene passer sammen, er ikke en plan, fordi den samme uoverensstemmelse gentages hver gang.

Bekræft grænsefladen efter genopbygningen

Efter en vellykket installation er oprettelsen af grænsefladen den test, der betyder noget, efterfulgt af at læse, hvad kernen faktisk indlæste, og hvad loggen siger, hvis den afviste. Et modul, der indlæses, og en grænseflade, der ikke kan oprettes, er forskellige fejl med forskellige årsager. De tre kommandoer nedenfor skiller dem.

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

Hvis modulet nægter at indlæse, angiver kernens log årsagen, og en versionuoverensstemmelse er kun en af mulighederne. Læs den linje, før du bygger igen, fordi en anden identisk build bruger de samme ti minutter og giver samme afvisning. Fjern derefter den midlertidige grænseflade, så den næste test starter fra en ren tilstand.