Red Hat Enterprise Linux 5.3

Notes de sortie

Notes de sortie pour toutes les architectures.

Ryan Lerch

Red Hat Engineering Content Services

Note légale

Copyright 2008 Red Hat, Inc.. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).

Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.

All other trademarks referenced herein are the property of their respective owners.

The GPG fingerprint of the [email protected] key is:

CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E



Résumé

Ce document nous décrit en détail les notes de sortie pour Red Hat Enterprise Linux 5.3.


1. Notes concernant l'installation
1.1. Toutes les architectures
1.2. Architectures PowerPC
1.3. Architectures s390x
1.4. Architectures ia64
2. Mises à jour de fonctionnalités
3. Mises à jour des pilotes
3.1. Toutes les architectures
4. Notes relatives au noyau
4.1. Toutes les architectures
4.2. Architectures x86
4.3. Architectures PowerPC
4.4. Architectures x86_64
4.5. Architectures s390x
4.6. Architectures ia64
5. Virtualisation
5.1. Mises à jour de fonctionnalités
5.2. Problèmes résolus
5.3. Problèmes connus
6. Aperçus technologiques
7. Problèmes résolus
7.1. Toutes les architectures
7.2. Architectures x86_64
7.3. Architectures s390x
7.4. Architectures PowerPC
8. Problèmes connus
8.1. Toutes les architectures
8.2. Architectures x86
8.3. Architectures x86_64
8.4. Architectures PowerPC
8.5. Architectures s390x
8.6. Architectures ia64
A. Historique de révision

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

Red Hat Network peut installer les paquetages nouveaux ou modifés et mettre à niveau un système Red Hat Enterprise Linux 5 existant. Sinon, Anaconda peut mettre à niveau un système Red Hat Enterprise Linux 5 existant ou bien effectuer une nouvelle installation de Red Hat Enterprise Linux 5.3.

A noter: mettre à niveau Red Hat Enterprise Linux 5.3 à partir des notes de mise à jour beta vers les notes GA n'est pas supporté.

De plus, malgré qu' Anaconda propose une option de mise à niveau des versions antérieures principales de Red Hat Enterprise Linux vers Red Hat Enterprise Linux 5.2, Red Hat ne les prend pas en charge actuellement. De manière générale, Red Hat ne supporte pas les mises à niveau en place entre aucune version principale de Red Hat Enterprise Linux. (Une version principale étant caractérisée par un grand nombre de changements. Par exemple, Red Hat Enteprise Linux 4 et Red Hat Enterprise Linux 5 sont deux versions principales de Red Hat Enterprise Linux.)

Les mises à niveau en place entre les versions principales ne permettent pas de préserver tous les paramètres de service ou configurations personnalisées du système. De ce fait, Red Hat conseille des installations nouvelles entre les mises à niveau.principales.

