കേർണൽ അപ്ഡേറ്റിന് ശേഷം WireGuard മൊഡ്യൂൾ ലോഡ് ചെയ്യുന്നില്ലേ? ഇത് പരിശോധിക്കുക

നിങ്ങളുടെ ടണൽ ഇന്നലെ പ്രവർത്തിച്ചിരുന്നു, അപ്ഡേറ്റിന് ശേഷം മെഷീൻ റീബൂട്ട് ചെയ്തു, ഇപ്പോൾ ഇന്റർഫേസ് ഉയരുന്നില്ല. WireGuard ബാഹ്യ മൊഡ്യൂളായി നിർമ്മിക്കുന്ന സിസ്റ്റത്തിൽ, സാധാരണ കാരണം ഡിസ്കിലെ മൊഡ്യൂൾ ഇപ്പോൾ പ്രവർത്തിക്കുന്ന കേർണൽ റിലീസിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു റിലീസിനുള്ളതാണ് എന്നതാണ്. അതേ മെഷീനിൽ സമാനമായ പേരുള്ള ഹെഡറുകൾ ആ പൊരുത്തത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. അത് തീരുമാനിക്കുന്നത് റിലീസ് സ്ട്രിംഗ് മാത്രമാണ്.

പ്രവർത്തിക്കുന്ന കേർണലോ ഇൻസ്റ്റാൾ ചെയ്ത കേർണലോ

ഒരു അപ്ഡേറ്റ് പുതിയ കേർണൽ പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യുകയും മെഷീൻ റീബൂട്ട് ചെയ്യുന്നതുവരെ പഴയത് ഡിസ്കിൽ വിടുകയും ചെയ്യുന്നു. റീബൂട്ടിന് ശേഷം പ്രവർത്തിക്കുന്ന റിലീസ് മാറുന്നു, മുമ്പത്തേതിനെതിരെ നിർമ്മിച്ച ഏത് മൊഡ്യൂളും അതിന്റെ ഫയലുകൾ ഇപ്പോഴും ഉണ്ടെങ്കിലും ഉപയോഗശൂന്യമാകുന്നു. ആ വിടവ്, റീബൂട്ടിന് മുമ്പ് കുഴപ്പമില്ലാതിരുന്നതും ശേഷം കേടായതുമായ മെഷീനെക്കുറിച്ചുള്ള പരിചിതമായ റിപ്പോർട്ട് വിശദീകരിക്കുന്നു, ഇടയിൽ ഒരു കോൺഫിഗറേഷൻ മാറ്റവുമില്ലാതെ. ഹെഡറുകൾ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ചിലപ്പോൾ പ്രശ്നം പരിഹരിക്കുന്നതായി തോന്നുന്നതും ചിലപ്പോൾ അല്ലാത്തതും ഇത് കൂടി വിശദീകരിക്കുന്നു.

നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഹെഡർ പാക്കേജ് യഥാർത്ഥത്തിൽ ബൂട്ട് ചെയ്ത കേർണലിനേക്കാൾ ഏറ്റവും പുതിയ കേർണൽ പാക്കേജിനോട് യോജിച്ചേക്കാം, പാക്കേജിന്റെ പേരിൽ ആ സന്ദർഭങ്ങളെ വേർതിരിക്കുന്ന ഒന്നുമില്ല; അത് ചെയ്യുന്നത് റിലീസ് സ്ട്രിംഗ് മാത്രമാണ്. എന്താണ് ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നത് എന്ന് പരിശോധിക്കുന്നതിന് മുമ്പ് എന്താണ് പ്രവർത്തിക്കുന്നത് എന്ന് പരിശോധിക്കുക.

പുനർനിർമ്മാണത്തിന് മുമ്പ് മൂന്ന് പരിശോധനകൾ

ആദ്യ പരിശോധന ഏത് കേർണൽ പ്രവർത്തിക്കുന്നു എന്നതാണ്. രണ്ടാമത്തേത് ആ റിലീസിന് മൊഡ്യൂൾ ഉണ്ടോ, അത് കണ്ടെത്താനാകുമോ എന്നതാണ്. മൂന്നാമത്തേത് കേർണൽ അത് ഇതിനകം ലോഡ് ചെയ്തിട്ടുണ്ടോ എന്നതാണ്. നാലാമത്തെ ചോദ്യം, ഇന്റർഫേസ് സൃഷ്ടിക്കാനാകുമോ എന്നത്, മൊഡ്യൂളിനെയല്ല അനുമതികളെയാണ് പരിശോധിക്കുന്നത്, അതിനാൽ അതിന്റെ സ്ഥാനം ഈ പട്ടികയിലല്ല, പുനർനിർമ്മാണത്തിന് ശേഷമാണ്.

