Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapitre 8. Installation et démarrage

Installation réseau corrigée dans initrd si la configuration réseau est fournie dans Kickstart

Auparavant, l'installateur échouait à paramétrer ou à reconfigurer les interfaces réseau dans initrd si celles-ci étaient définies dans les fichiers Kickstart. Cela pouvait entraîner l'échec de l'installation et celle-ci pouvait entrer en mode de secours si l'accès réseau était requis par d'autres commandes du fichier Kickstart.
Ce problème est désormais résolu et Anaconda gère correctement la configuration réseau à partir des fichiers Kickstart dans initrd assez tôt pendant le processus de démarrage.

Anaconda prend désormais en charge la création de volumes logiques dans le cache

L'installateur prend désormais en charge la création de volumes logiques LVM dans le cache et l'installation du système sur ces volumes.
Actuellement cette approche est uniquement prise en charge dans Kickstart. Pour créer un volume logique dans le cache, veuillez utiliser les nouvelles options --cachepvs=, --cachesize=, et --cachemode= de la commande Kickstart logvol.
Veuillez consulter le Guide d'installation Red Hat Enterprise Linux 7 pour obtenir des informations détaillées sur ces nouvelles options.

Amélioration du tri du menu de démarrage GRUB2

Un problème avec le mécanisme de tri utilisé par la commande grub2-mkconfig peut causer au fichier de configuration grub.cfg d'être généré avec les noyaux disponibles triés incorrectement.
GRUB2 utilise désormais le paquet rpmdevtools pour trier les noyaux disponibles et le fichier de configuration est généré correctement avec la version du noyau la plus récente, qui est répertoriée tout en haut.

Désormais, Anaconda restaure correctement les actions de disque lorsqu'il se produit des changements de sélection de disque

Auparavant, Anaconda et Blivet ne restauraient pas correctement les actions planifiées sur les disques lorsque les sélections de disques changeaient, causant ainsi divers problèmes. Avec cette mise à jour, Anaconda a été corrigé et crée un instantané de la configuration du stockage initiale et y retourne lorsque les sélections de disques changent, restaurant ainsi totalement toutes les actions planifiées pour les disques.

Amélioration de la détection des noms de disques device-mapper

Dans la version précédente de Red Hat Enterprise Linux 7, l'installateur pouvait tomber en panne lors d'une installation sur des disques qui contenaient auparavant des volumes logiques et que les métadonnées de ces volumes étaient toujours présentes. L'installateur ne pouvait pas reconnaîtres les noms device-mapper corrects et le processus de création de nouveaux volumes logiques LVM échouait.
La méthode utilisée pour obtenir des noms de périphérique device-mapper a été mise à jour et l'installation sur disques qui contenaient des métadonnées LVM existantes est désormais plus fiable.

Gestion de PReP Boot pendant le partitionnement corrigée

Sous certaines circonstances, la partition PReP Boot sur IBM Power Systems pouvait être paramétrée avec une taille invalide pendant un partitionnement personnalisé. Dans cette situation, la suppression de toute partition provoquait une panne de l'installateur.
Des vérifications sont maintenant implémentées dans anaconda afin de s'assurer que la partition est toujours correctement dimensionnée, entre 4096 Kio et 10 Mio. En outre, il n'est plus nécessaire de modifier le format de la partition PReP Boot pour changer sa taille.

Partitions EFI sur périphériques RAID1

Des partitions système EFI peuvent maintenant être créées sur un périphérique RAID1, ceci sert à permettre une récupération système lorsqu'un disque de démarrage échoue. Cependant, dans le cas où Boot#### et BootOrder, et le volume d'ESP découvert par le microprogramme soient corrompus, mais qu'ils apparaissent toujours comme un ESP valide, alors l'ordre de démarrage ne sera pas reconstruit automatiquement. Cependant, le système devrait toujours pouvoir démarrer manuellement à partir du second disque.

L'installation en mode texte ne tombe plus en panne pendant la configuration réseau

Auparavant, dans l'écran de configuration réseau de l'installateur en mode texte interactif, l'utilisation d'un espace lors de la spécification des serveurs de noms provoquait la panne de l'installateur.
Désormais, Anaconda gère correctement les espaces dans les définitions de serveurs de noms en mode texte, et l'installateur ne tombe plus en panne si un espace est utilisé pour séparer les adresses des serveurs de noms.

Les écrans du mode de secours sur IBM System z ne sont plus coupés

Auparavant, le second et le troisième écran du mode de secours sur serveurs IBM System z étaient affichés incorrectement et certaines parties de l'interface étaient coupées. Le mode de secours sur cette architecture a été amélioré et tous les écrans fonctionnent désormais correctement.

Module complémentaire OpenSCAP dans Anaconda

Il est désormais possible d'appliquer le contenu SCAP (« Security Content Automation Protocol ») pendant le processus d'installation. Ce nouveau module complémentaire de l'installateur offre une manière fiable et facile de configurer une politique de sécurité sans avoir à utiliser de scripts personnalisés.
Ce module complémentaire fournit une nouvelle section Kickstart (« %addon org_fedora_oscap ») ainsi qu'un nouvel écran dans l'interface utilisateur graphique pendant une installation interactive. Ces trois parties sont documentées dans le Guide d'installation Red Hat Enterprise Linux 7.
L'application d'une politique de sécurité pendant l'installation effectuera divers changements pendant et immédiatement après l'installation, selon la politique activée. Si un profil est sélectionné, le paquet openscap-scanner (un outil de vérification de conformité OpenSCAP) est ajouté à votre sélection de paquets et un scan de conformité initial sera effectué une fois l'installation terminée. Les résultats de ce scan seront enregistrés sur /root/openscap_data.
Plusieurs profils sont fournis sur le support d'installation par le paquet scap-security-guide. Vous pouvez également charger d'autres contenus en tant que flux de données, archives, ou en tant que paquets RPM à partir d'un serveur HTTP, HTTPS ou FTP si nécessaire.
Remarquez que l'application d'une politique de sécurité n'est pas nécessaire sur tous les systèmes. Ce module complémentaire doit être utilisé uniquement lorsqu'une politique spécifique est mandatée par les règles de votre organisation ou par des régulations gouvernementales, sinon le module complémentaire peut rester dans son état par défaut, qui n'applique aucune politique de sécurité.

Anaconda n'expires plus lorsqu'il attend un fichier Kickstart sur un CD ou DVD

Auparavant, si Anaconda était configuré pour charger un fichier Kickstart à partir d'un support optique utilisant la commande inst.ks=cdrom:/ks.cfg et que le système était également démarré à partir d'un CD ou DVD, l'installateur attendait un court moment que le disque soit échangé. Cette fenêtre était assez courte par défaut, 30 secondes uniquement. Une fois ce délai expiré, le système entrait en mode de secours.
Anaconda a été modifié pour ne jamais expirer en attendant d'un utilisateur qu'il fournisse un fichier Kickstart sur CD ou DVD. Si les options de démarrage inst.ks=cdrom sont utilisées et que le fichier Kickstart n'est pas détecté, Anaconda affichera une invite et attendra que le fichier soit fourni ou qu'un redémarrage soit effectué.