WireGuard-modulo ne ŝargiĝas post kernora ĝisdatigo? Kontrolu ĉi tion

Via tunelo funkciis hieraŭ, la maŝino restartis post ĝisdatigo, kaj nun la interfaco ne leviĝas. En sistemo, kie WireGuard estas konstruata kiel ekstera modulo, la kutima kaŭzo estas, ke la modulo sur la disko apartenas al alia kerno-eldono ol tiu, kiu nun funkcias. Kaplinioj kun simila nomo sur la sama maŝino pruvas nenion pri tiu kongruo. Nur la eldona ĉeno decidas tion.

Kuranta aŭ instalita kerno

Ĝisdatigo instalas novan kerno-pakon kaj lasas la malnovan sur la disko ĝis la maŝino restartos. Post la restarto la kuranta eldono ŝanĝiĝas, kaj ĉiu modulo konstruita kontraŭ la antaŭa fariĝas neuzebla, kvankam ĝiaj dosieroj ankoraŭ estas tie. Tiu breĉo klarigas la konatan raporton pri maŝino, kiu estis en ordo antaŭ restarto kaj difektita post ĝi, sen iu ajn agorda ŝanĝo intere. Ĝi ankaŭ klarigas, kial reinstali kapliniojn foje ŝajnas solvi la problemon kaj foje ne.

La kaplinio-pako, kiun vi instalas, eble respondas al la plej nova kerno-pako anstataŭ al la kerno, kiu efektive ekfunkciis, kaj nenio en la paka nomo distingas tiujn kazojn; nur la eldona ĉeno faras tion. Kontrolu, kio funkcias, antaŭ ol kontroli, kio estas instalita.

Tri kontroloj antaŭ la rekonstruado

La unua kontrolo estas, kiu kerno funkcias. La dua estas, ĉu ekzistas modulo por tiu eldono kaj ĉu ĝi troveblas. La tria estas, ĉu la kerno jam ŝargis ĝin. La kvara demando, ĉu la interfaco povas esti kreata, testas privilegiojn anstataŭ la modulon, do ĝi apartenas post la rekonstruado kaj ne en ĉi tiu listo.

La subaj komandoj respondas la unuajn tri sen ŝanĝi ion. Legu ĉiun rezulton antaŭ ol daŭrigi, ĉar ĉiu respondo ekskludas alian riparon.

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

Se la dua linio raportas, ke la vojo ne ekzistas, la konstrua medio por la kuranta kerno mankas kaj nenio, kion vi kompilos, kongruos kun ĝi. Se modinfo malsukcesas dum la vojo ekzistas, la modulo eble tute ne estas instalita, kio estas normala ĉe kernoj, kiuj liveras la efektivigon ene de la arbo. Se modinfo sukcesas kaj lsmod montras nenion, la modulo ekzistas sed ne estas ŝargita, kio estas ŝarga problemo anstataŭ konstrua. Ĉiu rezulto sendas vin aliloken, tial la legado pli gravas ol la komandoj.

Konstruu kontraŭ la kuranta eldono

Ekstera modulo kompiliĝas kontraŭ preparita kerno-arbo, kaj la gvidilo de la kerno pri eksteraj moduloj priskribas la uzon de la konstrua dosierujo, kiu apartenas al la kuranta kerno, anstataŭ tiu, kiu portas la plej altan versian numeron. Tiu konstrua dosierujo estas simbola ligilo prizorgata de la kerno-pako, do ĝi montras al la arbo por la eldono, kiu nun ekfunkciis. La nerektaĵo estas ĝuste la senco: ĝi forigas elekton, kiun vi alie farus malĝuste. Nomante ĝin eksplicite, la celo fariĝas senduba.

Unu detalo gravas, kiam la arbo nur prepariĝis kaj ne plene konstruiĝis. La prepara celo ne produktas la simbolan versian dosieron, kiun kelkaj eksteraj konstruoj bezonas, do arbo plena de kaplinioj ne estas aŭtomate kompleta konstrua medio. Se konstruo malsukcesas pro mankantaj simboloj, tiu dosiero estas la unua loko por rigardi.

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

Kiam pakaĵitaj kaplinioj malfruas

Ĉe distribuaĵoj kaj unuplataj komputiloj, kiuj pakaĵigas siajn proprajn kernojn, kaplinioj povas malfrui je tagoj aŭ semajnoj post la eldono. La kaplinio-pako povas esti ĝusta laŭ nomo kaj pli malnova laŭ enhavo, kio produktas konstruon, kiu kompiliĝas kaj poste malsukcesas ĉe ŝargado anstataŭ dum la kompilado. Miksi fontojn plimalbonigas tion: distribua kerno kun kaplinioj el deponejo de tria partio, aŭ vendista kerno kun ĝeneralaj kaplinioj, povas kompiliĝi pure kaj tamen esti rifuzata de la kuranta kerno, ĉar la agordo diferencas. Versiaj numeroj solaj ne solvas tion.

Se la maŝino sekvas eksperimentan kerno-kanalon, decidu konscie, ĉu resti tie kun kongruaj konstruaĵoj aŭ reveni al la subtenata pakaĵaro. Ripeti la ĝisdatigon kaj esperi, ke la pecoj kongruos, ne estas plano, ĉar la sama miskongruo ripetiĝas ĉiufoje.

Kontrolu la interfacon post la rekonstruado

Post sukcesa instalado, krei la interfacon estas la testo, kiu gravas, sekvata de legado de tio, kion la kerno efektive ŝargis, kaj de tio, kion diras la protokolo, se ĝi rifuzis. Modulo, kiu ŝargiĝas, kaj interfaco, kiun oni ne povas krei, estas malsamaj paneoj kun malsamaj kaŭzoj. La tri subaj komandoj apartigas ilin.

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

Se la modulo rifuzas ŝargiĝi, la kerno-protokolo nomas la kaŭzon, kaj versia miskongruo estas nur unu el la ebloj. Legu tiun linion antaŭ ol rekonstrui, ĉar dua identa konstruo elspezas la samajn dek minutojn kaj donas la saman rifuzon. Poste forigu la unuuzan interfacon, por ke la sekva testo komenciĝu de pura stato.