WireGuard-modulen laddas inte efter en kärnuppdatering? Kontrollera detta

Din tunnel fungerade i går, maskinen startade om efter en uppdatering, och nu kommer gränssnittet inte upp. På ett system där WireGuard byggs som en extern modul är den vanliga orsaken att modulen på disken hör till en annan kärnversion än den som körs nu. Rubriker med ett liknande namn på samma maskin bevisar ingenting om den matchningen. Bara versionssträngen avgör det.

Körande eller installerad kärna

En uppdatering installerar ett nytt kärnpaket och låter det gamla ligga kvar på disken tills maskinen startar om. Efter omstarten ändras den körande versionen, och varje modul som byggts mot den föregående blir oanvändbar även om filerna finns kvar. Det gapet förklarar den välbekanta rapporten om en maskin som var i ordning före en omstart och trasig efter, utan någon konfigurationsändring däremellan. Det förklarar också varför ominstallation av rubriker ibland ser ut att lösa problemet och ibland inte.

Rubrikpaketet du installerar kan motsvara det nyaste kärnpaketet i stället för kärnan som faktiskt startades, och ingenting i paketnamnet skiljer dessa fall; bara versionssträngen gör det. Kontrollera vad som körs innan du kontrollerar vad som är installerat.

Tre kontroller före ombyggnaden

Den första kontrollen är vilken kärna som körs. Den andra är om det finns en modul för den versionen och om den går att hitta. Den tredje är om kärnan redan har laddat den. Den fjärde frågan, om gränssnittet kan skapas, testar behörigheter och inte modulen, så den hör hemma efter ombyggnaden och inte i den här listan.

Kommandona nedan svarar på de tre första utan att ändra något. Läs varje resultat innan du går vidare, eftersom varje svar utesluter en annan reparation.

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

Om den andra raden rapporterar att sökvägen inte finns saknas byggmiljön för den körande kärnan, och ingenting du kompilerar kommer att passa. Om modinfo misslyckas medan sökvägen finns är modulen kanske inte installerad alls, vilket är normalt på kärnor som levererar implementeringen i trädet. Om modinfo lyckas och lsmod inte visar något finns modulen men är inte laddad, vilket är ett laddningsproblem och inte ett byggproblem. Varje resultat skickar dig någon annanstans, därför är läsningen viktigare än kommandona.

Bygg mot den körande versionen

En extern modul kompileras mot ett förberett kärnträd, och kärnans guide för externa moduler beskriver användningen av byggkatalogen som hör till den körande kärnan i stället för den som har det högsta versionsnumret. Den byggkatalogen är en symbolisk länk som underhålls av kärnpaketet, så den pekar på trädet för versionen som startades nu. Indirektionen är själva poängen: den tar bort ett val som du annars skulle göra fel. När du namnger den uttryckligen blir målet entydigt.

En detalj spelar roll när trädet bara är förberett och inte fullt ut byggt. Förberedelsemålet producerar inte symbolversionsfilen som vissa externa byggen behöver, så ett träd fullt av rubriker är inte automatiskt en komplett byggmiljö. Om ett bygge misslyckas på saknade symboler är den filen det första stället att titta på.

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 paketerade rubriker ligger efter

På distributioner och enkortsdatorer som paketerar sina egna kärnor kan rubriker ligga dagar eller veckor efter versionen. Rubrikpaketet kan vara korrekt i namnet och äldre i innehållet, vilket ger ett bygge som kompileras och sedan misslyckas vid laddning i stället för under kompileringen. Att blanda källor gör det värre: en distributionskärna med rubriker från ett tredjepartsförråd, eller en leverantörskärna med generiska rubriker, kan kompilera rent och ändå avvisas av den körande kärnan eftersom konfigurationen skiljer sig. Versionsnummer ensamma avgör inte det.

Om maskinen följer en experimentell kärnkanal bör du medvetet bestämma om du vill stanna där med matchande byggartefakter eller återgå till den stödda paketuppsättningen. Att upprepa uppdateringen och hoppas att delarna passar ihop är ingen plan, eftersom samma felmatchning återkommer varje gång.

Verifiera gränssnittet efter ombyggnaden

Efter en lyckad installation är skapandet av gränssnittet det test som spelar roll, följt av att läsa vad kärnan faktiskt laddade och vad loggen säger om den vägrade. En modul som laddas och ett gränssnitt som inte kan skapas är olika fel med olika orsaker. De tre kommandona nedan skiljer dem.

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

Om modulen vägrar laddas anger kärnloggen orsaken, och en versionsfelmatchning är bara en av möjligheterna. Läs den raden innan du bygger igen, eftersom ett andra identiskt bygge kostar samma tio minuter och ger samma avslag. Ta sedan bort det tillfälliga gränssnittet så att nästa test börjar från ett rent tillstånd.