Notes concernant l'installation

Mises à jour de fonctionnalités

Mises à jour du noyau

Mises à jour des pilotes

Aperçus technologiques

Problèmes réglés

Problèmes connus

Si vous copiez le contenu des CD-ROM de Red Hat Enterprise Linux 4.8 (par exemple, en vue d'une installation basée sur un réseau), assurez-vous de ne copier que les CD-ROM du système d'exploitation. Ne copiez pas les CD-ROM de paquetages supplémentaires et ne copiez aucun des CD-ROM de produits en couche car une telle opération écraserait certains fichiers nécessaires au bon fonctionnement d'Anaconda.

Ces CD-ROM doivent être installés après l'installation de Red Hat Enterprise Linux.

Cette version de GRUB envoyée avec Red Hat Enterprise Linux 4 (et toutes les mises à jour) ne prend pas en charge la duplication de logiciel (RAID1). Ainsi, si vous installez Red Hat Enterprise Linux 4 sur une partition RAID1, le chargeur de démarrage sera installé sur le premier disque dur au lieu du secteur d'amorçage principal (MBR). Ceci rendra le système impossible à démarrer.

Si vous souhaitez installer la partition Red Hat Enterprise Linux 4 sur une partition RAID1, vous devrez commencer par supprimer tout chargeur de démarrage pré-existant du MBR.

Lorsque vous installez Red Hat Enterprise Linux 4 en Mode Texte sur les systèmes qui utilisent des écrans plats et des cartes ATI, l'écran peut apparaître décalé. Dans ce cas, certaines zones de l'écran peuvent sembler sombres.

Si c'est le cas, continuer l'installation avec le paramètre linux nofb.

Lorsque vous procédez à la mise à jour de Red Hat Enterprise Linux 4.6 vers cette version, minilogd pourrait enregistrer quelques refus SELinux. Ces refus sont sans conséquences, et peuvent être tranquillement ignorés.

Auparavant, dans la documentation Kickstart Anaconda (située dans /usr/share/doc/anaconda-<anaconda-version>/kickstart-docs.txt), la section détaillant l'option --driveorder dans un fichier Kickstart indiquait :

 Specify which drive is first in the BIOS boot order.
                                        

Cependant, l'option --driveorder requiers en fait une liste de tous les lecteurs sur le système, avec le premier périphérique de démarrage listé en premier. Avec cette mise à jour, la documentation a été clarifiée :

 Specify which drive is first in the BIOS boot order.
 The ordered list must include all the drives in the system.
                                        

Lors de l'utilisation de l'option --driveorder dans un fichier Kickstart, la liste ordonnée doit inclure tous les lecteurs du système.

Red Hat Enterprise Linux 4 prend maintenant Systemtap entièrement en charge.Systemtap fournit une infrastructure de logiciels libres (GPL) pour simplifier la collecte d'informations sur le système Linux en cours d'exécution. Cela aide au diagnostique de problèmes de performance ou de fonctionnement. Avec l'assistance de systemtap, les développeurs n'ont plus besoin de passer par les séquences fastidieuses d'instrumentation, de recompilation, d'installation et de redémarrage qui sont autrement nécessaires à la collecte de données.

Veuillez noter que certaines fonctionnalités de systemtap pour les systèmes plus récents de Red Hat Enterprise Linux ou de systèmes Linux ne fonctionneront pas sur Red Hat Enterprise Linux 4, ceci est dû au fait que certaines fonctionnalités du noyau sont absentes. L'absence de utrace du noyau exclut le support de vérification d'espace-utilisateur.

dmidecode offre des informations à propos des BIOS et des révisions de la carte-mère. La version fournie de kernel-utils avec cette consultation met à jour dmidecode depuis la version 2.2 jusqu'à la version 2.9. Cette version identifie de nouveaux processeurs, emplacements et périphériques PCI-express, et blade chassis. Elle offre aussi un support prolongé pour la spécification SMBIOS v2.6.

Une nouvelle version de kernel-utils est incluse dans cette sortie, mettant ainsi à jour le fichier de microcode Intel à la version 20080910, afin d'offrir un support aux nouveaux processeurs d'Intel.

smartmontools a été prolongé afin de supporter les contrôleurs CCISS okus récents trouvés dans le nouveau matériel HP ProLiant.

Le paquetage Samba a été rebasé sur la version en amont 3.0.33. La série des versions 3.0x n'est qu'une branche de débogage du code de base Samba. En se rebasant sur 3.0.33, nous allons inclure un nombre important de corrections de bogues et de d'améliorations de sécurité. Il n'y aura pas de nouvelles fonctionnalités ajoutées par ce rebasage.

Pour obtenir plus d'informations sur les corrections en amont offertes par ce rebasage, veuillez vous référez aux notes de mise à jour de Samba : http://samba.org/samba/history/samba-3.0.33.html

ipmitool a été mis à jour à la version en amont 1.8.11, qui offre différentes corrections de bogues ainsi que des améliorations par rapport à la version précédente, y compris :

Veuillez noter que le comportement du commutateur de ligne de commande a changé de prompt for Kg key à read Kg key from environment variable. L'indicateur -Y se comporte maintenant comme le faisait -K avant cette mise à jour.

Il y avait auparavant une extension de signe manquante dans le code ptrace x86_64 qui a peut-être mis gdb en échec sur l'architecture x86_64 lors du débogage d'une application i386. Avec cette mise à jour, l'extension de signe manquante est maintenant correctement étendue, ce qui résout le problème.

Le module ibmphp n'est pas sécurisé si déchargé. Auparavant, le mécanisme empêchant le module ibmphp de se décharger n'était pas suffisant, et a fini par déclencher un "bug halt". La méthode utilisée dans cette mise à jour pour empêcher le déchargement du module a été améliorée, empêchant le "bug halt". Cependant, tenter de décharger le module peut entraîner un avertissement dans le journal de messages, indiquant ainsi que le module n'est pas sécurisé si déchargé. Cet avertissement peut être ignoré en toute tranquillité.

Avec cette mise à jour, la mémoire physique sera limitée à 64 Go pour des noyau 32-bit x86 exécutés sur des systèmes de plus de 64 Go. Le noyau sépare la mémoire en 2 régions distinctes : lowmem et highmem. Lowmem est tout le temps mappé dans l'espace d'adresse du noyau. Parcontre highmem est mappé dans une fenêtre virtuelle du noyau par page si besoin est. Si les entrées/sorties de mémoire peuvent dépasser 64 Go, la taille de mem_map (ou tableau de page) peut s'approcher ou même excéder la taille de lowmem. Si cela arrive, le noyau paniquera pendant le démarrage ou démarrera prématurément. Dans ce cas-ci, le noyau ne peut pas allouer de sa mémoire après avoir démarré et paniquera ou s'arrêtera intempestivement.

Auparavant, si un utilisateur appuyait continuellement sur les touches de flèches sur une machine hardware virtuelle (HVM), une condition de course interrompue entre les interrupteurs de hardware et de compteur se présentera. En conséquence, le pilote du clavier retourne des évenements-clés inconnus. Avec cette mise à jour, le compteur i8042 a été supprimé, ce qui résout ce problème.

Avec cette mise à jour, l'utilitaire diskdump (qui offre la possibilité de créer et rassembler les transferts vmcore du noyau) est maintenant pris en charge pour utilisation avec le pilote sata_svw.

Avec cette mise aà jour, le paramètre "swap_token_timeout" a été ajouté à /proc/sys/vm.

Ce fichier contient un temps d'attente valide de jeton de protection échangeable. Le sous-système de mémoire virtuelle Linux (VM) possède un mécanisme de contrôle de vidage basé sur des jetons et utilise ces jetons pour prévenir les fautes de page non-nécessaires en situation de vidage. L'unité de valeur est exprimée en secondes. La valeur peut être utile afin de déterminer le comportement du vidage. La régler sur 0 désactive le mécanisme d'échange de jeton.

Auparavant, lorsqu'un client NFSv4 (Serveur de fichiers réseau, de l'anglais network file server) rencontrait des problèmes lors du traitement de répertoire en utilisant readdir(), une erreur pour l'appel readdir() entier était retournée. Avec cette mise à jour, lorsque readdir() est appelée, l'indicateur fattr4_rdattr_error est maintenant réglé pour instruire au serveur de continuer et de ne reporter une erreur que sur l'entrée spécifique du répertoire qui a causé ce problème.

