ماژول 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

اگر ماژول از بارگذاری امتناع کند، گزارش کرنل علت را ذکر می‌کند و ناسازگاری نسخه تنها یکی از احتمالات است. پیش از ساخت دوباره آن خط را بخوانید، زیرا ساخت دوباره یکسان همان ده دقیقه را صرف می‌کند و همان امتناع را به بار می‌آورد. سپس رابط موقت را حذف کنید تا آزمون بعدی از وضعیت پاک آغاز شود.