Gestion des modules de noyau

Explique comment inspecter les modules de noyau chargés, ajuster les paramètres et contrôler les modules chargés sur Oracle Linux.

Utilisez la commande lsmod pour afficher les modules chargés dans le noyau en cours d'exécution. Utilisez la commande modinfo pour obtenir des informations sur un module de noyau. Utilisez la commande modprobe pour charger un module dans le noyau en cours d'exécution ou pour modifier les paramètres du module de noyau. Vous pouvez également créer des fichiers de configuration dans /etc/modprobe.d/ pour contrôler les paramètres utilisés lors du chargement des modules de noyau. Vous pouvez également configurer le chargement des modules au moment de l'initialisation en modifiant la configuration dans /etc/modules-load.d/.

Liste des informations sur les modules chargés

Utilisez la commande lsmod pour répertorier les modules chargés dans le noyau et utilisez la commande modinfo pour obtenir plus d'informations sur chaque module. Pour plus d'informations, reportez-vous aux pages de manuel lsmod(5) et modinfo(8).

Exécutez la commande lsmod pour répertorier les modules chargés dans le noyau.

lsmod

Module                  Size  Used by
udp_diag               16384  0
ib_core               311296  0
tcp_diag               16384  0
inet_diag              24576  2 tcp_diag,udp_diag
nfsv3                  49152  0
nfs_acl                16384  1 nfsv3
...
dm_mirror              24576  0
dm_region_hash         20480  1 dm_mirror
dm_log                 20480  2 dm_region_hash,dm_mirror
...

La sortie indique le nom du module, la quantité de mémoire qu'il utilise, le nombre de processus utilisant le module et les noms des autres modules dont il dépend. Le module dm_log, par exemple, dépend des modules dm_region_hash et dm_mirror. L'exemple montre également que deux processus utilisent les trois modules.

Utilisez la commande modinfo pour afficher des informations détaillées sur un module.
```
modinfo ahci
```
```
filename:       /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/ata/ahci.ko.xz
version:        3.0
license:        GPL
description:    AHCI SATA low-level driver
author:         Jeff Garzik
srcversion:     1DC2CDA088C5DC03187A5E0
alias:          pci:v*d*sv*sd*bc01sc06i01*
...
depends:        libata,libahci
intree:         Y
name:           ahci
retpoline:      Y
vermagic:       6.12.0-100.28.2.el10uek.x86_64 SMP preempt mod_unload modversions 
sig_id:         PKCS#7
signer:         Oracle CA Server
sig_key:        7B:38:D7:DC:38:51:E7:C7:F1:61:C5:5D:8D:CC:6B:1C:90:82:4D:05
sig_hashalgo:   sha512
signature:      64:05:FC:CC:B1:D3:88:91:B6:C9:A2:39:A3:A9:BB:8C:95:11:36:20:
                62:9C:95:D9:8B:B8:F6:5F:CC:D2:93:4E:7D:59:E1:80:DB:70:FA:4C:
                9B:8D:75:E3:98:AB:9D:BD:94:93:A7:72:0B:28:3B:15:4E:96:0D:E3:
                9F:FE:24:1A:09:B5:31:27:F2:EE:45:61:C8:4A:D3:4B:82:07:23:66:
                A1:06:F4:DF:B9:FF:D2:78:08:1D:AA:EC:DE:3C:E4:17:BD:69:6A:A5:

                ...
                64:F0:4F:E2:4E:F3:47:A5:40:E8:F7:07:68:3F:58:25:32:BA:13:E9:
                00:46:7A:2F:30:73:B4:32:48:76:6B:1E
parm:           marvell_enable:Marvell SATA via AHCI (1 = enabled) (int)
parm:           mobile_lpm_policy:Default LPM policy for mobile chipsets (int)
...
```
La sortie comprend les informations suivantes :

filename

Chemin absolu du fichier d'objet de noyau.

version

numéro de version du module. Notez que le numéro de version peut ne pas être mis à jour pour les modules corrigés et peut être manquant ou supprimé dans les noyaux plus récents.

license

Informations de licence pour le module.

description

Brève description du module.

author

Crédit de l'auteur pour le module.

srcversion

Hachage du code source utilisé pour créer le module.

alias

Noms d'alias internes du module.

depends

Liste des modules dont ce module dépend, séparés par des virgules.

retpoline

