Hindi naglo-load ang module ng WireGuard pagkatapos ng update ng kernel? Tingnan ito

Gumana ang tunnel mo kahapon, nag-reboot ang makina pagkatapos ng update, at ngayon hindi bumangon ang interface. Sa sistemang itinatayo ang WireGuard bilang panlabas na module, ang karaniwang dahilan ay kabilang ang module sa disk sa ibang release ng kernel kaysa sa tumatakbo ngayon. Ang mga header na may katulad na pangalan sa parehong makina ay walang pinatutunayan tungkol sa tugmang iyon. Ang string ng release lang ang nagpapasya niyan.

Kernel na tumatakbo o naka-install

Nag-i-install ang update ng bagong pakete ng kernel at iniiwan ang luma sa disk hanggang mag-reboot ang makina. Pagkatapos ng reboot nagbabago ang release na tumatakbo, at ang anumang module na itinayo laban sa nauna ay nagiging hindi magagamit kahit nandiyan pa ang mga file nito. Ipinaliliwanag ng agwat na iyon ang pamilyar na ulat tungkol sa makinang maayos bago ang reboot at sira pagkatapos, na walang anumang pagbabago sa configuration sa pagitan. Ipinapaliwanag din nito kung bakit minsan ay parang inaayos ng muling pag-install ng header ang problema at minsan ay hindi.

Ang pakete ng header na ini-install mo ay maaaring tumugma sa pinakabagong pakete ng kernel sa halip na sa kernel na talagang nag-boot, at walang anuman sa pangalan ng pakete ang naghihiwalay sa mga kasong iyon; ang string ng release lang ang gumagawa niyon. Tingnan kung ano ang tumatakbo bago tingnan kung ano ang naka-install.

Tatlong tsek bago muling itayo

Ang unang tsek ay kung aling kernel ang tumatakbo. Ang pangalawa ay kung may module para sa release na iyon at kung ito ay mahahanap. Ang pangatlo ay kung na-load na ito ng kernel. Ang ikaapat na tanong, kung magagawa ang interface, ay sumusubok ng mga pribilehiyo at hindi ang module, kaya pagkatapos ito ng muling pagtatayo at hindi sa listahang ito.

Sinasagot ng mga utos sa ibaba ang unang tatlo nang walang binabago. Basahin ang bawat resulta bago magpatuloy, dahil ang bawat sagot ay nag-aalis ng ibang pagkukumpuni.

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

Kung iniuulat ng ikalawang linya na wala ang path, kulang ang build environment para sa tumatakbong kernel at wala sa kokompile mo ang tutugma dito. Kung mabigo ang modinfo habang nandiyan ang path, maaaring hindi naka-install ang module, na normal sa mga kernel na naghahatid ng implementasyon sa loob ng tree. Kung magtagumpay ang modinfo at walang ipinakita ang lsmod, may module pero hindi ito naka-load, na problema sa pag-load at hindi sa pagtatayo. Ang bawat resulta ay nagdadala sa iyo sa ibang lugar, kaya mas mahalaga ang pagbasa kaysa sa mga utos.

Itayo laban sa tumatakbong release

Ang panlabas na module ay kino-compile laban sa inihandang tree ng kernel, at inilalarawan ng gabay ng kernel para sa panlabas na module ang paggamit ng build directory na kabilang sa tumatakbong kernel at hindi ng may pinakamataas na numero ng bersyon. Ang build directory na iyon ay simbolikong link na pinapanatili ng pakete ng kernel, kaya itinuturo nito ang tree ng release na kasalukuyang na-boot. Ang pagiging di-tuwiran ang mismong punto: inaalis nito ang pagpipiliang mali mo sana. Ang pagpangalan dito nang malinaw ay nagpapawalang-katiyakan sa target.

May isang detalyeng mahalaga kapag inihanda lang ang tree at hindi pa ganap na naitayo. Hindi ginagawa ng target ng paghahanda ang file ng bersyon ng simbolo na kailangan ng ilang panlabas na build, kaya ang tree na puno ng header ay hindi awtomatikong kumpletong build environment. Kung mabigo ang build dahil sa kulang na simbolo, ang file na iyon ang unang lugar na titingnan.

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

Kapag nahuhuli ang mga naka-paketeng header

Sa mga distribusyon at single-board computer na nagpapakete ng sarili nilang kernel, maaaring mahuli ang mga header nang ilang araw o linggo sa release. Maaaring tama ang pakete ng header sa pangalan at mas luma sa nilalaman, na nagbubunga ng build na nagko-compile at pagkatapos ay mabibigo sa pag-load sa halip na sa panahon ng pag-compile. Mas pinapalala ng paghahalo ng pinagmulan: ang kernel ng distribusyong may header mula sa third-party na repository, o kernel ng manufacturer na may generic na header, ay maaaring malinis na mag-compile at tanggihan pa rin ng tumatakbong kernel dahil iba ang configuration. Ang mga numero ng bersyon lang ay hindi nag-aayos niyon.

Kung sinusundan ng makina ang isang eksperimental na channel ng kernel, sadyang magpasiya kung mananatili doon na may tugmang build artifact o babalik sa sinusuportahang set ng pakete. Ang paulit-ulit na pag-update at pag-asa na magtutugma ang mga piraso ay hindi plano, dahil nauulit ang parehong hindi pagtutugma sa bawat pagkakataon.

I-verify ang interface pagkatapos ng muling pagtatayo

Pagkatapos ng matagumpay na pag-install, ang paggawa ng interface ang mahalagang pagsubok, na sinusundan ng pagbasa kung ano talaga ang ni-load ng kernel at kung ano ang sinasabi ng log kung tumanggi ito. Ang module na naglo-load at ang interface na hindi magawa ay magkaibang kabiguan na may magkaibang dahilan. Hinihiwalay ng tatlong utos sa ibaba ang mga iyon.

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

Kung tumanggi ang module na mag-load, tinutukoy ng log ng kernel ang dahilan, at ang hindi pagtutugma ng bersyon ay isa lang sa mga posibilidad. Basahin ang linyang iyon bago muling itayo, dahil ang pangalawang magkaparehong build ay gumugugol ng parehong sampung minuto at nagbibigay ng parehong pagtanggi. Pagkatapos ay alisin ang pansamantalang interface upang magsimula ang susunod na pagsubok mula sa malinis na kalagayan.