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

Если модуль отказывается загружаться, журнал ядра называет причину, и несовпадение версий — лишь одна из возможностей. Прочитайте эту строку перед пересборкой, потому что вторая идентичная сборка потратит те же десять минут и даст тот же отказ. Затем удалите временный интерфейс, чтобы следующая проверка началась с чистого состояния.