Error de carga del módulo de arranque SLES: Encuentre el controlador y soluciónelo.

Cuando SLES muestre el mensaje "Error al iniciar la carga de módulos del kernel" durante el arranque, primero revise systemd-modules-load.servicelos registros para identificar el módulo que falló. Si el módulo es una entrada opcional obsoleta, elimine esa solicitud de su configuración; si es necesario, repare la discrepancia del controlador o del kernel en lugar de deshabilitar el servicio.

Este procedimiento se aplica a SUSE Linux Enterprise Server (SLES) 15, utilizando la documentación de administración de SLES 15 SP7 como referencia. Los comandos deben ejecutarse desde una consola local o una sesión SSH activa con sudoacceso.

Qué significa el mensaje antes de que hagas cualquier cambio.

Un módulo del kernel es un controlador o una función del kernel que se puede cargar por separado. Durante el arranque, systemd-modules-load.servicelos procesos solicitan la carga de módulos específicos, incluidos los definidos en modules-load.darchivos. Una solicitud fallida puede provocar que el servicio falle, incluso si otras partes del servidor siguen funcionando.

SUSE indica que la mayoría de los controladores se cargan automáticamente al detectar el hardware. Generalmente, no es necesario crear una lista manual de módulos, por lo que una entrada obsoleta es una posibilidad razonable; sin embargo, el mensaje de arranque por sí solo no lo demuestra. Mantenga el acceso a la consola, cree una instantánea del sistema o una copia de seguridad de la configuración cuando sea posible y no desactive los controladores de almacenamiento, red o clúster solo para que desaparezca la advertencia. Consulte la guía de administración de módulos del kernel de SUSE para el modelo compatible.

Paso 1: Lea el estado del servicio y su registro de arranque.

Comience con el estado de systemd. systemdEs el administrador de servicios responsable de iniciar los servicios e informar sobre su estado.

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

El -bindicador restringe journalctlel arranque al actual y -uselecciona este servicio. Busque mensajes como «No se pudo encontrar el módulo», «Opción no válida» o «Error de permisos o firma» encima de la línea final «Error». Anote el nombre exacto del módulo y el texto del error. No dé por sentado que el módulo mencionado en el ejemplo a continuación existe en su servidor.

Si el registro de servicio no es concluyente, revise los mensajes del kernel para obtener más detalles:

sudo journalctl -k -b --no-pager

Si el equipo no puede acceder a una sesión de inicio de sesión utilizable, inicie un kernel instalado anteriormente desde GRUB si está disponible, o utilice el medio de rescate de SLES. No edite módulos críticos para el arranque desde una sesión remota no probada. SUSE documenta los filtros de registro en su capítulo de administración de journalctl .

Paso 2: Encuentra la configuración de inicio que lo solicita.

Supongamos que los nombres de las revistas son example_driver. Reemplace ese marcador de posición con el nombre real del módulo y luego busque en las listas de módulos:

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

Cada línea coincidente indica qué archivo solicita ese módulo al arrancar. La configuración local de un administrador suele estar en /etc/modules-load.d/, mientras que un paquete puede proporcionar su archivo en /usr/lib/modules-load.d/. Un archivo local con el mismo nombre base tiene prioridad sobre el archivo del proveedor, como se describe en la guía de configuración de systemd de SUSE . Si la búsqueda no encuentra nada, examine también cat /proc/cmdlinelas solicitudes de módulos al arrancar y verifique que el nombre del error se haya copiado correctamente.

Abra el archivo correspondiente e identifique si la entrada aún es necesaria para el hardware o la aplicación. Un módulo solicitado para un dispositivo antiguo y retirado es diferente de un controlador de almacenamiento o un monitor de clúster.

Paso 3: Pruebe el módulo y luego aplique la reparación correspondiente.

Comprueba qué kernel se está ejecutando y si el controlador está disponible para él. modprobeCarga los módulos del kernel y resuelve las dependencias; su -nopción realiza una prueba sin insertar ninguno.

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

Nuevamente, reemplace example_driver. La prueba en seco ayuda a identificar problemas de búsqueda o configuración, pero no prueba que un controlador se inicializará correctamente en su hardware o pasará las comprobaciones de firma de Secure Boot. SUSE recomienda modprobeen lugar de insmodla carga directa; los detalles de las banderas de la prueba en seco aparecen en el manual de modprobe .

Si una entrada opcional obsoleta apunta a un módulo faltante

Realice una copia de seguridad del archivo local específico y comente únicamente la línea obsoleta. Por ejemplo, si /etc/modules-load.d/example.confes la fuente confirmada:

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

Modifique una example_driverentrada individual # example_driver, guarde y deje intactas las demás solicitudes de módulos. Si el origen es un archivo de paquete en /usr/lib, no edite directamente dicho archivo; utilice una anulación local debidamente revisada o corrija la configuración del paquete. Nunca elimine una solicitud de módulo simplemente porque modinfoindique que falta si se requiere el dispositivo correspondiente.

Si falta un módulo necesario o es incompatible

No lo comente. Confirme que el paquete de controladores admite la salida uname -ry el Service Pack de SLES instalado. Un mensaje de "módulo no encontrado" puede indicar que el controlador correspondiente no se instaló o no se recompiló después de una actualización del kernel. Un mensaje de "formato de módulo no válido" sugiere un problema de compatibilidad; las líneas de registro del kernel pueden ayudar a identificarlo. Restaure o reinstale el controlador compatible siguiendo las instrucciones de SUSE o del fabricante del hardware. Evite copiar .koarchivos arbitrarios de un kernel diferente.

Si el módulo existe pero su índice de dependencias está claramente desactualizado, vuelva a construir ese índice para el kernel actual y vuelva a intentar la prueba en seco:

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

Este paso no instala un controlador faltante. Si ve el mensaje "Clave requerida no disponible" o el rechazo de la firma del módulo en un sistema Secure Boot, siga el flujo de trabajo de inscripción de claves de confianza y firma de controladores de SUSE; no desactive Secure Boot como solución alternativa genérica. SUSE explica las restricciones de los controladores de terceros en su guía de implementación de Secure Boot .

Paso 4: Confirme que el siguiente arranque se haya realizado correctamente.

Tras corregir la configuración o restaurar el controlador, vuelva a ejecutar el cargador e inspeccione su estado. Realice esto únicamente después de verificar que todas las entradas restantes sean correctas; reiniciar el sistema intentará realizar las cargas configuradas nuevamente.

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

Si la unidad funciona correctamente, programe un reinicio controlado con acceso a la consola y ejecute nuevamente los comandos de estado y registro. La solución se confirma cuando el servicio ya no falla en el nuevo arranque y cualquier hardware o software necesario que dependa del módulo sigue funcionando. Si el error reaparece, compare el nuevo registro con el anterior: es posible que otro módulo listado también esté fallando. Conserve la copia de seguridad hasta que se complete la verificación; no la enmascare systemd-modules-load.servicesimplemente para suprimir el mensaje de inicio.