Indicateur signalant que le module est construit et qui inclut une atténuation de la vulnérabilité de sécurité Spectre.

name

Nom du module.

intree

Indicateur signalant que le module est construit à partir de la source dans l'arborescence du noyau et qu'il n'est pas entaché.

vermagic

Version du noyau utilisée pour compiler le module, qui est vérifiée par rapport au noyau actuel lorsque le module est chargé.

sig_id

Méthode utilisée pour stocker les clés de signature qui auraient pu être utilisées pour signer un module pour l'initialisation sécurisée, généralement PKCS#7

signer

Nom de la clé de signature utilisée pour signer un module pour l'initialisation sécurisée.

sig_key

Identifiant de la clé de signature de la clé utilisée pour signer le module.

sig_hashalgo

Algorithme utilisé pour générer le hachage de signature pour un module signé.

signature

Données de signature d'un module signé.

parm

Paramètres et descriptions des modules.
Utilisez la commande modinfo -n pour rechercher le chemin d'accès au module sur le système de fichiers.
Les modules sont chargés dans le noyau à partir des fichiers d'objet du noyau (/lib/modules/kernel_version/kernel/*ko*). Pour afficher le chemin absolu d'un fichier d'objet de noyau, spécifiez l'option -n, par exemple :
```
modinfo -n parport
```
```
/lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/parport/parport.ko.xz
```

Charger et décharger des modules

Les modules sont chargés et déchargés à l'aide de la commande modprobe. Pour plus d'informations, reportez-vous aux pages de manuel modprobe(8) et modules.dep(5).

Chargez un module de noyau à l'aide de la commande modprobe.

La commande modprobe charge les modules de noyau, par exemple :

sudo modprobe nfs
sudo lsmod | grep nfs

nfs                   266415  0 
lockd                  66530  1 nfs
fscache                41704  1 nfs
nfs_acl                 2477  1 nfs
auth_rpcgss            38976  1 nfs
sunrpc                204268  5 nfs,lockd,nfs_acl,auth_rpcgss

Incluez l'option -v (détaillée) pour indiquer si d'autres modules sont chargés pour résoudre les dépendances.

sudo modprobe -v nfs

insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs_common/nfs_acl.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko 
...

Remarque

La commande modprobe ne recharge pas les modules déjà chargés. Vous devez d'abord décharger un module avant de pouvoir le recharger.

Déchargez un module à l'aide de la commande modprobe -r.
Utilisez l'option -r pour décharger les modules de noyau :
```
sudo modprobe -rv nfs
```
```
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs/nfs.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/lockd/lockd.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko
...
```
Les modules sont déchargés dans l'ordre inverse dans lequel ils ont été chargés. Les modules ne sont pas déchargés si un processus ou un autre module chargé les requiert.

Modification des paramètres de module de noyau

Les modules de noyau, tels que les pilotes matériels, ont souvent des paramètres personnalisés qui peuvent être définis pour modifier le comportement du pilote ou du module. Plusieurs mécanismes sont disponibles pour mettre à jour les paramètres du module.

Utilisez sysfs pour mettre à jour les paramètres du module immédiatement.
Vous pouvez modifier les valeurs de certains paramètres pour les modules chargés et les pilotes intégrés en écrivant la nouvelle valeur dans un fichier sous /sys/module/module_name/parameters, par exemple :
```
echo 0 | sudo tee /sys/module/ahci/parameters/skip_host_reset
```
Reportez-vous aux sections About the /sys Virtual File System et sysfs Directory Reference.

