WireGuard-module laai nie ná 'n kernopdatering nie? Kyk hier

Jou tonnel het gister gewerk, die masjien het ná 'n opdatering herbegin, en nou kom die koppelvlak nie op nie. Op 'n stelsel waar WireGuard as 'n eksterne module gebou word, is die gewone oorsaak dat die module op skyf aan 'n ander kernvrystelling behoort as die een wat nou loop. Kopstukke met 'n soortgelyke naam op dieselfde masjien bewys niks oor daardie passing nie. Die vrystellingsstring is die enigste ding wat dit bepaal.

Lopende kern of geïnstalleerde kern

'n Opdatering installeer 'n nuwe kernpakket en laat die ou een op skyf totdat die masjien herbegin. Ná die herbegin verander die lopende vrystelling, en enige module wat teen die vorige een gebou is, word onbruikbaar selfs al is die lêers nog daar. Daardie gaping verduidelik die bekende verslag van 'n masjien wat voor 'n herbegin reg was en daarna stukkend, sonder enige konfigurasiewysiging tussenin. Dit verduidelik ook waarom die herinstalleer van kopstukke soms die probleem lyk te regstel en soms nie.

Die kopstukpakket wat jy installeer, kan ooreenstem met die nuutste kernpakket eerder as met die kern wat werklik geboot het, en niks in die pakketnaam onderskei daardie gevalle nie; net die vrystellingsstring doen dit. Kyk wat loop voordat jy kyk wat geïnstalleer is.

Drie kontroles voordat jy herbou

Die eerste kontrole is watter kern loop. Die tweede is of 'n module vir daardie vrystelling bestaan en gevind kan word. Die derde is of die kern dit reeds gelaai het. 'n Vierde vraag, of die koppelvlak geskep kan word, toets voorregte eerder as die module, so dit hoort ná die herbou eerder as in hierdie lys.

Die opdragte hieronder beantwoord die eerste drie sonder om iets te verander. Lees elke resultaat voordat jy verder gaan, want elke antwoord sluit 'n ander herstelling uit.

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

As die tweede reël rapporteer dat die pad nie bestaan nie, ontbreek die bou-omgewing vir die lopende kern en niks wat jy kompileer sal daarby pas nie. As modinfo misluk terwyl die pad bestaan, is die module dalk glad nie geïnstalleer nie, wat normaal is op kerne wat die implementering in die boom lewer. As modinfo slaag en lsmod wys niks, bestaan die module maar is dit nie gelaai nie, wat 'n laaitydprobleem eerder as 'n bouprobleem is. Elke uitkoms stuur jou êrens anders heen, en daarom is die lees belangriker as die opdragte.

Bou teen die lopende vrystelling

'n Eksterne module kompileer teen 'n voorbereide kernboom, en die gids vir eksterne modules van die kern beskryf die gebruik van die bougids wat aan die lopende kern behoort eerder as watter gids ook al die hoogste weergawenommer het. Daardie bougids is 'n simskakel wat deur die kernpakket onderhou word, so dit wys na die boom vir die vrystelling wat tans geboot is. Die indireksie is juis die punt: dit verwyder 'n keuse wat jy andersins verkeerd sou kry. Om dit eksplisiet te noem, maak die teiken ondubbelsinnig.

Een detail maak saak wanneer die boom net voorberei is eerder as volledig gebou. Die prepare-teiken lewer nie die simboolweergawe-lêer wat sommige eksterne boue nodig het nie, so 'n boom vol kopstukke is nie outomaties 'n volledige bou-omgewing nie. As 'n bou op ontbrekende simbole misluk, is daardie lêer die eerste plek om te kyk.

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 kopstukke agterbly

Op verspreidings en enkelbordrekenaars wat hul eie kerne verpak, kan kopstukke die vrystelling met dae of weke agtervolg. Die kopstukpakket kan korrek in naam en ouer in inhoud wees, wat 'n bou lewer wat kompileer en dan by laaityd misluk eerder as tydens die kompilering. Om bronne te meng maak dit erger: 'n verspreidingskern met kopstukke van 'n derdeparty-bewaarplek, of 'n vervaardigerkern met generiese kopstukke, kan skoon kompileer en steeds deur die lopende kern verwerp word omdat die konfigurasie verskil. Weergawenommers alleen beslis dit nie.

As die masjien 'n eksperimentele kernkanaal volg, besluit doelbewus of jy daar wil bly met passende bouartefakte of wil terugkeer na die ondersteunde pakketstel. Om die opdatering te herhaal en te hoop die stukke pas, is nie 'n plan nie, want dieselfde wanpassing herhaal elke keer.

Verifieer die koppelvlak ná die herbou

Ná 'n suksesvolle installasie is die skep van die koppelvlak die toets wat saak maak, gevolg deur die lees van wat die kern werklik gelaai het en wat die log sê as dit geweier het. 'n Module wat laai en 'n koppelvlak wat nie geskep kan word nie, is verskillende mislukkings met verskillende oorsake. Die drie opdragte hieronder skei hulle.

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

As die module weier om te laai, noem die kernlog die rede, en 'n weergawe-wanpassing is net een van die moontlikhede. Lees daardie reël voordat jy weer herbou, want 'n tweede identiese bou spandeer dieselfde tien minute en lewer dieselfde weiering. Verwyder die weggooi-koppelvlak daarna sodat die volgende toets van 'n skoon toestand begin.