Исправлена ​​ошибка «Не удалось запустить загрузку модулей ядра» при загрузке SLES.

Сообщение SLES при загрузке «Не удалось запустить загрузку модулей ядра» обычно означает, что systemd-modules-load.serviceбыла предпринята попытка загрузить как минимум один модуль ядра, и один запрос не удался. Полезная цель состоит не просто в том, чтобы скрыть красную строку при загрузке. Правильное восстановление обеспечивает работоспособность службы, удаляет устаревшие запросы на модули, сохраняет все необходимые драйверы и обеспечивает работоспособность после следующей перезагрузки.

Данное руководство написано для SUSE Linux Enterprise Server 15 и соответствует текущему руководству по администрированию SLES 15 SP7. В документации SUSE указано, что systemd-modules-load.serviceмодули, указанные в файле конфигурации /etc/modules-load.d/*.conf, загружаются автоматически при обнаружении устройств, в то время как большинство современных аппаратных модулей обычно загружаются автоматически. Это различие важно: если устаревшая статическая запись указывает на модуль, который больше не существует, удаление или исправление этой записи часто безопаснее, чем принудительное возвращение устаревшего драйвера в систему. См. документацию SUSE по управлению модулями ядра для SLES 15 SP7 .

Как должен выглядеть успешный результат решения проблемы

Прежде чем что-либо менять, определите желаемый результат. После ремонта:

• systemctl status systemd-modules-load.serviceБольше не должно сообщать о неудачном результате.
• В журнале больше не должно отображаться то же сообщение об ошибке загрузки модуля при повторной загрузке.
• Если модуль действительно необходим, modprobe MODULE_NAMEон должен успешно работать, и соответствующее оборудование или функция должны функционировать.
• Если модуль устарел, устаревший запрос следует удалить, а не заменять его несвязанным модулем.
• Если проблема связана с ранней загрузкой, следует пересобрать initramfs, и машина должна перезагрузиться в обычном режиме.

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

Шаг 1: Подтвердите неисправность модуля и зафиксируйте точное сообщение об ошибке.

Начните с определения самой услуги, а не гадайте по сообщению на заставке:

sudo systemctl status systemd-modules-load.service --no-pager

Найдите имя модуля и сообщение об ошибке, например Module ... not found, No such device, , Operation not permitted, или сообщение о том, что неподдерживаемый модуль был отклонен. Точная формулировка определяет дальнейшие действия.

Если вывод состояния неполный, пока не редактируйте конфигурацию. Сначала получите полный журнал загрузки.

Шаг 2: Перед изменением файлов модулей прочтите журнал загрузки.

Для текущей загрузки запрашивайте информацию только об этой службе:

sudo journalctl -b -u systemd-modules-load.service --no-pager

Вы также можете просмотреть сообщения ядра, касающиеся загрузки модулей:

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

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

Результат, подобный этому, Module foo not found in directory /lib/modules/...обычно указывает на устаревшую конфигурацию, несоответствие ядра/пакета или сторонний драйвер, который не был пересобран для активного ядра. No such deviceДругой пример: файл модуля может существовать, но текущее оборудование или виртуальное устройство может не соответствовать ожиданиям драйвера.

Шаг 3: Выясните, кто запрашивает у SLES загрузку этого модуля.

Найдите стандартные места расположения статической нагрузки и конфигурацию modprobe:

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Замените MODULE_NAMEна имя из журнала. В SLES 15 SP7 локальные записи в /etc/modules-load.d/являются стандартным местом, управляемым администратором, для модулей, которые должны быть загружены при загрузке, в то время как упакованные записи могут существовать в /usr/lib/modules-load.d/. SUSE отмечает, что большинству модулей вообще не требуется ручная запись в modules-load.d.

Затем проверьте, действительно ли активное ядро ​​содержит этот модуль:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Если модуль устарел

Удалите или отключите локальный файл, который запрашивает это. Не удаляйте файл поставщика /usr/libпросто для того, чтобы заглушить ошибку, поскольку обновления пакетов могут его восстановить. Если вы определите, что локальный /etc/modules-load.d/*.confфайл был создан для устаревшего оборудования или старого программного обеспечения, удалите эту локальную запись и повторите проверку.

Если модуль должен существовать, но modinfo не может его найти.

Проверьте, соответствует ли запущенное ядро ​​дереву установленных модулей:

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

Стандартная проверка качества проста: /lib/modules/$(uname -r)драйвер должен существовать и содержать модули для фактически работающего ядра. Если драйвер стороннего разработчика был скомпилирован для более старой версии ядра, переустановите или пересоберите этот драйвер для текущего ядра SLES, используя поддерживаемую производителем процедуру. Избегайте копирования файла .koиз другой версии ядра только для того, чтобы modprobeчто-то найти; различия в ABI ядра или сигнатурах могут сделать это небезопасным или неэффективным.

Если модуль находится в чёрном списке

Найдите черный список или установите средство переопределения:

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Удаляйте черный список только после подтверждения причины его добавления. Черный список может защитить систему от конфликтующих драйверов. В руководстве по модулям SUSE описаны как постоянные черные списки, так и временные черные списки во время работы GRUB, поэтому правильным решением может быть удаление запроса на статическую загрузку вместо удаления черного списка.

Если SLES сообщает о неподдерживаемом модуле

Не включайте автоматически загрузку неподдерживаемых модулей. SLES помечает модули ядра для статуса поддержки, и принудительное включение неподдерживаемого модуля может повлиять на возможность его поддержки. SUSE описывает механизм исключений для сценариев тестирования или исправления от поставщика в своем Руководстве администратора. Используйте его только тогда, когда вы понимаете последствия для поддержки и имеете законную потребность в драйвере. Аналогичное актуальное руководство SUSE доступно по адресу SLES 15 SP7 Administration Guide .

Шаг 4: Пересобирайте initramfs только в том случае, если изменение затрагивает раннюю загрузку.

Если неисправный модуль необходим внутри initramfs, или вы изменили критически важные для загрузки драйверы или конфигурацию черного списка, которые должны быть там отражены, перегенерируйте образ:

sudo dracut -f

В документации SUSE подробно описано восстановление initramfs после изменений драйверов, влияющих на загрузку. В текущем руководстве по процессу загрузки объясняется, когда необходимо добавить драйверы в initramfs и как dracutэто делается для его восстановления: Введение в процесс загрузки в SLES 15 SP7 .

Не следует запускать dracut -fэту процедуру каждый раз при возникновении ошибки необязательного модуля. Если обычный модуль, установленный после загрузки, просто был указан в файле /etc/modules-load.d, исправления этого файла может быть достаточно. Пересборка initramfs наиболее актуальна, когда некорректная конфигурация встроена в образ загрузки или необходимый драйвер должен быть доступен до полного монтирования корневой файловой системы.

Перед тем как считать инцидент закрытым, убедитесь в качестве выполненного ремонта.

Сначала проверьте работу без перезагрузки, когда это будет безопасно:

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

Если необходимый модуль должен быть загружен, подтвердите это:

lsmod | grep -w MODULE_NAME

Затем перезагрузите компьютер во время планового технического обслуживания и проверьте новую загрузку:

sudo reboot

После входа в систему:

systemctl --failed
journalctl -b -u systemd-modules-load.service --no-pager

Наиболее убедительным признаком успеха является не исчезновение сообщения в консоли, а то, что после перезагрузки ошибка модуля не повторяется, и оборудование или подсистема, зависящие от этого модуля, по-прежнему работают.

Когда следует изменить подход

Ограничения этого исправления

Сообщение «Не удалось запустить загрузку модулей ядра» — это симптом, а не единичный дефект. Данная процедура устраняет сбои, вызванные запросами статических модулей, отсутствующими или несовместимыми модулями, черными списками и синхронизацией initramfs. Она не заменяет диагностику оборудования, поддержку сторонних драйверов, работу по подписанию Secure Boot или восстановление данных с хранилища, когда само корневое устройство недоступно.

Для производственных систем SLES необходимо обеспечить поддержку: отдавайте предпочтение модулю, поставляемому вместе с ядром SLES, следите за тем, чтобы драйверы сторонних разработчиков соответствовали матрице поддержки их поставщиков, и используйте документированные механизмы SUSE, а не обходите проверки просто для устранения сбоя службы. Восстановление считается завершенным, когда состояние службы, журнал загрузки и зависимое оборудование подтверждают, что проблема устранена.