Résolution de l'erreur « Échec du chargement des modules du noyau » lors du démarrage de SLES

Le message d'erreur de démarrage SLES « Échec du chargement des modules du noyau » signifie généralement systemd-modules-load.servicequ'au moins un module du noyau a tenté de se charger et qu'une requête a échoué. L'objectif n'est pas simplement de masquer cette erreur. Une réparation efficace garantit le bon fonctionnement du service, supprime les requêtes de modules obsolètes, préserve les pilotes nécessaires à la machine et est maintenue après le prochain redémarrage.

Ce guide est destiné à SUSE Linux Enterprise Server 15 et est conforme au guide d'administration SLES 15 SP7. SUSE indique que systemd-modules-load.serviceles modules nommés dans le fichier `/ etc/sys /etc/modules-load.d/*.conf/modules` sont chargés manuellement, tandis que la plupart des modules matériels modernes sont généralement chargés automatiquement lors de la détection des périphériques. Cette distinction est importante : si une entrée statique obsolète pointe vers un module qui n'existe plus, il est souvent plus sûr de la supprimer ou de la corriger que de forcer la réinstallation d'un pilote obsolète. Consultez la documentation SUSE relative à la gestion des modules du noyau pour SLES 15 SP7 .

À quoi devrait ressembler une solution réussie

Avant toute modification, définissez le résultat souhaité. Après la réparation :

• systemctl status systemd-modules-load.serviceNe devrait plus signaler un résultat d'échec.
• Le journal ne devrait plus afficher la même erreur de chargement de module lors d'un nouveau démarrage.
• Si le module est réellement nécessaire, modprobe MODULE_NAMEl'opération devrait réussir et le matériel ou la fonctionnalité associée devrait fonctionner.
• Si le module est obsolète, la requête obsolète doit être supprimée plutôt que remplacée par un module sans rapport.
• Si le problème est lié à un démarrage prématuré, l'initramfs devrait être reconstruit et la machine devrait redémarrer normalement.

Si toutes ces vérifications ne s'appliquent pas à votre situation, utilisez celles qui correspondent au composant défaillant. Par exemple, un serveur peut démarrer correctement même si un module optionnel est défaillant. Il est toujours utile de corriger ce problème, mais il est différent d'un pilote de stockage manquant qui empêche l'affichage du système de fichiers racine.

Étape 1 : Confirmer l’unité défaillante et relever l’erreur exacte du module

Commencez par examiner le service lui-même au lieu de deviner d'après le message de l'écran de démarrage :

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

Recherchez le nom du module et une erreur telle que Module ... not found« Module non pris en charge » No such device, « Module Operation not permittednon pris en charge » ou un message indiquant qu'un module non pris en charge a été refusé. Le libellé exact détermine l'action suivante.

Si le message d'état est tronqué, ne modifiez pas encore la configuration. Obtenez d'abord le journal de démarrage complet.

Étape 2 : Lisez le journal de démarrage avant de modifier les fichiers de module

Interrogez uniquement ce service pour le démarrage actuel :

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

Vous pouvez également examiner les messages du noyau relatifs au chargement des modules :

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

La première commande indique quelle requête de chargement statique a échoué . Le journal du noyau peut fournir des informations supplémentaires, comme le refus du périphérique détecté par un pilote, une dépendance du firmware, des problèmes de signature ou une autre erreur de bas niveau.

Un résultat de ce type Module foo not found in directory /lib/modules/...indique généralement une configuration obsolète, une incompatibilité noyau/paquet ou un pilote tiers qui n'a pas été recompilé pour le noyau actif. Le cas No such deviceest différent : le fichier du module peut exister, mais le matériel ou le périphérique virtuel actuel peut ne pas correspondre à ce qu'attend le pilote.

Étape 3 : Identifiez qui demande à SLES de charger ce module.

Recherchez les emplacements de charge statique normaux et la configuration de la sonde 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

Remplacez MODULE_NAMEpar le nom figurant dans le journal. Sous SLES 15 SP7, les entrées locales dans le répertoire ` /etc/modules-load.d/modules-load.d` constituent l'emplacement standard géré par l'administrateur pour les modules devant être chargés au démarrage, tandis que les entrées des paquets peuvent exister sous `modules /usr/lib/modules-load.d/-load.d`. SUSE précise que la plupart des modules ne nécessitent aucune entrée manuelle dans `modules-load.d`.

Vérifiez ensuite si le noyau actif possède effectivement le module :

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Si le module est obsolète

