Introduction

Les sujets suivants sont abordés dans ce document :

  • Release Notes Updates

  • 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/

Release Notes Updates

This section contains information about Red Hat Enterprise Linux 5.1 that did not make it into the Release Notes included in the distribution.

  • Virtualization does not work on architectures that use Non-Uniform Memory Access (NUMA). As such, installing the virtualized kernel on systems that use NUMA will result in a boot failure.

    Some installation numbers install the virtualized kernel by default. If you have such an installation number and your system uses NUMA (or cannot disable NUMA), deselect the Virtualization option during installation.

  • This release includes WBEMSMT, a suite of web-based applications that provides a user-friendly management interface for Samba and DNS. For more information about WBEMSMT, refer to http://sblim.wiki.sourceforge.net/.

  • Upgrading pm-utils from a Red Hat Enterprise Linux 5.1 Beta version of pm-utils will fail, resulting in the following error:

    error: unpacking of archive failed on file /etc/pm/sleep.d: cpio: rename
    

    To prevent this from occurring, delete the /etc/pm/sleep.d/ directory prior to upgrading. If /etc/pm/sleep.d contains any files, you can move those files to /etc/pm/hooks/.

  • Using the ipath in this architecture may result in openmpi crashes. As such, the ipath driver is currently released for this architecture as Technology Preview.

  • Hardware testing for the Mellanox MT25204 has revealed that an internal error occurs under certain high-load conditions. When the ib_mthca driver reports a catastrophic error on this hardware, it is usually related to an insufficient completion queue depth relative to the number of outstanding work requests generated by the user application.

    Although the driver will reset the hardware and recover from such an event, all existing connections are lost at the time of the error. This generally results in a segmentation fault in the user application. Further, if opensm is running at the time the error occurs, then it will have to be manually restarted in order to resume proper operation.

  • Driver Update Disks now support Red Hat's Driver Update Program RPM-based packaging. If a driver disk uses the newer format, it is possible to include RPM packaged drivers that will be preserved across system updates.

    Please note that driver RPMs are copied only for the default kernel variant that is in use on the installed system. For example, installing a driver RPM on a system running the virtualized kernel will install the driver only for the virtualized kernel. The driver RPM will not be installed for any other installed kernel variant in the system.

    As such, on a system that has multiple kernel variants installed, you will need to boot the system on each kernel variant and install the driver RPM. For example, if your system has both bare-metal and virtualized kernels installed, boot your system using the bare-metal kernel and install the driver RPM. Then, reboot the system into the virtualized kernel and install the driver RPM again.

  • During the lifetime of dom0, you cannot create guests (i.e. xm create) more than 32,750 times. For example, if you have guests rebooting in a loop, dom0 will fail to boot any guest after rebooting guests a total of 32,750 times.

    If this event occurs, restart dom0

  • Virtualization in this architecture can only support guests with a maximum RAM of 65,434 MB.

  • The Red Hat Enterprise Linux 5.1 NFS server now supports referral exports. These exports are based on extensions to the NFSv4 protocol. Any NFS clients that do not support these extensions (namely, Red Hat Enterprise Linux releases prior to 5.1) will not be able to access these exports.

    As such, if an NFS client does not support these exports, any attempt to access these exports may fail with an I/O error. In some cases, depending on the client implementation, the failure may be more severe, including the possibility of a system crash.

    It is important that you take precautions to ensure that NFS referral exports are not accessed by clients that do not support them.

  • 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.

    While much improved since its introduction in Red Hat Enterprise Linux 5, GFS2 remains a Technology Preview. The release notes included in the distribution incorrectly states that GFS2 is fully supported. Nevertheless, benchmark tests indicate faster performance on the following:

    • 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.

  • Installing Red Hat Enterprise Linux 5.1 on HP BL860c blade systems may hang during the IP information request stage. This issue manifests when you have to select OK twice on the Configure TCP/IP screen.

    If this occurs, reboot and perform the installation with Ethernet autonegotiation disabled. To do this, use the parameter ethtool="autoneg=off" when booting from the installation media. Doing so does not affect the final installed system.

  • The nohide export option is required on referral exports (i.e. exports that specify a referral server). This is because referral exports need to "cross over" a bound mount point. The nohide export option is required for such a "cross over" to be successful.

    For more information on bound mounts, refer to man exports 5.

  • This update includes the lvm2 event monitoring daemon. If you are already using lvm2 mirroring, perform the following steps to ensure that all monitoring functions are upgraded properly:

    1. Deactivate all mirrored lvm2 logical volumes before updating. To do this, use the command lvchange -a n <volume group or mirrored volume>.

    2. Stop the old lvm2 event daemon using killall -HUP dmeventd.

    3. Perform the upgrade of all related RPM packages, namely device-mapper and lvm2.

    4. Reactivate all mirrored volumes again using lvchange -a y <volume group or mirrored volume>.

  • Rapid Virtualization Indexing (RVI) is now supported on 64-bit, 32-bit, and 32-bit PAE kernels. However, RVI can only translate 32-bit guest virtual addresses on the 32-bit PAE hypervisor.

    As such, if a guest is running a PAE kernel with more than 3840MB of RAM, a wrong address translation error will occur. This can crash the guest.

    It is recommended that you use the 64-bit kernel if you intend to run guests with more than 4GB of physical RAM under RVI.

  • Running 16 cores or more using AMD Rev F processors may result in system resets when performing fully-virtualized guest installations.

  • If your system uses a P600 SmartArray controller, a machine check error may occur while running the virtualized kernel. When this occurs, dom0 will reboot.

    To prevent this, run the following shell script at the beginning of each boot:

    #!/bin/bash
    for x in $(lspci -d 103c:3220 | awk '{print $1}'); do
            val=$(setpci -s $x 40.b)
            val=$(( 0x$val | 1 ))
    setpci -s $x 40.b=$(printf '%x' $val)
    done        
    
  • If you encounter a guest installation failure, it is recommended that you restart the xend daemon before attempting to install a new guest.

  • Installing the systemtap-runtime package will result in a transaction check error if the systemtap package is already installed. Further, upgrading Red Hat Enterprise Linux 5 to 5.1 will also fail if the systemtap package is already installed.

    As such, remove the systemtap package using the command rpm -e systemtap-0.5.12-1.e15 before installing systemtap-runtime or performing an upgrade.

  • Kernel modules such as e1000 and qla2xxx cannot be unloaded if you are running the virtualized kernel.

    As such, if you install any third-party drivers, it is recommended that you reboot the system.

  • Paravirtualized guests cannot use the parted utility. To change disk partitionsing on paravirtualized guests, use parted within dom0 on the guest's disk; for example, parted /var/lib/xen/images/pv_guest_disk_image.img.

  • When setting up NFSROOT, BOOTPROTO must be set as BOOTPROTO=dhcp in /etc/sysconfig/network-scripts/ifcfg-eth0.

    If your environment requires a different setting for BOOTPROTO, then temporarily set BOOTPROTO=dhcp in /etc/sysconfig/network-scripts/ifcfg-eth0 before initially creating the initrd. You can reset the original value of BOOTPROTO after the initrd is created.

  • When attempting to create a fully-virtualized guest, the hypervisor may hang if you allocate too much of available RAM to the guest. In some cases, a kernel panic may occur.

    Both events are caused by hypervisor memory shortage. To ensure that hypervisor overhead is accounted for each time you allocate memory to a guest, consider the following equation:

    26MB + [(number of virtual CPUs used by guest) x 17MB] = (amount of memory to be left unallocated for each existent guest)

    For example, if you have 2048MB of RAM on your system and you intend to use 4 virtual CPUs for only one guest, you should leave 94MB unallocated. If you intend to have two guests, both using 4 virtual CPUs, leave 188MB unallocated (and so on).

  • Currently, live migration of fully virtualized guests is not supported on this architecture. The release notes included in the distribution incorrectly states that it is.

    In addition, kexec and kdump is also not supported for virtualization in this architecture.

  • Crash dumping through kexec and kdump may not function reliably with HP Smart Array controllers. Note that these controllers use the cciss driver.

    A solution to this problem, which is likely to involve a firmware update to the controller, is being investigated.

  • The QLogic iSCSI Expansion Card for the IBM Bladecenter provides both ethernet and iSCSI functions. Some parts on the card are shared by both functions. However, the current qla3xxx and qla4xxx drivers support ethernet and iSCSI functions individually. Both drivers do not support the use of ethernet and iSCSI functions simultaneously.

    As such, using both ethernet and iSCSI functions simultaneously may hang the device. This could result in data loss and filesystem corruption on iSCSI devices, or network disruptions on other connected ethernet devices.

  • When using virt-manager to add disks to an existing guest, duplicate entries may be created in the guest's /etc/xen/<domain name> configuration file. These duplicate entries will prevent the guest from booting.

    As such, you should remove these duplicate entries.

  • Repeatedly migrating a guest between two hosts may cause one host to panic. If a host is rebooted after migrating a guest out of the system and before migrating the same guest back, the panic will not occur.

  • sysreport is being deprecated in favor of sos. To install sos, run yum install sos. This command installs sos and removes sysreport. It is recommended that you update any existing kickstart files to reflect this.

    After installing sos, use the command sosreport to invoke it. Using the command sysreport generates a warning that sysreport is now deprecated; continuing will invoke sosreport.

    If you need to use the sysreport tool specifically, use the command sysreport.legacy to invoke it.

    For more information about sosreport, refer to man sosreport and sosreport --help.