1.1. Toutes les architectures

  • L'installation Text Mode d'Anaconda offre maintenant l'option de passer à Virtual Network Computing (VNC) pour terminer l'installation.

  • Créer ou utiliser des disques de logiciels RAID membre cryptés (c'est à dire des partitions software RAID) n'est pas pris en charge. Mais, créer des réseaux de logiciels RAID cryptés (c'est à dire /dev/md0 ) est pris en charge.

  • Le NFS par défaut est "locking" (verrouillage) pour RHEL5. Donc, pour monter des parts nfs à partir de la section %post d'anaconda, utiliser la commande mount -o nolock,udp pour démarrer le démon de verrouillage avant d'utiliser nfs pour monter les parts.

  • L'installation à partir de CD-ROM ou DVD-ROM sur un système comprenant un périphérique réseau configuré-iBFT Anaconda ne comprendra aucun système de stockage configuré-IBFT à moins que le réseau ne soit ainsi configuré. Pour permettre une installation en réseautage, utiliser la commande linux updates=http://[any] au niveau du message-guide d'amorçage. A noter que [any] peut être remplacé par n'importe quel URL.

    Si votre système requiert une configuration statique IP, utiliser la commande linux updates=http://[any] ip=[IP address] netmask=[netmask] dns=[dns].

  • Lors de l'installation de Red Hat Enterprise Linux 5.3 sur un invité pleinement virtuel, n'utiliser pas le noyau kernel-xen. L'utilisation de ce noyau sur des invités pleinement virtuels 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.3 sur un invité pleinement virtuel, 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.

    Noter que les invités pleinement paravirtuels ne sont pas affectés par ce problème. Les invités paravirtuels utilisent toujours le noyau kernel-xen.

  • Si vous utilisez le noyau virtuel lors de la mise à niveau de Red Hat Enterprise Linux 5 à 5.2, vous devez redémarrer le système en utilisant le noyau virtuel mis à jour.

    Les hyperviseurs de Red Hat Enterprise Linux 5 et 5.2 ne sont pas compatibles avec ABI. Si vous ne redémarrez pas entre les mises à niveau à l'aide du noyau virtuel mis à jour, les RPMs de virtualisation mis à niveau ne correspondront pas au noyau en cours d'exécution.

  • Lors de la mise à niveau de Red Hat Enterprise Linux 5.1 ou de Red Hat Enterprise Linux 4.6, gcc4 peut entraîner l'échec de la mise à niveau. De ce fait, vous devez retirer manuellement le paquetage gcc4 avant d'effectuer la mise à niveau.

  • Le plugin du langage firstboot a été retiré, car le système ne peut être correctement et totalement reconfiguré lorsque qu'un nouveau langage est sélectionné.

  • L'utilisation du protocole CHAP (de l'anglais "Challenge Handshake Authentication Protocol") n'est pas supporté. De ce fait, CHAP ne doit être activé qu'après que l'installation ne soit terminée.

    Si vous système est initialisé grâce à un périphérique iFBT, configurer CHAP dans l'écran d'installation de micrologiciel iFBT BIOS/. Vos paramètres CHAP seront alors utilisés pour la prochaine initialisation.

    Si votre système démarre à travers PXE iSCSI, configurer CHAP par iscsiadm. Après la configuration, utiliser mkinitrd pour vous assurer que vos paramètres CHAP seront utilisés au prochain démmarrage.

  • Lorsque vous provisionnez des invités en cours d'installation, l'option RHN tools for guests ne sera pas disponible. Dans un tel cas, le système aura besoin d'un privilège supplémentaire, distinct de celui qui a été utilisé par dom0.

    Pour éviter la consommation de privilèges supplémentaires pour les invités, installez le paquetage rhn-virtualization-common manuellement avant de tenter d'enregistrer le système dans le réseau Red Hat Network.

  • L'installation de Red Hat Enterprise Linux 5.3 sur un système comprenant des interfaces de réseaux multiples et spécifier les adresses IPv6 manuellement peut aboutir à une installation de réseau incorrecte. Dans ce cas, vos paramètres IPv6 n'apparaîtront pas sur le système installé.

    Pour contourner cette difficulté, configurez NETWORKING_IPV6 à yes dans /etc/sysconfig/network. Puis, redémarrez votre connexion de réseau en utilisant la commande service network restart.

  • SI votre système a yum-rhn-plugin-0.5.2-5.el5_1.2 (or an earlier version) d'installé, vous serez en mesure de le mettre à niveau vers Red Hat Enterprise Linux 5.3 par yum update. Pour contourner cette difficulté, procédez à la mise à niveau de yum-rhn-plugin vers la dernière version (en utilisant yum update yum-rhn-plugin) avant d'exécuter yum update.

  • Auparavant, anacondane pouvait pas accéder à plus de 8 contrôleurs SmartArray.Dans cette mise à jour, ce problème a été réglé.

  • Un disque de pilote, fourni par un OEM, est un fichier image simple, (*.img) qui peut comprendre des paquetages de pilotes et des modules de noyau multiples. Ces pilotes sont utilisés pendant l'installation pour prendre en charge le matériel qui ne serait normalement pas reconnu par Red Hat Enterprise Linux 5. Une fois que les paquetages du pilote et que les modules du noyau sont installés sur le système, ils sont placés dans le disque RAM (initrd) pour qu'ils puissent être chargés dans le système quand il démarre.

    Dans cette version, l'installation peut détecter automatiquement un disque de pilote (basé sur son label de système de fichiers), utilisant ainsi le contenu de ce disque pendant l'installation. Ce comportement est contrôlé par l'option de ligne de commande d'installation dlabel=on, qui active la recherche automatique. dlabel=on est le paramètre par défaut pour cette version.

    Tous les périphériques bloc qui ont l'étiquette de système de fichiers OEMDRV sont passés en revue et les pilotes sont chargés à partir de ces unités par ordre de détection.

  • Les périphériques en bloc crytpés existants contiennent des systèmes de fichiers vfat apparaîtront sous le type foreign (étrange) dans l'interface de partition; ainsi, ces périphériques ne seront pas montés automatiquement pendant en cours d'initialisation du système. Pour s'assurer que ces périphériques soient montés automatiquement, ajouter l'entrée qui convient dans /etc/fstab. Pour davantage d'informations sur la façon de procéder, consultez man fstab.

1.2. Architectures PowerPC

  • La mémoire RAM minimum requise pour installer Red Hat Enterprise Linux 5.2 est 1Go. Si une machine a moins que 1 Go de mémoire RAM, le processus d'installation peut s'interrompre.

    De plus, les machines PPC qui ont 1 Go de mémoire RAM connaissent des problèmes de performance significatifs avec certaines charges de travail qui demandent une utilisation intensive de la mémoire RAM. Pour qu'un système Red Hat Enterprise Linux 5.2 puisse accomplir de manière optimale des traitements qui demandent une utilisation intensive de la mémoire RAM, il est recommandé d'équiper les machines avec 4 Go de RAM. Cela permet de s'assurer que le système a le même nombre de pages physiques que celui des machines PPC utilisant 512 Mo de RAM utilisant Red Hat Enterprise Linux 4.5 ou une version plus récente.

1.3. Architectures s390x

  • anaconda supporte maintenant les deux ports CHPID pour OSA Express3 cards. L'installateur vous invitera à indiquer le numéro du port dans la phase initiale de l'installation. La valeur qui est proposée pour le port, affecte également le script de démarrage de l'interface de réseau installé. Quand le port 1 est sélectionné, la valeur portno=1 iest ajoutée au paramètre d'OPTIONS du fichier ifcfg-eth*.

    Note

    Lorsque vous installez sous z/VM, vous pouvez soit ajouter PORTNO=0 (pour utiliser port 0) ou PORTNO=1 (pour utiliser port 1) au fichier de configuration CMS pour éviter d'être prompté au niveau du mode.

  • L'installation sur une machine comprenant des systèmes de fichiers existant Linux ou non-Linux sur les périphériques bloc DASD pourrait entraîner l'arrêt de l'installateur. Si cela se produit, il faut supprimer toutes les partitions existantes sur les périphériques DASD que vous souhaitez utiliser et redémarrer l'installateur.

1.4. Architectures ia64

  • Si votre système ne supporte que 512 Mo de RAM, il n'est pas possible d'installer Red Hat Enterprise Linux 5.3. Afin d'éviter ce problème, procéder tout d'abord à une installation de base et installer tous les autres paquetages une fois l'installation terminée.

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

    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.

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

2. Mises à jour de fonctionnalités

Cryptage des périphériques bloc

Red Hat Enterprise Linux 5.3 inclut un support pour le cryptage des périphériques en bloc en utilisant la spécification Linux Unified Key Setup (LUKS). Le cryptage d'un périphérique protège toutes les données d'un périphérique bloc contre toute violation d'accès, même si le périphérique n'a pas été physiquement retiré d'un système. Pour accéder aux contenus d'un périphérique crypté, un utilisateur devra produire une phrase de passe ou une clé pour s'authentifier.

Pour toute information sur l'installation du cryptage disque, consultez le guide d'installation Red Hat Enterprise Linux :http://redhat.com/docs/

mac80211 802.11a/b/g pile protocole WIFI (mac80211)

La pile mac80211 (précédemment connue en tant que pile devicescape/d80211) est une fonctionnalité maintenant supportée par Red Hat Enterprise Linux 5.3. Elle active le pilote sans fil iwlwifi 4965GN.pour le matériel 4965G Wifi Link Intel®. Cette pile permet à certains périphériques sans fil de se connecter à des réseaux Wi-Fi.

Malgré que le composant mac80211 soit pris en charge par Red Hat Enterprise Linux 5.3, les symboles ne sont pas inclus dans la liste blanche du noyau.

Global File System 2 (GFS2)

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

Dans Red Hat Enterprise Linux 5.2, GFS2 était fourni en tant que module de noyau dans un but d'évaluation. Dans Red Hat Enterprise Linux 5.3 GFS2 fait maintenant partie du paquetage noyau. Si les modules de noyau Red Hat Enterprise Linux 5.2 GFS2 ont été installés, ils doivent être retirés pour utiliser GFS2 dans Red Hat Enterprise Linux 5.3.

Améliorations du Driver Disk Support

Un disque de pilote, fourni par un constructeur OEM, est un fichier à image unique (*.img), qui contient potentiellement des RPM de pilotes multiples et des modules de noyau. Ces pilotes sont utilisés en cours d'installation pour prendre en charge le matériel qui ne serait normalement pas reconnu. Les RPM sont installés sur le sytème et placés dans le initrd de façon à pouvoir être pris en charge quand la machine redémarre.

Dans Red Hat Enterprise Linux 5.3, l'installation peut détecter automatiquement la présence de disques de pilotes sur la base de l'étiquetage du système de fichiers, et utiliser le contenu de ce disque pendant l'installation. Ce comportement est contrôlé par l'option de ligne de commande de l'installation dlabel=on, qui permet la recherche automatique. Toutes les unités en bloc avec l'étiquette de système de fichier OEMDRVsont examinées et les pilotes sont chargés à partir de ces unités au fur et à mesure qu'on les rencontre.

iSCSI Boot Firmware Table

Red Hat Enterprise Linux 5.3 prend maintenant totalement en charge iSCSI Boot Firmware Table (iBFT) ce qui permet l'initialisation à partir des périphériques iSCSI. ce support nécessitait que les disques iSCSI (noeuds) ne soient plus sélectionnés pour démarrer automatiquement. Le système installé ne se connectera et ne s'authentifiera plus automatiquement aux disques iSCSI aux niveaux d'exécution 3 ou 5.

iSCSI est normalement utilisé dans le système de fichiers racine, dans lequel cas, ce changement ne fait aucune différence car le initrd se connectera et s'authentifiera aux disques iSCSI avant même qu'on saisisse le niveau d'exécution.

Malgré tout, si les disques iSCSI ont besoin d'être montés sur des répertoires non racine, comme par exemple /home ou /srv, alors ce changement aura un impact sur vous, puisque le système installé ne connectera plus automatiquement, ni ne s'authentifiera auprès de disques iSCSI qui ne sont pas utilisés dans le système de fichiers racine.

L'utilisation de disques iSCSI montés sur des répertoires non racine est toujours possible, mais requiert l'utilisation d'une des solutions suivantes :

  1. Installer le système sans utiliser des disques iSCSI montés sur des répertoires non racines et configurer plus tard les disques qui conviennent et les points de montage manuellement.

  2. Démarrer le système installé au niveau d'exécution 1, et sélectionnez tous les disques iSCSI qui ne sont pas utilisés par le système de fichiers racine pour le démarrage automatique en utilisant la commande suivante une fois par disque :

    iscsiadm -m node -T target-name -p ip:port -o update -n node.startup -v automatic

rhythmbox

rhythmbox a été mis à jour à la version 0.11.6. Cette version comprend maintenant une option qui permet d'y ajouter les plugins propriétaires GStreamer.

lftp Rebase

lftp a été mis à jour à la version 3.7.1. Cette version comprend maintenant les améliorations suivantes :

  • On a réglé un défaut de sécurité du système d'exploitation lftp qui citait des scripts générés par mirror --script (qui pourrait entraîner une escalade au niveau des privilèges non autorisés).

  • L'utilisation de lftp avec l'option -c ne cause plus la suspension delftp.

  • lftp ne corrompt plus les fichiers pendant un transfert par sftp.

Pour davantage d'informations à propos de lftp, rapportez-vous à http://lftp.yar.ru/news.html.

TTY Input Auditing

TTY input auditing est maintenant pris en charge. Si un processus est sélectionné pour la vérification des données, les données qu'il lit sur les TTY sont contrôlées. Cela apparaîtra sur les enregistrements audit avec pour type TTY.

Vous pouvez utiliser le module pam_tty_audit pour sélectionner un processus (et ses processus enfant) pour le processus de vérification des données de TTY. Vous trouverez les instructions relatives dans man pam_tty_audit(8).

Les enregistrements audit TTY contiennent les touches précises lues par le processus d'audit. Pour faciliter le décodage des données, bash audite la ligne de commande exacte, utilisant le type d'enregistrement USER_TTY.

Les enregistrements d'audit contiennent toutes les données lues par les processus d'audit de TTY. Cela inclut les données insérées dans le flux d'entrées par l'appel système TIOCSTI iocti.

SystemTap Re-Base

SystemTap a été re-basé sur la version 0.7.2. Cette mise à jour de SystemTap introduit plusieurs légères améliorations, ainsi que certaines fonctionnalités importantes. Ces nouvelles fonctionnalités comprennent :

  • SystemTap supporte maintenant le sondage symbolique sur les architectures PowerPC, x86, x86-64. Cela permet aux scripts SystemTap de placer des sondes dans les applications d'espace-utilisateur et dans les bibliothèques partagées. Ainsi, SystemTap peut maintenant fournir le même niveau de sondage de débogage que le sondage de noyau sur les applications d'espace-utilisateur.

    Ainsi, si coreutils-debuginfo est installé, vous pouvez imprimer un callgraph (graphique d'appels) de la commande ls en utilisant /usr/share/doc/systemtap-version/examples/general/callgraph.stp, comme dans:

    stap para-callgraph.stp 'process("ls").function("*")' -c 'ls -l'

    Afin de pouvoir réduire la possibilité d'une incompatibilité de versoin non détectée entre le binaire et ses RPM debuginfo, Red Hat vous conseille d'utiliser la variable d'environnement SYSTEMTAP_DEBUGINFO_PATH pour la valeur siuvante : +:.debug:/usr/lib/debug:build.

    Le support de sondages symboliques SystemTap s'étend aussi aux marqueurs placés dans le noyau de cette version. Pour utiliser ces marqueurs, chargez le module de noyau kernel-trace dans /etc/rc.local (en utilisant modprobe kernel-trace).

  • SystemTap prend également en charge les services de compilation distants. Cela permet à un ordinateur de se comporter sur le réseau comme un serveur deboginfo/compiler pour les clients SystemTap locaux. Les clients auto-localisent le serveur en utilisant mDNS (avahi), et a seulement besoin des paquetages systemtap-client et de systemtap-runtime pour fonctionner.

    A présent, cette fonctionnalité n'utilise pas de mécanismes de sécurité comme le cryptage. Donc, il est conseillé d'utiliser les services de compilation à distance. Pour davantage d'informations, veuillez consulter man stap-server.

  • La mise à jour du noyau de cette version inclut une extension API de noyau qui améliore énormément la fermeture des scripts SystemTap. Cette extension API de noyau ajoutée, élimine la synchronisation inutile entre les opérations de retrait de probes individuelles. De ce fait, les scripts SystemTap qui comptent des centaines de probes de noyaux sont traités plus rapidement.

    C'est surtout utile pour les administrateurs qui utilisent des scripts avec des probes qui contiennent des caractères de remplacement qui capturent de nombreux événements de noyau, comme probe syscall.* {}.

Pour une liste complète des mises à jour de SystemTap inclus dans cette version, veuillez consulter l'URL suivant :

http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=blob_plain;f=NEWS;hb=rhel53

Mise à jour du gestionnaire de clusters

L'utilitaire du gestionnaire de clusters (cman) a été mis à jour à la version 2.0.97. Cette version comprend maintenant les améliorations principales suivantes :

  • cman utilise maintenant les versions de microprocesseurs suivantes : APC AOS v3.5.7 and APC rpdu v3.5.6. Cela apporte la solution à un bogue qui empêchait APC 7901 d'utiliser le protocole de gestion de réseau simple (SNMP) correctement.

  • Les agents fence_drac, fence_ilo, fence_egenera, et fence_bladecenter prennent maintenant en charge ssh.

  • Les fichiers clé fence_xvmd sont maintenant rechargés sans besoin de nouveau démarrage.

  • Une méthode simple de clôture peut maintenant prendre en charge jusqu'à 8 périphériques de clôture.

sudo Re-base

sudo a été ré-basé sur la version en amont 1.6.9. Cette version de sudo prend maintenant en charge LDAP, et permet d'effectuer des recherches au niveau des sous-arborescences, à la place de recherches de base (c'est à dire au niveau de l'arborescence simplement) pour les privilèges sudo rights. Cela permet aux administrateurs de ranger les privilèges sudo par catégories, rendant ainsi les privilèges d'utilisation plus faciles à gérer.

RPM Re-Base

Le RedHat Package Manager (RPM) est maintenant ré-aligné sur la version en amont de Fedora 9. rpm ajoute maintenant des fichiers macro particuliers à l'architecture secondaire sur les systèmes multi-arch. De plus, rpm remplit maintenant tous les critères de certification pour son inclusion dans Red Hat Enterprise Linux 5.

Cette mise à jour applique à rpm plusieurs améliorations en amont et des résolutions de bogues, y compris :

  • rpm ne génère plus de fichiers inutiles .rpmnew ou .rpmsave sur les systèmes multi-arch.

  • Un bogue dans la fonction rpmgiNext() de rpm empêche de reporter les erreurs correctement. Cette mise à jour applique la sémantique qui s'applique au report d'erreurs, garantissant ainsi que rpm retourne le code de sortie correct pour toutes les instances.

Open Fabrics Enterprise Distribution (OFED) / opensm

opensm a été mis à jour vers la version en amont 3.2, qui comprend un changement mineur par rapport à l'API de bibliothèque opensm.

  • Le format du fichier opensm.conf a changé. Si vous avez fait des modifications pour personnaliser votre fichier opensm.conf existant, rpm va automatiquement installer le nouveau fichier opensm.conf en tant que /etc/ofed/opensm.conf.rpmnew. Vous aurez tout simplement besoin de faire migrer vos modifications vers ce fichier, puis de remplacer le fichier opensm.config existant par le résultat.

  • Red Hat surveille de près la base code OFED (Open Fabrics Enterprise Distribution) pour pouvoir fournir un niveau maximum de capacités à cette technologie en pleine évolution. Ainsi, Red Hat ne peut préserver la compatibilité API/ABI qu'à travers quelques versions de sortie mineures au même niveau que celui du projet en amont. Il s'agit d'une exception des bonnes pratiques du développement de Red Hat Enterprise Linux.

    De ce fait, les applications construites au dessus de la pile OFED (listée ci-dessous), auraient peut-être besoin de changements de recompilation ou même des codes au niveau-source quand on passe d'une version mineur de Red Hat Enterprise Linux à une autre plus récente.

    Cela n'est généralement pas utile pour les autres applications, qui sont construites sur la pile informatique Red Hat Enterprise Linux. Les composants affectés sont les suivants :

    • dapl

    • compat-dapl

    • ibsim

    • ibutils

    • infiniband-diags

    • libcxgb3

    • libehca

    • libibcm

    • libibcommon

    • libibmad

    • libibumad

    • libibverbs

    • libipathverbs

    • libmlx4

    • libmthca

    • libnes

    • librmdacm

    • libsdp

    • mpi-selector

    • mpitests

    • mstflint

    • mvapich

    • mvapich2

    • ofed-docs

    • openib

    • openib-mstflint

    • openib-perftest

    • openib-tvflash

    • openmpi

    • opensm

    • perftest

    • qlvnictools

    • qperf

    • rds-tools (futur)

    • srptools

    • tvflash

Net-SNMP Re-Base

Net-SNMP a été ré-aligné sur la version en amont 5.3.2.2. Cette mise à jour ajoute son support au protocole Stream Control Transmission Protocol (SCTP) (comme pour RFC 3873, http://www.ietf.org/rfc/rfc3873.txt) et introduit deux nouvelles options de configuration (à utiliser dans /etc/snmpd.conf):

  • dontLogTCPWrappersConnects -- supprime le logging des tentatives de connexions.

  • v1trapaddress -- permet aux administrateurs de créer une adresse IP d'agent dans les traps SNMP sortants.

Cette mise à jour apporte plusieurs améliorations en amont, y compris :

  • Le démon snmpd fonctionne maintenant correctement sur des systèmes de plus de 255 interfaces de réseau. De plus, snmpd reporte également une erreur lorsqu'il est configuré pour écouter à un port au dessus de 65535.

  • Un état de concurrence qui entraîne le démon snmpd à dévoiler des descripteurs de fichiers lorsqu'ils lisent /proc est maintenant résolu.

  • Le démon snmpd reporte maintenant correctement les IDs d'objet (OID)hrProcessorLoad, même sur le matériel multi-CPU. Notez, cependant, qu'il faut environ une minute à partir du démarrage du démon pour calculer la valeur de l'OID.

  • Le paquetage net-snmp-devel dépend maintenant du paquetage lm_sensors-devel.

OpenSSL Re-Base pour la certification FIPS

Les paquetages openssl mettent à niveau la bibliothèque OpenSSL vers une nouvelle version en amont, qui est actuellement sous procédure de validation aux standards Federal Information Processing Standards (FIPS-140-2). Le mode FIPS est désactivé par défaut, pour veiller à ce que la bibliothèque OpenSSL maintienne une parité fonctionnelle et une compatibilité API avec les versions précédentes des paquetages mode openssl de Red Hat Enterprise Linux 5.

Cette mise à jour apporte également les changements suivants en amont :

  • Par défaut, la compression zlib est utilisée pour les connexions SSL et TLS. Sur les architectures IBM System z possédant Central Processor Assist pour Cryptographic Function (CPACF), la compression est devenue le gros de la charge CPU, et la performance générale était déterminée par la vitesse de la compression (et non pas la vitesse de cryptage). Quand la compression était désactivée, la performance générale est bien supérieure. Dans ces paquetages mis à jour, la compression zlib pour les connexions SSL et TLS peuvent être désactivées par la variable d'environnement OPENSSL_NO_DEFAULT_ZLIB. Pour les connexions TLS sur un réseau lent, il vaut mieux laisser la compression active, de façon à ce que le montant de données à transférer soit réduit.

  • Lorsqu'on utilise la commande openssl avec les options s_client et s_server, le fichier de certificats CA par défaut (/etc/pki/tls/certs/ca-bundle.crt) n'était pas lu. Cela aboutissait à des certificats non vérifiés. Pour que les certificats passent la vérification, l'option -CAfile /etc/pki/tls/certs/ca-bundle.crt devait être utilisée. Dans ces paquetages mis à jour, le fichier de certificats CA par défaut est lu, et n'a plus besoin d'être spécifié par l'option -CAfile.

yum Re-Base

yum a été re-aligné sur la version en amont 3.2.18. Cette mise à jour améliore la vitesse à laquelle yum opère, en redressant ainsi le problème posé par le nombre de paquetages grandissant sans cesse dans chaque nouvelle version, De plus, cette mise à jour introduit également la commande 'reinstall', améliorant l'interface entre plusieurs commandes, et appliquant plusieurs résolutions de bogues, y compris :

  • Toute commande yum serait mise en échec si l'option -c était utilisée pour spécifier un fichier de configuration résidant sur une adresse web (http). Ce bogue est maintenant résolu.

  • Une focntion checkSignal() de yum a appelé une fonction de sortie incorrecte, et de ce fait, le yum actuel résulterait en un traceback à la place. Yum fait une sortie correcte dans ces nouvelles notes de sortie mises à jour.

flash-plugin Re-Base

Le paquetage flash-plugin a été re-basé sur la version 10.0.12.36. Cette mise à jour applique plusieurs résolutions de sécurité qui étaient incluses dans une mise à jour précédente ASYNC flash-plugin. De plus, ce plug-in mis à jour contient également flash-plugin, qui inclut les résolutions de bogues et les améliorations de fonctionnalité suivantes :

  • Amélioration de la stabilité de la plate-forme Linux par la résolution de l'état de concurrence dans la sortie son.

  • Nouveau support pour les filtres et les effets personnalisés, la transformation 3D et l'animation, le traitement audio avancé, un nouveau text engine plus flexible et une accélération du matériel GPU.

Pour davantage d'informations sur cette mise à jour, consultez les notes de sortie Adobe Flash Player 10 sur le lien suivant :

http://www.adobe.com/support/documentation/en/flashplayer/10/Flash_Player_10_Release_Notes.pdf

gdb Rebase

gdb est basé à nouveau sur la version 6.8. Cela permet d'appliquer plusieurs mises à jour de fonctionnalités en amont et de réparations de bogues, et plus particulièrement : un support pour les points d'interruption dans les modèles C++, les constructeurs et les fonctions enligne.

Pour davantage d'information sur les mises à jour de gdb appliquées dans cette version, consultez http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/NEWS?rev=1.259.2.1&cvsroot=src.

IBS (de l'anglais Instrution Based Samplings / Echantillons basés-instruction) sur des processeurs AMD Family10h

Un support de profilage de nouveau matériel pour les processeurs AMD Family10h a été ajouté à Red Hat Enterprise Linux 5.3. Ces nouveaux CPU AMD supportent les ISB (Instruction Based Samplings). Le support exige quelques changements au niveau du pilote oProfile pour récupérer cette information et pour initialiser les nouveaux MSR (Model Specific Registers / Registres spécifiques aux modèles) associés à ces nouvelles fonctionnalités.

Cette mise à jour ajoute les nouveaux échantillons de profilage IBS_FETCH et IBS_OP aux tampons par CPU et aux tampons événement. Des nouvelles entrées de contrôle ont également été ajoutées au /dev/oprofile pour contrôler les échantillons IBS. Ces changements sont rétro-compatibles avec l'unique version antérieure PMC du pilote, et une retouche séparée est disponible à oProfile 0.9.3 pour utiliser ces nouvelles données.

Pour plus d'informations sur IBS, consultez le document: Instruction-Based Sampling: A New Performance Analysis Technique for AMD Family 10h Processors, November 19, 2007

Squid Re-base

Squid a été re-basé sur la dernière version stable en amont (STABLE21). Cette mise à jour résout plusieurs bogues, notamment :

  • Le script squid init retournait toujours un code de sortie de 0 par erreur. Ce bogue est maintenant résolu, rendant ainsi squid compatible avec Linux Standard Base.

  • L'utilisation de la directive refresh_stale_hit cause le message d'erreur Clock going backwards (horloge qui va en sens inverse) dans le fichier de journalisation de squid.

  • Le processus d'installation squidn'a pas été configuré avec la propriété convenable du répertoire/usr/local/squid. Grâce à cette nouvelle version, squid est maintenant le propriétaire par défaut de /usr/local/squid.

  • A chaque fois que squid tente d'utiliser la fonction hash_lookup(), il peut abandonner avec signal 6.

  • L'utilisation de squid_unix_group pourrait entraîner l'échec de squid.

Evênement MPM (de l'anglais Multi Processing Model / Modèle multi-traitement) dans Apache

httpd, le paquetage Apache HTTP Server package, inclut maintenant le Multi-Processing Model (MPM) expérimental event. Ce MPM améliore la performance en utilisant des threads spécialement dédiés pour gérer les connexions keepalive.

Mise à jour de l'audit

Le paquetage d'audit comprends des utilitaires espace-utilisateur pour stocker et chercher des enregistrements d'audit qui auraient été enregistrés dans le sous-système de l'audit dans le noyau. Les paquetages audit ont été mis à jour vers la nouvelle version en amont 1.7.7, qui fournit des améliorations et des résolutions de bogues par rapport aux paquetages d'audit précédents.

Ces paquetages d'audit précédents mis à jour apportent les améliorations suivantes :

  • Le système d'audit est maintenant capable d'opérer la journalisation à distance.

  • l'utilitaire auditctl prend maintenant en charge les clés multiples des règles d'audit.

  • un échantillon de fichier de règles STIG (stig.rule) qui contient des règles auditctl, qui sont chargées quand le démon audit est démarré par les scripts init, est maintenant fourni comme exemple dans ces paquetages misà jour.

  • Un nouvel utilitaire, ausyscall, a été ajouté dans le but de croiser les références entre les noms de syscall et le nombre d'information.

  • aureport fournit maintenant un rapport sur les clés qu'il voit dans les événements audit.

  • Le parsage de la journalisation des événements pour les programmes ausearch et aureport ont été améliorés.

libgomp re-base

libgomp a été basé à nouveau sur la version 4.3.2-7.el5. Cela améliore la performance OpenMP et ajoute un support à OpenMP version 3.0 lorsqu'il est utilisé avec le compilateur gcc43.

Capacité de ciblage d'iSCSI

La capacité de ciblage d'ISCSI, fournie avec l'infrastructure de développement Linux Target (tgt), passe de l'aperçu technologique à la totale prise en charge par Red Hat Enterprise Linux 5.3. L'infrastructure de ciblage Linux permet à un système de servir le stockage SCSI niveau-block à d'autres systèmes dotés d'un initiateur SCSI. Cette capacité est tout d'abord déployée en tant que cible iSCSI, servant le stockage à travers un réseau vers n'importe quel initiateur iSCSI.

Pour configurer la cible iSCSI, installer le RPM scsi-target-utils et consulter les instructions dans : /usr/share/doc/scsi-target-utils-[version]/README et /usr/share/doc/scsi-target-utils-[version]/README.iscsi

3. Mises à jour des pilotes

3.1. Toutes les architectures

Mises à jour générales des pilotes/plate-formes
  • Le pilote audio Intel High Definition Audio d'ALSA a été mis à jour.

  • Le support audio High-Definition Multimedia Interface (HDMI) est maintenant supporté sur les chipsets intégrés AMD ATI.

  • Les chipsets suivants sont maintenant supportés par les pilotes linuxwacom:

    • Cintiq 20WSX

    • Intuos3 4x6

  • le pilote lpfc pour les adaptateurs Emulex Fibre Channel Host Bus ont été mis à jour à la version 8.2.0.33.2p. . Cette mise à niveau apporte plusieurs changements en amont, notamment :

    • le socket NETLINK_SCSITRANSPORT est maintenant utilisé

    • Accès noeud non initialisé résolu.

    • a réparé un bogue qui causait l'échec de l'échotest quand NPIV était activé.

    • fcauthd 1.19 est maintenant exigé pour l'authentification Fibre channel.

  • dm-multipath a maintenant le support corbeille d'arrivée pour IBM DS4000.

  • le pilote ixgbe: supporte maintenant l'adaptateur à port-double 82598AT et l'adaptateur 82598 CX4.

  • le pilote jsm a été mis à jour pour ajouter son support aux adaptateurs E/S Digi Neo PCI Express 4 HiProfile.

  • hp-ilo: pilote ajouté, procurant son support pour la technologie HP Integrated Lights Out (iLO) .

  • Le pilote radeon_tp est maintenant inclus dans cette nouvelle version. Ce pilote active les chipsets ATI R500/R600.

    Le pilote est également capable de :

    • Chipsets de réglage de mode sur R500/R600

    • Chipsets d'accélération 2D sur R500

    • Chipsets d'accélération du framebuffer (tampon de trame) double sur R600

  • Le pilote powernow-k8 est maintenant inclus dans cette version en tant que module chargeable. Cela permet aux structures existantes du pilote (comme le Red Hat Driver Update Model ou Dell DKMS) puissent délivrer des mises à jour du pilote powernow-k8 aux utilisateurs sous forme de paquetages RPM, sans avoir à mettre le noyau à niveau.

  • Pour cette version, Red Hat rajoute pnm2ppa pour pouvoir prendre en charge les anciennes imprimantes. Notez, cependant, que ce support est déprécié et ne continuera pas dans les versions majeures à venir.

  • Le pilote ccid a été re-basé pour ajouter son support aux claviers Smartcard USB.

  • les pilotes uvcvideo pour les périphériques video USB ont été ajoutés au noyau dans Red Hat Enterprise Linux 5.3.

Réseau
  • Le pilote bnx2 pour les cartes d'interface réseau Broadcom NetXtreme II a été mis à jour à la version 1.7.9. Cette mise à jour règle le problème des options éthernet 'ring buffer' sur les contrôleurs qui utilisent bnx2 pour régler un bogue qui aurait entraîné la panique du système au démarrage.

  • Le pilote e1000e des périphériques Intel PRO/1000 éthernet ont été mis à jour pour la version en amont de la version 0.3.3.3-k2. Avec cette mise à jour, les EEPROM et NVM des périphériques pris en charge, sont maintenant protégé-écriture.

  • igb: pilote pour IntelGigabit Ethernet Adapters a été mis à jour à la version 1.2.45-k2, ajoutant son support pour les périphériques basés 82576.

  • le pilote ixgbe pour les périphériques de réseau Intel(R) 10 Gigabit PCI Express a été mis à jour à la version 1.3.18-k4.

  • le pilote niu a été ajouté à Red Hat Enterprise Linux 5.3, ajoutant son support aux périphériques 10Gbps éthernet sur les systèmes Sun CP3220 .

  • les pilotes ipw2100 et ipw2200 des périphériques Intel PRO Sans fil ont été rétro-ajustés dans Red Hat Enterprise Linux 5.3 de Linux Kernel 2.6.25.

  • le pilote bcm43xx pour les périphériques Broadcom sans fil ont été réalignés dans Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.25.

  • Le composant de support ieee80211 pour les périphériques sans fil a été réalignés dans Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.25.

  • le pilote zd1211rw pour les périphériques ZyDas a été mis à jour pour correspondre à la dernière version non-mac80211 précédant de peu Linux 2.6.25.

  • Le pilotes iwlwifi ont été mis à jour depuis versions 2.6.26, ajoutant le support 802.11n aux périphériques sans fil iwl4965. De nombreuses solutions de bogues incluses dans les versions post-2.6.26 du pilote ont également été incorporées dans le pilote.

  • Le pilote myri10ge des périphériques Myricom Myri-10G Ethernet a été mis à jour à la version 1.3.2-10269

  • Pilote netxen pour les cartes réseau NetXen mis à jour vers la version 3.4.18.

  • Le pilote bnx2 pour les périphériques de réseau Broadcom Everest : mis à niveau vers la version 1.45.23 pour la prise en charge du matériel 57711.

  • Le pilote forcedeth-msi a été mis à jour pour réparer un bogue qui empêchait une bonne détection de jonction.

  • le pilote ath5k des périphériques Atheros sans fil a été réaligné sur Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.26.

  • les pilotes rt2x00 pour les périphériques Ralink ont été réalignés pour Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.26.

  • les pilotes rtl8180 et rtl8187 pour les périphériques Realtek sans fil ont été réalignés dans Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.26.

  • cxgb3: pilote maintenant inclus dans cette version (avec les micrologiciels correspondants). Ce pilote prend en charge l'adaptateur Chelsio RDMA 10Gb PCI-E Ethernet.

Stockage
  • 3w-xxxx: pilote pour les contrôleurs 3ware SATA RAID mis à jour à la version 1.26.03. On applique plusieurs changements en amont, notamment :

    • Solution de bogue qui a causé des corruptions de données au cours de l'utilisation des cartes de série 3ware 7000 ou 8000 dans un système de plus de 2GB de RAM.

    • Anaconda ne repose plus sur des architectures 64-bit avec l'utilisation de cartes de séries 3ware 8006 dans un système de plus de 4Go de RAM.

    • Le gestionnaire d'irq est maintenant libéré quand __tw_shutdown() est initié. Cela empêche la possibilité d'un pointer null de-référence si une interruption a été partagée pendant la fermeture.

    • RCD bit pour la page en cache mode est maintenant activé.

    • Les resets ioctl et scsi sont maintenant sérialisés de façon à ce qu'ils n'entrent pas en collision.

  • 3w-9xxx: pilote pour les contrôleurs 3ware SATA RAID mis à jour à la version 2.26.08. Cette mise à jour apporte plusieurs changements en amont, notamment :

    • L'appel pci_unmap_single() fonctionne correctement maintenant sur les systèmes supérieurs à 4Go de RAM

    • Solution de bogue qui causait le ralentissement de la performance d'écriture.

    • La configuration du mask DMA retourne à 32-bit si 64-bit échoue.

    • Support ajouté pour le périphérique de contrôle 3ware 9690SA SAS.

  • megaraid_sas: mis à jour pour la version 4.01-rh1. Cette mise à jour apporte plusieurs changements, notamment :

    • MFI_POLL_TIMEOUT_SECS ne dure plus que 60 secondes.

    • A réglé un bogue qui a causé des resets de puces continus et des délais de commande pour cause de comptage par image.

    • Support ajouté au LSI Generation 2 Controllers (0078, 0079).

    • A ajouté une commande pour fermer DCMD dans la phase routinière de fermeture pour améliorer la fermeture des micrologiciels.

    • A réglé un bogue qui a causé des interruptions impromptues du pilote Linux du matériel.

  • L'infrastructure du gestionnaire de périphériques SCSI (scsi_dh) a été mise à jour, offrant les améliorations suivantes :

    • un gestionnaire générique ALUA (accès à l'unité logique asymétrique) a été implémenté.

    • support supplémentaire pour les périphériques de stockage basés LSI RDAC SCSI.

  • le pilote qla2xxx pour les adaptateurs QLogic Fibre Channel Host Bus a été ajouté, ajoutant un support pour les cartes de type ISP84XX.

  • les pilotes ibmvscsi pour émuler les périphériques SCSI (vSCSI) ont été mis à jour, procurant leur support aux équipements à bande virtualisés.

  • le pilote lpfc: mis à jour pour la version 8.2.0.30. Cette mise à jour apporte plusieurs changements, notamment:

    • Une gestion des erreurs EEH (de l'anglais Enhanced Error Handling) améliorée pour les adaptateurs PCI sur les architectures PowerPC.

    • Augmentation du nombre de ports virtuels NPIV pris en charge.

    • Logique du pilote améliorée pour contrôler la taille de la file d'attente E/S

    • Support ajouté pour Fibre Channel sur les adaptateurs (FCoE) Ethernet

    • Initialisation à partir de SAN est maintenant prise en charge pour le nouveau matériel.

  • the cciss driver for HP Smart Array controllers has been updated to version 3.6.20-RH2.

4.1. Toutes les architectures

  • relayfs avait auparavant une taille de mémoire tampon limitée à 64Mo. Dans cette mise à jour, la taille de la mémoire allouée à relayfs pour les on-memory buffers a été augmentée à 4095MB. Cela permet à SystemTap et aux autres outils de traçage qui utilisent relayfs la possibilité de garder la trace de davantage d'événements.

  • Le pilote de Dell Remote Access Controller 4 (DRAC4) n'était pas présent. De ce fait, tous les périphériques virtuels fournis par DRAC4 n'étaient pas détectés par le noyau. Dans cette mise à jour, le module de noyau pata_sil680 qui fournit le pilote qui convient, a été ajouté, ce qui règle ce problème.

  • Les tampons/régulateurs de messages de l'interface relais étaient uniquement alloués aux CPU en ligne quand relay_open() était appelé. Par conséquence, si un CPU hors-ligne était activé après que relay_open() a été appelé, on assistait à une panique de noyau. Dans cette mise à jour, un nouveau tampon/régulateur de message est alloué de façon dynamique si un nouveau CPU est ajouté.

  • Le pilote pour les ports de série basés 8250 a été mis à jour pour ajouter son support au contrôle de flux du matériel DSR/DTR.

  • La prise en charge des cartes Dell Wireless Wide Area Network (WWAN) ont été ajoutées au noyau. Les périphériques qui ne sont pas pris en charge sont :

    • Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card

    • Dell Wireless 5500 Mobile Broadband HSDPA Mini-Card

    • Dell Wireless 5505 Mobile Broadband HSDPA Mini-Card

    • Dell Wireless 5700 Mobile Broadband CDMA/EVDO ExpressCard

    • Dell Wireless 5510 Mobile Broadband HSDPA ExpressCard

    • Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card

    • Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card

    • Dell Wireless 5720

    • Dell Wireless HSDPA 5520

    • Dell Wireless HSDPA 5520

    • Dell Wireless 5520 Voda I Mobile Broadband (3G HSDPA) Mini-Card

  • Le module de noyau thinkpad_acpi a été mis à jour pour offrir un meilleur support aux nouveaux modèles Thinkpad.

  • Le logiciel détecteur de verrouillage peut maintenant être configuré pour déclencher une panique de noyau à la place d'un message d'avertissement. Cela permet aux utilisateurs de générer et d'analyser un vidage sur incident au cours d'un verrouillage déclenché dans des buts d'investigation.

    Pour configurer le détecteur de verrouillage pour créer une panique, fixer le paramètre de noyau soft_lockup à 1. Ce paramètre est normalement fixé à 0par défaut.

  • oprofile n'identifiait par correctement les processeurs basés sur la Next-Generation Intel Microarchitecture (du nom de code "Nehalem".). De ce fait, l'unité de contrôle de la performance ne pouvait pas être utilisée et le processeur se repliait suite à l'interruption de l'horloge. Le noyau a du être mis à jour pour régler ce problème.

  • On a ajouté un support au noyau pour l'état de puissance CPU, C3, sur Next-Generation Intel Microarchitecture (du nom de code "Nehalem"). Le fait qu'on puisse entrer C3 (également connu sous le nom d'état dormant) améliore l'efficacité de la puissance du CPU lorsqu'il est au repos.

  • Auparavant, la limite MAX_ARG_PAGES qui est fixée pour le noyau était trop basse, et pouvait entraîner l'erreur suivante :

    execve: Argument list too long
    Dans cette mise à jour, cette limite a été portée à 25% de la taille de la pile, ce qui résout ce problème.

  • Les mises à jour de autofs4 ont été transférées à Red Hat Enterprise Linux 5.3 depuis linux kernel version 2.6.27.

  • Red Hat Enterprise Linux 5.3 comprend maintenant la possibilité de spécifier que les fichiers principaux soient transmis (piped) dans une copie à fourche (forked) d'une application d'espace utilisateur, plutôt que directement dans un fichier. Cela est rendu possible en plaçant | path/to/applicationdans /proc/sys/kernel/core_pattern. Quand le core

  • Le fichier /proc/cpuinfo rapporte maintenant l'ID de l'Advanced Programmable Interrupt Controller (APIC) qui est utilisé par chaque individuel CPU.

  • Le sous-système du noyau de Machine Check Exception (MCE) a été amélioré pour pouvoir prendre ne charge des configurations de mémoires plus grandes, suivant les besoins des nouveaux systèmes.

  • La commande de montage prend maintenant en charge l'authentification au moment du montage de systèmes via Samba. Les commutateurs sec=krb5 ou sec=krb5i permet au noyau d'appeler une application espace-utilisateur (cifs.upcall) qui retourne un blob de sécurité (Objet binaire) SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism).

  • Si vousconfigurez le paramètre de noyau kernel.unknown_nmi_panic sur un système qui utilisait la méthode de surveillance IOAPIC NMI, cela peut résulter par une panique de noyau. Cela est dû au fait que le système de surveillance NMI n'était pas en mesure de désactiver la source des NMI en toute sécurité.

    Dans cette version, le code du système de surveillance NMI a été révisé pour permettre aux utilisateurs de désactiver la source NMI en toute sécurité. Ainsi, vouspouvez maintenant configurer le paramètre du noyau en toute sécurité kernel.unknown_nmi_panic sur des systèmes qui utilisent la méthode de surveillance IOAPIC NMI.

4.2. Architectures x86

  • Le pilote powernowk8 n'opérait pas suffisamment de contrôle sur le nombre de CPU en cours d'exécution. De ce fait, quand le pilote était démarré, un message d'erreur 'oops' de noyau pourrait était susceptible d'apparaître. Dans cette mise à jour, le pilote powernowk8 vérifie que le nombre de CPU pris en charge (supported_cpus) correspond au nombre de CPU en ligne (num_online_cpus), ce qui résout ce problème.

4.3. Architectures PowerPC

  • CPUFreq, le sous-système de noyau qui cadre le voltage et la fréquence CPU, a été mis à jour par un support amélioré des unités de traitement par cellule. Cette mise à jour implémente un CPUFreq governor - SPU (de l'anglais Synergistic Processing Unit / Unité de traitement synergétique) qui améliore la capacité de gestion des unités de traitement par cellule.

  • Error Detection and Correction (EDAC) est maintenant pris en charge par l'architecture Cell Broadband Engine de Red Hat Enterprise Linux 5.3. Pour activer EDAC, utiliser la commande: modprobe cell_edac

    Pour vérifier que ce module a bien été ajouté à votre noyau en cours d'exécution, vérifiez les sorties de /var/log/dmesg de la sorte :

    EDAC MC: Ver: 2.0.1 Oct  4 2008
    EDAC MC0: Giving out device to cell_edac MIC: DEV cbe-mic
    EDAC MC1: Giving out device to cell_edac MIC: DEV cbe-mic

    Si vous rencontrez des erreurs de mémoire auxquelles on peut remédier, le message suivant retournera à la console :

    EDAC MC0: CE page 0xeff, offset 0x5700, grain 0, syndrome 0x51, row 0, channel
    0, label "":
  • Déboguer à l'aide de points d'observation particuliers du matériels, en utilisant une variable qui est partagée entre les threads multiples qui entraîne le Débogueur GNU (GDB) à manquer erratiquement les événements responsables. Le noyau a été mis à jour pour permettre au GDB de recevoir régulièrement les éléments responsables sur les points d'observation, pour améliorer la qualité de la session de déboggage.

4.4. Architectures x86_64

  • kprobe-booster est maintenant pris en charge par les architectures ia64 et x86_64, qui permettent aux utilisateurs de tester des événements de noyau plus rapidement. Cette fonctionnalité permettra de diminuer la charge causée par les outils de sondage (par ex. SystemTap et Kprobes) sur les serveurs exécutés sur des architectures 64-bit.

  • On a ajouté un support pour le noyau de _PTC (Processor Throttling Control), _TSS (Throttling Supported States) et des objets _TPC (Throttling Present Capabilities) . Ce support, qui fait partie d'Advance Configuration and Power Interface specification (ACPI) propose une meilleure gestion du contrôle du processeur.

4.5. Architectures s390x

  • Dans zipl.conf, les paramètres entourés de doubles guillemets à l'intérieur de guillemets (c'est à dire parameters='vmhalt="LOGOFF"') ont été analysés de manière erronée. De ce fait, l'installation du paquetage kernel-kdump pourrait avoir échoué, résultant par l'erreur :

    grubby fatal error: unable to find a suitable template
    Pour résoudre ce problème, les paramètres devraient être entourés de guillemets à l'intérieur de doubles guillemets (c'est à dire parameters="vmhalt='LOGOFF'")

    Note

    La structure syntaxique des guillemets à l'intérieur des doubles guillemets est la structure par défaut dans Red Hat Enterprise Linux 5.

4.6. Architectures ia64

  • Le processeur Dual-Core Intel Itanium 2 remplissait le enregistrement d'architecture (MCA) différemment des processeurs Itanium Intel précédents. Les identifiants cibles de vérification de mise en cache et de bus peuvent maintenant différer dans certaines circonstances. Le noyau a été mis à jour pour trouver l'identifiant cible qui convient.

  • kprobe-booster est maintenant pris en charge par les architectures ia64 et x86_64, qui permettent aux utilisateurs de tester des événements de noyau plus rapidement. Cette fonctionnalité permettra de diminuer la charge causée par les outils de sondage (par ex. SystemTap et Kprobes) sur les serveurs exécutés sur des architectures 64-bit.

  • Dans cette mise à jour, le support pour les appels de systèmes pselect() et ppoll() ont été ajouté au noyau.

5. Virtualisation

Cette section contient des informations de mise à jour pour Red Hat Enterprise Linux suite d'outils de virtualisation.

5.1. Mises à jour de fonctionnalités

  • La boîte à outil d'espace utilisateur blktap (blocktap) a été mise à jour, fournissant la fonctionnalité qu'il faut pour contrôler le transfert de statistiques des invités virtuels possédant blktap.

  • On a ajouté un support à la fonctionnalité Intel EPT (Extended Page Table), pour améliorer la performance des invités pleinement virtuels sur le matériel qui supporte EPT.

  • L'émulation du périphérique réseaue1000 pour les invités, a été ajouté à cette mise à jour, prenant en charge les invités Windows 2003 sur l'architecture ia64. Pour utiliser l'émulation e1000, la commande xm doit être utilisée.

  • Les pilotes pour virtio, la plateforme pour la virtualisation E/S dans KVM, ont été réactualisés dans Red Hat Enterprise Linux 5.3 depuis Linux Kernel 2.6.27. Ces pilotes vont permettre aux invités KVM de réaliser des niveaux de performance E/S plus élevés. De nombreux composants d'espace utilisateur comme : anaconda, kudzu, lvm, selinux et mkinitrd ont également été mis à jour pour prendre en charge les périphériques virtio.

  • Le noyau natif Linux supporte vmcoreinfo automatiquement, mais, pour configurer les domaines kdump sur dom0, on avait besoin du paquetage kernel-xen-debuginfo Dans cette mise à jour, le noyau et l'hyperviseur ont été modifiés et supportent maintenant vmcoreinfo lisant et écrivant kdump nativement. Les utilisateurs qui ont besoin d'utiliser kdump pour débboguer ou pour procéder à toute autre recherche sur dom0, peuvent maintenant le faire sans installer les paquetages debuginfo ou debuginfo-common .

  • Les invités pleinement virtuels Red Hat Enterprise Linux 5 rencontraient une performance sous-optimale lorsqu'ils utilisaient les périphériques de réseau et les disques émulés. Dans cette mise à jour, le paquetage kmod-xenpv a été inclus pour simplifier l'utilisation des réseaux et des disques paravirtuels pour les invités pleinement virtuels.

    L'utilisation de ces pilotes pour les invités pleinement virtuels peut énormément améliorer la performance et la fonctionnalité des invités pleinement virtuels. Les résolutions de bogues pour les pilotes block front et netfront sont effectuées et synchronisées immédiatement dans le paquetage du noyau.

  • Les invités ont la possibilité d'utiliser les tables de mémoire de pages de sauvegarde de 2 Mo, qui peuvent améliorer la performance du système.

5.2. Problèmes résolus

5.2.1. Toutes les architectures

  • Fermer un invité paravirtuel aurait pu entraîner dom0 à cesser de répondre pendant un certain temps. Certains invités possédant des grands volumes de mémoire (comme par ex. 12 Go et plus) ont pu connaître des délais de plusieurs secondes. Dans cette mise à jour, le noyau virtuel permet que la fermeture d'un grand nombre d'invités paravirtuels soit agrémentée d'un droit de préemption, ce qui résout ce problème.

  • crash n'était pas en mesure de lire l'adresse de relocalisation de l'hyperviseur à partir d'un fichier vmcore. De ce fait, l'ouverture d'un fichier vmcore de noyau virtuel avec crash échouait, résultant à l'erreur :

    crash: cannot resolve "idle_pg_table_4"
    Dans cette mise à jour, l'hyperviseur sauvegarde maintenant l'adresse correctement, ce qui résout ce problème.

  • Auparavant, les invités paravirtuels ne pouvaient accumuler que 16 disques au maximum. Dans cette mise à jour, cette limite a été augmentée à 256.

  • La mémoire allouée au noyau kdump était incorrecte, résultant à des vidages sur incidents inutilisables. Dans cette mise à jour, l'allocation de mémoire a été rectifiée, ce qui permet la génération de vidages sur incidents correcte.

  • Attacher un nom précis à un disque (c'est à dire /dev/xvdaa, /dev/xvdab, /dev/xvdbc etc.) d'un invité paravirtuel aboutissait à un périphérique corrompu /dev à l'intérieur d'un invité. Cette mise à jour a résolu ce problème de façon à ce qu'attacher ces noms aux disques d'un invité paravirtuel crée le périphérique /dev qui convient à l'intérieur de l'invité.

  • Auparavant, le nombre de périphériques de bouclage était limité à 4. Cela limitait donc la possibilité de créer des ponts sur des systèmes comprenant plus de 4 interfaces de réseau. Dans cette mise à jour, le pilote netloop peut maintenant créer des périphériques de bouclage supplémentaires suivant les besoins.

  • On peut faire face à un état de concurrence lors de la création ou de la destruction de périphériques de réseaux virtuels. Dans certaines circonstances - surtout dans les situations de charges importantes - cela amenait le périphérique virtuel à ne pas répondre. Dans cette mise à jour, l'état du périphérique virtuel est contrôlé pour éviter l'état de concurrence.

  • Une fuite de mémoire dans virt-manager pouvait survenir si on laissait l'application continuer d'exécuter. De ce fait, l'application consommait toujours de plus en plus de ressources, ce qui entrainait une perte de mémoire. Dans cette mise à jour, cette fuite a été résolue, et le problème réglé.

  • L'utilitaire crash ne pouvait pas analyser les vmcores x86_64 pour les systèmes exécutant kernel-xen car l'hyperviseur Red Hat Enterprise Linux était relogeable et l'adresse de base physique relogée n'était pas communiquée à l'en-tête ELF du fichier vmcore. La nouvelle option de ligne de commande --xen_phys_start de l'utilitaire crash permet à l'utilisateur de passer à crash l'adresse physique de base relogée.

  • Tous les événements générés par la souris étaient saisis et traités par leParavirtual Frame Buffer (PVFB). De ce fait, la molette de défilement ne fonctionnait pas en interaction avec un invité paravirtuel dans la Virtual Machine Console (console MV). Dans cette mise à jour, les événements générés par la souris à molette de défilement sont maintenant gérés correctement, ce qui résout ce problème.

  • Sur les systèmes possédant de grands volumes de mémoire (c'est à dire 256G0 ou plus), installer dom0 pouvait épuiser le tas de la mémoire de l'hyperviseur. Pour contourner ce problème, les arguments de lignes de commande dom_0 et xenheap devaient posséder les valeurs qui convenaient pour le système en question. Dans cette mise à jour, l'hyperviseur a été mis à jour pour configurer ces valeurs automatiquement, ce qui règle ce problème.

  • L'utilisation de la virtualisation sur une machine possédant un grand nombre de CPU aurait pu entraîner le plantage de l'hyperviseur pendant l'installation d'un invité. Dans cette mise à jour, le problème a été résolu.

  • Dans le cas où l'on créait un invité avec un grand volume de mémoire, on risquait de créer un softlockup. De ce fait, on pouvait apercevoir une trace du dépistage de l'erreur sur le dom0 et sur l'invité. Dans cette mise à jour, le problème a été résolu.

  • Sur les processeurs Intel qui retournaient une valeur de famille CPUID de 6, un seul compteur d'enregistrement de performance était activé dans kernel-xen. De ce fait, seul le compteur 0 fournissait des exemples. Dans cette mise à jour, le problème a été résolu.

5.2.2. Architectures x86

  • Sur les systèmes dotés de nouveaux CPU, l'ID du CPU APIC est différente de celle du CPU. De ce fait, le noyau virtuel n'était pas en mesure d'initialiser la mise à l'échelle de la fréquence du CPU. Dans cette mise à jour, le noyau virtuel extrait maintenant l'ID du CPU APIC de l'hyperviseur, permettant d'initialiser correctement l'échelle de fréquence du CPU.

  • Lorsque vous exécutez un invité x86 paravirtuel, si un processus accède à la mémoire invalide, il exécutait en boucle au lieu d'obtenir un signal SEGV. Cela provenait d'une erreur sur la façon dont les contrôles execshield étaient effectués par l'hyperviseur. Dans cette mise à jour, le problème a été résolu.

5.2.3. Architectures ia64

  • Un bogue xend qui empêchait le bon fonctionnement de l'installation des invités a maintenant été résolu.

  • Le périphérique de canal d'événements evtchn manquait de barrières de mémoire et de verrous. Cela entraînait xenstore à ne pas répondre. Dans cette mise à jour, ce problème a été résolu.

  • L'information Non-Uniform Memory Access (NUMA) n'a pas été affichée par la commandexm info. De ce fait, la valeur node_to_cpu de chaque noeud était retournée de façon erronée sous la forme no cpus. Dans cette mise à jour, le problème a été résolu.

  • Auparavant, créer un invité sur une machine HVM (Hardware Virtual Machine) échouait sur des processeurs qui incluent la technologie VT-i2. Dans cette mise à jour, le problème a été résolu.

5.2.4. Architectures x86_64

  • Quand les IRQ Dynamiques disponibles aux machines virtuelles des invités étaient épuisés, le noyau dom0 se plantait. Dans cette mise à jour, ce problème a été résolu, et le nombre d'IRQ disponibles a été augmenté, ce qui résout ce problème.

  • Sur les systèmes dotés de nouveaux CPU, l'ID du CPU APIC est différente de celle du CPU. De ce fait, le noyau virtuel n'était pas en mesure d'initialiser la mise à l'échelle de la fréquence du CPU. Dans cette mise à jour, le noyau virtuel extrait maintenant l'ID du CPU APIC de l'hyperviseur, permettant d'initialiser correctement l'échelle de fréquence du CPU.

5.3. Problèmes connus

5.3.1. Toutes les architectures

  • Le lecteur de disquettes n'est pas accessible lorsque vous utilisez un noyau virtuel. Pour contourner ce problème, utilisez une unité de disque attachée à un USB.

    Notez que lecteur de disquettes fonctionne toujours avec les noyaux non-virtuels.

  • Dans les migrations live d'invités paravirtuels, les processus d'invités sujets-à-la-durée sont susceptibles de ne pas fonctionner correctement si les durées (dom0) des invités correspondantes ne sont pas synchronisées. Utilisez NTP pour synchroniser les durées des systèmes pour tous les hôtes correspondants avant la migration.

  • La migration dynamique directe d'invités paravirtuels entre deux hôtes peut causer à un hôte de paniquer. Si un hôte est réinitialisé après avoir migré un invité en dehors du système, et avant de migrer à nouveau ce même invité dans le système de départ, il y aura panique.

  • Formater un disque en exécutant Windows 2008 ou Windows Vista en tant qu'invité peut échouer quand l'invité a été démarré par des CPU virtuels multiples. Pour contourner ce problème, démarrez l'invité avec un CPU virtuel simple pendant le formatage.

  • Les invités totalement virtuels créés par virt-manager pouvaient parfois empêcher la souris de se mouvoir librement à travers l'écran. Pour contourner ce problème, utiliser virt-manager pour configurer une tablette USB pour un invité.

  • Le nombre maximum de CPU doit être limité à moins de 128 sur un système CPU de 128 ou plus. Pour l'instant, la valeur maximum supportée est de 126. Utilisez l'argument de l'hyperviseur maxcpus=126 pour limiter l'hyperviseur à 126.

  • Les invités pleinement virtuels ne peuvent pas rattraper le temps perdu pour cause de domaine suspendu ou non. L'un des avantages des noyaux paravirtuels est de pouvoir garder la trace des événements suspendus ou non. Ce problème est réglé en amont grâce à des indicateurs de durée remplaçables, de façon à ce que les invités virtuels puissent avoir des indicateurs de durée paravirtuels. Actuellement, ce code est en cours de développement en amont, et devrait être disponible dans les versions à venir de Red Hat Enterprise Linux.

  • La migration répétée des invités pleinement virtuels pourrait aboutir à des messagesbad mpa sur la console dom0. Dans certains cas, l'hyperviseur pourrait également paniquer.

    Pour éviter la panique de noyau d'hyperviseur, redémarrer les invités migrés une fois que les messages bad mpa apparaissent.

  • Lorsque vous configurez l'interface sur dom0, le script par défaut network-bridge pourrait entraîner les interfaces de réseaux attachés à alterner entre unavailable (non disponible) et available (disponible). Ce phénomène est connu sous le terme flapping(battement).

    Pour éviter ce phénomène, remplacez la ligne standard network-script de /etc/xen/xend-config.sxp par la ligne suivante :

    (network-script network-bridge-bonding netdev=bond0)

    Cela désactivera le périphérique netloop, ce qui empêchera le contrôle d'ARP (Address Resolution Protocol) d'échouer au cours du processus de transfert d'adresse.

  • Lorsque vous exécutez plusieurs domaines d'invités, le traitement en réseau d'invités peut cesser de fonctionner temporairement, résultant à l'erreur suivante reportée dans le système de journalisation de dom0 :

    Memory squeeze in netback driver
    Pour contourner ce problème, augmentez le montant de mémoire disponible dans le dom0 par l'option de la ligne de commande de l'hyperviseur dom0_mem.

5.3.2. Architectures x86

  • L'opération de migration d'invités paravirtuels par xm migrate [domain] [dom0 IP address] ne fonctionne pas.

  • Lorsque vous installez Red Hat Enterprise Linux 5 sur un invité SPM pleinement virtuel, l'installation peut se figer. Ceci peut survenir lorsque l'hôte (dom0) exécute Red Hat Enterprise Linux 5.2.

    Afin d'éviter ce problème, amenez l'invité à utiliser un processeur unique en utilisant installation. Vous pouvez procéder à cette opération en utilisant l'option --vcpus=1. Lorsque l'installation est terminée, vous pouvez donner accès à SMP (multitraitement symétrique) à l'invité en modifiant la commande assignée vcpus dans virt-manager.

5.3.3. Architectures x86_64

  • L'opération de migration d'invités paravirtuels par xm migrate [domain] [dom0 IP address] ne fonctionne pas.

  • L'installation de la fonction de virtualisation peut générer un avertissement time went backwards sur les systèmes HP avec les numéros de modèle xw9300 et xw9400.

    Pour contourner ce problème sur les machines xw9400, configurez les paramètres du BIOS pour activer l'indicateur de durée HPET. Notez que cette option n'est pas disponible sur les machines xw9300.

  • L'installation de Red Hat Enterprise Linux 3.9 sur un invité pleinement virtuel peut être extrêmement lente. De plus, le démarrage de l'invité après l'installation peut produire des erreurs hda: lost interrupt.

    Pour éviter cette erreur de démarrage, configurer l'invité pour qu'il utilise le noyau SMP.

  • La mise à niveau d'un système hôte (dom0) vers Red Hat Enterprise Linux 5.2 peut rendre les invités paravirtuels Red Hat Enterprise Linux 4.5 existants impossible à démarrer. Ceci se produit généralement lorsque le système hôte a plus de 4Go de mémoire RAM.

    Pour contourner ce problème, démarrer chaque invité Red Hat Enterprise Linux 4.5 en mode CPU seul et mettre à jour son noyau avec la dernière version (pour Red Hat Enterprise Linux 4.5.z).

5.3.4. Architectures ia64

  • L'opération de migration d'invités paravirtuels par xm migrate [domain] [dom0 IP address] ne fonctionne pas.

  • Sur certains systèmes Itanium configurés pour une sortie console sur VGA, le noyau virtuel dom0 pourrait ne pas démarrer. Cela est dû au fait que le noyau virtuel 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 console=tty aux options de démarrage du noyau dans le fichier /boot/efi/elilo.conf.

  • Dans certains systèmes Itanium (comme Hitachi Cold Fusion 3e), le port de série ne peut être détecté dans dom0 quand la console VGA n'est pas activée par le Manager de maintenance EFI. De ce fait, vous devez fournir les informations de port de série suivantes au noyau dom0 :

    • Vitesse en octets/secondes

    • Nombre d'octets d'information

    • Parité

    • adresse io_base

    Ces détails doivent être spécifiés dans la ligne append= du pilote dom0 dans /boot/efi/elilo.conf. Par exemple :

    append="com1=19200,8n1,0x3f8 -- quiet rhgb console=tty0 console=ttyS0,19200n8"

    Dans cet exemple,com1 est un port de série, 19200 est la vitesse (en octets/second), 8n1 spécifie le nombre d'octets utiles/paramètres de parité, et 0x3f8 est l'adresse de io_base.

  • La virtualisation ne fonctionne pas sur les architectures qui utilisent NUMA. Ainsi, l'installation du noyau virtuel sur des systèmes qui utilisent NUMA conduira à l'échec de l'opération d'initialisation.

    Certains numéros d'installation installent le noyau virtuel par défaut. Si vous possédez un tel numéro d'installation et que votre système utilise NUMA et ne fonctionne pas avec kernel-xen, annulez la sélection option Virtualisation pendant la phase d'installation.

  • Actuellement, la migration des invités pleinement virtuels n'est pas supportée par cette architecture. De plus, le noyau dom0 dans /boot/efi/elilo.conf n'est pas supporté pour la représentation virtuelle dans cette architecture.

6. Aperçus technologiques

Les fonctionnalités en aperçus technologiques ne sont actuellement pas supportés par les services d'abonnement Red Hat Enterprise Linux peuvent ne pas être fonctionnellement complets et ne sont généralement pas appropriés pour une utilisation en production. Cependant, elles sont incluses pour la convenance des clients et pour leur donner une exposition plus large.

Les clients peuvent trouver ces fonctionnalités utiles dans un environnement qui n'est pas en production. Ils peuvent également faire des commentaires et suggestions sur ces fonctionnalités en aperçu technologique avant qu'elles ne soient pleinement supportées. 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.

Mode ALUA sur EMC Clariion

Le failover explicite actif-passif (ALUA) utilisant dm-multipath sur le stockage EMC Clariion est maintenant disponible. Ce mode est fourni dans les spécifications T10, mais n'est fourni dans cette mise à jour qu'en temps qu'aperçu technologique.

Pour davantage d'informations sur T10, se reporter à http://www.t10.org.

ext4

La dernière génération du système de fichiers ext, ext4, est disponible dans cette version en tant qu'aperçu technologique. Ext4 représente un progrès incrémentiel important sur le système de fichiers ext3 développé par Red Hat et la communauté Linux. Le nom de la version de ce système de fichier pour l'aperçu technologique est ext4dev.

Le système de fichiers est fourni par le module de noyau ext4dev.ko, et un nouveau paquetage e4fsprogs qui contient des versions mises à jour des outils administratifs bien connus e2fsprogs qu'on utilise pour ext4. Pour l'utiliser, installer e4fsprogs puis, utiliser les commandes mkfs.ext4dev du programme e4fsprogs pour créer un système de fichiers ext4-base. Lorsque vous ferez référence au système de fichiers sur une ligne de commande de montage ou pour un fichier fstab, utiliser le nom du système de fichiers ext4dev.

FreeIPMI

FreeIPMI est maintenant inclus dans cette mise à jour en tant qu'aperçu technologique. FreeIPMI représente une collection de logiciels de base IPMI (de l'anglais: Intelligent platform Management / Système de gestion intelligent de plateformes). Ceci procure un logiciel symétrique et asymétrique, ainsi qu'un librairie de développement conforme aux normes de l'interface de gestion de plateformes intelligente (IPMI v1.5 and v2.0).

Pour davantage d'informations à propos de FreeIPMI, se référer à http://www.gnu.org/software/freeipmi/

TrouSerS et tpm-tools

TrouSerS et tpm-tools sont inclus dans cette mise à jour et permettent l'utilisation du matériel Trusted Platform Module (TPM) . Les fonctions TPM comprennent (entre autres):

  • La création, le stockage, et l'utilisation des clés RSA en toute sécurité (sans les exposer à la mémoire)

  • Vérification de l'état d'un logiciel de plateforme utilisant des empreintes cryptographiques

TrouSerS est une implémentation des spécifications TSS (Trusted Computing Group's Software Stack). Vous pouvez utiliser TrouSers pour rédiger des applications qui utilisent le matériel TPM. tpm-tools est une suite d'outils utilisés pour gérer et pour utiliser le matériel TPM.

Pour davantage d'informations à propos de TrouSerS, reportez-vous à http://trousers.sourceforge.net/.

eCryptfs

eCryptfs est un système de fichiers cryptographiques empilés pour Linux. Il est monté sur les annuaires individuels situés dans les systèmes de fichiers inférieurs existants comme EXT3. Il n'y a aucun besoin de changer les systèmes de fichiers ou partitions pour commencer à utiliser eCryptfs.

Dans cette version, eCryptfs a été basé à nouveau sur la version 56, qui propose de nombreuses résolutions de bogues et améliorations. De plus, cette mise à jour fournit un programme graphique pour faciliter la configuration de eCryptfs (ecryptfs-mount-helper-gui).

Cette mise à jour change également la syntaxe de certaines options de montage eCryptfs. Si vous choisissez de mettre à jour cette version de eCryptfs, vous devriez mettre à jour tous les scripts de montage affectés et les entrées /etc/fstab. Pour toute information sur ces changements, veuillez consulter man ecryptfs.

La mise en garde suivante s'applique à cette version de eCryptfs:

  • Notes que le système de fichiers eCryptfs ne fonctionnera correctement que si le système de fichiers crypté est monté une fois au moins sur le répertoire sous-jacent du même nom. Ainsi :

    mount -t ecryptfs /mnt/secret /mnt/secret

    La portion sécurisée du système de fichiers ne devrait pas être exposé, par ex., il ne devrait pas être monté sur des autres points de montage, bind mounts, et similaires.

  • Les points de montage eCryptfs des systèmes de fichiers sur réseau (comme . NFS, Samba) ne fonctionneront pas correctement.

  • Cette version eCryptfs du pilote de noyau requiert que l'espace utilisateur soit mis à jour, par ecryptfs-utils-56-4.el5 ou version plus récente.

Pour davantage d'informations sur eCryptfs, se référer à http://ecryptfs.sf.net. Vous pouvez également consulter http://ecryptfs.sourceforge.net/README et http://ecryptfs.sourceforge.net/ecryptfs-faq.html pour les informations de base d'installation.

Linux sans état

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 de systèmes préparées qui sont répliquées et gérées sur un grand nombre de systèmes sans état, exécutant le système d'exploitation en lecture seule (veuillez vous référer à /etc/sysconfig/readonly-root pour davantage d'informations).

Dans leur état courant de développement, les fonctions sans état sont des sous-ensembles des objectifs souhaités. Cette capacité reçoit donc le statut d'aperçu technologique.

Nous recommandons fortement aux personnes voulant tester le code sans état de lire les HOWTO (COMMENT SAVOIR FAIRE) à l'adresse suivante: http://fedoraproject.org/wiki/StatelessLinuxHOWTO et de rejoindre la liste [email protected].

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 pris en charge. Il vise à activer les effets GL accélérés sur un bureau standard. Le projet consiste en :

  • 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 ou de les désactiver sans remplacer votre serveur X. AIGLX active également les applications GLX distantes pour profiter de l'accélération du matériel GLX.

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 pour 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, rapportez-vous à man tgtadm.

FireWire

Le module firewire-sbp2 est inclus dans cette mise à jour en tant qu'aperçu technologique. Ce module active la connexité avec les scanners et périphériques de stockage FireWire.

Actuellement, FireWire ne supporte pas ce qui suit:

  • IPv4

  • Les contrôleurs d'hôte pcilynx

  • les périphériques de stockage multi-LUN

  • les accès non-exclusifs 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.

ktune

Cette version comprend ktune (du paquetage ktune), un service qui configure plusieurs paramètres de réglage du noyau à des valeurs qui conviennent à des profils de systèmes spécifiques. Actuellement, ktune ne procure qu'un profil pour des systèmes à large-mémoire, exécutant des applications intensives en espace réseau et en espace disque.

Les paramètres fournis par ktune ne remplacent pas ceux de /etc/sysctl.conf ou ceux proposés par la ligne de commande du noyau. ktune n'est pas forcément adapté à certains systèmes ou charges de travail; donc, vous devriez le tester en détails, avant de le déployer en production.

Vous pouvez désactiver toute configuration définie par ktune et revenir à vos paramètres habituels en arrêtant simplement le service ktune en utilisant service ktune stop (en tant que racine).

Support SGPIO pour dmraid

Serial General Purpose Input Output (SGPIO) est une méthode de communication standard de la profession, utilisée entre un tableau de bord principal et un ensemble d'enceintes de logements d'unités de disques durs externes ou internes. Cette méthode peut être utilisée pour contrôler les lumières LED dans un système fermé par l'interface du pilote AHCI.

Dans cette version , le support SGPIO de dmraid est inclus en tant qu'aperçu technologique. Cela va permettre à dmraid de fonctionner correctement dans les enceintes de disques.

GCC 4.3

Le Gnu Compiler Collection version 4.3 (GCC4.3) est maintenant inclus dans cette version en tant qu'aperçu technologique. Cette collection de compilateurs inclut C, C++, et Fortran 95 avec les bibliothèques de support qui les accompagnent.

Noter que dans les paquetages gcc43, la valeur par défaut de l'optiongnu89-inline a été remplacée par -fgnu89-inline, alors que dans les mises à jour en amont et à venir de Red Hat Enterprise Linux 5 la valeur par défaut sera -fno-gnu89-inline. Cela est nécessaire car de nombreux en-têtes fournis dans Red Hat Enterprise Linux 5 sont conçus pour que GNU soit en lignes sémantiques et non pas en sémantique ISO C99. Ces titres n'ont pas été ajustées pour réclamer des sémantiques en ligne-GNU à travers les attributs.

Kernel Tracepoint Facility

Dans cette mise à jour, la nouvelle fonction marker/tracepoint est proposée en tant qu'aperçu technologique. Cette interface ajoute des points de sondage statiques dans le noyau, à utiliser avec des outils comme SystemTap.

Fibre Channel over Ethernet (FCoE) - Canal fibre optique sur éthernet

Le pilote Fibre Channel over Ethernet (FCoE), combiné à libfc, offre la possibilté d'exécuter FCoE sur une carte éthernet standard. Cette fonction est proposée en tant qu'aperçu technologique dans Red Hat Enterprise Linux 5.3.

Red Hat Enterprise Linux 5.3 fournit son support total pour FCoE sur trois implémentations de matériel: le pilote Cisco fnic, le pilote Emulex lpfc, et le pilote Qlogic qla2xx.

Device Failure Monitoring (Contrôle des échecs de périphériques) des ensembles RAID

Device Failure Monitoring, est inclus dans Red Hat Enterprise Linux 5.3 en tant qu'aperçu technologique en utilisant les outils dmraid et dmevent_tool. Cela permet d'observer et de reporter les échecs des périphériques de composants d'ensembles RAID.

7. Problèmes résolus

7.1. Toutes les architectures

  • Les données des rapports d'activité des périphériques TTY n'étaient pas générés correctement, de ce fait, la commande sar -y échouait, retournant l'erreur suivante :

    Activités réclamées non disponibles sur fichier

    Dans ce paquetage mis à jour, sar a été corrigé de façon à ce que l'option -y fasse sortir l'activité des périphériques TTY.

  • Auparavant, configurer max_fds à unlimited dans /etc/multipath.conf empêchait le démon multipathd de démarrer. Si un nombre de descripteurs de fichiers a besoin d'être configuré à un maximum pour le système, max_fds devrait être configuré à max.

  • mod_perl est maintenant basé à nouveau sur la version 2.0.4, la dernière version en amont. Cette mise à jour applique plusieurs mises à jour, y compris une résolution de bogue qui permet que mod_perl puisse fonctionner correctement avec Bugzilla 3.0.

  • cups a été mis à jour à nouveau sur la version 1.3.7. Cette version comprend maintenant les améliorations suivantes (entre autres):

    • L'authentification Kerberos est maintenant supportée.

    • L'imprimante définie par l'utilisateur et les politiques de job sont maintenant chargées correctement.

    • Les files d'attente cache éloignées ne sont plus chargées quand le balayage est désactivé.

    • Le fichier de configuration classes.conf a maintenant les permissions de fichiers correctes.

  • lm_sensors a été basé à nouveau sur la version 2.10.7. Cette mise à jour applique plusieurs améliorations de performance en amont et des résolutions de bogues, y compris une solution qui permet d'éviter que les libsensors ne se plantent avec un message General parse error quand k8temp est également chargé.

  • La mise à jour elfutils de cette version résout les bogues suivants :

    • L'utilitaire eu-readelf pouvait se planter quand il lisait certains fichiers.

    • L'utilitaire eu-strip est utilisé dans les procédures rpmbuild qui créent des nouveaux paquetages binaires. Il sépare des informations de déboggage d'exécution fr codes exécutables pour constituer des paquetages -debuginfo. Dans cet utilitaire, un bogue résultait en une information de déboggage inutilisable pour les fichiers ET_REL de la plateforme s390. Cela affectait les fichiers de module de noyau Linux (.ko.debug), et avait pour conséquence que les paquetages kernel-debuginfo ne fonctionnaient plus avec Systemtap sur s390.

  • vnc-server est maintenant basé à nouveau sur la version 4.1.2-14.el5. Cette mise à jour applique les solutions suivantes :

    • Un bogue, qui empêchait vncserver d'imprimer les messages d'erreur quand Xvnc échouait au démarrage, est maintenant résolu.

    • Xvnc n'utilise plus la mauvaise profondeur de fenêtre racine, il utilise maintenant la profondeur de fenêtre qui convient et spécifiée par l'option -depth .

    • Un bogue qui entraîne le plantage du serveur X par le module libvnc.so, est maintenant résolu.

    • Xvnc supporte maitenant les extentions GLX et RENDER sur toutes les architectures.

  • smartmontools a été basé à nouveau sur la version 5.38. Cette mise à jour améliore l'autodétection des périphériques de matériel, ainsi que le support pour les réseaux CCISS RAID, et se caractérise par une base de données importante de périphériques pris en charge.

    Cette mise à jour résout un bogue qui empêchait SELinux de contrôler smartmontools les périphériques RAID 3ware. smartmontools peut maintenant contrôler ces périphériques correctement.

  • python-urlgrabber a été mise à jour à la version 3.1.0-5. Cette version comprend maintenant les améliorations suivantes (entre autres):

    • yum ne peut pas re-décharger correctement à partir du dépôt yum qui ne prend pas en charge les déchargements partiels.

    • yum ne peut pas terminer un déchargement interrompu même si le dépôtyum est basé-FTP avec un port particulier.

    • La taille des barres de progression sont dynamiques par rapport à la taille du terminal. De plus, les barres de progression sont maintenant plus propres, et affichent un pourcentage du total des données déchargées.

    • Le signal keepalive de l'applicationpython-urlgrabber est maintenant réparé. Avant, un bogue dans ce signal augmentait incorrectement l'utilisation de la mémoire pendant les déchargements. De plus, ce bogue empêchait également reposync et yumdownloader d'opérer correctement au moment du déchargement d'un grand nombre de paquetages.

  • yum-utils a été mis à jour à la version en amont 1.1.16. Cette version comprend maintenant les améliorations suivantes (entre autres):

    • yum update --security peut maintenant localiser correctement d'anciennes mises à jour de sécurité utiles.

    • yum-versionlock fonctionne maintenant correctement à l'encontre des paquetages obsolètes.

    Cette mise à jour inclut également le plugin yum-fastestmirror qui permet à yum de choisir le dépôt le plus rapide dans une mirrolist.

  • Samba a été basé à nouveau sur la version en amont 3.2.0. Cela résout plusieurs bogues, y compris un bogue qui empêchait les utilisateurs de rejoindre des domaines qui utilisaient Windows 2003 comme nom de serveur. Cette mise à jour règle également un bogue qui causait l'appartenance au domaine samba à disparaître après un changement de mot de passe de système en utilisant net rpc changetrustpw.

    Pour une plus grande liste des mises à jour en amont comprises dans cette version, samba , consultez http://www.samba.org/samba/history/samba-3.0.32.html

  • OpenLDAP a été mis à jour à la version 2.3.43. Cette version comprend maintenant les améliorations suivantes (entre autres):

    • Le script init donne maintenant un avertissement si le démonslapd ne peut pas lire un fichier de certificat TLS.

    • Toutes les bibliothèques du paquetage openldap-debuginfo sont maintenant remontées.

    • Désinstaller le paquetage openldap-devel n'endommage plus les librairies OpenLDAP.

    Red Hat distribue maintenant des segments de recouvrement pour les serveurs OpenLDAP. A part pour syncprov, tous les segments de recouvrement peuvent être trouvés dans des paquetages openldap-servers-overlays séparés, compilés sous forme de modules chargeables. Le segment de recouvrement syncprov est statistiquement lié au serveur OpenLDAP pour conserver la compatibité avec les versions antérieures de OpenLDAP

  • Comme le binaire xterm avait set groupe ID bit (setgid) configuré, certaines variables d'environnement (comme LD_LIBRARY_PATH et TMPDIR) n'étaient pas fixées. Dans cette version, le binaire xterm a maintenant les permissions mode 0755 configurées, ce qui résout ce problème.

  • La méthode recommandée pour équilibrer la charge sur les serveurs NIS quand des machines multiples sont connectées par ypbind a changé dans cette version. Le comportement du démon ypbind n'a pas changé: il contrôle toujours tous les serveurs NIS listés dans le fichier de configuration /etc/ypbind.conf et le relie alors aux serveurs NIS disponibles dans chaque machine. Avant, il était recommandé de lister tous les serveurs NS dans le fichier de configuration /etc/ypbind.conf de chaque machine. Cependant, comme même certains serveurs sous charge élevée peuvent répondre rapidement à ce contrôle de connexion, et donc, augmenter leur propre charge par mégarde, on recommande maintenant aux administrateurs de lister un plus petit nombre de serveurs NIS disponibles pour chaque ypbind.conf de chaque machine, et de faire varier cette liste entre les machines. Ainsi, les serveurs seront automatiquement équilibrés car chaque serveur NIS ne sera pas listé comme disponibles pour toutes les machines.

  • Openmotif a été mis à jour à la version 2.3.1. Cette version comprend maintenant les améliorations suivantes (entre autres):

    • Un bogue, qui comme OpenMotif gérait les événements Grab et Ungrab est maintenant résolu. Dans les versions précédentes, ce bogue pouvait entraîner le verrouillage de l'affichage.

    • Un bogue de nedit pouvait causer un échec quand on utilisait l'interface d'utilisation graphique. Cela était dû à une fonction du code, qui causait une faute de segmentation dans certains cas de sélection d'éléments. Elle est maintenant résolue.

  • dbus a été basée à nouveau sur la version 1.1.2. Cette mise à jour résout un bogue pour lequel des programmes multi-thread pouvaient entraîner un interblocage dans dbus. Dans les versions précédentes, quand un thread écoutait dbus et traitait les messages, un deuxième thread envoyait les messages à dbus.

  • strace a été basée à nouveau sur la version 4.5.18. Elle résout plusieurs bogues, y compris :

    • Un bogue qui causait l'échec de strace quand l'option -f était utilisée sur certains programmes multi-thread (particulièrement sur des systèmes 64-bit), est maintenant résolu.

    • Un bogue qui empêchait la version 64-bit de strace d'exécuter un appel de fonction vfork() sur un processus 32-bit, est maintenant résolu.

  • cpuspeed a maintenant été mis à jour à la version 1.2.1-5. Grâce à cette mise à jour, le script cpuspeed init charge maintenant le module speedstep-centrino dans le cas où tous les autres modules échouent au chargement. De plus, un bogue espace-utilisateur qui empêche le module Powernow-k8 de se charger, est maintenant résolu.

  • La suite d'outils frysk a été complètement supprimée de cette distribution. frysk était introduit, à l'origine, en tant qu'aperçu technologique dans Red Hat Enterprise Linux 5.0.

  • Auparavant, les statistiques de partition E/S de la commande iostat -x étaient incomplets. Dans cette nouvelle version, les statistiques de partition sont maitenant calculés de la même manière que les statistiques disques, procurant ainsi des statistiques E/S cohérents et complets au niveau partition.

  • On a identifié un problème de divulgation dans le fichier de configuration du serveur de messagerie Dovecot. Si le serveur avait l'optionssl_key_password définie, n'importe quel utilisateur local pouvait visualiser le mot de passe de la clé SSL. (CVE-2008-4870)

    Note

    Ce problème ne permettait cependant pas à l'agresseur de s'approprier les contenus de la clé SSL. Le mot de passe n'a aucune valeur sans le fichier-clé pour lequel les utilisateurs arbitraires n'auraient pas pu avoir l'accès lecture.

    Pour protéger au mieux cette valeur, le fichier dovecot.conf supporte maintenant la directive "!include_try". L'option ssl_key_password devrait passer du fichier dovecot.conf vers un nouveau fichier qui ne puisse être possédé, lu et écrit que par le superutilisateur racine (ie 0600). Ce fichier pourrait être référencié à partir de dovecot.conf en configurant l'option !include_try /path/to/password/file.

7.2. Architectures x86_64

  • ksha été basé à nouveau sur la version 2008-02-02. Cette mise à jour permet la gestion de caractères multi-byte, règle de nombreux problèmes de contrôles de jobs et applique plusieurs résolutions de bogues à partir de l'amont. Notez que cette mise à jour vers ksh maintient la compatibilité avec les scripts existants.

7.3. Architectures s390x

  • Un bogue vmconvert l'empêchait de travailler correctement sur le noeud de périphérique vmur (/dev/0.0.000c). Cela entraînait l'échec de vmconvert lorsqu'il tentait d'accéder les fichiers de vidage sur le périphérique vmur avec l'erreur vmconvert: Open dump file failed! (Permission denied). La mise à jour de s390utils dans cette version, résout ce problème.

  • Le script init et le fichier config pour le démon mon_procd et le démon mon_fsstatd manquaient au paquetage s390utils . De ce fait, ces démons ne pouvaient pas être construits ou utilisés. Les fichiers manquants ont été ajouté à cette mise à jour et résolvent ce problème.

7.4. Architectures PowerPC

  • Un bogue qui empêche le module ehci_hcd de recharger sur cette architecture, est maintenant résolu. Ce permet à l'adaptateur Belkin 4-port PCI-Express USB Lily, et autre périphériques du même genre, de pouvoir maintenant fonctionner correctement avec Red Hat Enterprise Linux 5 quand ils utilisent le module ehci_hcd.

  • La biblitothèque libhugetlbfs est maintenant basée à nouveau sur la version 1.3. Cette mise à jour applique plusieurs améliorations en amont de la bibliothèque, augmentant ainsi la performance des applications qui utilisent les pages Huge.

    Pour une liste complète des mises à jour de libhugetlbfs, consultez les pages suivantes :

    http://sourceforge.net/mailarchive/message.php?msg_name=20080515170754.GA1830%40us.ibm.com

  • Dans Red Hat Enterprise Linux 5.2, une version 64-bit de httpd était fournie dans cette architecture en plus de la version 32-bit httpd. Si un utilisateur installait les deux versions, un conflit httpd avait lieu, empêchant httpd de fonctionner correctement.

    Pour résoudre ce problème, la version 64-bit de httpd a été supprimée de cette version. La mise à niveau de httpd pour cette version va automatiquement supprimer les version 64-bit de httpd également.

8. Problèmes connus

8.1. Toutes les architectures

  • Lorsque vous utilisez la nouvelle fonctionnalité de cryptage du disque pour encoder le système de fichiers racine, vous verrez le message erreur suivant apparaître sur la console lors de la fermeture du système :

    Stopping disk encryption [FAILED]

    Ce message peut être ignoré en toute sécurité, le processus de fermeture se terminera avec succès.

  • Lorsque vous utilisez un périphérique crypté, le message d'erreur suivant pourrait apparaître en cours d'initialisation :

    insmod: error inserting '/lib/aes_generic.ko': -1 File exists
    Ce message peut être ignoré en toute sécurité.

  • Toute installation utilisant un dispositif multiple (MD) RAID sur Multivoies, aboutira à un problème d'initialisation de la machine. Les Multivoies vers les SAN (réseaux de stockage) qui fournissent RAID en interne, ne seront pas affectées.

  • Quand on ajoute un grand nombre de LUN à un noeud, le multivoies peut augmenter énormément pendant la période qu'il faut pour que udev puisse créer les noeuds de périphériques pour ces LUN. Si vous rencontrez ce problème, vous pourrez y remédier en effaçant la ligne suivante dans /etc/udev/rules.d/40-multipath.rules:

    KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod | /bin/grep ^dm_multipath'", RUN+="/sbin/multipath -v0 %M:%m"
    . Cette ligne entraîne udev à exécuter multivoies à chaque fois qu'un périphérique en bloc est ajouté au noeud. Même si cette ligne est supprimée, multipathd continuera de créer des périphériques des périphériques multivoies, et multivoies sera toujours appelé pendant le processus de démarrage, pour les noeuds qui ont des systèmes de fichiers multivoies. Le seul changement réside dans le fait que les périphériques multivoies ne seront pas automatiquement créés quand multipathd n'est pas exécuté, ce qui ne devrait pas poser de problème pour la majorité des utilisateurs multivoies.

  • Lorsque vous procédez à la mise à niveau à partir d'une version plus récente de Red Hat Enterprise Linux vers 5.3, vous pourriez rencontrer l'erreur suivante :

    Updating  : mypackage                 ################### [ 472/1655]
    rpmdb: unable to lock mutex: Invalid argument

    La cause du problème de verrouillage est que le verrouillage futex partagé de glibc a été amélioré par les futexes par-process entre 5.2 et 5.3. De ce fait, les programmes exécutés dans 5.2 glibc ne peuvent pas effectuer de verrouillage futex partagé dans les programmes exécutés par le glibc 5.3.

    Ce message erreur particulier est un effet secondaire d'un paquetage appelant rpm en tant que faisant partie de ses scripts d'installation. L'instance rpm qui effectue la mise à niveau utilise le glibc pendant la mise à niveau, mais l'instance rpm qui est lancée à partir du script utilise le nouveau glibc.

    Pour éviter cette erreur, procédez à la mise à niveau de glibc pour commencer, dans une session séparée :

    # yum update glibc
    # yum update
    . Vous apercevrez également cette erreur si vous déclassez glibc vers une version plus récente sur un système 5.3 installé.

  • mvapich et mvapich2 de Red Hat Enterprise Linux 5 sont compilés pour ne prendre en charge que les interconnexions InfiniBand/iWARP. De ce fait, ils ne pourront pas être exécutés sur l'éthernet ou sur d'autres interconnexions de réseaux.

  • Sur les systèmes qui comptent plus de deux périphériques bloc cryptés, anaconda a pour option de fournir un mot de passe générale. Les scripts init, cependant, de prennent pas en charge cette fonctionnalité. Lorsque vous démarrez le système, vous devrez saisir chaque mot de passe individuel pour chaque périphérique crypté.

  • Lorsque vous procédez à la mise à niveau de openmpi en utilisant yum, l'avertissement suivant peut être retourné:

    cannot open `/tmp/openmpi-upgrade-version.*' for reading: No such file or directory
    Le message est inoffensif et peut être ignoré en toute sécurité.

  • Configurer l'affinité IRQ SMP n'a aucun effet sur certains périphériques qui utilisent MSI (de l'anglais Message Signalled Interrupts / interruptions signalées par des messages) sans posséder de capacité de masquage par-vecteur MSI. Les périphériques Ethernet Broadcom NetXtreme qui utilisent le pilote bnx2 constituent des exemples de tels périphériques.

    Si vous avez besoin de configurer l'affinité IRQ d'un tel périphérique, désactivez MSI en créant un fichier /etc/modprobe.d/ qui comprend les lignes suivantes :

    options bnx2 disable_msi=1

    Sinon, vous pouvez désactiver MSI complètement en utilisant le paramètre de module de noyau pci=nomsi.

  • L'unité CD-ROM/DVD-ROM sur les serveurs Dell PowerEdge R905 ne fonctionne pas sur Red Hat Enterprise Linux 5. Veuillez consulter la Base de connaissance #13121 pour davantage de détails: http://kbase.redhat.com/faq/FAQ_103_13121.

    Important

    Suivre la procédure dans l'article dans Base de connaissance sus mentionné pourrait aboutir à d'autres problèmes qui ne pouvent pas être pris en charge par GSS.

  • Un bogue présent dans le fichier /etc/udev/rules.d/50-udev.rules mis à jour empêche la création de noms persistants d'unités de bande comprenant des nombres supérieurs à 9 dans leur intitulé. Par exemple, un nom persistant ne sera pas créé pour une unité de bande comprenant un nom de nst12.

    Pour contourner ce problème, ajoutez un astérisque (*) après chaque occurence de la chaîne de caractères nst[0-9] in /etc/udev/rules.d/50-udev.rules.

  • L'outil smartctl ne peut pas lire correctement les paramètres SMART des périphériques SATA.

  • Un bogue présent dans les versions précédentes de openmpi et de lam peut vous empêcher de mettre ces paquetages à niveau. Ce bogue se manifeste dans l'erreur suivante (lorsque vous tentez de mettre à niveau openmpi ou lam) :

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

    Ainsi, vous avez besoin de retirer manuellement les anciennes versions de openmpi et de lam afin d'installer leurs dernières versions. Dans ce but, utiliser la commande rpm:

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

  • Lorsque vous utilisez dm-multipath, si features "1 queue_if_no_path" est spécifié dans /etc/multipath.conf alors tout processus qui émet E/S s'interrompra jusqu'à ce qu'un ou plusieurs chemins soient restaurés.

    Afin d'éviter ce problème, no_path_retry [N] dans /etc/multipath.conf (où [N] est le nombre de fois que le système doit réessayer un chemin). Lorsque vous procédez, retirer l'option features "1 queue_if_no_path" de /etc/multipath.conf également.

    Si vous avez besoin d'utiliser "1 queue_if_no_path" et que vous expérienciez le problème décrit ci dessus, utilisez dmsetup pour éditer la politique en cours d'exécution pour un LUN en particulier (c'est à dire un LUN pour lequel tous les chemins sont disponibles).

    Pour illustrer ce propos: exécutez dmsetup message [device] 0 "fail_if_no_path", dans lequel [device] est le nom du périphérique à trajets multiples (par ex. mpath2; ne pas spécifier le chemin) pour lequel vous souhaitez changer la police de "queue_if_no_path" à "fail_if_no_path".

  • L'activation de versions multiples installées du même module de noyau n'est pas supportée. De plus, un bogue dans la façon dont les versions de module de noyau sont analysées, peut parfois résulter dans l'activation d'une ancienne version du même module de noyau.

    Red Hat recommande que lorsque vous installez une version récente du module de noyau installé, vous devez effacer l'ancienne version d'abord.

  • Exécuter kdump sur un IBM Bladecenter QS21 ou QS22 configuré avec une racine NFS sera mis en échec. Pour éviter ceci, spécifier une cible de clichage NFS dans /etc/kdump.conf.

  • Les portables IBM T60 vont s'éteindre complètement lorsqu'ils seront attachés à une station de base ou lorsqu'ils seront suspendus. Pour éviter ce problème, initialiser le système par l'argument acpi_sleep=s3_bios.

  • QLogic iSCSI Expansion Card pour IBM Bladecenter procure à la fois des fonctions ethernet et iSCSI. Certaines parties de la carte sont partagées par les deux fonctions. Malgré tout, les pilotes actuels qla3xxx et qla4xxx supportent les fonctions ethernet et ISCSI individuellement. Les deux pilotes ne supportent pas l'utilisation des fonctions.ethernet et ISCSI simultanément.

    A cause de cette limitation, les initialisations successives (par les commandes consécutives ifdown/ifup) peuvent interrompre le fonctionement du matériel. Agin d'éviter cela, autoriser un intervalle de 10 secondes après un ifup et avant d'émettre un ifdown. Aussi, autoriser le même intervalle de 10 secondes après un ifdown avant d'émettre un ifup. Cet intervalle vous donne suffisamment de temps pour stabiliser et réinitier toutes les fonctions lorsqu'un ifup est émis.

  • 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 éthernet (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).

  • La journalisation lors du démarrage vers /var/log/boot.log n'est pas disponible dans cette version de Red Hat Enterprise Linux 5.3.

  • 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.2 sur une machine avec un chipset nVidia CK804 installé, vous pourriez recevoir des messages du noyau semblables à 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 demandent pas d'interruptions (IRQ). En plus, ces messages n'affectent en aucun cas l'opération de la machine.

  • Les périphériques de stockage amovibles (tels que les CD-ROM et DVD) ne sont pas montés automatiquement lorsque vous êtes connecté en tant que racine. Ainsi, vous devrez monter le périphérique manuellement par 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
  • Lorsqu'un LUN est détecté sur un système de stockage configuré, le changement n'est pas reflété sur l'hôte. Dans de telles situations, les commandes lvm seront interrompues indéfiniment lorsque dm-multipath est utilisé, étant donné que le LUN est maintenant devenu stale.

    Pour contourner ce problème, supprimer toutes 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écuter la commande suivante:

    ls -l /dev/mpath | grep [stale LUN]

    Par exemple, si [stale LUN] is 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
  • Exécuter la commande multipath en conjonction à l'option -ll peut entraîner l'interruption de cette commande si l'un des chemins est sur le dispositif de blocage. Noter que le pilote n'aborte pas les demandes au bout d'un moment si le périphérique ne répond pas.

    C'est dû au code de nettoyage, qui attend jusqu'à ce que la demande du vérificateur de chemin soit positive ou bien échoue. Pour faire apparaître l'état actuel multipath sans interrompre la commande, utiliser multipath à la place.

  • La mise à niveau de pm-utils à partir de Red Hat Enterprise Linux à la version 5.2 Beta de pm-utils échouera, résultant dans l'erreur suivante:

    erreur: éclatement de. l'archivage échoué sur fichier /etc/pm/sleep.d: cpio: rename

    Afin d'éviter ce problème, effacer l'annuaire /etc/pm/sleep.d/ avant la mise à niveau. Si /etc/pm/sleep.d contient des fichier, déplacer ces fichiers dans /etc/pm/hooks/.

  • Les essais de matériel de traitement des données du Mellanox MT25204 a révélé qu'un erreur interne peut avoir lieu sous certaines conditions de hauts chargements. Lorsque le pilote ib_mthca rend compte d'une erreur catastrophique sur ce matériel, c'est normalement lié à une longueur de file d'attente trop courte par rapport au nombre de demandes de tâches restantes réclamées, générées par l'application utilisateur.

    Malgré que le pilote va redémarrer le matériel et recouvrir d'un tel événement, toutes les connexions existantes au moment de l'erreur seront perdues. Ceci résulte généralement dans une faute de segmentation dans l'application utilisateur. De plus, si opensm est en active au moment où l'erreur se produit, alors, il vous faudra redémarrer manuellement pour reprendre le bon cours des opérations.

  • Lorsque vous installez Red Hat Enterprise Linux 5 sur un invité, l'invité est configuré pour utiliser explicitement un noyau d'installation temporaire fourni par dom0. Un fois que l'installation est terminée, il peut alors utiliser sont propre chargeur de démarrage. Mais, cela ne peut uniquement être réalisé en forçant le premier redémarrage de l'invité à être un arrêt.

    De ce fait, quand le bouton Reboot apparaît en fin d'installation de l'invité, si vous appuyez dessus, vous faîtes sortir l'invité, mais vous ne le faîtes pas redémarrer. C'est un comportement inattendu.

    Notez que lorsque vous démarrez un invité par la suite, il utilisera alors son propre chargeur d'amorçage.

  • Exécuter rpmbuild sur la source RPM compiz échouera si un KDE ou des paquetages de développement qt (comme par exemple, qt-devel) sont installés. Cela est dû à un bogue compiz du script de configuration .

    Pour contourner ce problème, retirez tous les KDE ou paquetages de développement qt avant de tenter de construire le paquetage compiz à partir de son RPM source.

  • Si votre système est équipé de cartes graphiques ATI Radeon R500 ou R600, la commande firstboot ne sera pas exécutée après l'installation. Le système ira directement dans l'écran d'authentification graphique et passera outre firstboot. Si vous tentez d'exécuter firstboot manuellement (c'est à dire à partir d'un terminal à sécurité intégrée), la session X échouera.

    Ce problème est causé par le pilote qui est utilisé par le matériel ATI Radeon R500/R600. Le pilote par défaut utilisé par ces cartes graphiques n'est toujours qu'un aperçu technologique. Pour contourner ce problème, faîtes une copie de sauvegarde de votre fichier /etc/X11/xorg.conf, puis, configurez X pour utiliser le pilote vesa pris en charge au lieu d'utiliser la commande suivante :

    system-config-display --reconfig --set-driver=vesa

    Vous pouvez maintenant exécuter firstboot. Pour retourner à vos paramètres d'origine, restaurez votre /etc/X11/xorg.conf d'origine.

  • Si votre système utilise le chronomètre TSC, l'appel système gettimeofday pourrait reculer. Cela est dû à un problème de surcharge qui entraîne le chronomètre TSC à faire des grands bonds en avant dans certains cas. Dans de tels cas, le chronomètre TSC s'auto-corrigera, mais finira par enregistrer un mouvement en arrière au bout d'un moment.

    Ce problème est particulièrement critique pour les systèmes sensibles à la durée, comme ceux qui sont utilisés pour les systèmes de transactions et les bases de données. Ainsi, si votre système exige une certaine précision, Red Hat recommande hautement que vous configuriez le noyau pour qu'il puisse utiliser un autre chronomètre (comme HPET, par exemple).

  • Tenter d'exécuter sniff peut résulter en une erreur. C'est parce que certains paquetages requis ne sont pas installés avec dogtail.

    Pour l'éviter, installer les paquetages suivants manuellement :

    • librsvg2

    • ghostscript-fonts

    • pygtk2-libglade

  • Thin Provisioning (connu également en tant que "virtual provisioning") sera tout d'abord mis à votre disposition dans EMC Symmetrix DMX3 et DMX4. Veuillez consulter EMC Support Matrix et Symmetrix Enginuity pour davantage de détails.

  • Dans /etc/multipath.conf, configurer max_fds à unlimited empêchera le démon multipathd de démarrer correctement. Donc, vous devriez utiliser une valeur suffisamment élevée à la place pour ce paramètre.

  • SystemTap utilise GCC pour sonder les événements espace-utilisateur. GCC est, cependant, incapable de procurer aux déboggueurs l'information sur la liste des locations précises des paramètres. Dans certains cas, GCC ne fournit pas de visibilité sur certains paramètres. De ce fait, les scripts SystemTaps qui sondent l'espace-utilisateur pourraient retourner des lectures erronnées.

  • Le modèle de portable IBM T41 n'entre pas dans Suspend Mode correctement; et donc, Suspend Mode consommera la durée de l'accumulateur comme d'habitude. C'est parce que Red Hat Enterprise Linux 5 n'inclut pas encore le module radeonfb .

    Pour contourner ce problème, ajoutez un script intitulé hal-system-power-suspend à /usr/share/hal/scripts/ et comprenant les lignes suivantes :

    chvt 1
    radeontool light off
    radeontool dac off

    Ce script assurera que le portable IBM T41 entre dans le Suspend Mode correctement. Pour veiller à ce que le système fonctionne correctement, ajouter le script restore-after-standby au même répertoire également, comprenant les lignes suivantes :

    radeontool dac on
    radeontool light on
    chvt 7
  • Si le module edac est chargé, la journalisation de la mémoire BIOS ne fonctionnera pas. C'est parce que le module edac nettoie le journal utilisé par BIOS dans ce but.

    Le modèle de mise à jour du pilote actuel Red Hat Enterprise Linux instruit le noyau de charger tous les modules disponibles (y compris le module edac) par défaut. Si vous souhaitez être sûr que la mémoire BIOS soit journalisée dans votre système, vous devrez indiquer manuellement les modules edac sur la liste noire. Pour cela, ajoutez les lignes suivantes dans /etc/modprobe.conf :

    blacklist edac_mc
    blacklist i5000_edac
    blacklist i3000_edac
    blacklist e752x_edac
  • Red Hat Enterprise Linux 5.3 peut détecter l'élargissement ou la diminution d'un périphérique bloc sous-jacent en ligne. Cependant, il n'existe pas de méthode pour détecter automatiquement le changement de taille d'un périphérique, donc on a besoin d'étapes manuelles pour identifier ce changement et recalibrer la taille des systèmes de fichiers qui résident dans n'importe quel(s) périphérique(s) donné(s). Quand un périphérique bloc recalibré est détecté, un message ressemblant au message qui suit apparaîtra dans les journalisations système :

    VFS: inodes actifs sur des media modifiés ou sdi de disques recalibrés.

    Si le périphérique en blocs s'est élargi, alors ce message peut être ignoré en toute sécurité. Mais, si le périphérique en blocs a été réduit sans réduire les données initialement placées sur le périphérique en bloc, les données résidant sur le périphérique pourraient être corrompues.

    Il est possible de faire un recalibrage d'un système de fichiers qui a été créé sur un LUN complet (ou un périphérique en blocs) en ligne. S'il y a une table de partition sur un périphérique en blocs, alors le système de fichiers devra être démonté pour mettre la table de partitions à jour.

  • Si un système de fichiers GFS2 est monté sur votre système, un noeud pourrait est interrompu si un inode cache peut être accédé par un noeud et puisse être déconnecté par un autre. Dans un tel cas, le noeud interrompu ne sera pas disponible à moins que vous le clôturiez et que vous le recouvriez par le mécanisme de recouvrement de clusters habituel. La fonction appelle gfs2_dinode_dealloc et shrink_dcache_memory apparaîtra également dans les traces de la pile de tout processus coincé dans le noeud interrrompu.

    Ce problème n'affecte pas les systèmes de fichiers GFS2 à noeud-simple.

  • Vous rencontrerez sans doute ce message affiché au cours du démarrage du système :

    Could not detect stabilization, waiting 10 seconds.
    Reading all physical volumes.  This may take a while...
    Ce délai (jusqu'à 10 secondes, dépendant de la configuration du matériel) est utile pour s'assurer que le noyau ait bien terminé de balayer les disques.

  • L'implémentation actuelle de User Payload Access dans ipmitool vous permet de configurer les périphériques, mais ne vous permet pas d'extraire les paramètres courants de ces périphériques.

  • En utilisant le paramètre swap --grow dans un fichier de démarrage sans configurer le paramètre --maxsize en même temps, amène Anaconda à imposer une restriction sur la taille maximum de la partition swap. Cela ne lui permet pas de grandir pour remplir le périphérique.

    Pour des systèmes de moins de 2Go de mémoire physique, la limite imposée est deux fois le montant de la mémoire physique. Pour les systèmes de plus de 2Go, la limite imposée est la taille de la mémoire physique, plus 2Go.

  • Le programme gfs2_convert ne libérera peut-être pas tous les blocs des métadonnées GFS qui ne sont plus utilisées sous GFS2. Ces blocs de métadonnées seront découvertes et libérées la prochaine fois que gfs_fsck sera exécuté sur le système de fichiers. Il est recommandé que gfs2_fscksoit exécuté après que le système de fichiers ait été converti pour libérer les blocs non utilisés. Ces blocs non utilisés seront balisés par gfs2_fsck avec les messages suivants :

    Ondisk and fsck bitmaps differ at block 137 (0x89) 
    Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
    Metadata type is 0 (free)
    Ces messages n'indiquent pas de corruption dans le système de fichiers GFS2, ils indiquent des blocs qui auraient dû être libérés, mais qui ne l'ont pas été. Le nombre de blocs qui a besoin d'être libéré variera en fonction de la taille du système de fichiers et de la taille du bloc. Le problème ne se posera pas pour tous les systèmes de fichiers. Les grands systèmes de fichiers auront peut-être un plus petit nombre de blocs (en général moins de 100).

8.2. Architectures x86

  • Lors du démarrage du noyau (non virtuel) bare-metal, le serveur X pourrait ne pas être en mesure de récupérer les informations EDID de l'écran. Lorsque cela se produit, le pilote graphique n'affichera pas les résolutions supérieures à 800x600.

    Pour contourner ce problème, ajoutez la ligne suivante à la section ServerLayout du fichier /etc/X11/xorg.conf:

    Option "Int10Backend" "x86emu"
  • L'enregistrement doit être activé manuellement sur Dell M4300 et sur M6300. Pour cela, procéder aux étapes suivantes :

    1. Ouvrir alsamixer.

    2. Appuyer sur Tab pour afficher [Capture] dans le champ View (situé dans la partie supérieure gauche du menu).

    3. Appuyez sur la barre-espace Space.

    4. Pour vérifier que l'enregistrement est activé, le texte situé au dessus du champ ADCMux doit afficher L R CAPTUR.

  • Si le cryptage est activé sur le périphérique de démarrage pendant l'installation du système, le message suivant sera enregistré au cours du démarrage du système :

    padlock: VIA PadLock not detected.
    Ce message peut être ignoré en toute sécurité.

8.3. Architectures x86_64

  • Certaines machines qui utilisent des cartes graphiques NVIDIA peuvent afficher des graphismes ou des polices corrompus lors de l'utilisation de l'installateur graphique ou durant une connexion graphique. Pour contourner ce problème, basculez vers une console virtuelle, puis retournez vers l'hôte X d'origine.

  • Sur un portable IBM T61, Red Hat recommande que vous évitiez de cliquer sur la fenêtre glxgears (quand glxgears est exécuté) car cela peut verrouiller le système.

    Pour contourner ce problème, désactivez la fonctionnalité de pavage (tiling). Pour cela, ajoutez la ligne suivante à la section Device de /etc/X11/xorg.conf :

    Option "Tiling" "0"
  • L'enregistrement doit être activé manuellement sur Dell M4300 et sur M6300. Pour cela, procéder aux étapes suivantes :

    1. Ouvrir alsamixer.

    2. Appuyer sur Tab pour afficher [Capture] dans le champ View (situé dans la partie supérieure gauche du menu).

    3. Appuyez sur la barre-espace Space.

    4. Pour vérifier que l'enregistrement est activé, le texte situé au dessus du champ ADCMux doit afficher L R CAPTUR.

  • Si votre système utilise une carte graphique Intel 945GM, n'utilisez pas le pilote i810. Vous devriez utiliser le pilote intel par défaut à la place.

  • Sur les portables en duo-GPU, si l'une des puces graphiques, est basée-Intel, le mode de graphiques Intel ne peut pas gérer de connexion digitale externe (y compris HDMI, DVI, et DisplayPort). Il s'agit d'une limitation du GPU Intel. Si vous avez besoin de connexions digitales externes, configurez le système pour pouvoir utiliser la puce de graphiques discrète (dans le BIOS).

8.4. Architectures PowerPC

  • Lors de l'utilisation des touches Alt-SysRq-W pour déboguer, le message d'avertissement suivant apparaîtra:

    Badness in smp_call_function at arch/powerpc/kernel/smp.c:223

    Ensuite, le système vous avertit qu'il va s'interrompre. Ce message devrait être ignoré car en réalité le système ne sera pas interrompu.

  • L'enregistrement doit être activé manuellement sur Dell M4300 et sur M6300. Pour cela, procéder aux étapes suivantes :

    1. Ouvrir alsamixer.

    2. Appuyer sur Tab pour afficher [Capture] dans le champ View (situé dans la partie supérieure gauche du menu).

    3. Appuyez sur la barre-espace Space.

    4. Pour vérifier que l'enregistrement est activé, le texte situé au dessus du champ ADCMux doit afficher L R CAPTUR.

  • La taille de l'image de noyau PPC est trop grande pour qu'OpenFirmware puisse la prendre en charge. De ce fait, le démarrage du réseau échouera, résultant à l'erreur suivante :

    Please wait, loading kernel...
    /pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: No such file or directory
    boot: 
    Pour contourner ce problème :
    1. Démarrez l'invite OpenFirmware, en pressant le touche '8' quand l'écran splash IBM est affiché.

    2. Exécutez la commande suivante :

      setenv real-base 2000000

    3. Démarrez le SMS (de l'anglais System Management Services / service de gestion des systèmes) par la commande :

      0
      > dev /packages/gui obe

8.5. Architectures s390x

  • Lorsque vous exécutez Red Hat Enterprise Linux 5.2 sur un z/VM qui comprend plus de 2Go de stockage invité de défini, les données invalides peuvent être lues et inscrites sur n'importe quel appareil FCP ou OSA en mode QDIO avec l'option QIOASSIST activée. Si votre système possède de tels appareils attachés, Red Hat recommande que vous chargiez et installiez les PTF (modification temporaire de logiciel) z/VM à partir du lien suivant:

    http://www-1.ibm.com/support/docview.wss?uid=isg1VM64306

  • Il n'est pas possible de lire ou de convertir directement un clichage z/VM dans un fichier. Vous devez, à la place, copier la première copie du clichage à partir du lecteur z/VM dans le système de fichiers Linux en utilisant vmur et convertir ce clichage dans un fichier lisible par Linux en utilisant vmconvert.

  • IBM System z ne fournit pas une console physique de style Unix traditionnelle. Ainsi, Red Hat Enterprise Linux 5.2 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.2 sur IBM System z, exécuter 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.

8.6. Architectures ia64

  • Certains systèmes Itanium ne peuvent pas produire correctement de sortie de console à partir du code kexec purgatory. Ce code contient des instructions pour sauvegarder les premiers 640k de mémoire après un crash.

    Tandis que la sortie de console purgatory peut s'avérer utile pour le diagnostique de problèmes , elle n'est pas utile pour que kdump fonctionne correctement. Ainsi, si votre système Itanium est réinitialisé pendant une opération kdump, désactiver la sortie de console danspurgatory en ajoutant --noio à la variable KEXEC_ARGS dans /etc/sysconfig/kdump.

  • Exécuter perftest échouera si des vitesses de CPU différentes sont détectées. Ainsi, vous devrez désactiver le cadrage de vitesse CPU avant d'exécuter perftest.

  • Quand le noyau kdump est démarré, l'erreur suivante apparaîtra dans le journal d'initialisation :

    mknod: /tmp/initrd.[numbers]/dev/efirtc: No such file or directory

    Cette erreur résulte d'une demande mal formulée de créer efirtc dans un chemin erroné. Cependant, le chemin de périphérique en question est également créé statistiquement dans le initramfs quand le service kdump démarre. Ainsi, une création du noeud de périphérique en cours d'exécution, est redondante, et ne devrait pas affecter la performance kdump.

  • Certains systèmes pourraient être incapables de démarrer le noyau kdump correctement. Dans de tels cas, utilisez le paramètre de noyau machvec=dig.

  • L'enregistrement doit être activé manuellement sur Dell M4300 et sur M6300. Pour cela, procéder aux étapes suivantes :

    1. Ouvrir alsamixer.

    2. Appuyer sur Tab pour afficher [Capture] dans le champ View (situé dans la partie supérieure gauche du menu).

    3. Appuyez sur la barre-espace Space.

    4. Pour vérifier que l'enregistrement est activé, le texte situé au dessus du champ ADCMux doit afficher L R CAPTUR.

  • Sur les systèmes Intel basés-Itanium et exécutant SELinux en mode forcé, les Booleans allow_unconfined_execmem_dyntrans ou allow_execmem Booleans doivent être activés de façon à ce que les Couches d'exécution IA-32 (the ia32el service) puissent opérer correctement. Si le Boolean allow_unconfined_execmem_dyntrans est désactivé, mais que le Booleanallow_execmem est activé, ce qui correspond à la configuration par défaut dans Red Hat Enterprise Linux 5, alors le service ia32el supporte l'émulation 32-bit, mais si les deux Booleans sont désactivés, alors l'émulation échouera.

A. Historique de révision

Historique des versions
Version 1.016th October 2008Ryan Lerch