WireGuard-module laadt net nei in kernelfernijing? Besjoch dit

Jo tunnel wurke juster, de masine starte opnij nei in fernijing, en no komt de ynterface net omheech. Op in systeem dêr't WireGuard as eksterne module boud wurdt, is de gewoane oarsaak dat de module op skiif by in oare kernelferzje heart as dy't no rint. Headers mei in ferlykbere namme op deselde masine bewiisje neat oer dy oerienkomst. Allinnich de ferzjestring beslút dat.

Rinnende of ynstallearre kernel

In fernijing ynstallearret in nij kernelpakket en lit it âlde op skiif oant de masine opnij start. Nei it opnij starten feroaret de rinnende ferzje, en elke module dy't tsjin de foarige boud is wurdt ûnbrûkber, ek al steane syn bestannen der noch. Dat gat ferklearret it bekende ferhaal fan in masine dy't foar in opnij starten goed wie en dêrnei stikken, sûnder konfiguraasjeferoaring dertusken. It ferklearret ek wêrom't it opnij ynstallearjen fan headers it probleem soms liket te ferhelpen en soms net.

It headerpakket dat jo ynstallearje kin by it nijste kernelpakket hearre ynstee fan by de kernel dy't echt opstart is, en neat yn 'e pakketnamme ûnderskiedt dy gefallen; allinnich de ferzjestring docht dat. Kontrolearje wat rint foardat jo kontrolearje wat ynstallearre is.

Trije kontrôles foardat jo opnij bouwe

De earste kontrôle is hokker kernel rint. De twadde is oft der in module foar dy ferzje bestiet en te finen is. De tredde is oft de kernel him al laden hat. De fjirde fraach, oft de ynterface makke wurde kin, test foarrjochten ynstee fan 'e module, sadat er nei it opnij bouwen heart en net yn dizze list.

De kommando's hjirûnder beantwurdzje de earste trije sûnder eat te feroarjen. Lês elk resultaat foardat jo fierder geane, want elk antwurd slút in oare reparaasje út.

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

As de twadde rigel meldt dat it paad net bestiet, ûntbrekt de bou-omjouwing foar de rinnende kernel en neat dat jo kompilearje sil dêrby passe. As modinfo mislearret wylst it paad bestiet, is de module miskien hielendal net ynstallearre, wat normaal is op kernels dy't de ymplemintaasje yn 'e beam leverje. As modinfo slagget en lsmod neat toant, bestiet de module wol mar is er net laden, wat in laadprobleem is en gjin bouprobleem. Elk resultaat stjoert jo earne oars hinne, dêrom is it lêzen wichtiger as de kommando's.

Bou tsjin de rinnende ferzje

In eksterne module wurdt kompilearre tsjin in taret kernelbeam, en de gids fan 'e kernel foar eksterne modules beskriuwt it brûken fan 'e boumap dy't by de rinnende kernel heart ynstee fan hokker map dan ek mei it heechste ferzjenûmer. Dy boumap is in symboalyske keppeling dy't it kernelpakket ûnderhâldt, sadat er wiist nei de beam foar de ferzje dy't no opstart is. De yndireksje is krekt it punt: it nimt in kar fuort dy't jo oars ferkeard dwaan soene. It eksplisyt beneamen makket it doel ûndûbelsinnich.

Ien detail is wichtich as de beam allinnich taret is en net folslein boud. It tariedingsdoel produsearret net it symboalferzje-bestân dat guon eksterne bouwen nedich hawwe, sadat in beam fol headers net automatysk in folsleine bou-omjouwing is. As in bou mislearret op ûntbrekkende symboalen, is dat bestân it earste plak om te sjen.

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

As pakkette headers efterbliuwe

Op distribúsjes en single-board-kompyuters dy't har eigen kernels pakketsje, kinne headers dagen of wiken efter de ferzje rinne. It headerpakket kin goed wêze yn namme en âlder yn ynhâld, wat in bou jout dy't kompilearret en dan mislearret by it laden ynstee fan by it kompilearjen. Boarnen mingen makket it slimmer: in distribúsjekernel mei headers út in depot fan tredden, of in leveransierskernel mei generike headers, kin skjin kompilearje en dochs troch de rinnende kernel wegere wurde om't de konfiguraasje ferskilt. Ferzjenûmers allinnich besljochtsje dat net.

As de masine in eksperiminteel kernelkanaal folget, beslút dan bewust oft jo dêr bliuwe wolle mei passende bou-artefakten of weromgean wolle nei de stipe pakketset. De fernijing werhelje en hoopje dat de stikken passe is gjin plan, want deselde misferstân werhellet him elke kear.

Kontrolearje de ynterface nei it opnij bouwen

Nei in slagge ynstallaasje is it meitsjen fan 'e ynterface de test dy't telt, folge troch it lêzen wat de kernel echt laden hat en wat it logboek seit as er wegere. In module dy't laadt en in ynterface dy't net makke wurde kin, binne ferskillende flaters mei ferskillende oarsaken. De trije kommando's hjirûnder skiede se.

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

As de module wegeret te laden, neamt it kernellogboek de reden, en in ferzjemisferstân is mar ien fan 'e mooglikheden. Lês dy rigel foardat jo opnij bouwe, want in twadde identike bou kostet deselde tsien minuten en jout deselde wegering. Ferwiderje dêrnei de tydlike ynterface, sadat de folgjende test fan in skjinne steat begjint.