Notes concernant l'installation

La section suivante contient des informations spécifiques à l'installation de Red Hat Enterprise Linux 5.1 et au programme d'installation Anaconda.

To upgrade an already-installed Red Hat Enterprise Linux 5, you can use Red Hat Network to update those packages that have changed.

You may also use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 5.1 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 5.1. Anaconda can also be used to upgrade an already-installed Red Hat Enterprise Linux 5.

  • Red Hat Enterprise Linux 5.1 pour l'architecture Intel Itanium2 64 bits inclut la prise en charge lors de l'exécution des applications 32 bits au moyen de la couche d'exécution d'Intel baptisée IA-32 Execution Layer.

    La couche d'exécution nommée IA-32 Execution Layer est fournie sur le disque supplémentaire pour l'architecture Intel Itanium2. De plus, un ensemble de bibliothèques et d'applications 32 bits est fourni sur un disque séparé pour la couche de compatibilité 32 bits (32-bit Compatibility Layer). IA-32 Execution Layer et les paquetages de compatibilité 32 bits fournissent ensemble un environnement d'exécution pour les applications 32 bits sur la distribution native 64 bits.

    Pour installer IA-32 Execution Layer et les paquetages de compatibilité 32 bits requis, suivez les étapes suivantes :

    1. Installez Red Hat Enterprise Linux 5.1 pour l'architecture Intel Itanium2.

    2. Insérez le CD-ROM supplémentaire de Red Hat Enterprise Linux 5.1 qui contient le paquetage ia32el.

    3. Une fois que le système a monté le CD-ROM, passez dans le répertoire qui contient les paquetages supplémentaires. Par exemple :

      cd /media/cdrom/Supplementary/

    4. Installez le paquetage ia32el :

      rpm -Uvh ia32el-<version>.ia64.rpm

      Remplacez <version> par la version correspondante du paquetage ia32el à installer.

    5. Éjectez le CD-ROM supplémentaire :

      eject /media/cdrom

    6. Pour vérifier l'installation de la couche de compatibilité et des bibliothèques 32 bits après l'installation, vérifiez que le répertoire /emul a été créé et qu'il contient bien des fichiers.

    7. Pour vérifier que le mode de compatibilité 32 bits est bien en place, saisissez la commande suivante à une invite du shell :

      service ia32el status

    8. À ce stade, vous pouvez installer les bibliothèques de compatibilité en insérant le disque pour la couche de compatibilité 32 bits. Vous pouvez choisir d'installer tous les paquetages disponibles sur le disque ou choisir des paquetages spécifiques, requis pour fournir une prise en charge pour des applications 32 bits lors de l'exécution.

  • 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.

  • If you are using the Virtualized kernel when upgrading from Red Hat Enterprise Linux 5 to 5.1, you must reboot after completing the upgrade. You should then boot the system using the updated Virtualized kernel.

    The hypervisors of Red Hat Enterprise Linux 5 and 5.1 are not ABI-compatible. If you do not boot the system after upgrading using the updated Virtualized kernel, the upgraded Virtualization RPMs will not match the running kernel.

