Copyright © 2007 Red Hat, Inc. et autres [1]
Les sujets suivants sont abordés dans ce document :
Notes concernant l'installation
Mises à jour de fonctionnalités
Mises à jour de pilotes
Mises à jour relatives au noyau
Autres mises à jour
Aperçus technologiques
Problèmes résolus
Problèmes connus
Certaines informations sur Red Hat Enterprise Linux 5.1 peuvent ne pas apparaître dans ces notes de mise à jour. Une version mise à jour de ces notes peut également être disponible à l'adresse suivante :
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/index.html
La section suivante contient des informations spécifiques à l'installation de Red Hat Enterprise Linux 5.1 et au programme d'installation Anaconda.
Afin de mettre à niveau un système Red Hat Enterprise Linux 5 déjà installé, vous devez utiliser Red Hat Network pour mettre à jour les paquetages qui ont changé.
Vous pouvez utiliser Anaconda pour effectuer une nouvelle installation de Red Hat Enterprise Linux 5.1 ou pour effectuer une mise à niveau de la dernière version mise à jour de Red Hat Enterprise Linux 5 vers Red Hat Enterprise Linux 5.1.
Si vous copiez le contenu des CD-ROM de Red Hat Enterprise Linux 5 (par exemple, en vue d'une installation réseau), assurez-vous de ne copier que les CD-ROM du système d'exploitation. Ne copiez pas le CD-ROM supplémentaire et ne copiez aucun des CD-ROM de produits en couche car une telle opération écraserait des fichiers nécessaires au bon fonctionnement d'Anaconda.
Le contenu des CD-ROM supplémentaires et des CD-ROM de produits en couche doit être installé après l'installation de Red Hat Enterprise Linux 5.1.
Lors de l'installation de Red Hat Enterprise Linux 5.1 sur un invité pleinement virtualisé, n'utilisez pas le noyau kernel-xen. L'utilisation de ce noyau sur des invités pleinement virtualisés peut causer l'interruption de votre système.
Si vous utilisez un numéro d'installation lors de l'installation de Red Hat Enterprise Linux 5.1 sur un invité pleinement virtualisé, assurez-vous de dé-sélectionner le groupe de paquetages Virtualization durant l'installation. Les options du groupe de paquetages Virtualization installent le noyau kernel-xen.
Notez que les invités pleinement paravirtualisés ne sont pas affectés par ce problème. Les invités paravirtualisés utilisent toujours le noyau kernel-xen.
Si vous utilisez le noyau virtualisé lors de la mise à niveau de Red Hat Enterprise Linux 5 vers la version 5.1, vous devez redémarrer lorsque la mise à niveau est terminée.
Les hyperviseurs de Red Hat Enterprise Linux 5 et 5.1 ne sont pas compatibles avec ABI. Si vous ne redémarrez pas entre les mises à niveau, les RPM de virtualisation mis à niveau ne correspondront pas au noyau en cours d'exécution.
L'installation et le démarrage iSCSI étaient au départ inclus dans Red Hat Enterprise Linux 5 en tant qu'aperçu technologique. Cette fonctionnalité est maintenant pleinement supportée, avec les restrictions décrites ci-dessous.
Selon où vous êtes, cette fonctionnalité a trois configurations :
Utilisation d'un initiateur iSCSI matériel (tel que QLogic qla4xxx)
Utilisation de l'initiateur open-iscsi sur un système avec la prise en charge du démarrage firmware pour iSCSI (tel que iSCSI Boot Firmware ou une version de Open Firmware qui fournit la capacité de démarrage iSCSI)
Utilisation de l'initiateur open-iscsi sur un système sans prise en charge du démarrage firmware pour iSCSI.
Si vous utilisez un initiateur iSCSI matériel, vous pouvez utiliser l'utilitaire de paramétrage du BIOS de la carte pour saisir l'adresse IP et les autres paramètres requis afin d'accéder au stockage distant. Les unités logiques du stockage distant seront disponibles dans Anaconda comme des périphériques sd standards sans paramétrage supplémentaire requis.
Si vous avez besoin de déterminer le nom qualifié de l'initiateur (IQN de l'anglais "initiator's qualified name") afin de configurer le serveur de stockage distant, suivez les étapes suivantes durant l'installation :
Allez sur la page de l'installateur où vous sélectionnez le lecteur de disques à utiliser pour l'installation.
Cliquez sur .
Cliquez sur .
L'IQN iSCSI sera affiché sur cet écran.
Si vous utilisez l'initiateur logiciel open-iscsi sur un système avec la prise en charge du démarrage firmware pour iSCSI, utilisez l'utilitaire d'installation firmware pour entrer l'adresse IP et d'autres paramètres requis afin d'accéder au stockage distant. Ce faisant, vous configurez le système afin qu'il démarre à partir du stockage iSCSI distant.
Actuellement, Anaconda n'accède pas aux informations iSCSI détenues par le firmware. Vous devez donc saisir manuellement l'adresse IP cible durant l'installation. Pour ce faire, déterminez l'IQN de l'initiateur en utilisant la procédure décrite ci-dessus. Ensuite, sur la même page de l'installateur où l'IQN est affiché, spécifiez l'adresse IP de la cible iSCSI que vous voulez installer.
Après avoir spécifié manuellement l'adresse IP de la cible iSCSI, les unités logiques sur les cibles iSCSI seront disponibles pour l'installation. L'image initrd créée par Anaconda obtiendra maintenant l'IQN et l'adresse IP de la cible iSCSI.
Si plus tard, l'IQN ou l'adresse IP de la cible iSCSI change, démarrez l'utilitaire de paramétrage iBFT ou Open Firmware sur chaque initiateur et changez les paramètres correspondants. Ensuite, modifiez l'image initrd (se trouvant dans le stockage iSCSI) pour chaque initiateur comme ci-après :
Développez l'image initrd en utilisant gunzip.
Décompressez-la en utilisant la commande cpio -i.
Dans le fichier init, recherchez la ligne contenant la chaîne de caractères iscsistartup. Cette ligne contient également l'IQN et l'adresse IP de la cible iSCSI ; mettez à jour cette ligne avec le nouvel IQN et la nouvelle adresse IP.
Re-compressez l'image initrd en utilisant la commande cpio -o.
Empaquetez l'image initrd en utilisant gunzip.
La capacité du système d'exploitation à obtenir les informations iSCSI détenues par Open Firmware/iBFT firmware est planifiée pour une prochaine version. Une amélioration de la sorte permettra de ne plus avoir à modifier l'image initrd (se trouvant dans le stockage iSCSI) pour chaque initiateur, que l'IQN ou l'adresse IP de la cible iSCSI change ou non.
Si vous utilisez l'initiateur logiciel open-iscsi sur un système sans prise en charge du démarrage Firmware pour iSCSI, utilisez un outil de démarrage réseau (tel que PXE/tftp). Dans ce cas, suivez la même procédure que celle décrite précédemment afin de déterminer l'IQN de l'initiateur et spécifier l'adresse IP de la cible iSCSI. Une fois terminé, copiez l'image initrd sur le serveur de démarrage réseau et paramétrez le système pour un démarrage réseau.
De façon similaire, si l'adresse IP ou l'IQN de la cible iSCSI change, l'image initrd doit être modifiée en conséquence. Pour ce faire, utilisez la même procédure que celle décrite précédemment afin de modifier l'image initrd pour chaque initiateur.
La capacité maximale d'EXT3 est maintenant de 16To (elle a augmenté de 8 To). Cette amélioration était au départ incluse dans Red Hat Enterprise Linux 5 en tant qu'aperçu technologique. Elle est maitenant pleinement supportée dans cette mise à jour.
Il est maintenant possible de limiter yum afin d'installer uniquement des mises à jour de sécurité.
yum update --security
C'est maintenant possible de redémarrer une ressource dans un cluster sans interrompre son service parent. Cela peut être configuré dans le fichier /etc/cluster/cluster.conf sur un noeud en cours d'exécution en utilisant l'attribut __independent_subtree="1" afin de marquer une ressource comme étant indépendante.
Par exemple :
<service name="example">
<fs name="One" __independent_subtree="1" ...>
<nfsexport ...>
<nfsclient .../>
</nfsexport>
</fs>
<fs name="Two" ...>
<nfsexport ...>
<nfsclient .../>
</nfsexport>
<script name="Database" .../>
</fs>
<ip/>
</service>
Ici, deux ressources de système de fichiers sont utilisées : One et Two. Si One échoue, elle est redémarrée sans interrompre Two. Si Two échoue, tous les composants (One, les enfants de One et les enfants de Two) sont redémarrés. À aucun moment Two et ses enfants dépendent de ressources fournies par One.
Notez que Samba requiert une structure de services spécifique, ainsi il ne peut pas être utilisé dans un service avec des arborescences dépendantes. Ceci est également vrai pour d'autres ressources, utilisez donc l'attribut __independent_subtree="1" avec précaution.
Les mises à jour de virtualisation suivantes sont également incluses dans cette version :
Le noyau virtualisé peut maintenant utiliser la fonction kdump.
AMD-V est maintenant supporté dans cette version. Ceci permet la migration de domaine en direct (live) pour les invités pleinement virtualisés.
Le noyau virtualisé prend maintenant en charge jusqu'à 256Go de mémoire RAM.
L'API socket in-kernel est maintenant étendue afin de corriger un bogue qui se produisait lors de l'exécution de sctp entre les invités.
La mise en réseau virtuelle fait maintenant partie de libvirt, la bibliothèque de virtualisation. libvirt possède un ensemble de commandes qui configurent un NAT/routeur et un réseau privé pour tous les invités locaux sur une machine. Cela est particulièrement utile pour les invités qui n'ont pas besoin d'être routable depuis l'extérieur. C'est également utile pour les développeurs qui utilisent la virtualisation sur des ordinateurs portables.
Notez que la capacité de mise en réseau virtuelle ajoute une dépendance sur dnsmasq, qui manipule dhcp pour le réseau virtuel.
Pour davantage d'informations à propos de libvirt, reportez-vous à http://libvirt.org.
libvirt peut maintenant gérer les machines virtuelles inactives. libvirt fait cela en définissant et en retirant la définition des domaines sans les mettre en pause ou les arrêter. Cette fonctionnalité est similaire aux commandes virsh define et virsh undefine.
Cette amélioration permet au gestionnaire de machines virtuelles de Red Hat d'afficher tous les invités disponibles. Cela vous permet de démarrer ces invités directement à partir de l'interface graphique.
L'installation du paquetage kernel-xen ne mène plus à la création d'entrées elilo.conf incomplètes/incorrectes.
Les invités pleinement virtualisés prennent maintenant en charge les migrations "à chaud" ("hot-migration").
La commande xm create a maintenant un équivalent graphique dans virt-manager.
Nested Paging (NP) est maintenant supporté. Cette fonctionnalité réduit la complexité de la gestion de mémoire dans les environnements virtualisés. De plus, NP réduit également l'utilisation CPU pour les invités avec une mémoire intensive ("memory-intesive").
À présent, NP n'est pas activé par défaut. Si votre système supporte NP, nous vous recommandons de l'activer en démarrant l'hyperviseur avec le paramètre hap=1.
Cette mise à jour de la fonctionnalité de virtualisation inclut également la possibilité d'installer et démarrer des invités paravirtualisés 32 bits sur des hôtes 64 bits. Cependant, cette fonctionnalité est fournie en tant qu'aperçu technologique et n'est donc pas supportée dans un environnement de production.
Les tables de pages partagées sont maintenant supportées pour la mémoire hugetlb. Cela permet aux entrées des tables de pages d'être partagées entre plusieurs processus.
Le partage des entrées des tables de pages entre de multiples processus consomme moins d'espace cache. Cela améliore le ratio de connexions au cache de l'application et les performances de l'application en général.
L'option tick_divider=<value> est un paramètre sysfs qui vous permet d'ajuster l'horloge du système tout en maintenant la même valeur de temps en Hz visible aux applications de l'espace utilisateur.
L'utilisation de l'option tick_divider= vous permet de réduire la charge du CPU et d'améliorer son efficacité en diminuant la précision des opérations de temps et de profilage.
Les valeurs utiles pour l'élément <values> de l'horloge standard 1000Hz sont :
2 = 500Hz
4 = 250Hz
5 = 200Hz
8 = 125Hz
10 = 100Hz (valeur utilisée par les versions précédentes de Red Hat Enterprise Linux)
Notez que le noyau virtualisé ne supporte pas de multiples valeurs de temps sur les invités. dom0 utilise une valeur de temps fixe définie à travers tous les invités ; cela réduit la charge causée par plusieurs valeurs de temps.
Anaconda a maintenant la capacité de détecter, créer et installer les périphériques dm-multipath. Pour activer cette fonction, ajoutez le paramètre mpath à la ligne de démarrage du noyau.
Cette fonctionnalité était au départ incluse dans Red Hat Enterprise Linux 5 en tant qu'aperçu technologique. Elle est maitenant pleinement supportée dans cette mise à jour.
Notez que dm-multipath fournit également un support inbox pour le Dell MD3000. Cependant, les noeuds multiples qui utilisent dm-multipath pour accéder au MD3000 ne peuvent pas effectuer de récupérations d'erreurs immédiates.
De plus, nous vous recommandons d'utiliser l'interface de dans Anaconda si votre système possède à la fois des périphériques avec plusieurs chemins d'accès et des périphériques avec un seul chemin d'accès. L'utilisation du dans de telles situations peut causer la création de ces deux types de périphériques dans les mêmes groupes de volumes logiques.
À présent, les restrictions suivantes s'appliquent à cette fonctionnalité :
S'il n'y a qu'un seul chemin d'accès au numéro d'unité logique (LUN de l'anglais "Logical Unit Number") de démarrage, Anaconda effectue l'installation vers le périphérique SCSI, même si mpath est spécifié. Même après l'activation de plusieurs chemins d'accès au LUN de démarrage et la recréation de l'image initrd, le système d'exploitation démarrera à partir du périphérique SCSI au lieu du périphérique dm-multipath.
Cependant, s'il y a plusieurs chemins d'accès au LUN de démarrage avec lequel commencer, Anaconda effectuera l'installation correctement vers le périphérique dm-multipath correspondant après que mpath ait été spécifié dans la ligne de démarrage du noyau.
Par défaut, user_friendly_names est paramétré sur yes dans le fichier multipath.conf. Il s'agit d'un paramètre requis dans l'implémentation de la prise en charge du périphérique root dm-multipath. Ainsi, le paramétrage de user_friendly_names sur no et la recréation de l'image initrd résulteront en un échec de démarrage avec l'erreur suivante :
Checking filesystems fsck.ext3: No such file or directory while trying to open /dev/mapper/mpath0p1
La capacité à démarrer à partir d'un périphérique disque SAN est maintenant supportée. Dans ce cas, SAN se réfère à un protocole Fibre Channel ou une interface iSCSI. Cette capacité fournit également la prise en charge pour la connexion système-à-stockage à travers de multiples chemins d'accès en utilisant dm-multipath.
Dans les configurations qui utilisent plusieurs adaptateurs de bus hôte (HBA de l'anglais "host bus adapters"), vous pourriez avoir besoin de paramétrer le BIOS système afin de démarrer à partir d'un autre adaptateur si tous les chemins d'accès à travers l'adaptateur courant échouent.
nfsroot est pleinement supporté dans cette mise à jour. Cela permet aux utilisateurs de démarrer Red Hat Enterprise Linux 5.1 avec son système de fichiers root (/) monté via NFS.
nfsroot était au départ inclus dans Red Hat Enterprise Linux 5 en tant que sous-ensemble de l'aperçu technologique Stateless Linux. L'implémentation complète de Stateless Linux reste encore un aperçu technologique.
À présent, nfsroot a les restrictions suivantes :
Chaque client doit avoir son propre système de fichiers root séparé sur le serveur NFS. Cette restriction s'applique même lorsque le système de fichiers root en lecture-seule est utilisé.
SWAP n'est pas supporté sur NFS
SELinux ne peut pas être activé sur les clients nfsroot. En général, Red Hat ne recommande pas la désactivation de SELinux. Ainsi, les clients doivent être conscients des implications au niveau de la sécurité d'une telle action.
Reportez-vous à la procédure suivante quant à la façon de configurer nfsroot. Cette procédure part du principe que votre périphérique réseau est eth0 et que le pilote réseau associé est tg3. Voici les ajustements que vous pourriez avoir besoin d'effectuer :
Créer l'image initrd dans votre répertoire personnel en utilisant la commande suivante :
mkinitrd --with=tg3 --rootfs=nfs --net-dev=eth0 --rootdev=<nfs server ip>:/<path to nfsroot> ~/initrd-<kernel-version>.img <kernel-version>
Cette image initrd doit être créée en utilisant le noyau de Red Hat Enterprise Linux 5.1.
Ensuite, créez une image zImage.initrd à partir de l'initrd généré plus tôt. zImage.initrd est un noyau compressé et initrd en une seule image. Utilisez la commande suivante :
mkzimage /boot/System.map-<kernel-version> ~/initrd-<kernel-version>.img /usr/share/ppc64-utils/zImage.stub ~/zImage.initrd-<kernel-version>
Copiez l'image zImage.initrd-<kernel-version> créée vers un emplacement exportable sur votre serveur tftp.
Assurez-vous que le système de fichiers exporté nfsroot sur le serveur nfs contienne les modules et les binaires nécessaires. Ces modules et binaires doivent correspondre au noyau utilisé afin de créer l'initrd lors de la première étape.
Configurez le serveur DHCP afin qu'il dirige le client vers la cible zImage.initrd-<kernel-version>.
Pour ce faire, ajoutez les entrées suivantes dans le fichier /etc/dhcpd.conf du serveur DHCP :
next-server <tftp hostname/IP address>; filename "<tftp-path>/zImage.initrd";
Notez que <tftp-path> devrait spécifier le chemin d'accès vers zImage.initrd à partir de l'intérieur du répertoire tftp exporté. Par exemple, si le chemin d'accès absolu vers zImage.initrd est /tftpboot/mykernels/zImage.initrd et que /tftpboot/ est le répertoire tftp exporté, alors <tftp-path> devrait être mykernels/zImage.initrd.
Pour finir, définissez les paramètres de configuration du démarrage de votre système afin que celui-ci démarre en premier à partir du périphérique réseau (dans cet exemple le périphérique réseau est eth0).
GFS2 est une amélioration progressive de GFS. Cette mise à jour apporte d'importantes améliorations qui requièrent un changement dans le format du système de fichiers on-disk. Les systèmes de fichiers peuvent être convertis à GFS2 en utilisant l'utilitaire gfs2_convert, qui met à jour les méta-données d'un système de fichiers GFS en conséquence.
GFS2 était au départ inclus dans Red Hat Enterprise Linux 5 en tant qu'aperçu technologique et est maintenant pleinement supporté dans cette mise à jour. Des tests indiquent une amélioration des performances dans les secteurs suivants :
Utilisation intensive dans un seul répertoire et exploration plus rapide des répertoires (Postmark benchmark)
Opérations d'E/S synchrones (fstest indique une amélioration des performances pour les applications de messagerie telles que TIBCO)
Lecture du cache, étant donné qu'il n'y a plus de verrouillage
Opérations d'E/S directes aux fichiers pré-alloués
Boucles de traitement des fichiers NFS
df car les informations d'allocation sont maintenant mises en cache
GFS2 apporte également les changements suivants :
Les journaux sont maintenant des fichiers texte (même s'ils sont cachés) plutôt que des méta-données. Ils peuvent être ajoutés dynamiquement étant donné que les serveurs supplémentaires montent un système de fichiers.
Les quotas sont maintenant activés et désactivés par l'option de montage quota=<on|off|account>
quiesce n'est plus nécessaire sur les clusters afin d'exécuter les journaux en cas de récupération d'échecs
La référence tempotelle nanoseconde est maintenant supportée
De façon similaire à ext3, GFS2 supporte le mode data=ordered
Les paramètres des attributs lsattr() et chattr() sont maintenant supportés via le standard ioctl()
Les systèmes de fichiers dont la taille est supérieure à 16To sont maintenant supportés
GFS2 est un système de fichiers standard et peut être utilisé dans des configurations sans cluster.
Le programme de mise à jour des pilotes (DUP de l'anglais "Driver Update Program ") a été conçu pour permettre aux vendeurs tiers (tels que OEM) d'ajouter leurs propres pilotes de périphériques ainsi que d'autres noyaux Linux aux systèmes Red Hat Enterprise Linux 5 en utilisant des paquetages RPM habituels tels que les conteneurs de distribution.
Red Hat Enterprise Linux 5.1 applique plusieurs mises à jour au DUP, notamment :
Durant l'installation, les RPM de mise à jour des pilotes disponibles à travers les disques de mise à jour des pilotes sont maitenant supportés
Les mises à jour de pilotes bootpath affectant le bootpath du système sont maintenant supportés
La prise en charge de l'empaquetage tiers d'ALSA (de l'anglais "Advanced Linux Sound Architecture") est maintenant dépréciée
De plus, plusieurs mises à jour ont été apportées à la liste blanche des symboles ABI du noyau. Ces listes blanches sont utilisées par les pilotes d'empaquetage pour déterminer les structures des symboles et données fournies par le noyau qui peuvent être utilisées dans un pilote tiers.
Pour davantage d'informations, reportez-vous à http://www.kerneldrivers.org/RedHatKernelModulePackages.
acpi : module ibm_acpi mis à jour pour adresser plusieurs problèmes avec ACPI et les stations d'accueil ("docking station") pour les ordinateurs portables Lenovo.
ipmi : le sondage de kthread ne démarre plus lorsqu'une interruption matérielle est assignée à un contrôleur d'administration BMC (de l'anglais "Baseboard Management Controller").
sata : SATA/SAS mis à niveau vers la version 2.6.22-rc3.
openib et openmpi : mis à niveau vers la version 1.2 d'OFED (de l'anglais "OpenFabrics Enterprise Distribution").
powernow-k8 : mis à niveau vers la version 2.0.0 pour supporter pleinement Greyhound.
xinput : ajouté afin d'activer le support RSA.
aic94xx : mis à niveau vers la version 1.0.2-1, en accord avec une mise à niveau du firmware du séquenceur embarqué vers la version v17. Ces mises à jour apportent les changements suivants :
Correction de la condition de concurrence ascb sur les plateformes avec des extenseurs
Ajout des gestionnaires REQ_TASK_ABORT et DEVICE_RESET
Les ports physiques sont maintenant nettoyés correctement lors d'une erreur de recherche
phys peut maintenant être activé et désactivé à travers sysfs
Utilisation étendue du verrou DDB pour empêcher une condition de concurrence de DDB
Mise à jour d'ALSA vers la version 1.0.14. Cette mise à jour apporte les corrections suivantes :
Correction d'un problème sonore sur l'IBM Taroko (M50)
Realtek ALC861 est maintenant supporté
Correction d'un problème avec l'option "Muet" sur xw8600 et xw6600
ADI 1884 Audio est maintenant supporté
Correction d'un problème de configuration audio sur xw4600
Ajout de fonctions d'appel pour définir la taille maximale des requêtes de lecture pour PCIX et PCI-Express
Les machines IBM System P prennent maintenant en charge le branchement "à chaud" ("hotplugging") PCI-Express
Ajout des pilotes et PCI ID nécessaires à la prise en charge SB600 SMBus
Pilote e1000 : mis à niveau vers la version 7.3.20-k2 pour la prise en charge des puces I/OAT-enabled.
Pilote bnx2 : mis à niveau vers la version 1.5.11 pour la prise en charge du matériel 5709.
Pilote ethernet B44 : backporté à partir de la version 2.6.22-rc4 afin d'apporter les changements suivants :
Plusieurs corrections endianness ont été faites
La constante DMA_30BIT_MASK est maintenant utilisée
skb_copy_from_linear_data_offset() est maintenant utilisé
spin_lock_irqsave() fournit maintenant une désaction des interruptions plus sécurisée
Une vérification d'erreurs simple est effectuée lors de la reprise
Plusieurs corrections relatives à la multi-diffusion ont été appliquées
La réinitialisation des puces prévoit maintenant plus de temps qu'auparavant
Pilote Marvell sky2 : mis à jour pour la version 1.14 afin de corriger un bogue qui causait l'émission d'un signal "panic" si les commandes ifup/ifdown étaient exécutées à plusieurs reprises.
Pilote forcedeth-0.60 : inclus maintenant dans cette version. Ce pilote apporte plusieurs corrections de bogues critiques pour les clients utilisant des puces de cartes mère NVIDIA MCP55 et les cartes réseaux (NIC de l'anglais "Network Interface Card") correpondantes.
Pilote ixgb : mis à jour par rapport à la dernière version (1.0.126).
Pilote netxen_nic : version 3.4.2-2 ajoutée pour activer le support pour les cartes réseau NetXen 10GbE.
Le contrôleur ethernet Chelsio 10G est maintenant supporté.
Support ajouté pour la récupération des erreurs PCI pour le périphérique s2io.
Le pilote ethernet sans fil Broadcomm prend maintenant en charge PCI ID pour la carte nx6325.
Correction d'un bogue qui causait une erreur ASSERTION FAILED lors de la tentative de démarrage d'un BCM4306 via ifup.
Pilote ixgb : mis à jour pour ajouter le support de récupération d'erreurs EEH PCI pour la carte ethernet Intel 10-gigabit. Pour davantage d'informations, reportez-vous à /usr/share/doc/kernel-doc-<kernel version>/Documentation/pci-error-recovery.txt.
Pilote qla3xxx : réactivé et mis à jour pour la version 2.03.00-k3 afin de fournir une prise en charge réseau pour les adaptateurs iSCSI QLogic sans utiliser iSCSI.
Pilote réseau Intel PRO/Wireless 3945ABG : mis à jour pour la version 1.2.0. Cette mise à jour corrige plusieurs problèmes, y compris une erreur de blocage qui peut se produire sous certaines circonstances sur des ordinateurs portables.
qla2xxx : pilote mis à niveau vers la version 8.01.07-k6. Cette mise à niveau apporte plusieurs changements, notamment :
iIDMA est maintenant supporté
Les attributs suivants du canal de fibre sont maintenant supportés :
symbolic nodename
system hostname
fabric name
host port state
Les évènements asynchrones trace-control ne sont plus journalisés
La logique de gestion de la reconfiguration a été corrigée
MSI-X est maintenant supporté
Les allocations IRQ-0 sont maintenant traitées par système
Les mises à jour NVRAM prennent effet immédiatement
Cette version apporte une mise à jour du groupe de pilotes IPMI pour inclure les changements en amont de la version 2.6.21.3, avec des correctifs de la version 2.6.22-rc-4. Cette mise à jour apporte (entre autres) les changements suivants :
Correction d'un bogue lié aux données non initialisées dans ipmi_si_intf
kipmid n'est plus démarré si un autre pilote supporte les interruptions
Les utilisateurs sont maintenant autorisés à surcharger le démon noyau enable à travers force_kipmid
L'enregistrement des commandes par canal est maintenant supporté
MAX_IPMI_INTERFACES n'est plus utilisé
La suppression de l'interface système "à chaud" est maintenant supportée
Ajout d'un mode de maintenance pour prendre en charge les mises à jour firmware
Ajout de la prise en charge poweroff pour l'IPMC pigeonpoint
Le subdriver BT résiste maintenant aux longs délais d'attente
Ajout du traitement pci_remove pour un nettoyage convenable lors de suppressions "à chaud"
Pour davantage d'informations à propos des paramètres de modules, reportez-vous au fichier /usr/share/doc/kernel-doc-<kernel version>/Documentation/IPMI.txt.
La liste noire ("blacklist") SCSI a été migrée de Red Hat Enterprise Linux 4 à cette version.
Ajout des PCI ID pour le pilote aic79xx.
Pilote aacraid : mis à niveau vers la version 1.1.5-2437 pour la prise en charge PRIMERGY RX800S2 et RX800S3.
Pilote megaraid_sas : mis à jour pour la version 3.10. Cette mise à jour définit le point d'entrée pour bios_param, ajoute un ensemble de mémoire IOCTL et apporte plusieurs corrections de bogues mineures.
Pilote Emulex lpfc : mis à jour pour la version 8.1.10.9. Cette mise à jour apporte plusieurs changements, notamment :
Correction de la gestion host_lock dans les chemins d'accès ioctl
La puce AMD est maintenant détectée automatiquement et réduit la longueur DMA à 1024 bytes
Les noeuds ne sont plus supprimés durant dev_loss_tmo si la découverte est active
Les vitesses de liens à 8Go sont maintenant supportées
Pilote qla4xxx mis à jour afin d'apporter les changements suivants :
Ajout de la prise en charge d'IPV6, QLE406x et du module ioctl
Corrige un bogue mutex_lock qui pouvait causer des blocages
Corrige des problèmes de blocage de qla4xxx et qla3xxx lors de la tentative de chargement/déchargement de l'une ou l'autre de ces interfaces
Pilotes mpt fusion : mis à jour pour la version 3.04.04. Cette mise à jour apporte plusieurs changements, notamment :
Corrections de plusieurs bogues liés au traitement d'erreurs
mptsas sérialise maintenant les reconfigurations cibles
mptsas et mptfc prennent maintenant en charge les LUN (de l'anglais "Logical Unit Numbers") et cibles plus grands que 255
Correction de la régression d'un pilote mptspi LSI qui résultait en des performances très lentes du pilote DVD
Lorsqu'un périphérique LSI SCSI retourne un statut BUSY, les tentatives d'E/S n'échouent plus après plusieurs essais
Les tableaux RAID ne sont plus indisponibles après un "auto-rebuild"
Pilote arcmsr : inclut afin de fournir un support pour les contrôleurs RAID Areca.
Module 3w-9xxx : mis à jour pour prendre en charge correctement 3ware 9650SE.
Le client CIFS a été mis à jour pour la version 1.48aRH. Ceci est basé sur la version 1.48a, avec des correctifs qui apportent les changements suivants :
L'option de montage sec=none résulte en un montage anonyme
CIFS satisfait maintenant umask lorsque les extensions POSIX sont activées.
Correction des options de montage sec= qui demandent la signature de paquets
Notez que pour les utilisateurs du produit EMC Celerra (Code NAS 5.5.26.x et les versions précédentes), le client CIFS s'interrompt lorsqu'il accède à EMC NAS. Ce problème est caractérisé par les messages suivants du noyau :
kernel: CIFS VFS: server not responding kernel: CIFS VFS: No response for cmd 162 mid 380 kernel: CIFS VFS: RFC1001 size 135 bigger than SMB for Mid=384
Après un montage CIFS, il devient impossible de lire/écrire des fichiers sur ce dernier et les applications qui essaient une E/S sur le point de montage seront interrompues. Pour résoudre ce problème, faites une mise à niveau vers NAS Code 5.5.27.5 ou une version plus récente (utilisez le numéro Primus emc165978).
Les balises MODULE_FIRMWARE sont maintenant supportées.
Les contrôleurs ICH9 sont maintenant supportés.
Les processeurs Greyhound sont maintenant supportés dans les appels CPUID.
Oprofile supporte maintenant les nouveaux évènements de compteur de performance de Greyhound.
Directed DIAG est maintenant supporté afin d'améliorer l'utilisation de z/VM.
La puce graphique Intel est maintenant supportée à travers le module de noyau DRM. De plus, l'API DRM a été mise à niveau vers la version 1.3 pour prendre en charge le rendu direct.
Des mises à jour relatives à la gestion d'alimentation ACPI ont amélioré le mode S3 (suspend-to-RAM) et S4 (hibernate).
gaim est maintenant appelé pidgin.
Intel microcode mis à jour pour la version 1.17. Cela ajoute la prise en charge pour les nouveaux processeurs Intel.
Le failover implicite active-active utilisant dm-multipath sur le stockage EMC Clariion est maintenant supporté.
La police d'écriture chinoise Zysong n'est plus installée avec le paquetage fonts-chinese. Zysong est maintenant empaqueté séparément sous la forme du paquetage fonts-chinese-zysong. Le paquetage fonts-chinese-zysong se trouve sur le CD-ROM supplémentaire.
Notez que le paquetage fonts-chinese-zysong est nécessaire pour supporter le standard national chinois GB18030.
Le nom d'utilisateur et le mot de passe CHAP (de l'anglais "Challenge Handshake Authentication Protocol") ont une limite de 256 caractères.
pump est obsolète dans cette mise à jour. Ainsi, la configuration de votre interface réseau à travers netconfig peut résulter en des scripts ifcfg erronés.
Pour configurer correctement votre interface réseau, utilisez plutôt system-config-network. L'installation des paquetages system-config-network mis à jour supprime netconfig.
rpm --aid n'est plus supporté. Nous vous recommandons d'utiliser yum lors de la mise à jour et de l'installation de paquetages.
Les aperçus technologiques ne sont actuellement pas supportés par les services d'abonnement Red Hat Enterprise Linux 5.1, peuvent ne pas être fonctionnellement complets et ne sont généralement pas appropriés à une utilisation en production. Cependant, ils sont inclus pour la convenance des clients et pour fournir la fonction avec une exposition plus large.
Les clients peuvent trouver ces fonctions utiles dans un environnement qui n'est pas en production. Ils peuvent également faire des commentaires et suggestions de fonctionnalités concernant un aperçu technologique avant qu'il ne devienne pleinement supporté. Des errata seront fournis pour les problèmes de sécurité critiques.
Durant le développement d'un aperçu technologique, des portions additionnelles peuvent également être disponibles au publique pour être testées. L'intention de Red Hat est de supporter pleinement les aperçus technologiques dans une version ultérieure.
Stateless Linux est une nouvelle façon de penser à la manière dont un système doit être exécuté et géré, conçu pour simplifier le provisionnement et la gestion de grands nombres de systèmes en les rendant facilement remplaçables. Ceci est principalement accompli en établissant des images systèmes préparées qui sont répliquées et gérées sur un grand nombre de systèmes stateless (sans état), exécutant le système d'exploitation en lecture seule (veuillez vous référer à /etc/sysconfig/readonly-root pour davantage de détails).
Dans son état courant de développement, les fonctions stateless sont des sous-ensembles des objectifs souhaités. Cette capacité reçoit donc le statut d'aperçu technologique.
Voici une liste des fonctionnalités initiales incluses dans Red Hat Enterprise Linux 5 :
Exécution d'une image stateless sur NFS
Exécution d'une image stateless via loopback sur NFS
Exécution sur iSCSI
Nous recommandons fortement aux personnes voulant tester le code stateless de lire les HOWTO à l'adresse suivante : http://fedoraproject.org/wiki/StatelessLinuxHOWTO et de rejoindre la liste stateless-list@redhat.com.
Les pièces d'infrastructure nécessaires pour l'activation de Stateless linux étaient à l'origine introduites dans Red Hat Enterprise Linux 5.
AIGLX est un aperçu technologique de l'autre serveur X pleinement supporté. Il vise à activer les effets GL accélérés sur un bureau standard. Le projet consiste en ce qui suit :
Un serveur X légèrement modifié
Un paquetage Mesa mis à jour qui ajoute un nouveau support de protocole
En installant ces composants, vous pouvez avoir des effets GL accélérés sur votre bureau avec très peu de changements ainsi que la possibilité de les activer et désactiver sans remplacer votre serveur X. AIGLX active également les applications GLX distantes pour profiter de l'accélération matérielle GLX.
La pile devicescape active le pilote sans fil iwlwifi 4965GN. Cette pile permet à certains périphériques sans fil de se connecter à des réseaux Wi-Fi.
Cette pile a une base de code qui doit encore être acceptée en amont. De plus, la stabilité de cette pile doit être vérifiée à travers des tests. Ainsi, cette pile est incluse dans cette version en tant qu'aperçu technologique.
FS-Cache est un service local de mise en cache pour les systèmes de fichiers distants qui permet aux utilisateurs de mettre en cache des données NFS sur un disque monté localement. Pour configurer le service FS-Cache, installez le RPM cachefilesd et référez-vous aux instructions dans /usr/share/doc/cachefilesd-<version>/README.
Remplacez <version> par la version correspondante du paquetage cachefilesd installé.
Systemtap fournit une infrastructure logicielle libre (GPL) pour simplifier le rassemblement d'informations d'un système Linux en cours d'exécution. Cela assiste les diagnostiques d'un problème de performance ou fonctionnel. Avec l'aide de systemtap, les développeurs n'ont plus besoin de se soumettre aux cycles fastidieux et perturbateurs de recompilation, installation et de redémarrage des séquences qui peuvent être requis pour collecter les données.
Le framework cible Linux (tgt) permet à un système de servir le stockage SCSI de niveau bloc à d'autres systèmes qui ont un initiateur SCSI. Cette capacité a été initialement déployée en tant que cible iSCSI Linux, servant le stockage via un réseau à n'importe quel initiateur iSCSI.
Pour paramétrer la cible iSCSI, installez le RPM scsi-target-utils et reportez-vous aux instructions dans :
/usr/share/doc/scsi-target-utils-<version>/README
/usr/share/doc/scsi-target-utils-<version>/README.iscsi
Remplacez <version> par la version correspondante du paquetage installé.
Pour davantage d'informations, reportez-vous à man tgtadm.
Le module firewire-sbp2 est inclus dans cette mise à jour en tant qu'aperçu technologique. Ce module active la connectivité avec les scanners et périphériques de stockage FireWire.
Actuellement, FireWire ne supporte pas ce qui suit :
IPv4
Les contrôleurs de l'hôte pcilynx
Les périphériques de stockage multi-LUN
Les accès non-exclusif aux périphériques de stockage
De plus, les problèmes suivants existent encore dans la version de FireWire :
Une perte de mémoire dans le pilote SBP2 peut faire en sorte que la machine ne réponde plus.
Un code dans cette version ne fonctionne pas correctement avec les machines big-endian. Cela peut provoquer des comportements inattendus avec PowerPC.
Un bogue SATA, qui causait la mise en pause des systèmes équipés SATA durant le processus de démarrage et l'affichage d'une erreur avant la reprise des systèmes, a été corrigé.
Sur les systèmes à démarrages multiples, parted préserve maintenant le secteur de démarrage de la première partition primaire où Windows Vista™ est installé. Ainsi, lors de la configuration d'un système à démarrages multiples avec Red Hat Enterprise Linux 5.1 et Windows Vista™, le dernier est démarrable.
rmmod xennet ne provoque plus le plantage de domU
Les systèmes Sun Blade X8400 Server Module 4-socket AMD qui n'ont pas la mémoire configurée dans node 0 n'émettent plus de signal "panic" durant le démarrage.
conga et luci peuvent maintenant être utilisés afin de créer et configurer les domaines failover.
Lors de l'installation du groupe Cluster Storage à travers yum, la transaction n'échoue plus.
Durant l'installation, les contextes SELinux incorrects ne sont plus assignés à /var/log/faillog et /var/log/tallylog.
L'installation de Red Hat Enterprise Linux 5.1 en utilisant un média d'installation partagé (par exemple, un CD-ROM ou NFSISO) ne cause plus d'erreurs lors de l'installation d'amanda-server.
EDAC reporte maintenant la quantité correcte de mémoire sur les derniers processeurs k8.
La connexion distante au bureau Gnome via gdm ne provoque plus l'interruption de l'écran de connexion.
Un bogue autofs qui empêchait le bon fonctionnement des montages multiples a été résolu.
Le démarrage de tvtime et xawtv avec le module noyau bttv ne cause plus l'arrêt du système.
Plusieurs correctifs en rapport à utrace résolvent les problèmes suivants :
Correction d'un bogue qui causait un plantage en condition de concurrence lors de l'utilisation de ptrace
Correction d'une régression qui résultait en un retour EIO erroné à partir de certains appels PTRACE_PEEKUSR
Correction d'une régression qui empêchait le déclenchement de certains appels wait4 lorsqu'un processus enfant se terminait sous certaines circonstances
Correction d'une régression qui empêchait parfois SIGKILL de terminer un processus. Cela se produisait si ptrace était exécuté sur un processus sous certaines circonstances.
Un bogue RTC (de l'anglais "RealTime Clock"), qui empêchait les alarmes et interruptions RTC périodiques de fonctionner correctement, a été corrigé.
Lorsqu'un utilisateur cliquait pour la première fois sur le bouton des dans Anaconda, un délai se produisait pendant l'affichage. Durant ce délai, une liste vide s'affichait dans la fenêtre. En principe l'affichage apparaît rapidement, il se peut donc que les utilisateurs n'aient pas remarqué ce problème.
Le délai est en grande partie dû au fait que la phase d'installation des paquetages est la phase qui demande le plus de ressources CPU.
Certaines machines qui utilisent des cartes graphiques NVIDIA peuvent afficher des graphismes ou des polices corrompus lors de l'utilisation de l'installateur graphique ou durant une connexion graphique. Pour contourner ce problème, basculez vers une console virtuelle puis retournez vers l'hôte X d'origine.
Les adaptateurs de bus hôte qui utilisent le pilote MegaRAID doivent être configurés pour opérer dans un mode d'émulation "Mass Storage" et non pas dans un mode d'émulation "I2O". Pour ce faire, accomplissez les étapes suivantes :
Entrez dans le MegaRAID BIOS Set Up Utility (utilitaire d'installation du BIOS).
Entrez dans le Adapter settings menu (menu des paramètres de l'adaptateur).
Sous Other Adapter Options, sélectionnez Emulation et mettez Mass Storage.
Si l'adaptateur est incorrectement configuré avec une émulation "I2O", le système essayera de charger le pilote i2o. Cela échouera et empêchera le chargement du pilote approprié.
Généralement, les versions précédentes de Red Hat Enterprise Linux n'essaient pas de charger le pilote I2O avant le pilote MegaRAID. Indépendamment de cela, le matériel devrait toujours être configuré en mode émulation "Mass Storage" quand il est utilisé avec Linux.
Les ordinateurs portables qui sont équipés de cartes sans fil Cisco Aironet MPI-350 peuvent s'interrompre lorsqu'ils essaient d'obtenir une adresse DHCP durant une installation réseau utilisant le port ethernet (wired ethernet).
Pour contourner ce problème, utilisez un média local pour votre installation. Autrement, vous pouvez désactiver la carte sans fil dans le BIOS de l'ordinateur portable avant l'installation (vous pouvez réactiver la carte sans fil après avoir terminé l'installation).
Actuellement, system-config-kickstart ne supporte pas la sélection et la désélection de paquetages. Lors de l'utilisation de system-config-kickstart, l'option Package Selection indique que la sélection et la désélection sont désactivées. Ceci est dû à system-config-kickstart qui utilise yum pour rassembler les informations de groupe mais qui n'est pas capable de le configurer pour se connecter à Red Hat Network.
Pour le moment, vous devez mettre à jour la section des paquetages manuellement dans vos fichiers kickstart. Lorsque vous utilisez system-config-kickstart pour ouvrir un fichier kickstart, il conserve toutes les informations des paquetages et les réécrit lorsque vous enregistrerez.
La journalisation lors du démarrage vers /var/log/boot.log n'est pas disponible dans cette version de Red Hat Enterprise Linux 5. Une fonctionnalité équivalente sera ajoutée dans une version ultérieure.
Lors de la mise à niveau de Red Hat Enterprise Linux 4 vers Red Hat Enterprise Linux 5, le guide déploiement n'est pas installé automatiquement. Vous devez utiliser pirut pour l'installer manuellement lorsque l'installation est terminée.
Si X est démarré et qu'il n'utilise pas le pilote vesa, le système peut ne pas redémarrer correctement dans un noyau kexec/kdump. Ce problème existe uniquement avec les puces graphiques ATI Rage XL.
Si X est démarré sur un système équipé d'une puce ATI Rage XL, assurez-vous qu'il utilise le pilote vesa afin qu'il puisse redémarrer correctement dans un noyau kexec/kdump.
L'installation de la fonction de virtualisation peut générer un avertissement time went backwards sur les systèmes HP avec les numéros de modèle xw9300 et xw9400.
Pour contourner ce problème sur les machines xw9400, configurez les paramètres du BIOS pour activer le minuteur HPET. Notez que cette option n'est pas disponible sur les machines xw9300.
Cela sera résolu dans une mise à jour ultérieure du BIOS par HP
Lors de l'utilisation de Red Hat Enterprise Linux 5 sur une machine avec un chipset nVidia CK804 installé, vous pourriez recevoir des messages du noyau similaires à ceux-ci :
kernel: assign_interrupt_mode Found MSI capability kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Ces messages indiquent que certains ports PCI-E ne requêtent pas IRQ. En plus, ces messages n'affectent en aucun cas l'opération de la machine.
Les périphériques de stockage amovibles (tels que les CD-ROM et DVD) ne sont pas montés automatiquement lorsque vous êtes connecté en tant que root. Ainsi, vous devrez monter le périphérique manuellement à travers le gestionnaire de fichiers graphique.
Autrement, vous pouvez exécuter la commande suivante pour monter un périphérique vers /media :
mount /dev/<device name> /media
La puce Calgary IOMMU n'est pas supportée par défaut dans cette mise à jour. Pour activer le support pour cette puce, utilisez l'option en ligne de commande du noyau iommu=calgary.
IBM System z ne fournit pas une console physique de style Unix traditionnelle. Ainsi, Red Hat Enterprise Linux 5 pour IBM System z ne supporte pas la fonctionnalité firstboot durant le chargement initial des programmes.
Pour initialiser correctement l'installation de Red Hat Enterprise Linux 5 sur IBM System z, exécutez les commandes suivantes après l'installation :
/usr/bin/setup — fourni par le paquetage setuptool.
/usr/bin/rhn_register — fourni par le paquetage rhn-setup.
Lors de la mise à niveau à partir de Red Hat Enterprise Linux 5 vers Red Hat Enterprise Linux 5.1 via Red Hat Network, yum pourrait ne pas vous demander d'importer la clé redhat-beta. Ainsi, nous vous conseillons d'importer la clé redhat-beta manuellement afin d'effectuer la mise à niveau. Pour ce faire, exécutez la commande suivante :
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta
Lorsqu'un LUN est détecté sur un filer configuré, le changement n'est pas reflété sur l'hôte. Dans de telles situations, les commandes lvm sont interrompues indéfiniment lorsque dm-multipath est utilisé, étant donné que le LUN est maintenant devenu stale.
Pour contourner ce problème, supprimez tous les entrées relatives aux périphériques et liens mpath dans le fichier /etc/lvm/.cache spécifique au LUN stale.
Pour découvrir quelles sont ces entrées, exécutez la commande suivante :
ls -l /dev/mpath | grep <stale LUN>
Par exemple, si <stale LUN> est 3600d0230003414f30000203a7bc41a00, les résultats suivants peuvent apparaître :
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4 lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
Cela signifie que 3600d0230003414f30000203a7bc41a00 est mappé à deux liens mpath : dm-4 et dm-5.
Ainsi, les lignes suivantes devraient être supprimées à partir de /etc/lvm/.cache :
/dev/dm-4 /dev/dm-5 /dev/mapper/3600d0230003414f30000203a7bc41a00 /dev/mapper/3600d0230003414f30000203a7bc41a00p1 /dev/mpath/3600d0230003414f30000203a7bc41a00 /dev/mpath/3600d0230003414f30000203a7bc41a00p1
Lorsque vous essayez de créer un serveur Windows™ 2003 pleinement virtualisé à partir d'un CD-ROM ou DVD-ROM, il se peut que la deuxième étape de l'installation de l'invité ne continue pas sur un redémarrage.
Pour contourner ce problème, modifiez /etc/xen/<name of guest machine> en annexant correctement une entrée pour le CD-ROM/DVD.
Si l'installation avec un seul fichier est utilisée comme un périphérique virtuel, la ligne disk de /etc/xen/<name of guest machine> ressemblera à ce qui suit :
disk = [ 'file:/PATH-OF-SIMPLE-FILE,hda,w']
Un DVD se trouvant sur l'hôte, tel que /dev/dvd, peut être rendu disponible à l'étape 2 de l'installation en tant que hdc en ajoutant une entrée comme 'phy:/dev/dvd,hdc:cdrom,r'. Ainsi, la ligne du disque devrait maintenant ressembler à ce qui suit :
disk = [ 'file:/opt/win2003-sp1-20061107,hda,w', 'phy:/dev/dvd,hdc:cdrom,r']
Le chemin exact du périphérique à utiliser peut varier en fonction de votre matériel.
Si le module sctp n'est pas ajouté au noyau, le démarrage de netstat avec l'option -A inet ou -A inet6 s'arrêtera de façon anormale et produira le message suivant :
netstat: no support for `AF INET (sctp)' on this system.
Pour éviter cela, installez le module de noyau sctp.
L'installation de Red Hat Enterprise Linux 3.9 sur un invité pleinement virtualisé peut être extrêmement lente. De plus, le démarrage de l'invité après l'installation peut produire des erreurs hda: lost interrupt.
Pour éviter cette erreur de démarrage, configurez l'invité pour qu'il utilise le noyau SMP.
Les noyaux actuels ne certifient pas les signaux DTR (de l'anglais "Data Terminal Ready") avant l'impression vers des ports séries durant le démarrage. La certification DTR est requise par certains périphériques ; ainsi, les messages de démarrage du noyau ne sont pas imprimés vers les consoles en série sur de tels périphériques.
La mise à niveau d'un système hôte (dom0) vers Red Hat Enterprise Linux 5.1 peut rendre les invités paravirtualisés SMP Red Hat Enterprise Linux 4.5 existants indémarrables. Ceci se produit généralement lorsque le système hôte a plus de 4Go de mémoire RAM.
Pour contourner ce problème, démarrez chaque invité Red Hat Enterprise Linux 4.5 en mode CPU seul et mettez à jour son noyau avec la dernière version (pour Red Hat Enterprise Linux 4.5.z).
Les puces AMD 8132 et HP BroadCom HT100 utilisées sur certaines plateformes (par exemple la plateforme HP dc7700) ne supportent pas les cycles MMCONFIG. Si votre système utilise une puce de ce type, votre configuration PCI devrait utiliser le mécanisme d'héritage PortIO CF8/CFC. Pour configurer cela, démarrez le système avec le paramètre de noyau -pci nommconfig durant l'installation et ajoutez pci=nommconf à GRUB après le redémarrage.
De plus, la puce AMD 8132 ne supporte pas les interruptions MSI (de l'anglais "Message Signaled Interrupts"). Si votre système utilise cette puce, vous devriez désactiver MSI. Pour ce faire, utilisez le paramètre de noyau -pci nomsi durant l'installation et ajoutez pci=nomsi à GRUB après le redémarrage.
Cependant, si votre plateforme spécifique est déjà mise en liste noire par le noyau, votre système ne requiert pas les paramètres de noyau pci susmentionnés. Les plateformes HP suivantes sont déjà mises en liste noire par le noyau :
DL585g2
dc7500
xw9300
xw9400
Le Gestionnaire de machines virtuelles (virt-manager) inclus dans cette version ne permet pas aux utilisateurs de spécifier des arguments de démarrage supplémentaires à l'installateur d'invités paravirtualisés. Ceci est vrai même lorsque de tels arguments sont requis pour l'installation de certains types d'invités paravirtualisés sur des types de matériels spécifiques.
Ce problème sera adressé dans une version ultérieure de virt-manager. Pour spécifier des arguments de noyau arbitraires en ligne de commande dans l'installation d'invités paravirtualisés, utilisez virt-install.
Avec la configuration par défaut dm-multipath, les périphériques Netapp peuvent prendre plusieurs minutes avant de terminer un failback, après que l'échec d'un chemin d'accès soit restauré. Pour résoudre ce problème, ajoutez la configuration de périphériques Netapp suivante au niveau de la section devices du fichier multipath.conf :
devices {
device {
vendor "NETAPP"
product "LUN"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_netapp /dev/%n"
features "1 queue_if_no_path"
hardware_handler "0"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
rr_min_io 128
path_checker directio
}
( amd64 )
[1] Ce matériel peut être distribué uniquement conformément aux termes et conditions présentés dans la Licence de Publication Ouverte, v1.0, disponible à http://www.opencontent.org/openpub/.