WireGuard-module laadt niet na een kernelupdate? Controleer dit

Uw tunnel werkte gisteren, de machine startte opnieuw na een update, en nu komt de interface niet omhoog. Op een systeem waar WireGuard als externe module wordt gebouwd, is de gebruikelijke oorzaak dat de module op schijf bij een andere kernelrelease hoort dan degene die nu draait. Headers met een vergelijkbare naam op dezelfde machine bewijzen niets over die overeenkomst. Alleen de releasestring bepaalt dat.

Draaiende of geïnstalleerde kernel

Een update installeert een nieuw kernelpakket en laat het oude op schijf staan tot de machine opnieuw start. Na de herstart verandert de actieve release, en elke module die tegen de vorige is gebouwd, wordt onbruikbaar ook al staan de bestanden er nog. Dat gat verklaart het bekende verhaal van een machine die voor een herstart in orde was en erna stuk, zonder enige configuratiewijziging daartussen. Het verklaart ook waarom het opnieuw installeren van headers het probleem soms wel lijkt op te lossen en soms niet.

Het headerpakket dat u installeert, kan bij het nieuwste kernelpakket horen in plaats van bij de kernel die daadwerkelijk is opgestart, en niets in de pakketnaam onderscheidt die gevallen; alleen de releasestring doet dat. Controleer wat er draait voordat u controleert wat er is geïnstalleerd.

Drie controles voor de herbouw

De eerste controle is welke kernel er draait. De tweede is of er een module voor die release bestaat en of die te vinden is. De derde is of de kernel hem al heeft geladen. De vierde vraag, of de interface kan worden gemaakt, test rechten in plaats van de module, dus hoort die na de herbouw en niet in deze lijst.

De opdrachten hieronder beantwoorden de eerste drie zonder iets te wijzigen. Lees elk resultaat voordat u verdergaat, want elk antwoord sluit een andere reparatie uit.

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

Als de tweede regel meldt dat het pad niet bestaat, ontbreekt de bouwomgeving voor de draaiende kernel en niets van wat u compileert zal daarbij passen. Als modinfo mislukt terwijl het pad bestaat, is de module misschien helemaal niet geïnstalleerd, wat normaal is op kernels die de implementatie in de boom meeleveren. Als modinfo slaagt en lsmod niets toont, bestaat de module wel maar is hij niet geladen, wat een laadprobleem is en geen bouwprobleem. Elk resultaat stuurt u ergens anders heen, daarom is het lezen belangrijker dan de opdrachten.

Bouw tegen de draaiende release

Een externe module wordt gecompileerd tegen een voorbereide kernelboom, en de handleiding van de kernel voor externe modules beschrijft het gebruik van de bouwmap die bij de draaiende kernel hoort in plaats van de map met het hoogste versienummer. Die bouwmap is een symbolische koppeling die door het kernelpakket wordt onderhouden, dus hij wijst naar de boom van de release die nu is opgestart. De indirectie is juist het punt: ze haalt een keuze weg die u anders verkeerd zou maken. Als u hem expliciet benoemt, wordt het doel ondubbelzinnig.

Eén detail telt wanneer de boom alleen is voorbereid en niet volledig is gebouwd. Het voorbereidingsdoel levert niet het symboolversiebestand op dat sommige externe builds nodig hebben, dus een boom vol headers is niet automatisch een volledige bouwomgeving. Als een build mislukt op ontbrekende symbolen, is dat bestand de eerste plek om te kijken.

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

Wanneer verpakte headers achterblijven

Op distributies en single-board computers die hun eigen kernels verpakken, kunnen headers dagen of weken achterlopen op de release. Het headerpakket kan in naam correct en in inhoud ouder zijn, wat een build oplevert die compileert en vervolgens bij het laden mislukt in plaats van tijdens het compileren. Bronnen mengen maakt het erger: een distributiekernel met headers uit een externe repository, of een leverancierskernel met generieke headers, kan schoon compileren en toch door de draaiende kernel worden geweigerd omdat de configuratie verschilt. Versienummers alleen lossen dat niet op.

Als de machine een experimenteel kernelkanaal volgt, beslis dan bewust of u daar blijft met bijpassende bouwartefacten of terugkeert naar de ondersteunde pakketset. De update herhalen en hopen dat de stukken op elkaar aansluiten is geen plan, omdat dezelfde mismatch elke keer terugkomt.

Controleer de interface na de herbouw

Na een geslaagde installatie is het maken van de interface de test die telt, gevolgd door het lezen wat de kernel werkelijk heeft geladen en wat het log zegt als hij weigerde. Een module die laadt en een interface die niet kan worden gemaakt, zijn verschillende storingen met verschillende oorzaken. De drie opdrachten hieronder scheiden ze.

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

Als de module weigert te laden, noemt het kernellog de reden, en een versiemismatch is slechts een van de mogelijkheden. Lees die regel voordat u opnieuw bouwt, want een tweede identieke build kost dezelfde tien minuten en geeft dezelfde weigering. Verwijder daarna de tijdelijke interface zodat de volgende test vanuit een schone toestand begint.