Installation/Démarrage pour l'initiateur logiciel iSCSI (open-iscsi)

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.

Utilisation de l'initiateur iSCSI matériel

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 :

  1. Allez sur la page de l'installateur où vous sélectionnez le lecteur de disques à utiliser pour l'installation.

  2. Cliquez sur Configuration avancée du stockage.

  3. Cliquez sur Ajouter une cible iSCSI.

  4. L'IQN iSCSI sera affiché sur cet écran.

Utilisation d'open-iscsi sur un système avec la prise en charge du démarrage Firmware pour iSCSI.

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 :

  1. Développez l'image initrd en utilisant gunzip.

  2. Décompressez-la en utilisant la commande cpio -i.

  3. 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.

  4. Re-compressez l'image initrd en utilisant la commande cpio -o.

  5. 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.

Utilisation d'open-iscsi sur un système sans prise en charge du démarrage Firmware pour iSCSI.

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.

Mises à jour de fonctionnalités

Amélioration pour EXT3

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.

yum-security

Il est maintenant possible de limiter yum afin d'installer uniquement des mises à jour de sécurité.

yum update --security

Redémarrage d'une ressource de façon indépendante

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.

Virtualisation

Les mises à jour de virtualisation suivantes sont également incluses dans cette version :

  • AMD-V est maintenant supporté dans cette version. Ceci permet la migration de domaine en direct (live) pour les invités pleinement virtualisés.

  • 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.

  • DomU n'émet plus de signal "panic" lorsque vous effectuez l'action sauvegarder/restaurer plusieurs fois après une compilation du noyau.

  • 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.

