Модуль 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

Якщо модуль відмовляється завантажуватися, журнал ядра називає причину, і невідповідність версій — лише одна з можливостей. Прочитайте цей рядок перед перезбиранням, бо друге ідентичне збирання витратить ті самі десять хвилин і дасть ту саму відмову. Потім видаліть тимчасовий інтерфейс, щоб наступна перевірка почалася з чистого стану.