WireGuard-modulen lastes ikke etter en kjerneoppdatering? Sjekk dette

Tunnelen din virket i går, maskinen startet på nytt etter en oppdatering, og nå kommer grensesnittet ikke opp. På et system der WireGuard bygges som en ekstern modul, er den vanlige årsaken at modulen på disken hører til en annen kjerneversjon enn den som kjører nå. Headere med et lignende navn på samme maskin beviser ingenting om den samsvaren. Bare versjonsstrengen avgjør det.

Kjørende eller installert kjerne

En oppdatering installerer en ny kjerne-pakke og lar den gamle ligge på disken til maskinen starter på nytt. Etter omstarten endres den kjørende versjonen, og enhver modul som er bygget mot den forrige, blir ubrukelig selv om filene fortsatt er der. Det gapet forklarer den kjente rapporten om en maskin som var i orden før en omstart og ødelagt etterpå, uten noen konfigurasjonsendring imellom. Det forklarer også hvorfor reinstallasjon av headere noen ganger ser ut til å løse problemet og noen ganger ikke.

Header-pakken du installerer, kan samsvare med den nyeste kjerne-pakken snarere enn med kjernen som faktisk ble startet, og ingenting i pakkenavnet skiller disse tilfellene; bare versjonsstrengen gjør det. Sjekk hva som kjører før du sjekker hva som er installert.

Tre sjekker før du bygger på nytt

Den første sjekken er hvilken kjerne som kjører. Den andre er om det finnes en modul for den versjonen, og om den kan finnes. Den tredje er om kjernen allerede har lastet den. Det fjerde spørsmålet, om grensesnittet kan opprettes, tester privilegier og ikke modulen, så det hører hjemme etter ombyggingen og ikke i denne listen.

Kommandoene nedenfor svarer på de tre første uten å endre noe. Les hvert resultat før du går videre, fordi hvert svar utelukker en annen reparasjon.

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

Hvis den andre linjen rapporterer at stien ikke finnes, mangler byggemiljøet for den kjørende kjernen, og ingenting du kompilerer vil passe til den. Hvis modinfo feiler mens stien finnes, er modulen kanskje ikke installert i det hele tatt, noe som er normalt på kjerner som leverer implementasjonen i treet. Hvis modinfo lykkes og lsmod ikke viser noe, finnes modulen, men er ikke lastet, noe som er et lasteproblem og ikke et byggeproblem. Hvert resultat sender deg et annet sted, derfor er lesingen viktigere enn kommandoene.

Bygg mot den kjørende versjonen

En ekstern modul kompileres mot et forberedt kjernetre, og kjernens veiledning for eksterne moduler beskriver bruk av byggemappen som hører til den kjørende kjernen, snarere enn den mappen som har det høyeste versjonsnummeret. Den byggemappen er en symbolsk lenke som vedlikeholdes av kjerne-pakken, så den peker til treet for versjonen som er startet nå. Indirektionen er nettopp poenget: den fjerner et valg du ellers ville tatt feil. Når du navngir den eksplisitt, blir målet entydig.

En detalj betyr noe når treet bare er forberedt og ikke fullt ut bygget. Forberedelsesmålet produserer ikke symbolversjonsfilen som noen eksterne bygg trenger, så et tre fullt av headere er ikke automatisk et komplett byggemiljø. Hvis et bygg feiler på manglende symboler, er den filen det første stedet å se.

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 headere ligger bak

På distribusjoner og enkeltkortdatamaskiner som pakker sine egne kjerner, kan headere ligge dager eller uker bak versjonen. Header-pakken kan være riktig i navnet og eldre i innholdet, noe som gir et bygg som kompileres og deretter feiler ved lasting i stedet for under kompileringen. Å blande kilder gjør det verre: en distribusjonskjerne med headere fra et tredjepartsarkiv, eller en leverandørkjerne med generiske headere, kan kompilere rent og likevel bli avvist av den kjørende kjernen fordi konfigurasjonen er forskjellig. Versjonsnumre alene avgjør ikke det.

Hvis maskinen følger en eksperimentell kjernekanal, bør du bevisst bestemme om du vil bli der med samsvarende byggeartefakter eller gå tilbake til det støttede pakkesettet. Å gjenta oppdateringen og håpe at bitene passer sammen er ikke en plan, fordi den samme uoverensstemmelsen gjentar seg hver gang.

Bekreft grensesnittet etter ombyggingen

Etter en vellykket installasjon er opprettelsen av grensesnittet den testen som betyr noe, etterfulgt av å lese hva kjernen faktisk lastet og hva loggen sier hvis den nektet. En modul som lastes, og et grensesnitt som ikke kan opprettes, er forskjellige feil med forskjellige årsaker. De tre kommandoene nedenfor skiller dem.

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

Hvis modulen nekter å laste, angir kjerneloggen årsaken, og en versjonsuoverensstemmelse er bare én av mulighetene. Les den linjen før du bygger på nytt, fordi et andre identisk bygg bruker de samme ti minuttene og gir samme avvisning. Fjern deretter det midlertidige grensesnittet slik at neste test starter fra en ren tilstand.