La virtualisation est pleinement supportée dans cette mise à jour. Cette fonctionnalité était à l'origine un aperçu technologique dans Red Hat Enterprise Linux 5.

Notez, cependant, que l'installation de Red Hat Enterprise Linux 5 sur un invité provoquera l'interruption de l'invité et une erreur de l'hôte, même si l'hôte possède Red Hat Enterprise Linux 5.1. Ainsi, Red Hat Enterprise Linux 5 n'est pas supporté en tant qu'invité dans cette architecture. Les invités Red Hat Enterprise Linux doivent être en version 5.1 ou une version plus récente.

Tables de pages partagées

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.

Installation des périphériques dm-multipath

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 Partitionnement personnalisé 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 Partitionnement automatique 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
    
Démarrage à partir d'un réseau de stockage (SAN de l'anglais "Storage Area Network")

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.

Programme de mise à jour des pilotes

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.

Mises à jour de pilotes

Mises à jour générales des pilotes
  • 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

Audio

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

PCI
  • 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

Réseau
  • 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.

  • 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

IPMI

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.

SCSI
  • 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.

Mises à jour relatives au noyau

  • 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.

  • L'appel système getcpu est maintenant supporté.

  • 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).

Autres mises à jour

  • gaim est maintenant appelé pidgin.

  • La limite de mémoire certifiée pour l'architecture est maintenant 1To (au lieu de 256Go).

  • 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.

Aperçus technologiques

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

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

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.

FS-Cache

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

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.

Cible iSCSI

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.

FireWire

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.

Problèmes résolus

  • 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.

  • 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 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é.