Auparavant, le client NFS (serveur de fichier réseau, de l'anglais network file system) ne prenait pas en charge les réponses malformées de la fonction readdir(). En conséquence, la réponse du serveur indiquait que l'appel vers la fonction readdir() était réussi, mais celle-ci ne contenait pas d'entrées. Avec cette mise à jour, la logique d'analyse de réponse à été changée de façon à ce que le client retourne une erreur EIO lorsqu'une réponse malformée est reçue.

Le client RPC stocke le résultat d'un appel portmap dans un endroit de la mémoire qui peut être libéré et réaffecté sous certaines circonstances. Toutefois, selon les circonstances, le résultat de l'appel portmap pouvait être libéré trop tôt, ce qui endommageait la mémoire. Avec cette mise à jour, un comptage de références a été ajouté à l'emplacement de la mémoire dans lequel le réultat portmap est stocké, et celui-ci ne sera libéré qu'une fois utilisé.

Sous certaines circonstances, l'allocation de certaines structures de données pour les appels RPC peut être bloquée quand le niveau de mémoire système est trop bas. En conséquence, un blocage peut être rencontré lorsque la mémoire est sous haute pression, quand de nombreuses pages NFS attendent une écriture différée. Cette mise à jour permet l'allocation de structures de données non-bloquantes, résolvant ainsi ce problème.

Auparavant, une dégradation des performances pouvait être rencontrée lors de l'écriture simultanée vers un volume miroir LVM (en utilisant l'indicateur O_SYNC). En conséquence, chaque écriture d'entrée/sortie vers un volume miroir était différée de 3 ms, ce qui faisait que le volume miroir était de 5 à 10 fois plus lent qu'un volume linéaire. Avec cette mise à jour, une déconnexion de la file d'attente d'entrée/sortie a été ajoutée au pilote dm-raid1, et la performance des volumes miroirs a été améliorée de manière à pouvoir être comparable à celle des volumes linéaires.