താഴെയുള്ള കമാൻഡുകൾ ഒന്നും മാറ്റാതെ ആദ്യത്തെ മൂന്നിന് ഉത്തരം നൽകുന്നു. മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് ഓരോ ഫലവും വായിക്കുക, കാരണം ഓരോ ഉത്തരവും വ്യത്യസ്തമായ ഒരു അറ്റകുറ്റപ്പണി ഒഴിവാക്കുന്നു.

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

രണ്ടാമത്തെ വരി പാത നിലവിലില്ല എന്ന് റിപ്പോർട്ട് ചെയ്താൽ, പ്രവർത്തിക്കുന്ന കേർണലിന്റെ നിർമ്മാണ പരിതസ്ഥിതി ഇല്ല, നിങ്ങൾ കംപൈൽ ചെയ്യുന്നതൊന്നും അതിനോട് യോജിക്കില്ല. പാത ഉണ്ടായിരിക്കെ modinfo പരാജയപ്പെട്ടാൽ, മൊഡ്യൂൾ ഒട്ടും ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടാകണമെന്നില്ല, ഇത് നടപ്പാക്കൽ മരത്തിനുള്ളിൽ നൽകുന്ന കേർണലുകളിൽ സാധാരണമാണ്. modinfo വിജയിച്ച് lsmod ഒന്നും കാണിക്കുന്നില്ലെങ്കിൽ, മൊഡ്യൂൾ ഉണ്ട് പക്ഷേ ലോഡ് ചെയ്തിട്ടില്ല, ഇത് നിർമ്മാണത്തിന്റെയല്ല, ലോഡിംഗ് സമയത്തിന്റെ പ്രശ്നമാണ്. ഓരോ ഫലവും നിങ്ങളെ വേറെയൊരിടത്തേക്ക് അയക്കുന്നു, അതിനാൽ കമാൻഡുകളെക്കാൾ വായനയാണ് പ്രധാനം.

പ്രവർത്തിക്കുന്ന റിലീസിനെതിരെ നിർമ്മിക്കുക

ബാഹ്യ മൊഡ്യൂൾ തയ്യാറാക്കിയ കേർണൽ ട്രീയ്ക്കെതിരെ കംപൈൽ ചെയ്യുന്നു, ഏറ്റവും ഉയർന്ന പതിപ്പ് നമ്പറുള്ള ഡയറക്ടറിയല്ല, പ്രവർത്തിക്കുന്ന കേർണലിനുള്ള നിർമ്മാണ ഡയറക്ടറി ഉപയോഗിക്കാൻ കേർണലിന്റെ ബാഹ്യ മൊഡ്യൂൾ ഗൈഡ് വിശദീകരിക്കുന്നു. ആ നിർമ്മാണ ഡയറക്ടറി കേർണൽ പാക്കേജ് പരിപാലിക്കുന്ന സിംബോളിക് ലിങ്ക് ആണ്, അതിനാൽ അത് ഇപ്പോൾ ബൂട്ട് ചെയ്ത റിലീസിന്റെ ട്രീയിലേക്ക് ചൂണ്ടുന്നു. ഈ പരോക്ഷതയാണ് കാര്യം: അല്ലെങ്കിൽ നിങ്ങൾ തെറ്റായി ചെയ്യുന്ന ഒരു തിരഞ്ഞെടുപ്പ് അത് ഒഴിവാക്കുന്നു. അത് വ്യക്തമായി നാമനിർദ്ദേശം ചെയ്യുന്നത് ലക്ഷ്യത്തെ അവ്യക്തമല്ലാതാക്കുന്നു.

ട്രീ പൂർണ്ണമായി നിർമ്മിക്കാതെ തയ്യാറാക്കി മാത്രം വെച്ചിരിക്കുമ്പോൾ ഒരു വിശദാംശം പ്രധാനമാണ്. തയ്യാറെടുപ്പ് ലക്ഷ്യം ചില ബാഹ്യ നിർമ്മാണങ്ങൾക്ക് ആവശ്യമായ സിംബോൾ പതിപ്പ് ഫയൽ സൃഷ്ടിക്കുന്നില്ല, അതിനാൽ ഹെഡറുകൾ നിറഞ്ഞ ട്രീ സ്വയമേവ പൂർണ്ണ നിർമ്മാണ പരിതസ്ഥിതിയല്ല. സിംബോളുകൾ ഇല്ലാത്തതിനാൽ നിർമ്മാണം പരാജയപ്പെട്ടാൽ, ആ ഫയലാണ് ആദ്യം നോക്കേണ്ട സ്ഥലം.

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

