Chapitre 11. Problèmes connus
Cette partie décrit les problèmes connus dans Red Hat Enterprise Linux 9.2.
11.1. Création d'installateurs et d'images
Les commandes auth et authconfig Kickstart nécessitent le dépôt AppStream
Le paquetage authselect-compat est requis par les commandes Kickstart auth et authconfig lors de l'installation. Sans ce paquet, l'installation échoue si auth ou authconfig est utilisé. Cependant, par conception, le paquet authselect-compat n'est disponible que dans le dépôt AppStream.
Pour contourner ce problème, vérifiez que les dépôts BaseOS et AppStream sont disponibles pour le programme d'installation ou utilisez la commande authselect Kickstart pendant l'installation.
Bugzilla:1640697
Les commandes reboot --kexec et inst.kexec ne fournissent pas un état prévisible du système
L'installation de RHEL à l'aide de la commande reboot --kexec Kickstart ou des paramètres de démarrage du noyau inst.kexec n'offre pas le même état prévisible du système qu'un redémarrage complet. Par conséquent, le passage au système installé sans redémarrage peut produire des résultats imprévisibles.
Notez que la fonctionnalité kexec est obsolète et sera supprimée dans une prochaine version de Red Hat Enterprise Linux.
Bugzilla:1697896
Politiques SELinux inattendues sur les systèmes où Anaconda s'exécute en tant qu'application
Lorsqu'Anaconda est exécuté en tant qu'application sur un système déjà installé (par exemple pour effectuer une autre installation sur un fichier image à l'aide de l'option –image anaconda), il n'est pas interdit au système de modifier les types et attributs SELinux au cours de l'installation. Par conséquent, certains éléments de la politique SELinux peuvent changer sur le système où Anaconda est exécuté. Pour contourner ce problème, n'exécutez pas Anaconda sur le système de production et exécutez-le dans une machine virtuelle temporaire. Ainsi, la politique SELinux sur un système de production n'est pas modifiée. L'exécution d'Anaconda dans le cadre du processus d'installation du système, tel que l'installation à partir de boot.iso ou dvd.iso, n'est pas concernée par ce problème.
Local Media la source d'installation n'est pas détectée lors du démarrage de l'installation à partir d'une clé USB créée à l'aide d'un outil tiers
Lors du démarrage de l'installation RHEL à partir d'une clé USB créée à l'aide d'un outil tiers, le programme d'installation ne détecte pas la source d'installation Local Media (seule Red Hat CDN est détectée).
Ce problème survient parce que l'option de démarrage par défaut int.stage2= tente de rechercher le format d'image iso9660. Cependant, un outil tiers peut créer une image ISO avec un format différent.
En guise de solution de contournement, utilisez l'une ou l'autre des solutions suivantes :
-
Lors du démarrage de l'installation, cliquez sur la touche
Tabpour modifier la ligne de commande du noyau et remplacez l'option de démarrageinst.stage2=parinst.repo=. - Pour créer un périphérique USB amorçable sous Windows, utilisez Fedora Media Writer.
- Si vous utilisez un outil tiers tel que Rufus pour créer un périphérique USB amorçable, régénérez d'abord l'image ISO RHEL sur un système Linux, puis utilisez l'outil tiers pour créer un périphérique USB amorçable.
Pour plus d'informations sur les étapes à suivre pour exécuter l'une des solutions de contournement spécifiées, voir, Le support d'installation n'est pas détecté automatiquement lors de l'installation de RHEL 8.3.
Bugzilla:1877697
Le lecteur de CD-ROM USB n'est pas disponible comme source d'installation dans Anaconda
L'installation échoue lorsque le lecteur de CD-ROM USB en est la source et que la commande Kickstart ignoredisk --only-use= est spécifiée. Dans ce cas, Anaconda ne peut pas trouver et utiliser ce disque source.
Pour contourner ce problème, utilisez la commande harddrive --partition=sdX --dir=/ pour effectuer l'installation à partir d'un lecteur de CD-ROM USB. L'installation n'échoue alors pas.
Échec des installations de disques durs partitionnés avec le système de fichiers iso9660
Vous ne pouvez pas installer RHEL sur des systèmes dont le disque dur est partitionné avec le système de fichiers iso9660. Cela est dû à la mise à jour du code d'installation qui est configuré pour ignorer tout disque dur contenant une partition du système de fichiers iso9660. Cela se produit même lorsque RHEL est installé sans utiliser de DVD.
Pour contourner ce problème, ajoutez le script suivant dans le fichier kickstart pour formater le disque avant le début de l'installation.
Remarque : avant d'exécuter la solution de contournement, sauvegardez les données disponibles sur le disque. La commande wipefs formate toutes les données existantes sur le disque.
%pre
wipefs -a /dev/sda
%endPar conséquent, les installations fonctionnent comme prévu, sans aucune erreur.
Anaconda ne parvient pas à vérifier l'existence d'un compte d'utilisateur administrateur
Lors de l'installation de RHEL à l'aide d'une interface graphique, Anaconda ne vérifie pas si le compte administrateur a été créé. En conséquence, les utilisateurs peuvent installer un système sans aucun compte d'utilisateur administrateur.
Pour contourner ce problème, veillez à configurer un compte d'utilisateur administrateur ou à définir le mot de passe root et à déverrouiller le compte root. Ainsi, les utilisateurs peuvent effectuer des tâches administratives sur le système installé.
De nouvelles fonctionnalités XFS empêchent le démarrage des systèmes PowerNV IBM POWER dont le microprogramme est antérieur à la version 5.10
Les systèmes PowerNV IBM POWER utilisent un noyau Linux pour le micrologiciel et Petitboot en remplacement de GRUB. Ainsi, le noyau du microprogramme monte /boot et Petitboot lit la configuration de GRUB et démarre RHEL.
Le noyau RHEL 9 introduit les fonctionnalités bigtime=1 et inobtcount=1 dans le système de fichiers XFS, que les noyaux dotés d'un microprogramme antérieur à la version 5.10 ne comprennent pas.
Pour contourner ce problème, vous pouvez utiliser un autre système de fichiers pour /boot, par exemple ext4.
Bugzilla:1997832
L'image d'installation de RHEL for Edge ne parvient pas à créer des points de montage lors de l'installation d'une charge utile rpm-ostree
Lors du déploiement des charges utiles rpm-ostree, utilisées par exemple dans une image d'installation RHEL for Edge, le programme d'installation ne crée pas correctement certains points de montage pour les partitions personnalisées. En conséquence, l'installation est interrompue avec l'erreur suivante :
The command 'mount --bind /mnt/sysimage/data /mnt/sysroot/data' exited with the code 32.
Pour contourner ce problème :
- Utilisez un schéma de partitionnement automatique et n'ajoutez pas de points de montage manuellement.
-
Attribuer manuellement des points de montage uniquement dans le répertoire
/var. Par exemple,/var/my-mount-point), et les répertoires standard suivants ://boot,/var.
Le processus d'installation se termine donc avec succès.
NetworkManager ne démarre pas après l'installation lorsqu'il est connecté à un réseau mais qu'il n'y a pas d'adresse DHCP ou d'adresse IP statique configurée
À partir de RHEL 9.0, Anaconda active automatiquement les périphériques réseau lorsqu'il n'y a pas de configuration réseau spécifique ip= ou kickstart. Anaconda crée un fichier de configuration persistant par défaut pour chaque périphérique Ethernet. Dans le profil de connexion, les valeurs ONBOOT et autoconnect sont définies sur true. Par conséquent, lors du démarrage du système installé, RHEL active les périphériques réseau et le service networkManager-wait-online échoue.
En guise de solution de contournement, procédez de l'une des manières suivantes :
Supprimez toutes les connexions à l'aide de l'utilitaire
nmcli, à l'exception de celle que vous souhaitez utiliser. Par exemple :Liste de tous les profils de connexion :
# nmcli connection show
Supprimez les profils de connexion dont vous n'avez pas besoin :
# nmcli connection delete <connection_name>
Remplacez <nom_de_la_connexion> par le nom de la connexion que vous souhaitez supprimer.
Désactive la fonction de connexion automatique au réseau dans Anaconda si aucune configuration réseau spécifique
ip=ou kickstart n'est définie.- Dans l'interface graphique d'Anaconda, naviguez jusqu'à Network & Host Name.
- Sélectionnez un périphérique réseau à désactiver.
- Cliquez sur Configure.
- Dans l'onglet General, désélectionnez l'option Connect automatically with priority
- Cliquez sur Save.
Bugzilla:2115783
Impossible de charger un pilote mis à jour à partir du disque de mise à jour des pilotes dans l'environnement d'installation
Une nouvelle version d'un pilote provenant du disque de mise à jour des pilotes peut ne pas se charger si le même pilote provenant du disque d'installation initial a déjà été chargé. Par conséquent, une version mise à jour du pilote ne peut pas être appliquée à l'environnement d'installation.
Pour contourner le problème, utilisez l'option de ligne de commande du noyau modprobe.blacklist= en même temps que l'option inst.dd. Par exemple, pour s'assurer qu'une version mise à jour du pilote virtio_blk provenant d'un disque de mise à jour des pilotes est chargée, utilisez modprobe.blacklist=virtio_blk, puis suivez la procédure habituelle d'application des pilotes à partir du disque de mise à jour des pilotes. Le système peut ainsi charger une version mise à jour du pilote et l'utiliser dans l'environnement d'installation.
L'installateur se bloque en mode FIPS lors de la création de dispositifs LUKS avec une phrase de passe courte
La longueur minimale d'une phrase de passe utilisée pour les périphériques LUKS est de 8 octets lorsque le système fonctionne en mode FIPS. Par conséquent, lors de la création d'un périphérique LUKS avec une phrase de passe inférieure à 8 octets et d'une installation en mode FIPS, le programme d'installation se bloque. Pour contourner ce problème, utilisez une phrase de passe LUKS d'au moins 8 octets. Par conséquent, le programme d'installation ne se bloque pas lors de la création de périphériques LUKS en mode FIPS.
Certains caractères nécessitent plus d'un octet pour être codés. Par conséquent, vous pouvez utiliser moins de 8 caractères dans certains cas, en fonction des caractères utilisés. Une phrase de passe comportant au moins 8 caractères fonctionne dans tous les cas.
Les installations Kickstart ne parviennent pas à configurer la connexion réseau
Anaconda effectue la configuration réseau du kickstart uniquement par le biais de l'API NetworkManager. Anaconda traite la configuration du réseau après la section %pre kickstart. Par conséquent, certaines tâches de la section de démarrage %pre sont bloquées. Par exemple, le téléchargement de paquets à partir de la section %pre échoue en raison de l'indisponibilité de la configuration du réseau.
Pour contourner ce problème :
-
Configurer le réseau, par exemple à l'aide de l'outil
nmcli, dans le cadre du script%pre. -
Utilisez les options de démarrage du programme d'installation pour configurer le réseau pour le script
%pre.
Par conséquent, il est possible d'utiliser le réseau pour les tâches de la section %pre et le processus d'installation de kickstart se termine.