Supprimez ou désactivez le fichier local qui en fait la demande. Ne supprimez pas un fichier fournisseur /usr/libsimplement pour faire disparaître l'erreur, car les mises à jour du package peuvent le rétablir. Si vous constatez qu'un /etc/modules-load.d/*.conffichier local a été créé pour du matériel obsolète ou un logiciel ancien, supprimez cette entrée locale et effectuez un nouveau test.

Si le module devrait exister mais que modinfo ne le trouve pas

Vérifiez si le noyau en cours d'exécution correspond à l'arborescence des modules installés :

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

Un contrôle qualité courant est simple : /lib/modules/$(uname -r)le pilote doit exister et contenir les modules nécessaires au noyau en cours d’exécution. Si un pilote tiers a été compilé pour un noyau plus ancien, réinstallez-le ou recompilez-le avec le noyau SLES actuel en suivant la procédure recommandée par le fournisseur. Évitez de copier un .kofichier depuis une autre version du noyau dans le seul but de modprobele rechercher ; les différences d’ABI ou de signature du noyau peuvent rendre cette opération dangereuse ou inefficace.

Si le module est sur liste noire

Rechercher une liste noire ou installer une solution de remplacement :

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

Ne supprimez une liste noire qu'après avoir vérifié la raison de son ajout. Une liste noire peut protéger le système contre un pilote incompatible. Le guide des modules SUSE documente à la fois les listes noires permanentes et les listes noires temporaires (au moment de l'exécution de GRUB). Il peut donc être plus judicieux de supprimer la requête de chargement statique plutôt que la liste noire.

Si SLES signale un module non pris en charge

Ne pas activer automatiquement le chargement des modules non pris en charge. SLES marque les modules du noyau pour leur prise en charge, et le chargement forcé d'un module non pris en charge peut affecter cette prise en charge. SUSE documente le mécanisme d'exception pour les tests ou les correctifs d'urgence des fournisseurs dans son Guide d'administration. Utilisez-le uniquement si vous comprenez les conséquences sur la prise en charge et si vous avez un besoin légitime en matière de pilotes. Le même guide SUSE est disponible dans le Guide d'administration de SLES 15 SP7 .

Étape 4 : Reconstruisez l’initramfs uniquement si la modification affecte le démarrage initial.

Si le module défaillant est nécessaire dans l'initramfs, ou si vous avez modifié un pilote critique pour le démarrage ou une configuration de liste noire qui doit y être reflétée, régénérez l'image :

sudo dracut -f

SUSE documente spécifiquement la reconstruction de l'initramfs après des modifications de pilotes affectant le démarrage. Son guide actuel du processus de démarrage explique quand il est nécessaire d'ajouter des pilotes à l'initramfs et comment dracutl'utiliser pour le régénérer : Introduction au processus de démarrage dans SLES 15 SP7 .

N'exécutez pas dracut -fcette opération systématiquement pour chaque erreur de module optionnel. Si un module post-démarrage ordinaire est simplement listé dans le /etc/modules-load.dfichier `initramfs`, la correction de ce fichier peut suffire. La reconstruction d'initramfs est surtout pertinente lorsque la configuration erronée est intégrée à l'image de démarrage ou lorsque le pilote requis doit être disponible avant que le système de fichiers racine ne soit entièrement monté.

Vérifiez la réparation avant de considérer l'incident comme clos.

Premier test sans redémarrage lorsque cela sera possible en toute sécurité :

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

Si le module requis est maintenant chargé, veuillez le confirmer :

lsmod | grep -w MODULE_NAME

Redémarrez ensuite pendant une fenêtre de maintenance appropriée et vérifiez le nouveau démarrage :

sudo reboot

Après la connexion :

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

Le signe le plus probant de réussite n'est pas la disparition ponctuelle du message d'erreur dans la console, mais l'absence de réapparition de cette erreur après un nouveau redémarrage et le bon fonctionnement du matériel ou du sous-système qui en dépend.

Quand changer d'approche

Limites de cette solution

Le message « Échec du chargement des modules du noyau » indique un symptôme, et non un défaut unique. Cette procédure traite les échecs liés aux requêtes de modules statiques, aux modules manquants ou incompatibles, aux listes noires et à la synchronisation initramfs. Elle ne remplace pas les diagnostics matériels, la prise en charge des pilotes tiers, la signature du démarrage sécurisé ni la récupération du stockage lorsque le périphérique racine est indisponible.

Pour les systèmes SLES de production, privilégiez la maintenance : utilisez de préférence le module fourni avec votre noyau SLES, assurez-vous que les pilotes tiers respectent la matrice de compatibilité de leur fournisseur et utilisez les mécanismes documentés de SUSE plutôt que de contourner les vérifications pour masquer une panne de service. La réparation est terminée lorsque l’état du service, le journal de démarrage et le matériel dépendant confirment que le problème est résolu.