Échec du chargement du module de démarrage SLES : Trouvez le pilote et corrigez-le

Lorsque SLES affiche le message « Échec du chargement des modules du noyau » au démarrage, commencez par consulter systemd-modules-load.serviceles journaux pour identifier le module défaillant. S'il s'agit d'une entrée optionnelle obsolète, supprimez la requête correspondante de sa configuration ; s'il est requis, corrigez l'incompatibilité du pilote ou du noyau au lieu de désactiver le service.

Cette procédure s'applique à SUSE Linux Enterprise Server (SLES) 15 et se réfère à la documentation d'administration de SLES 15 SP7. Les commandes doivent être exécutées depuis une console locale ou une session SSH active disposant sudodes droits d'accès.

Que signifie ce message avant toute modification ?

Un module noyau est un pilote ou une fonctionnalité du noyau pouvant être chargé séparément. Au démarrage, systemd-modules-load.serviceil traite les requêtes de chargement de modules spécifiques, y compris ceux définis dans modules-load.ddes fichiers. Une requête infructueuse peut entraîner l'arrêt du service, même si d'autres parties du serveur continuent de fonctionner.

SUSE indique que la plupart des pilotes se chargent automatiquement lors de la détection du matériel. Une liste de modules manuelle est généralement inutile ; une entrée obsolète est donc plausible, mais le message de démarrage seul ne le prouve pas. Conservez l’accès à la console, effectuez une sauvegarde système ou de configuration si possible, et ne désactivez pas les pilotes de stockage, de réseau ou de cluster simplement pour faire disparaître l’avertissement. Consultez le guide d’administration des modules du noyau de SUSE pour connaître le modèle pris en charge.

Étape 1 : Lire l’état du service et son journal de démarrage

Commencez par consulter l'état de systemd. systemdest le gestionnaire de services chargé de démarrer les services et de signaler leur état.

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

L' -boption limite l'exécution journalctlau démarrage en cours et -usélectionne ce service. Au-dessus de la dernière ligne « Échec », recherchez des messages tels que « Module introuvable », une option invalide ou une erreur d'autorisation ou de signature. Notez le nom exact du module et le texte de l'erreur. Ne présumez pas que le module mentionné dans l'exemple ci-dessous existe sur votre serveur.

Si le journal de service n'est pas concluant, consultez les messages du noyau pour obtenir plus de détails :

sudo journalctl -k -b --no-pager

Si l'ordinateur ne parvient pas à se connecter, démarrez un noyau installé plus ancien depuis GRUB s'il est disponible, ou utilisez le support de récupération SLES. Ne modifiez pas les modules critiques pour le démarrage depuis une session distante non testée. SUSE documente les filtres de journalisation dans le chapitre consacré à l'administration de journalctl .

Étape 2 : Trouvez la configuration de démarrage qui la demande

Supposons que les noms des revues example_driver… Remplacez cet espace réservé par le nom réel du module, puis effectuez une recherche dans les listes de modules :

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

Chaque ligne correspondante indique le fichier qui requiert ce module au démarrage. La configuration locale d'un administrateur se trouve généralement dans `/etc/systemd/systemd` /etc/modules-load.d/, tandis qu'un paquet peut fournir son fichier dans `/etc/ /usr/lib/modules-load.d/systemd/systemd`. Un fichier local portant le même nom de base est prioritaire sur le fichier du fournisseur, comme décrit dans le guide de configuration systemd de SUSE . Si la recherche ne donne aucun résultat, examinez également cat /proc/cmdlineles demandes de modules au démarrage et vérifiez que le nom d'erreur a été correctement copié.

Ouvrez le fichier correspondant et vérifiez si l'entrée est toujours nécessaire au matériel ou à l'application. Un module demandé pour un périphérique ancien et supprimé est différent d'un pilote de contrôleur de stockage ou d'un chien de garde de cluster.

Étape 3 : Tester le module, puis appliquer la réparation correspondante

Vérifie quel noyau est en cours d'exécution et si le pilote est disponible. modprobeCharge les modules du noyau et résout les dépendances ; son -noption permet un test à blanc sans insertion de pilote.

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

Là encore, remplacez example_driver. L'exécution à blanc permet d'identifier les problèmes de recherche ou de configuration, mais ne garantit pas qu'un pilote s'initialisera correctement sur votre matériel ni qu'il réussira les vérifications de signature du démarrage sécurisé. SUSE recommande l'exécution à blanc modprobeplutôt que le chargement directinsmod ; les détails des options d'exécution à blanc sont disponibles dans le manuel de modprobe .

Si une entrée optionnelle obsolète pointe vers un module manquant

Sauvegardez le fichier local concerné et commentez uniquement la ligne obsolète. Par exemple, si /etc/modules-load.d/example.confla source est confirmée :

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

Modifiez une example_driverentrée isolée # example_driver, enregistrez et laissez les autres demandes de modules intactes. Si la source est un fichier de paquetage situé sous /usr/lib, ne modifiez pas directement ce fichier ; utilisez une modification locale dûment validée ou faites corriger la configuration du paquetage. Ne supprimez jamais une demande de module simplement parce modinfoqu'elle est signalée comme manquante si le périphérique correspondant est requis.

Si un module requis est manquant ou incompatible

Ne commentez pas cette ligne. Vérifiez que le paquet de pilotes est compatible avec la sortie de la commande uname -ret le Service Pack SLES installé. Un message « module introuvable » peut indiquer que le pilote correspondant n'a pas été installé ou n'a pas été recompilé après une mise à jour du noyau. Un message « format de module invalide » suggère un problème de compatibilité ; les journaux du noyau peuvent permettre de préciser le problème. Restaurez ou réinstallez le pilote compatible en suivant les instructions de SUSE ou du fabricant du matériel. Évitez de copier .kodes fichiers arbitraires provenant d'un autre noyau.

Si le module existe mais que son index de dépendances est manifestement obsolète, reconstruisez cet index pour le noyau actuel et réessayez la simulation :

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

Cette étape n'installe pas de pilote manquant. Si le message « Clé requise non disponible » ou le rejet de la signature du module s'affiche sur un système Secure Boot, suivez la procédure d'inscription des clés de confiance et de signature des pilotes de SUSE ; ne désactivez pas Secure Boot comme solution de contournement générique. SUSE explique les restrictions relatives aux pilotes tiers dans son guide de déploiement de Secure Boot .

Étape 4 : Vérifiez que le prochain démarrage est propre

Après avoir corrigé la configuration ou restauré le pilote, relancez le chargeur et vérifiez son état. N'effectuez cette opération qu'après avoir vérifié que toutes les entrées restantes sont correctes ; le redémarrage tentera à nouveau les chargements configurés.

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 l'opération réussit, planifiez un redémarrage contrôlé avec accès console et exécutez à nouveau les commandes d'état et de journalisation. La correction est confirmée lorsque le service ne présente plus d'erreur au nouveau démarrage et que tout matériel ou logiciel requis par le module fonctionne correctement. Si l'erreur persiste, comparez le nouveau journal avec l'ancien : un autre module listé peut également être défaillant. Conservez la sauvegarde jusqu'à ce que ce test soit concluant ; ne masquez pas systemd-modules-load.servicele message d'erreur au démarrage.