Solucionar el error "Error al iniciar la carga de módulos del kernel" en el arranque de SLES

El mensaje de arranque de SLES «Error al iniciar la carga de módulos del kernel» suele indicar systemd-modules-load.serviceque se intentó cargar al menos un módulo del kernel y que una solicitud falló. El objetivo no es simplemente ocultar la línea roja de arranque. Una buena reparación deja el servicio en buen estado, elimina las solicitudes de módulos obsoletas, conserva los controladores que la máquina realmente necesita y permite que el sistema siga funcionando tras el siguiente reinicio.

Esta guía está escrita para SUSE Linux Enterprise Server 15 y está alineada con la Guía de administración actual de SLES 15 SP7. SUSE documenta que systemd-modules-load.servicecarga módulos nombrados en /etc/modules-load.d/*.conf, mientras que la mayoría de los módulos de hardware modernos normalmente se cargan automáticamente cuando se detectan dispositivos. Esa distinción es importante: si una entrada estática obsoleta apunta a un módulo que ya no existe, eliminar o corregir esa entrada suele ser más seguro que forzar un controlador obsoleto de nuevo en el sistema. Consulte la documentación de SUSE sobre la administración de módulos del kernel para SLES 15 SP7 .

Cómo debería ser una solución exitosa

Antes de cambiar nada, defina el resultado que desea. Después de la reparación:

• systemctl status systemd-modules-load.serviceYa no debería informar un resultado fallido.
• El registro ya no debería mostrar el mismo error de carga de módulo durante un arranque nuevo.
• Si el módulo es realmente necesario, modprobe MODULE_NAMEdebería funcionar correctamente y el hardware o la función relacionada deberían funcionar.
• Si el módulo está obsoleto, la solicitud antigua debe eliminarse en lugar de reemplazarse por un módulo no relacionado.
• Si el problema está relacionado con el arranque temprano, se debe reconstruir el initramfs y la máquina debería reiniciarse con normalidad.

Si no todas esas comprobaciones se aplican a su situación, utilice las que coincidan con el componente que falla. Por ejemplo, un servidor puede arrancar correctamente incluso si falla un módulo opcional. En ese caso, también conviene solucionarlo, pero es diferente a la falta de un controlador de almacenamiento que impide que aparezca el sistema de archivos raíz.

Paso 1: Confirme la unidad defectuosa y capture el error exacto del módulo.

Empiece por el servicio en sí, en lugar de adivinar a partir del mensaje de la pantalla de inicio:

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

Busque el nombre del módulo y un error como Module ... not found, No such device, Operation not permitted, o un mensaje que indique que se rechazó un módulo no compatible. La redacción exacta determinará la siguiente acción.

Si la salida de estado está truncada, no edite la configuración todavía. Obtenga primero el registro de arranque completo.

Paso 2: Lea el registro de arranque antes de modificar los archivos del módulo.

Consultar únicamente este servicio para el arranque actual:

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

También puedes inspeccionar los mensajes del kernel relacionados con la carga de módulos:

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

El primer comando responde qué solicitud de carga estática falló . El registro del kernel puede agregar contexto, como un controlador que rechaza el dispositivo detectado, una dependencia de firmware, problemas de firma u otro error de nivel inferior.

Un resultado como este Module foo not found in directory /lib/modules/...suele indicar una configuración obsoleta, una incompatibilidad entre el kernel y el paquete, o un controlador de terceros que no se recompiló para el kernel activo. No such deviceEs diferente: el archivo del módulo puede existir, pero el hardware o dispositivo virtual actual puede no coincidir con lo que espera el controlador.

Paso 3: Averigüe quién le está pidiendo a SLES que cargue ese módulo.

Busque las ubicaciones normales de carga estática y la configuración de 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

Reemplazar MODULE_NAMEcon el nombre del diario. En SLES 15 SP7, las entradas locales en /etc/modules-load.d/son el lugar estándar administrado por el administrador para los módulos que deben cargarse al arrancar, mientras que las entradas empaquetadas pueden existir en /usr/lib/modules-load.d/. SUSE señala que la mayoría de los módulos no necesitan una entrada manual modules-load.d en absoluto.

Luego, compruebe si el kernel activo realmente tiene el módulo:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Si el módulo está obsoleto

Elimine o desactive el archivo local que lo solicita. No borre un archivo de proveedor /usr/libsolo para silenciar el error, ya que las actualizaciones de paquetes pueden restaurarlo. Si determina que /etc/modules-load.d/*.confse creó un archivo local para hardware obsoleto o software antiguo, elimine esa entrada local y vuelva a realizar la prueba.

Si el módulo debería existir pero modinfo no puede encontrarlo

Compruebe si el kernel en ejecución coincide con el árbol de módulos instalado:

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

Una comprobación de calidad común es sencilla: /lib/modules/$(uname -r)debe existir y contener los módulos del kernel que se está ejecutando. Si un controlador de terceros se compiló para un kernel antiguo, reinstálelo o vuelva a compilarlo con el kernel SLES actual siguiendo el procedimiento recomendado por el proveedor. Evite copiar un .koarchivo de otra versión del kernel solo para intentar modprobeencontrar algo; las diferencias en la ABI o la firma del kernel pueden hacer que esto sea inseguro o ineficaz.

Si el módulo está en la lista negra

Busque una lista negra o instale una anulación:

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

Solo elimine una lista negra después de confirmar el motivo de su adición. Una lista negra puede proteger el sistema de un controlador conflictivo. La guía de módulos de SUSE documenta tanto las listas negras persistentes como las temporales creadas durante el funcionamiento de GRUB, por lo que la solución más adecuada podría ser eliminar la solicitud de carga estática en lugar de la lista negra.

Si SLES informa de un módulo no compatible

No habilite automáticamente la carga de módulos no compatibles. SLES marca los módulos del kernel según su estado de soporte, y forzar un módulo no compatible puede afectar la compatibilidad. SUSE documenta el mecanismo de excepción para escenarios de prueba o parches de proveedores en su Guía de administración. Úselo solo cuando comprenda las consecuencias para la compatibilidad y tenga un requisito legítimo del controlador. La misma guía actual de SUSE está disponible en la Guía de administración de SLES 15 SP7 .

Paso 4: Reconstruya el initramfs solo cuando el cambio afecte al arranque inicial.

Si el módulo que falló es necesario dentro del initramfs, o si cambió la configuración del controlador crítico de arranque o de la lista negra que debe reflejarse allí, regenere la imagen:

sudo dracut -f

SUSE documenta específicamente la reconstrucción del initramfs después de cambios en los controladores que afectan al arranque. Su guía actual del proceso de arranque explica cuándo es necesario agregar controladores al initramfs y cómo dracutse utiliza para regenerarlo: Introducción al proceso de arranque en SLES 15 SP7 .

No lo ejecute dracut -fcomo un ritual para cada error de módulo opcional. Si un módulo posterior al arranque ordinario solo aparece listado en /etc/modules-load.d, corregir ese archivo puede ser suficiente. Reconstruir initramfs es más relevante cuando la configuración incorrecta está integrada en la imagen de arranque o el controlador necesario debe estar disponible antes de que el sistema de archivos raíz real se monte por completo.

Verifique la reparación antes de dar por cerrado el incidente.

Primero, realice una prueba sin reiniciar el sistema cuando sea seguro hacerlo:

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

Si el módulo requerido debe cargarse ahora, confírmelo:

lsmod | grep -w MODULE_NAME

Luego, reinicie durante una ventana de mantenimiento adecuada y compruebe el nuevo arranque:

sudo reboot

Después de iniciar sesión:

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

La señal de éxito más clara no es que el mensaje de la consola haya desaparecido una sola vez, sino que, tras un reinicio completo, no se repita el mismo error del módulo y que el hardware o subsistema que depende de dicho módulo siga funcionando correctamente.

Cuándo cambiar de enfoque

Limitaciones de esta solución

El mensaje "Error al iniciar la carga de módulos del kernel" es un síntoma, no un defecto aislado. Este procedimiento soluciona los fallos causados ​​por solicitudes de módulos estáticos, módulos faltantes o incompatibles, listas negras y sincronización de initramfs. No reemplaza el diagnóstico de hardware, la compatibilidad con controladores de terceros, la firma de arranque seguro ni la recuperación de almacenamiento cuando el dispositivo raíz no está disponible.

Para sistemas SLES de producción, priorice la compatibilidad: utilice el módulo proporcionado para su kernel SLES, mantenga los controladores de terceros alineados con la matriz de soporte de su proveedor y use los mecanismos documentados de SUSE en lugar de omitir las comprobaciones simplemente para solucionar un fallo del servicio. La reparación se completa cuando el estado del servicio, el registro de arranque y el hardware dependiente coinciden en que el problema se ha resuelto.