Problèmes connus

  • Lorsqu'un utilisateur cliquait pour la première fois sur le bouton des Notes de mise à jour 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.

  • 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 :

    1. Entrez dans le MegaRAID BIOS Set Up Utility (utilitaire d'installation du BIOS).

    2. Entrez dans le Adapter settings menu (menu des paramètres de l'adaptateur).

    3. 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.

  • 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.

  • L'utilisation de yum pour installer des paquetages à partir du disque pour la couche de compatibilité 32 bits peut échouer. Si c'est le cas, c'est parce que la clé de signature du paquetage Red Hat n'a pas été importée dans la base de données RPM. Cela se produit si vous ne vous êtes pas encore connecté à Red Hat Network et que vous n'avez pas obtenu les mises à jour. Pour importer la clé manuellement, exécutez la commande suivante en tant que root :

    rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    

    Une fois que la clé GPG Red Hat est importée, vous pouvez utiliser yum pour installer les paquetages à partir du disque pour la couche de compatibilité 32 bits.

    Notez que durant l'installation à partir de ce disque, nous vous conseillons d'utiliser yum à la place de rpm afin de vous assurer que les dépendances OS de base soient résolues durant l'installation.

  • 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
    
  • 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.

  • 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.

  • 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.

  • Par défaut, le noyau virtualisé Itanium dom0 démarre avec 512Mo de mémoire RAM et un CPU. Vous pouvez surcharger ces valeurs sur la ligne de commande de l'hyperviseur en utilisant les paramètres dom0_mem et dom0_max_vcpus. Par exemple, vous pouvez paramétrer dom0 pour qu'il démarre avec 4Go de mémoire RAM et 8 CPU en utilisant les paramètres dom0_mem=4G dom0_max_vcpus=8.

    Avec Red Hat Enterprise Linux 5, la valeur maximale supportée pour dom0_mem est 256Go. La valeur maximale supportée pour dom0_max_vcpus est 32.

    Cependant, paramétrer dom0 pour démarrer avec la quantité réelle de mémoire RAM que le système possède peut provoquer un signal "panic". Ceci est dû au fait que la mémoire RAM que dom0 peut utiliser n'est probablement pas entièrement disponible. À présent, l'hyperviseur n'est pas capable de traiter cette situation de façon élégante.

    Ainsi, si le système a une quantité x de mémoire RAM, nous ne vous recommandons pas d'utiliser dom0_mem=x.

  • Sur certains systèmes Itanium configurés pour une sortie console sur VGA, le noyau virtualisé dom0 pourrait ne pas démarrer. Cela est dû au noyau virtualisé qui n'a pas su détecter correctement le périphérique console par défaut à partir des paramètres EFI (de l'anglais Extensible Firmware Interface).

    Lorsque cela se produit, vous pouvez contourner ce problème en ajoutant le paramètre de démarrage mem=3000m aux options de démarrage du noyau dans le fichier /boot/efi/elilo.conf.

  • Sur certains systèmes Itanium, X ne démarre pas sur la console VGA. Ceci est dû à la disposition de la mémoire système qui n'empêche pas à X la tentative d'utilisation de zones mémoire incompatibles à ses besoins. Ceci peut causer un MCA (de l'anglais "Machine Check Abort"), alors que dans certains cas X échouera simplement avec une entrée de journalisation X de xf86MapDomainMem(): mmap() failure.

    Il est recommandé de démarrer les systèmes affectés avec le niveau d'exécution 3, et les applications X nécessaires devraient être démarrées à l'intérieur d'un serveur X VNC ou par X11-forwarding sur un hôte distant. Les noyaux virtualisés et bare-metal sont affectés par ce problème.

    Ce problème sera corrigé dans une mise à jour ultérieure de Red Hat Enterprise Linux 5. Les résultats des tests confirment que ce problème devrait seulement se manifester sur les systèmes Itanium disposant de plus de 128 périphériques PCI. Ce comportement est cohérent avec X sur Red Hat Enterprise Linux 5.

  • 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
            }
    

( ia64 )



[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/.