Un nouveau paramètres de réglage a été ajouté afin de permettre aux administrateurs de changer le nombre maximal d'écritures kupdate de pages modifiées vers disque par itération à chaque fois qu'il change. Ce nouveau réglage /proc/sys/vm/max_writeback_pages) possède une valeur par défaut de 1024 (4Mo), ainsi un maximum de 1024 pages peut être écrit par chaque itération de kupdate. L'augmentation de cette valeur modifie l'agressivité avec laquelle kupdate purge les pages modifiées et réduit le montant potentiel de données perdues si une panne de système se produit entre différentes exécutions de kupdate. Toutefois, l'augmentation de la valeur max_writeback_pages peut aussi avoir des conséquences de performance négative sur les systèmes sensibles aux charges d'entrée/sortie.

Une nouvelle valeur autorisée a été ajoutée au paramètre de réglage /proc/sys/kernel/wake_balance. Régler wake_balance à une valeur de 2 instruira au planificateur d'exécuter le thread sur n'importe quel processeur (CPU) plutôt que de le planifier sur le processeur optimal. Régler ce paramètre de noyau à 2 forcera la planificateur à réduire la latence, même si cela provoque un débit total du système.

Lorsqu'il vérifie l'arborescence de répertoire, le noyau peut, dans certains cas, se tromper dans sa décision de quel arbre n'est pas occupé. Un montage décalé actif avec descripteur de fichier utilisé pour les expirations cause au descripteur de fichier de ne pas être considéré comme occupé. Ceci résulte en requêtes de montage faites pour des décalages déjà montés. Cette mise à jour a corrigé la vérification des modules du noyau, et les requêtes de montage incorrectes ne sont plus générées.

Pendant l'initialisation du système, le fournisseur du processeur n'était détecté qu'après l'initialisation des contrôleurs d'interruption programmables avancés (APIC). En conséquence, sur les systèmes AMD x86_64 de plus de 8 noyaux, le mode clusterisé APIC est utilisé, résultant en une performance système suboptimale. Avec cette mise à jour, le fournisseur du processeur est maintenant questionné avant l'initialisation des APIC, résolvant ainsi le problème en utilisant le mode physique plat par défaut.

Le code Common Internet File System (CIFS) a été mis à jour dans Red Hat Enterprise Linux 4.8, réglant un nombre important de bogues qui avaient été réparés en amont, ces changements incluent :

Auparavant, lors du montage d'un serveur sans extension Unix, il était possible de changer le mode d'un fichier. Cependant, ce changement de mode n'était pas stocké de manière permanente, et pouvait revenir à son mode initial à tout moment. Avec cette mise à jour, le mode du fichier ne peut pas, par défaut, être changé temporairement ; les appels chmod() seront retournés comme réussis mais n'auront aucun effet. Une nouvelle option dynperm doit être utilisée si l'ancien comportement est requis.

Auparavant, il y avait une condition de concurrence dans le noyau qui pouvait être rencontrée entre dio_bio_end_aio() et dio_await_one(). Ceci pouvait conduire à une situation dans laquelle l'entrée/sortie directe est abandonnée indéfiniment sur un processus d'entrée/sortie déjà terminé.Avec cette mise à jour, les opérations de comptage de référence sont bloquées de manière à ce que les chemins de soumission et de complétion soient dans un état unifié, ce qui résout ce problème.

Auparavant, mettre à jour un système d'hôte entièrement virtualisé de Red Hat Enterprise Linux 4.6 (avec le paquetage kmod-xenpv installé) avec les versions plus récentes de Red Hat Enterprise Linux 4 résultait en un modèle de dépendance incorrect entre les modules intégrés du noyau : xen-vbd.ko & xen-vnif.ko et le plus ancien module xen-platform-pci.ko . En conséquence, les systèmes de fichiers montés via le pilote de blocage xen-vbd.ko, et la mise en réseau d'hôte(s) en utilisant pilote réseau xen-vnif.ko échoueront.

Dans Red Hat Enterprise Linux 4.7, la fonctionnalité dans le module xen-platform-pci.ko était intégrée dans le noyau. Cependant, lorsque le module du noyau officiellement chargeable est devenu une partie du noyau, la vérification de dépendance de symbole pour modules chargeables existants n'était plus prise en compte correctement dans module-init-tools. Avec cette mise à jour, la fonctionnalité xen-platform-pci.ko a été retirée du noyau intégré et replacée dans un module chargeable, permettant ainsi à module-init-tools de vérifier et créer les dépendances correctes pendant la mise à jour du noyau.

