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.
When using an encrypted device, the following error message may be reported during bootup:
insmod: error inserting '/lib/aes_generic.ko': -1 File exists
This message can safely be ignored.
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.
When a large number of LUNs are added to a node, multipath can significantly increase the time it takes for udev to create device nodes for them. If you experience this problem, you can correct it by deleting the following line in
/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"
This line causes udev to run multipath every time a block device is added to the node. Even with this line removed, multipathd will still automatically create multipath devices, and multipath will still be called during the boot process, for nodes with multipathed root filesystems. The only change is that multipath devices will not be automatically created when multipathd is not running, which should not be a problem for the vast majority of multipath users.
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.
To avoid this error, upgrade glibc first in a separate run:
# yum update glibc
# yum update
You will also see this error if you downgrade glibc to an earlier version on an installed 5.3 system.
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é.
When upgrading openmpi using yum, the following warning may be returned:
cannot open `/tmp/openmpi-upgrade-version.*' for reading: No such file or directory
The message is harmless and can be safely ignored.
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.
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
When using dm-multipath, if features "1 queue_if_no_path" is specified in /etc/multipath.conf then any process that issues I/O will hang until one or more paths are restored.
To avoid this, set no_path_retry [N] in /etc/multipath.conf (where [N] is the number of times the system should retry a path). When you do, remove the features "1 queue_if_no_path" option from /etc/multipath.conf as well.
If you need to use "1 queue_if_no_path" and experience the issue noted here, use dmsetup to edit the policy at runtime for a particular LUN (i.e. for which all the paths are unavailable).
To illustrate: run dmsetup message [device] 0 "fail_if_no_path", where [device] is the multipath device name (e.g. mpath2; do not specify the path) for which you want to change the policy from "queue_if_no_path" to "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 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 (also known as "virtual provisioning") will be first released with EMC Symmetrix DMX3 and DMX4. Please refer to the EMC Support Matrix and Symmetrix Enginuity code release notes for further details.
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 correctement; et donc, 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 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: busy inodes on changed media or resized disk sdi
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.
The following message may be encountered during system boot:
Could not detect stabilization, waiting 10 seconds.
Reading all physical volumes. This may take a while...
This delay (which may be up to 10 seconds, dependant on the hardware configuration) is necessary to ensure that the kernel has completed scanning the disks.
L'implémentation actuelle de 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.
The
gfs2_convert program may not free up all blocks from the GFS metadata that are no longer used under GFS2. These unused metadata blocks will be discovered and freed the next time gfs2_fsck is run on the file system. It is recommended that
gfs2_fsck be run after the filesystem has been converted to free the unused blocks. These unused blocks will be flagged by gfs2_fsck with messages such as:
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)
These messages do not indicate corruption in the GFS2 file system, they indicate blocks that should have been freed, but were not. The number of blocks needing to be freed will vary depending on the size of the file system and block size. Many file systems will not encounter this issue at all. Large file systems may have a small number of blocks (typically less than 100).