പാക്കേജ് ചെയ്ത ഹെഡറുകൾ പിന്നിലാകുമ്പോൾ

തങ്ങളുടെ കേർണലുകൾ പാക്കേജ് ചെയ്യുന്ന ഡിസ്ട്രിബ്യൂഷനുകളിലും സിംഗിൾ ബോർഡ് കമ്പ്യൂട്ടറുകളിലും, ഹെഡറുകൾ റിലീസിൽ നിന്ന് ദിവസങ്ങളോ ആഴ്ചകളോ പിന്നിലാകാം. ഹെഡർ പാക്കേജ് പേരിൽ ശരിയും ഉള്ളടക്കത്തിൽ പഴയതുമായിരിക്കാം, അത് കംപൈൽ ചെയ്ത് പിന്നീട് കംപൈൽ ചെയ്യുമ്പോഴല്ല, ലോഡ് ചെയ്യുമ്പോൾ പരാജയപ്പെടുന്ന നിർമ്മാണം നൽകുന്നു. ഉറവിടങ്ങൾ കലർത്തുന്നത് അത് കൂടുതൽ വഷളാക്കുന്നു: മൂന്നാം കക്ഷി റിപ്പോസിറ്ററിയിൽ നിന്നുള്ള ഹെഡറുകളുള്ള ഡിസ്ട്രിബ്യൂഷൻ കേർണലോ, പൊതു ഹെഡറുകളുള്ള നിർമ്മാതാവിന്റെ കേർണലോ വൃത്തിയായി കംപൈൽ ചെയ്തിട്ടും കോൺഫിഗറേഷൻ വ്യത്യസ്തമായതിനാൽ പ്രവർത്തിക്കുന്ന കേർണൽ നിരസിച്ചേക്കാം. പതിപ്പ് നമ്പറുകൾ മാത്രം അത് പരിഹരിക്കുന്നില്ല.

മെഷീൻ പരീക്ഷണാത്മക കേർണൽ ചാനൽ പിന്തുടരുന്നുവെങ്കിൽ, യോജിച്ച നിർമ്മാണ ആർട്ടിഫാക്ടുകളുമായി അവിടെ തുടരണോ പിന്തുണയുള്ള പാക്കേജ് ഗണത്തിലേക്ക് മടങ്ങണോ എന്ന് ബോധപൂർവം തീരുമാനിക്കുക. അപ്ഡേറ്റ് ആവർത്തിച്ച് കഷണങ്ങൾ ഒത്തുചേരുമെന്ന് പ്രതീക്ഷിക്കുന്നത് ഒരു പദ്ധതിയല്ല, കാരണം അതേ പൊരുത്തക്കേട് ഓരോ തവണയും ആവർത്തിക്കുന്നു.

പുനർനിർമ്മാണത്തിന് ശേഷം ഇന്റർഫേസ് പരിശോധിക്കുക

വിജയകരമായ ഇൻസ്റ്റാളേഷന് ശേഷം ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നതാണ് പ്രധാന പരീക്ഷണം, അതിന് ശേഷം കേർണൽ യഥാർത്ഥത്തിൽ എന്ത് ലോഡ് ചെയ്തു, നിരസിച്ചെങ്കിൽ ലോഗ് എന്ത് പറയുന്നു എന്ന് വായിക്കുക. ലോഡ് ചെയ്യുന്ന മൊഡ്യൂളും സൃഷ്ടിക്കാനാകാത്ത ഇന്റർഫേസും വ്യത്യസ്ത കാരണങ്ങളുള്ള വ്യത്യസ്ത പരാജയങ്ങളാണ്. താഴെയുള്ള മൂന്ന് കമാൻഡുകൾ അവയെ വേർതിരിക്കുന്നു.

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

മൊഡ്യൂൾ ലോഡ് ചെയ്യാൻ വിസമ്മതിച്ചാൽ, കേർണൽ ലോഗ് കാരണം പറയുന്നു, പതിപ്പ് പൊരുത്തക്കേട് സാധ്യതകളിൽ ഒന്ന് മാത്രമാണ്. വീണ്ടും നിർമ്മിക്കുന്നതിന് മുമ്പ് ആ വരി വായിക്കുക, കാരണം രണ്ടാമത്തെ അതേ നിർമ്മാണം അതേ പത്ത് മിനിറ്റ് ചെലവഴിച്ച് അതേ വിസമ്മതം നൽകുന്നു. അതിന് ശേഷം താൽക്കാലിക ഇന്റർഫേസ് നീക്കം ചെയ്യുക, അടുത്ത പരീക്ഷണം ശുദ്ധമായ അവസ്ഥയിൽ നിന്ന് തുടങ്ങാൻ.