Notez que les modifications ne sont pas persistantes et ne s'appliquent pas automatiquement après le redémarrage.
Utilisez la commande modprobe pour modifier la configuration en cours d'exécution d'un module.
Pour modifier le comportement d'un module, spécifiez les paramètres du module dans la commande modprobe :
```
sudo modprobe module_name parameter=value ...
```
Séparez les paires paramètre/valeur par des espaces. Les valeurs de tableau sont représentées par une liste séparée par des virgules, par exemple :
```
sudo modprobe foo parm=bar arrayparm=1,2,3,4
```
Mettez à jour la configuration modprobe pour obtenir des modifications de configuration de module plus permanentes.
Les fichiers de configuration (/etc/modprobe.d/*.conf) spécifient les options de module, créent des alias de module et remplacent le comportement habituel de modprobe pour les modules ayant des exigences particulières. Le fichier /etc/modprobe.conf qui a été utilisé avec des versions antérieures de modprobe est également valide s'il existe. Les entrées des fichiers /etc/modprobe.conf et /etc/modprobe.d/*.conf utilisent la même syntaxe. Pour plus d'informations, reportez-vous à Référence de configuration Modprobe.

Spécification des modules à charger au moment de l'initialisation

Le système charge automatiquement la plupart des modules au moment de l'initialisation. Vous pouvez également ajouter des modules à charger en créant un fichier de configuration pour le module dans le répertoire /etc/modules-load.d. Le nom de fichier doit porter l'extension .conf.

Les modifications apportées au répertoire /etc/modules-load.d persistent après les réinitialisations.

Pour forcer le chargement d'un module au moment de l'initialisation, créez un fichier de configuration dans /etc/modules-load.d pour le module.
Par exemple, pour forcer le chargement de bnxt_en.conf au moment de l'initialisation, exécutez la commande suivante :
```
echo bnxt_en | sudo tee /etc/modules-load.d/bnxt_en.conf
```
Vérifiez que le fichier existe et contient le nom du module.
```
cat /etc/modules-load.d/bnxt_en.conf
```
Si le module n'est pas déjà chargé, vous pouvez le charger manuellement à l'aide de la commande modprobe, ou vous pouvez réinitialiser le système et le charger automatiquement à l'aide de la configuration que vous avez fournie.

Empêcher le chargement des modules au moment de l'initialisation

Vous pouvez empêcher le chargement des modules au moment de l'initialisation en ajoutant une règle de refus dans un fichier de configuration du répertoire /etc/modprobe.d, puis en reconstruisant le disque RAM initial utilisé pour charger le noyau au moment de l'initialisation.

Avertissement

La désactivation de modules peut avoir des conséquences inattendues et empêcher un système de s'initialiser ou d'être complètement fonctionnel après l'initialisation. Il est recommandé de créer une image de sauvegarde du disque RAM avant d'apporter des modifications et de vérifier que la configuration est correcte.

Créez un fichier de configuration pour empêcher le chargement du module.

Par exemple :

sudo tee /etc/modprobe.d/bnxt_en-deny.conf <<'EOF'
#DENY bnxt_en
blacklist bnxt_en
install bnxt_en /bin/false
EOF

Recréez l'image de disque RAM initiale.
```
sudo dracut -f -v
```
Relancez le système pour que les modifications prennent effet.
```
sudo reboot
```

Suppression des modules de mise à jour faibles

Dans certains cas, vous pouvez supprimer les modules de mise à jour faibles à la place d'un noyau plus récent, par exemple, dans le cas où un problème avec un pilote livré a été résolu dans un noyau plus récent. Dans ce cas, vous pouvez préférer utiliser le nouveau pilote plutôt que le module externe que vous avez installé dans le cadre d'une mise à jour de pilote. Pour plus d'informations, reportez-vous à A propos des modules de mise à jour faibles.

Deux approches différentes peuvent être utilisées pour supprimer un module de mise à jour faible.

Supprimez le lien symbolique manuellement.
Comme les modules de mise à jour faibles sont liés symboliquement pour chaque version du noyau sur le système, vous pouvez supprimer le lien symbolique pour le module de chaque noyau où vous ne voulez pas qu'il s'applique. Par exemple :
```
sudo rm -rf /lib/modules/6.12.0-100.28.2.el10uek.x86_64/weak-updates/kmod-kvdo
```
Dans cet exemple, le module de mise à jour faible, kmod-kvdo, est supprimé du noyau 6.12.0-100.28.2.el10uek.x86_64.
Utilisez la commande weak-modules pour supprimer le module.
Vous pouvez utiliser la commande weak-modules pour supprimer un module de mise à jour faible spécifié pour tous les noyaux compatibles ou utiliser la commande pour supprimer le module de mise à jour faible pour le noyau actuel. Vous pouvez également utiliser la commande weak-modules de la même manière pour ajouter des modules de mise à jour faibles. Pour plus d'informations sur cette commande, exécutez la commande suivante :
```
weak-modules -h
```
Vous pouvez également utiliser la commande weak-modules avec l'option dry-run pour tester les résultats sans apporter de modifications réelles, par exemple :
```
weak-modules --remove-kernel --dry-run --verbose
```