Auparavant, tenter de monter des disques ou partitions dans un hôte entièrement virtualisé Red Hat Enterprise Linux 4.6 32 bits en utilisant le pilote de blocage paravirtuel (xen-vbd.ko) sur un hôte 64 bits ne fonctionnait pas. Avec cette mise à jour, la pilote de blocage avant (block.c) a été mis à jour pour informer le pilote de blocage arrière que l'hôte utilise un protocole 32 bits, ce qui résout le problème.

Auparavant, installer les pilotes pv-on-hvm sur un noyau sans système d'exploitation créait automatiquement le répertoire /proc/xen. En conséquence, les applications qui vérifient, en cherchant la présence du répertoire /proc/xen, si le système exécute un noyau virtualisé peuvent supposer incorrectement que le noyau virtualisé est utilisé. Avec cette mise à jour, les pilotes pv-on-hvm ne créent plus le répertoire /proc/xen, ce qui résout ce problème.

Auparavant, les hôtes paravirtualisés ne pouvaient avoir qu'un maximum de 16 pérphériques de disques. Dans cette mise à jour, la limite a été augmentée à un maximum de 256.

Le pilote de haute définition audio Intel® (de l'anglais High Definition Audio, HDA) dans ALSA a aussi été mis à jour. Celui-ci améliore le support audio de nouveau matériel avec audio intégré HDA.

Auparavant, les périphériques de réseau utilisant le pilote forcedeth cessaient de fonctionner lorsque la commande rcp était lançée depuis de multiples clients. Avec cette mise à jour, le pilote forcedeth a été mis à niveau, réglant ainsi ce problème.

Auparavant, le mode accès automatique direct à la mémoire (ADMA) était activé par défaut dans le pilote sata_nv. En conséquence, des erreurs et délais d'attente de périphérique peuvent arriver avec certains des périphériques utilisant le pilote sata_nv. Avec cette mise à jour, le mode ADMA est maintenant désactivé par défaut.

Les pilotes pour virtio, la plate-forme pour virtualisation d'entrée/sortie dans KVM, ont été retransportés depuis Linux Kernel 2.6.27 jusque dans Red Hat Enterprise Linux 4.8. Ces pilotes permettront aux hôtes KVM d'atteindre de plus importants niveaux de performance d'entrée/sortie. Différents composants d'espace utilisateur (tels que anaconda, kudzu, lvm, selinux et mkinitrd) ont aussi été mis à jour pour prendre en charge les périphériques virtio.

Le pilote r8169 a été mis à jour pour offrir la prise en charge de nouveaux chipsets réseau. Avec cette mise à jour, toute les variantes de RTL810x/RTL8168(9) sont prises en charge dans Red Hat Enterprise Linux 4.8.

Le pilote mptsas a été mis à jour au niveau de la version 3.12.29.00. Cette mise à jour inclut la correction de bogues et permet ces nouvelles fonctions :

Le pilote lpfc a été mis à niveau à la version 8.0.16.46. Cette mise à jour apporte plusieurs changements, notamment:

Le pilote megaraid_sas pour contrôleurs RAID basés SAS a été mis à jour avec la version 4.01-RH1. Plusieurs corrections de bogues et améliorations sont appliquées par cette mise à jour, y compris :

le pilote de périphérique ethernet eHEA pour IBM eServer System P a été mis à jour avec la version 0078-08.

Le pilote de périphérique EHCA infinband ne sera plus pris en charge par 8, ni par toute autre future sortie de Red Hat Enterprise Linux 4.

Auparavant, si l' applet Red Hat Network était utilisé pour ré-enregistrer le client sur un Serveur Red Hat Satellite différent, l'applet continuait d'afficher des mises à jour qui étaient disponibles sur l'ancien serveur, même si elles n'étaient plus disponibles sur le serveur actuel. /etc/sysconfig/rhn/rhn-applet ne changeait pas pour refléter les détails du nouveau serveur. La version de l'applet offerte avec cette mise à jour associe un cache de mises à jour avec un serveur URL, et assure ainsi que les mises à jour affichées sont bien correctes. Cette version peut aussi détecter si son fichier de configuration a changé. Si un tel changement est détecté, l'applet va automatiquement recharger les variables de configuration et créer de nouvelles connexions de serveur.

sysreport.legacy utilisait $HOME comme répertoire root. Dans le cas où la variable d'environnement n'existait pas ou si le répertoire auquel il se référait n'était pas accessible en écriture, sysreport.legacy ne pouvait pas générer son rapport et s'annulait en affichant le message Cannot make temp dir. Sysreport.legacy utilise maintenant un répertoire créé aléatoirement comme répertoire root et peut ainsi générer un rapport même sur un système sans fichier $HOME utilisable.

Le daemon automount utilisait une mémoire tampon de 128 octets pour recevoir des information de SIOCGIFCONF ioctl à propos des interfaces locales quand il testait la proximité d'un hôte correspondant à un montage donné. Comme les détails de chaque interface font 40 octets de long, le daemon ne pouvait recevoir les informations de plus de trois interfaces locales. Si l'hôte corrrespondant au montage avait une adresse locale mais ne correspondait pas à l'une des trois interfaces, la proximité était classée de manière incorrecte.

Le daemon automount alloue maintenant dynamiquement une mémoire tampon, s'assurant qu'elle est assez large pour contenir toutes les informations sur toutes les interfaces du système, offrant ainsi la possibilité de correctement déterminer la proximité d'un hôte donné pour un montage NFS.

Les entrées de mappage Automount se référant à de multiples hôtes dans l'emplacement de montage (montage dupliqué), le daemon automount sonde une liste d'hôtes distants pour connaître leurs proximité et version NFS. Si les hôtes ne répondent pas, ils sont supprimés de la liste. Si aucun hôte distant ne répond, la liste devient vide. Auparavant, le daemon ne vérifiait pas si la liste était vide, suivant la sonde initiale qui conduisait à une faute de segmentation (en supprimant un pointeur NULL). Cette vérification a été ajoutée.

Le paquetage ttfonts-zh_CN incluait anciennement la police Zhong Yi Song TrueType. Les droits d'auteur de cette police appartiennent à Beijing Zhong Yi Electronics Co., qui a uniquement autorisé Red Hat Inc. à distribuer cette police avec les prooduits et logiciels sous le nom de Red Hat Inc. L'inclusion de cette police dans ttfonts-zh_CN prévient ainsi Red Hat de distribuer ce paquetage gratuitement. La police Zhong Yi Song TrueTypeest toujours disponible aux clients Red Hat via le Red Hat Network et le CD supplémentaire (Supplementary CD) dans le paquetage fonts-chinese-zysong.

multipathd se bloquait avec le statut multipathd dead but pid file exists quand multipath était configuré pour 1024 chemins d'accès ou plus, parcequ'il ne pouvait pas ouvrir un descripteur de fichier pour chaque chemin d'accès. Ceci pouvait aussi causer des erreurs error calling out /sbin/mpath_prio_ontap /dev/[device]. Maintenant, un nouveau paramètre multipath.conf parameter, max_fds, permet aux utilisateurs finaux d'ajuster le nombre maximal de descripteurs de fichiers que le processus multipathd peut garder ouverts, ou d'utiliser max pour ajuster ce nombre au maximum autorisé par le système. Ajuster max_fds dans multipathd à un nombre suffisamment important ou sur max permet d'éviter de se retrouver bloqué.

Auparavant, lors de l'utilisation du pilote accraid ou du contrôleur Adaptec 2120S ou Adaptec 2200S, le système pouvait ne pas réussir à démarrer, retournant l'erreur : aac_srb:aac_fib_send failed with status 8195. Avec cette mise à jour, le pilote accraid a été remis à niveau.

SOS est un ensemble d'outils qui rassemble des informations concernant le matériel (hardware) du système et la configuration actuelle. Ces informations peuvent ensuite être utilisées pour faire des diagnostiques et débogages.

Avec cette mise `jour, les rapports générés par sosreport incluent maintenant cinq types d'informations qui ne pouvaient pas être rassemblées auparavant.

automount utilise umount(8) lorsque les montages qui expirent et umount(8) peuvent attendre indéfiniment qu'un serveur réponde. Ceci peut conduire le temps d'expiration à se bloquer pour une longue période dans le même processus /usr/sbin/automount (qui est le montage que le processus de montage automatique gère). En conséquence, si un serveur est inaccessible, alors le montage automatique ne démontera aucun montage expiré, même sur les serveurs qui répondent encore. Les systèmes peuvent ainsi être abandonnés avec un nombre important de montages qui auraient pu expirer mais ne le sont pas. Le montage automatique inclut maintenant une option de ligne de commande pour spécifier un temps d'attente avant qu'il n'abandonne sa tâche et ne passe aux montages suivants. Les montages expirés peuvent ainsi être démontés même si certains serveurs ne répondent pas.

Les serveurs de protocole de message Internet ICQ ont récemment changés et requièrent maintenant des clients pour utiliser une nouvelle version du protocole ICQ. Avant, se connecter à ICQ à l'aide de Pidgin 2.5.2 (la version précédente fournie avec Red Hat Enterprise Linux 4) échouait et affichait un message d'erreur. Dans cette mise à jour, Pidgin a été mis à jour vers la version 2.5.5, résolvant ainsi ce problème.

Auparavant, l'article dans la base de connaissances de Red Hat (Red Hat Knowledgebase) documentant la relance d'analyse Fibre Channel dans Red Hat Enterprise Linux 4 n'était pas précis. Cette procédure a maintenant été mise à jour et peut être trouvée à l'adresse suivante : http://kbase.redhat.com/faq/docs/DOC-3942

Après s'être connecté à un serveur SSH avec succès, le serveur pouvait retourner une bannière à base de texte au client SSH. En d'autres termes, si gftp (un client graphique ftp) tentait de se connecter (via SFTP) à un serveur SSH qui retourne une bannière, gftp aurait assimilé la bannière à une erreur et fermé la connexion. gftp a été mis à jour vers la version 2.0.18, permettant ainsi la connexion aux serveurs avec bannières.

Lors du téléchargement d'un fichier unique vers un répertoire NFS, le timestamp indiquant les moments de modification et d'accession au fichier n'étaient pas toujours enregistrés correctement. Le timestamp est maintenant mis à jour et le problème réglé.

Le code de sondage dans kudzu pour périphériques PCI ne trouvait pas certains modules travaillant en liaison avec des classes PCI spécifiques, notamment le pilote sgiioc4 sur les systèmes Altix SGI. Sans le chargement de ces modules, le système ne pouvait pas détecter les périphériques qui dépendaient du pilote. Une nouvelle version de ce code de sondage est maintenant incluse dans le paquetage de mise à jour, celui-ci peut maintenant trouver ces modules.

Le gestionnaire de volume logique (Logical Volume Manager) dans Red Hat Enterprise Linux 4.8 rapporte les fuites de descripteurs de fichiers et retourne dans la sortie de l'installation le message d'erreur suivant :

File descriptor NUM (socket:XXXX) leaked on lvm invocation.
                                        

Ce message peut être ignoré sans risque.

Lors de l'installation de Red Hat Enterprise Linux 4 à travers un serveur de fichiers réseau (NFS), le programme d'installation ne peut pas fermer les points de montages NFS correctement. Ceci peut causer au serveur NFS de mal se comporter. Dans ces cas, Red Hat suggère l'utilisation d'un serveur HTTP pour les installations.

Sur des systèmes où le BIOS est en mesure de faire à la fois la connexion à chaud PCI patrimonial (acpiphp) et natif (pciehp), il est nécessaire que l'administrateur choisisse une méthode et d'explicitement empêcher Red Hat Enterprise Linux 4 de charger le module de la méthode indésirable. Ceci peut être fait en mettant le module indésirable dans la liste noire située dans /etc/modprobe.conf.

Le test du matériel Mellanox MT25204 a révélé une erreur interne sous certaines conditions de haut volume de traitement. Quand le pilote ib_mthca rapporte une erreur catastrophique sur ce matériel, c'est normalement suite à une longueur de file d'attente d'achèvement insuffisante par rapport au nombre de demandes de travail en attente qui sont générées par l'application de l'utilisateur.

Malgré que le pilote va redémarrer le matériel et se remettre d'un tel événement, toutes les connexions présentes au moment de l'erreur seront perdues. Ceci résulte généralement en une faute de segmentation dans l'application utilisateur. De plus, si opensm est exécuté au moment ou l'erreur a lieu, alors vous aurez besoin de redémarrer manuellement en vue de terminer les opérations correctement.

Un bogue présent dans les versions openmpi and lam précédentes, pourrait vous empêcher de mettre ces paquetages à niveau. Ce bogue particulier pourrait causer l'échec de la commande up2date lorsque vous mettez à niveau vos paquetages.

Ce bogue se manifeste dans l'erreur suivante lorsque vous tenterez de mettre à niveau les fichiers openmpi ou lam:

error: %preun(openmpi-[version]) scriptlet failed, exit status 2
                                

Ce bogue se manifeste également dans le message d'erreur suivant (enregistré dans /var/log/up2date) lorsque vous tentez de mettre à niveau tous les paquetages à travers la commande up2date:

up2date Failed running rpm transaction - %pre %pro failure ?.
                                

Ainsi, vous aurez besoin de supprimer les versions openmpi et lam antérieures manuellement de façon à éviter ces erreurs. Dans ce but, utiliser la commande suivante rpm:

rpm -qa | grep '^openmpi-\|^lam-' | xargs rpm -e --noscripts --allmatches

Quand vous supprimez un LUN dans un système de stockage configuré, le changement n'est pas reflété dans l'hôte. Dans un tel cas, les commandes lvm vont être suspendues indéfiniement quand dm-multipath est utilisé, car le LUN est maintenant hors service.

Pour contourner cela, effacer tous les périphériques et mpath les saisies de lien dans le fichier /etc/lvm/.cache qui se rapportent au LUN hors service. Pour trouver ces entrées, exécuter 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
lrwxrwx--rwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
                                

Cela signife que 3600d0230003414f30000203a7bc41a00 est mappé sur deux liens mpath: dm-4 et dm-5.

Ainsi, les lignes de commande suivantes devraient être effacées du fichier /etc/lvm/.cache:

/dev/dm-4 
/dev/dm-5 
/dev/mapper/3600d0230003414f30000203a7bc41a00
/dev/mapper/3600d0230003414f30000203a7bc41a00p1
/dev/mpath/3600d0230003414f30000203a7bc41a00
/dev/mpath/3600d0230003414f30000203a7bc41a00p1
                                

Dans la configuration HA-RAID deux-systèmes, deux adaptateurs SAS sont branchés sur deux systèmes et sont connectés à un tiroir à disque partagé SAS. La configuration de l'attribut Preferred Dual Adapter State dans Primary sur les deux adaptateurs SAS peut entraîner une condition de concurrence et causer une situation d'échec infinie entre les deux adaptateurs SAS. C'est parce qu'un des adaptateurs SAS peut être paramétré à Primary.

Pour éviter cette erreur, veillez à ce que le Preferred Dual Adapter State d'un des adaptateurs soit paramétré None si l'autre adaptateur SAS est paramétré None.

Si vous avez besoin d'utiliser le module de noyau hp_sw, installez le paquetage mis à jour device-mapper-multipath.

Vous aurez également besoin de configurer correctement le tableau HP pour pouvoir utiliser correctement le mode actif/passif et pour pouvoir reconnaître les connexions en provenance d'une machine Linux. Dans ce but, procédez aux étapes suivantes:

Red Hat décourage l'utilisation de quota sur des systèmes de fichier EXT3, car, dans certains cas, cela pourrait occasionner une impasse.

Les essais ont révélé que la commande kjournald peut parfois bloquer certains appels spécifiques-EXT3 qui sont utilisés quand quota est exécuté. Ainsi, Red Hat n'envisage pas de résoudre ce problème dans cette version de Red Hat Enterprise 4, car les modifications nécessaires seraient trop invasives.

Notez que ce problème n'est pas présent dans Red Hat Enterprise Linux 5.

Le test du matériel Mellanox MT25204 a révélé une erreur interne sous certaines conditions de haut volume de traitement. Quand le pilote ib_mthca rapporte une erreur catastrophique sur ce matériel, c'est normalement suite à une longueur de file d'attente insuffisante par rapport au nombre de demandes en attente qui sont générées par l'application de l'utilisateur.

Malgré que le pilote va redémarrer le matériel et recouvrir d'un tel événement, toutes les connexions présentes au moment de l'apparition de d'erreur, seront perdues. Ceci résulte généralement en une faute de segmentation dans l'application utilisateur. De plus, si opensm est exécuté au moment ou l'erreur a lieu, alors vous aurez besoin de redémarrer manuellement en vue de terminer les opérations correctement.

L'icône de connexion Desktop Sharing affiche son menu de contexte quand on clique deux fois dessus, et non pas quand vous cliquez à droite. Tous les autres icônes affichent leurs menus de contexte quand vous cliquez à droite dessus.

Si le pilote InfiniBand ib_ehca est chargé en mode auto-détection de port (en utilisant le paramètre de module nr_ports=-1), les interfaces réseau IP-over-InfiniBand (ibX) peuvent devenir disponibles trop tard. Lorsque ceci arrive, la commande ifup ibX publiée par le script de démarrage openibd échouera ; par conséquent, l'interface ibX ne sera pas disponible.

Lorsque ceci arrive, utilisez la commande rcnetwork restart pour régler ce problème.

Dans le manuel IBM Redbook "Implementing InfiniBand in IBM System p (SG247351), le tableau 6-3 (page 220 de la version PDF) décrit les définitions de bits de codes de débogage, plusieurs bits d'indicateurs d'erreurs HCA y sont aussi décrits.

Notez qu'avec les adaptateurs eHCA2, les bits 46 et 47 de ces bits d'indicateur d'erreurs peuvent retourner de faux positifs.

Sur les consoles de travail HP ICH10, l'audio est uniquement activé à l'aide de jacks frontaux 3.5mm. Ainsi, pour recevoir une sortie audio ou pour enregistrer, vous devrez branchez votre casque audio, vos haut-parleurs ou microphone(s) sur ces jacks frontaux. En ce moment, les jacks antérieurs, le haut-parleur interne et le volume principal ne fonctionnent pas.

Avec cette mise à jour, le mode PCI de détection et de mise en séquence des modèles suivants a changé :

Ces modèles utilisent un mode de scan et d'énumération de périphériques qui n'est pas celui par défaut dans Red Hat Enterprise Linux4 ou 5. Le mode utilisé par ces modèles HP Proliant peut causer aux cartes complémentaires d'être détectées et ajoutées avant les périphériques internes/intégrés. Cette mise en séquence peut provoquer des difficultées lors de l'installation de nouvelles instances de Red Hat Enterprise Linux, de l'ajout de hardware, ou lors de la maintenance.

La numérotation des cartes d'interface réseau (NIC) pour les modèles HP Proliant mentionnés ci-dessus peut changer lors de la mise à jour avec le noyau de Red Hat Enterprise Linux 4.7. L'installer change la numérotation NIC si le paramètre HWADDR=MAC ADDRESS n'est pas défini dans /etc/sysconfig/network-scripts/ifcfg-eth[X] pour chaque NIC installée. Ainsi, Red Hat vous recommande de vous assurer que ce paramètre est défini afin d'éviter tout problème résultant d'une numérotation NIC inattendue.

De plus, pour éviter tout changement de numérotation NIC après avoir mis ces modèles HP Proliant à jour avec Red Hat Enterprise Linux 4.7, ajoutez le paramètre de démarreur du noyau pci=nobfsort à /boot/grub/grub.conf.

Lorsqu'un groupe de volumes contient un miroir ou une capture instantanée offrant la commande Ivchange avec un paramètre de groupe de volume peut causer un erreur et afficher le message suivant :

Unable to change mirror log LV fail_secondary_mlog directly
Unable to change mirror image LV fail_secondary_mimage_0 directly
Unable to change mirror image LV fail_secondary_mimage_1 directly
                                        

Ces messages peuvent être ignorés sans risque.

Les systèmes Dell PowerEdge SC1435s peuvent se bloquer pendant le démarrage. Pour éviter cela, modifiez la ligne terminal dans grub.conf et remplacez la chaîne serial console par console serial.

Le pilote ixgbe ne prend pas en charge Intel 82598AT (Copper Pond 10GbE).

Red Hat Enterprise Linux 5.3 peut détecter si un périphérique de blocage sous-jacent est en croissance en ligne ou en réduction en ligne. Cependant, il n'y a pas de méthode pour détecter automatiquement si un périphérique a changé de taille, des étapes doivent être faites manuellement sont requises afin de reconnaître et redimensionner tout système de fichier résidant sur le(s) périphérique(s) en question. Lorsqu'un périphérique de blocage redimensionné est détecté, un message comme le suivant apparaîtra dans les journaux du système :

VFS: busy inodes on changed media or resized disk sdi
                                

Si le périphérique de blocage a pu croître, alors ce message peut être ignoré. Cependant si ce périphérique de blocage était réduit sans réduire les ensembles de données qui se trouvent dessus au préalable, alors les données résiduelles risqueront d'être corrompues.

Il est possible de procéder à un redimensionnement en ligne d'un système de fichiers créé sur le LUN (ou périphérique de blocage) entier. S'il y a une table de partition sur le périphérique de blocage, alors le système devra être démonté afin de mettre la table de partition à jour.

Il y a une fuite de mémoire connue avec la famille res_n* des résolveurs (c'est-à-dire res_nquery, res_nsearch et res_nmkquery). Les logiciels qui utilisent ces fonctions vont perdre de leur mémoire au fil du temps. Ceci a été réglé dans les versions de glibc plus récentes. Cependant, la correction est trop envahissante pour être appliquée à Red Hat Enterprise Linux 4. Les programmes qui utilisent ces fonctions devront peut-être être redémarrés occasionnellement afin de libérer de la mémoire.

Le nombre de périphériques pouvant être utilisés pendant l'installation de Red Hat Enterprise Linux 4 dépend de la taille de l'image d'installation initrd. Ainsi, dans des situations où il y a de nombreux périphériques attachés à une machine (comme pour les installations de Fibre Channel remplies), l'installation ne sera pas possible à moins de réduire le nombre de périphériques visibles.

La première mise à jour du pilote aacraid introduite dans Red Hat Enterprise Linux 4.7 requérait un micrologiciel Adaptec PERC3/Di mis à jour. Les mises à jour suivantes de Red Hat Enterprise Linux 4 (y compris cette version 4.8) requièrent que la version du micrologiciel PERC3/Di soit 2.8.1.7692, A13 ou plus récente. Le micrologiciel peut être obtenu depuis la location suivante :

http://support.dell.com/support/downloads/download.aspx?c=us&cs=555&l=en&s=biz&releaseid=R168387&SystemID=PWE_PNT_PIII_1650&servicetag=&os=WNET&osl=en&deviceid=1375&devlib=0&typecnt=0&vercnt=9&catid=-1&impid=-1&formatcnt=4&libid=35&fileid=228550

Pendant l'installation, anaconda peut ne pas supprimer toutes les métadonnées (LVM) Logical Volume Manager qui existaient sur un système avant l'installation. Ces métadonnées en trop peuvent causer à l'outil LVM de déclarer des groupes de volumes, ou des volumes logiques, manquant(s) après l'installation. Pour contourner ce problème, supprimez les métadonnées LVM périmées une fois l'installation complète.

multipath n'empêche pas les messages d'erreurs d'apparaître lorsqu'ils sont affichés par ses programmes d'appel. Ainsi, si multipath est lancé lorsque les chemins sont fermés, divers messages d'erreurs seront affichés. Les messages affichés dépendent du programme d'appel spécifique utilisé par multipath. Par exemple, si multipath est exécuté alors que certains périphériques scsi ont échoués, alors scsi_id affichera

<H>:<B>:<T>:<L>:Unable to get INQUIRY vpd 1 page 0x0.
<H>:<B>:<T>:<L>:sg_io failed status 0x0 0x1 0x0 0x0
                                        

Ou si multipath -ll est exécuté alors qu'un EMC CLARiiON est fermé, l'appel mpath_prio_emc priority affichera query command indicates error.