Moduli WireGuard nuk ngarkohet pas një përditësimi të kernelit? Kontrolloni këtë

Tuneli juaj funksiononte dje, makina u rinis pas një përditësimi, dhe tani ndërfaqja nuk ngrihet. Në një sistem ku WireGuard ndërtohet si modul i jashtëm, shkaku i zakonshëm është që moduli në disk i përket një versioni të kernelit të ndryshëm nga ai që po ekzekutohet tani. Kokat me emër të ngjashëm në të njëjtën makinë nuk provojnë asgjë për atë përputhje. Vetëm vargu i versionit e vendos këtë.

Kernel që po ekzekutohet ose i instaluar

Një përditësim instalon një paketë të re kerneli dhe e lë të vjetrën në disk derisa makina të riniset. Pas rinisjes versioni që po ekzekutohet ndryshon, dhe çdo modul i ndërtuar për atë të mëparshëm bëhet i papërdorshëm edhe pse skedarët e tij janë ende aty. Ai hendek shpjegon raportin e njohur për një makinë që ishte në rregull përpara një rinisjeje dhe e prishur pas saj, pa asnjë ndryshim konfigurimi në mes. Shpjegon gjithashtu pse riinstalimi i kokave ndonjëherë duket se e zgjidh problemin dhe ndonjëherë jo.

Paketa e kokave që instaloni mund të përputhet me paketën më të re të kernelit dhe jo me kernelin që u nis në të vërtetë, dhe asgjë në emrin e paketës nuk i dallon këto raste; vetëm vargu i versionit e bën këtë. Kontrolloni çfarë po ekzekutohet përpara se të kontrolloni çfarë është instaluar.

Tre kontrolle përpara rindërtimit

Kontrolli i parë është cili kernel po ekzekutohet. I dyti është nëse ekziston një modul për atë version dhe nëse mund të gjendet. I treti është nëse kerneli e ka ngarkuar tashmë. Pyetja e katërt, nëse ndërfaqja mund të krijohet, teston privilegjet dhe jo modulin, prandaj vendi i saj është pas rindërtimit dhe jo në këtë listë.

Komandat më poshtë u përgjigjen tre të parave pa ndryshuar asgjë. Lexoni çdo rezultat përpara se të vazhdoni, sepse çdo përgjigje përjashton një riparim tjetër.

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

Nëse rreshti i dytë raporton se shtegu nuk ekziston, mjedisi i ndërtimit për kernelin që po ekzekutohet mungon dhe asgjë që kompiloni nuk do të përputhet. Nëse modinfo dështon ndërsa shtegu ekziston, moduli mund të mos jetë instaluar fare, gjë që është normale për kernelët që e ofrojnë zbatimin brenda pemës. Nëse modinfo ka sukses dhe lsmod nuk tregon asgjë, moduli ekziston por nuk është ngarkuar, gjë që është problem i ngarkimit dhe jo i ndërtimit. Çdo rezultat ju çon diku tjetër, prandaj leximi ka më shumë rëndësi se komandat.

Ndërtoni për versionin që po ekzekutohet

Një modul i jashtëm kompilohet kundrejt një peme kerneli të përgatitur, dhe udhëzuesi i kernelit për modulet e jashtme përshkruan përdorimin e drejtorisë së ndërtimit që i përket kernelit që po ekzekutohet dhe jo asaj me numrin më të lartë të versionit. Ajo drejtori ndërtimi është një lidhje simbolike e mirëmbajtur nga paketa e kernelit, prandaj tregon pemën e versionit që është nisur tani. Tërthortësia është pikërisht çështja: heq një zgjedhje që përndryshe do ta bënit gabim. Emërtimi i saj shprehimisht e bën objektivin të paqartë.

Një detaj ka rëndësi kur pema është vetëm e përgatitur dhe jo plotësisht e ndërtuar. Objektivi i përgatitjes nuk prodhon skedarin e versionimit të simboleve që disa ndërtime të jashtme kërkojnë, prandaj një pemë plot me koka nuk është automatikisht mjedis i plotë ndërtimi. Nëse një ndërtim dështon për shkak të simboleve që mungojnë, ai skedar është vendi i parë për t'u parë.

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

Kur kokat e paketuara mbeten pas

Në shpërndarjet dhe kompjuterët me një pllakë që paketojnë kernelët e tyre, kokat mund të mbeten ditë ose javë pas versionit. Paketa e kokave mund të jetë e saktë në emër dhe më e vjetër në përmbajtje, gjë që prodhon një ndërtim që kompilohet dhe më pas dështon në ngarkim dhe jo gjatë kompilimit. Përzierja e burimeve e përkeqëson: një kernel shpërndarjeje me koka nga një depo e palës së tretë, ose një kernel prodhuesi me koka gjenerike, mund të kompilohet pastër dhe gjithsesi të refuzohet nga kerneli që po ekzekutohet sepse konfigurimi ndryshon. Vetëm numrat e versionit nuk e zgjidhin këtë.

Nëse makina ndjek një kanal eksperimental kerneli, vendosni me vetëdije nëse do të qëndroni atje me artefakte ndërtimi përputhëse ose do të ktheheni te grupi i paketave të mbështetura. Përsëritja e përditësimit dhe shpresa se pjesët do të përputhen nuk është plan, sepse i njëjti mospërputhje përsëritet çdo herë.

Verifikoni ndërfaqen pas rindërtimit

Pas një instalimi të suksesshëm, krijimi i ndërfaqes është testi që ka rëndësi, i ndjekur nga leximi i asaj që kerneli ngarkoi në të vërtetë dhe çfarë thotë regjistri nëse refuzoi. Një modul që ngarkohet dhe një ndërfaqe që nuk mund të krijohet janë dështime të ndryshme me shkaqe të ndryshme. Tre komandat më poshtë i ndajnë ato.

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

Nëse moduli refuzon të ngarkohet, regjistri i kernelit tregon shkakun, dhe mospërputhja e versionit është vetëm një nga mundësitë. Lexoni atë rresht përpara se të rindërtoni, sepse një ndërtim i dytë identik shpenzon të njëjtat dhjetë minuta dhe jep të njëjtin refuzim. Më pas hiqni ndërfaqen e përkohshme, që testi i radhës të fillojë nga një gjendje e pastër.