8.8. Noyau
kdump ne démarre pas sur le noyau RHEL 9
Le paramètre crashkernel=auto n'est pas configuré par défaut dans le noyau RHEL 9. Par conséquent, le service kdump ne démarre pas par défaut.
Pour contourner ce problème, configurez l'option crashkernel= avec la valeur requise.
Par exemple, pour réserver 256 Mo de mémoire à l'aide de l'utilitaire grubby, entrez la commande suivante :
# grubby --args crashkernel=256M --update-kernel ALL
En conséquence, le noyau RHEL 9 démarre kdump et utilise la valeur de la taille de la mémoire configurée pour vider le fichier vmcore.
(BZ#1894783)
Le mécanisme kdump ne parvient pas à capturer vmcore sur les cibles chiffrées par LUKS
Lors de l'exécution de kdump sur des systèmes dotés de partitions chiffrées Linux Unified Key Setup (LUKS), les systèmes requièrent une certaine quantité de mémoire disponible. Lorsque la mémoire disponible est inférieure à la quantité de mémoire requise, le service systemd-cryptsetup ne parvient pas à monter la partition. Par conséquent, le second noyau ne parvient pas à capturer le fichier de vidage d'urgence (vmcore) sur les cibles chiffrées LUKS.
La commande kdumpctl estimate vous permet d'interroger Recommended crashkernel value, qui est la taille de mémoire recommandée pour kdump.
Pour contourner ce problème, procédez comme suit pour configurer la mémoire requise pour kdump sur les cibles cryptées LUKS :
Imprimer la valeur estimée de
crashkernel:# kdumpctl estimate
Configurez la quantité de mémoire requise en augmentant la valeur de
crashkernel:# grubby --args=crashkernel=652M --update-kernel=ALL
Redémarrez le système pour que les modifications soient prises en compte.
# reboot
Par conséquent, kdump fonctionne correctement sur les systèmes dotés de partitions chiffrées par LUKS.
(BZ#2017401)
L'allocation de la mémoire du noyau de crash échoue au démarrage
Sur certains systèmes Ampere Altra, l'allocation de la mémoire du noyau de crash pour l'utilisation de kdump échoue au démarrage lorsque la mémoire disponible est inférieure à 1 Go. Par conséquent, la commande kdumpctl ne parvient pas à démarrer le service kdump car la mémoire requise est supérieure à la taille de la mémoire disponible.
Pour contourner le problème, diminuez la valeur du paramètre crashkernel d'au moins 240 Mo afin de respecter la taille requise, par exemple crashkernel=240M. Par conséquent, l'allocation de mémoire au noyau de crash pour kdump n'échoue pas sur les systèmes Ampere Altra.
kTLS ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau
Kernel Transport Layer Security (kTLS) ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau. Par conséquent, le chiffrement logiciel est utilisé avec TLS 1.3 même lorsque les cartes réseau prennent en charge le délestage TLS. Pour contourner ce problème, désactivez TLS 1.3 si le délestage est nécessaire. Par conséquent, vous ne pouvez décharger que TLS 1.2. Lorsque TLS 1.3 est utilisé, les performances sont moindres, car TLS 1.3 ne peut pas être déchargé.
(BZ#2000616)
L'activation de FADump avec Secure Boot peut entraîner une perte de mémoire (OOM) dans GRUB
Dans l'environnement Secure Boot, GRUB et PowerVM allouent ensemble une zone de mémoire de 512 Mo, connue sous le nom de Real Mode Area (RMA), pour la mémoire de démarrage. La région est divisée entre les composants de démarrage et, si l'un d'entre eux dépasse son allocation, des pannes de mémoire se produisent.
En général, le système de fichiers initramfs installé par défaut et la table de symboles vmlinux sont dans les limites permettant d'éviter de telles défaillances. Toutefois, si la fonction Firmware Assisted Dump (FADump) est activée dans le système, la taille par défaut de initramfs peut augmenter et dépasser 95 Mo. Par conséquent, chaque redémarrage du système entraîne un état GRUB OOM.
Pour éviter ce problème, n'utilisez pas Secure Boot et FADump en même temps. Pour plus d'informations et de méthodes sur la manière de contourner ce problème, voir le lien:https://www.ibm.com/support/pages/node/6846531.
(BZ#2149172)
Les systèmes en mode Secure Boot ne peuvent pas exécuter d'opérations dynamiques sur les LPAR
Les utilisateurs ne peuvent pas exécuter d'opérations de partition logique dynamique (DLPAR) à partir de la console de gestion du matériel (HMC) si l'une ou l'autre de ces conditions est remplie :
-
La fonction Secure Boot est activée, ce qui permet d'activer implicitement le mécanisme du noyau
lockdownen mode intégrité. -
Le mécanisme du noyau
lockdownest activé manuellement en mode intégrité ou confidentialité.
Dans RHEL 9, le noyau lockdown bloque complètement l'accès des Run Time Abstraction Services (RTAS) à la mémoire système accessible via le fichier de périphérique de caractères /dev/mem. Plusieurs appels RTAS nécessitent un accès en écriture à /dev/mem pour fonctionner correctement. Par conséquent, les appels RTAS ne s'exécutent pas correctement et les utilisateurs voient le message d'erreur suivant :
HSCL2957 Il n'y a actuellement aucune connexion RMC entre la console de gestion et la partition <LPAR name> ou la partition ne prend pas en charge les opérations de partitionnement dynamique. Vérifiez la configuration du réseau sur la console de gestion et la partition et assurez-vous que l'authentification du pare-feu entre la console de gestion et la partition a eu lieu. Exécutez la commande diagrmc de la console de gestion pour identifier les problèmes qui pourraient être à l'origine de l'absence de connexion RMC.
(BZ#2083106)
