Durante l'utilizzo della nuova funzione di cifratura del disco per cifrare il filesystem root, sarà possibile visualizzare il seguente messaggio d'errore sulla console durante lo spegnimento del sistema:
Stopping disk encryption [FAILED]
Questo messaggio può essere ignorato, il processo di spegnimento verrà completato con successo.
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.
L'installazione utilizzando un Multiple Device (MD) RAID insieme a multipath risulterà in un fallimento della procedura d'avvio della macchina. I dispositivi Multipath to Storage Area Network (SAN) che forniscono RAID internamente non vengono interessati.
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.
Quando si esegue l'aggiornamento da una versione precedente di Red Hat Enterprise Linux a 5.3, è possibile incontrare il seguente errore:
Updating : mypackage ################### [ 472/1655]
rpmdb: unable to lock mutex: Invalid argument
Il blocco si genera poichè il futex locking condiviso in glibc è stato migliorato in un futex per processo tra 5.2 e 5.3. Come risultato, i programmi in esecuzione con il 5.2 glibc non sono in grado di eseguire correttamente il futex locking condiviso nei confronti dei programmi in esecuzione con il 5.3 glibc.
Questo messaggio d'errore in particolare è un effetto collaterale di un pacchetto che richiama un rpm come parte dei propri script d'installazione. L'istanza rpm che esegue l'aggiornamento utilizza il glibc precedente attraverso il processo di aggiornamento, ma l'istanza rpm lanciata dall'interno dello script utilizza il nuovo 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 e mvapich2 in Red Hat Enterprise Linux 5 sono compilati per supportare solo gli interconnettori InfiniBand/iWARP. Di conseguenza essi non potranno essere eseguiti su ethernet o altri interconnettori di rete.
Sui sistemi con più di due dispositivi a blocchi cifrati, anaconda presenta una opzione per fornire una frase segreta globale. Gli script init tuttavia, non supportano questa caratteristica. Quando si avvia il sistema sarà richiesto l'inserimento di ogni singola frase segreta per tutti i dispositivi cifrati.
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.
La configurazione dell'affinità IRQ SMP non ha alcun effetto su alcuni dispositivi che utilizzano il message signalled interrupts (MSI) senza alcuna capacità MSI per-vector masking. Esempi dei suddetti dispositivi includono i dispositivi ethernet Broadcom NetXtreme che utilizzano il driver bnx2.
Se è necessario configurare l'affinità IRQ per questi dispositivi, disabilitare MSI tramite la creazione di un file in /etc/modprobe.d/ contenente la seguente riga:
options bnx2 disable_msi=1
Alterntivamente è possibile disabilitare completamente MSI utilizzando il parametro d'avvio del kernel pci=nomsi.
Un bug presente nel file /etc/udev/rules.d/50-udev.rules aggiornato, impedisce la creazione dei nomi persistenti per i dispositivi a nastro, con numeri maggiori di 9 nei propri nomi. Per esempio, per un dispositivo a nastro con un nome nst12, non verrà creato un nome persistente.
Per risolvere questo problema aggiungete un asterisco (*) dopo ogni stringa nst[0-9] in /etc/udev/rules.d/50-udev.rules.
Il tool smartctl non è in grado di leggere correttamente i parametri SMART dei dispositivi SATA.
Un bug presente nelle versioni precedenti di openmpi e lam potrebbe inpedire l'aggiornamento di questi pacchetti. Il suddetto bug si manifesta tramite il seguente errore (durante il tentativo di aggiornamento di openmpi o lam:
error: %preun(openmpi-[version]) scriptlet failed, exit status 2
Per questo motivo sarà necessario rimuovere manualmente le versioni più vecchie di openmpi e lam per installare le ultimissime versioni corrispondenti. Per fare questo utilizzate il seguente comando 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".
Non è supportata l'abilitazione di versioni multiple installate dello stesso modulo del kernel. In aggiunta, la presenza di un bug nel modo in cui i moduli del kernel sono analizzati, può talvolta risultare nell'abilitazione di una vecchia versione dello stesso modulo del kernel.
Red Hat consiglia durante l'installazione di una versione più recente di un modulo del kernel installato, di cancellare prima la versione più vecchia.
L'esecuzione di kdump su di un IBM Bladecenter QS21 o QS22 configurato con NFS root fallirà. Per evitare ciò specificate un target per l'NFS dump in /etc/kdump.conf.
I portatili IBM T60 si spegneranno completamente quando sospesi e connessi ad una docking station. Per evitare questo comportamento avviate il sistema con l'argomento acpi_sleep=s3_bios.
La Scheda di espansione iSCSI di QLogic per IBM Bladecenter fornisce le funzioni iSCSI ed ethernet. Alcune parti presenti sulla scheda sono condivise da entrambe le funzioni. Tuttavia i driver correnti qla3xxx e qla4xxx supportano in modo individuale le funzioni ethernet e iSCSI. I suddetti driver non supportano l'utilizzo simultaneo delle funzioni ethernet e iSCSI.
A causa di questa limitazione i successivi resettaggi (tramite comandi ifdown/ifup consecutivi), potrebbero sospendere il dispositivo. Per evitare questa sospensione fate trascorrere un intervallo di 10 secondi dopo ifup, prima di emettere ifdown. Altresì, fate trascorrere lo stesso intervallo di 10 secondi dopo un ifdown, prima di emettere ifup. Il suddetto intervallo permette di stabilizzare e inizializzare nuovamente tutte le funzioni quando viene emesso un ifup.
I laptop con scheda wireless Cisco Aironet MPI-350, possono entrare in una fase di sospensione nel tentativo di ottenere un indirizzo DHCP durante qualsiasi installazione basata sulla rete, utilizzando una porta ethernet cablata.
Per risolvere questo problema utilizzate per la vostra installazione il media locale. Alternativamente disabilitate la scheda wireless nel BIOS del laptop prima di eseguire l'installazione (è possibile riabilitare la scheda wireless dopo aver completato l'installazione).
Con Red Hat Enterprise Linux 5.3 il Boot-time logging su /var/log/boot.log non è disponibile.
Il sistema potrebbe non eseguire correttamente il riavvio nel kernel kexec/kdump, se X risulta essere in esecuzione ed utilizza un driver diverso da vesa. Questo problema esiste solo con i chpset grafici ATI Rage XL.
Se X è in esecuzione su di un sistema equipaggiato con ATI Rage XL, assicuratevi che esso stia utilizzando il driver vesa in modo da poter eseguire correttamente un processo di riavvio in un kernel kexec/kdump.
Se utilizzate Red Hat Enterprise Linux 5.2 su di una macchina con chipset nVidia CK804, è possibile visualizzare i seguenti messaggi del kernel:
kernel: assign_interrupt_mode Found MSI capability
kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
I suddetti messaggi indicano che porte PCI-E specifiche non richiedono IRQ. Altresì essi non interessano in alcun modo la normale funzionalità della macchina.
I dispositivi di storage estraibili (come ad esempio CD e DVD), non vengono montati automaticamente se siete registrati come utenti root. Per questo motivo sarà necessario montarli manualmente attraverso il file manager grafico.
Alternativamente è possibile eseguire il seguente comando per montare un dispositivo su /media:
mount /dev/[device name] /media
Se cancellate il LUN su di un sistema di storage configurato, questa modifica non verrà riportata sull'host. In questi casi i comandi lvm verranno sospesi in modo indeterminato se si utilizza dm-multipath, poichè il LUN è divenuto stale.
Per risolvere questo problema cancellate tutti i dispositivi e le entry del link mpath in /etc/lvm/.cache, specifiche al LUN in questione.
Per sapere quali sono queste entry eseguite il seguente comando :
ls -l /dev/mpath | grep [stale LUN]
Per esempio, se [stale LUN] è 3600d0230003414f30000203a7bc41a00, il risultato potrebbe essere:
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
Ciò significa che 3600d0230003414f30000203a7bc41a00 viene mappato su due link mpath: dm-4 e dm-5.
Per questo motivo le seguenti righe dovrebbero essere cancellate da /etc/lvm/.cache:
/dev/dm-4
/dev/dm-5
/dev/mapper/3600d0230003414f30000203a7bc41a00
/dev/mapper/3600d0230003414f30000203a7bc41a00p1
/dev/mpath/3600d0230003414f30000203a7bc41a00
/dev/mpath/3600d0230003414f30000203a7bc41a00p1
L'esecuzione del comando multipath con l'opzione -ll, può causare la sospensione del comando se uno dei percorsi si trova su di un dispositivo bloccante. Da notare che il driver non causa il fallimento della richiesta, se il dispositivo non risponde dopo un certo periodo di tempo.
Ciò è causato da un cleanup code, il quale attende fino a quando la richiesta del controllore del percorso viene completata o fallisce. Per visualizzare lo stato corrente di multipath senza sospendere il comando, utilizzare multipath -l.
L'aggiornamento di pm-utils da una versione Beta di Red Hat Enterprise Linux 5.2 di pm-utils fallirà generando il seguente errore:
error: unpacking of archive failed on file /etc/pm/sleep.d: cpio: rename
Per evitare questo tipo di errore cancellate la directory /etc/pm/sleep.d/ prima di eseguire l'aggiornamento. Se /etc/pm/sleep.d contiene alcuni file, spostateli su /etc/pm/hooks/.
Prove hardware per Mellanox MT25204 hanno rivelato la presenza di un errore interno sotto carichi di lavoro molto elevati. Quando il driver di ib_mthca riporta un errore catastrofico per questo hardware, esso si riferisce ad un completamento insufficiente della coda, relativo al numero di richieste pendenti generate dall'applicazione dell'utente.
Anche se il driver resetterà l'hardware e sarà in grado di ripristinare le proprie funzioni dopo tale evento, durante questo errore tutti i collegamenti esistenti verranno persi. Ciò risulterà in un errore di segmentazione nell'applicazione dell'utente. Altresì, se opensm è in esecuzione al momento dell'errore, sarà necessario riavviarlo manualmente per ripristinare le funzioni corrette.
Durante l'installazione di Red Hat Enterprise Linux 5 su di un guest, il guest viene configurato in modo da usare esplicitamente un kernel d'installazione temporaneo fornito da dom0. Una volta terminata l'installazione, esso potrà utilizzare il proprio bootloader. Tuttavia è possibile eseguire questo processo forzando il primo riavvio del guest in modo da risultare uno spegnimento.
Quindi, se si visualizza il pulsante al termine dell'installazione del guest, la sua selezione comporterà un arresto del guest senza riavviarlo. Questo è un comportamento previsto.
Se si desidera riavviare il guest dopo questo processo, esso utilizzerà il proprio bootloader.
L'esecuzione di rpmbuild sull'RPM sorgente compiz fallirà se qualsiasi KDE o pacchetto di sviluppo qt (per esempio qt-devel) sono installati. Tale comportamento è causato da un bug nello script di configurazione compiz.
Per risolvere questo problema rimuovere qualsiasi pacchetto di sviluppo qt o KDE, prima di compilare il pacchetto compiz dal proprio RPM sorgente.
Se il sistema possiede una scheda grafica ATI Radeon R500 o R600, firstboot non verrà eseguito dopo l'installazione. Il sistema andrà direttamente sulla schermata di login grafica saltando firstboot. Se si cercherà di eseguire manualmente firstboot (es. da un terminale failsafe), la sessione di X si arresterà inaspettatamente.
Questo problema si verifica a causa dell'impiego del driver usato dall'hardware ATI Radeon R500/R600. Il driver predefinito usato dalle schede grafiche risulta essere ancora una technology preview. Per risolvere questo problema eseguire il backup del file /etc/X11/xorg.conf; successivamente configurare X in modo da usare il driver vesa supportato invece di utilizzare il seguente comando:
system-config-display --reconfig --set-driver=vesa
Ora è possibile eseguire firstboot. Per smistarsi sulle vecchie impostazioni ripristinare /etc/X11/xorg.conf originale.
Se il vostro sistema utilizza il TSC timer, la chiamata del sistema gettimeofday potrebbe subire uno spostamento all'indietro. Tale comportamento si verifica a causa di un overflow il quale causerà un salto da parte del TSC timer in avanti in presenza di alcuni casi; Se si verifica tale situazione, il TSC timer sarà in grado di correggersi da solo registrando però un movimento indietro nel tempo.
Questo problema è particolarmente critico per sistemi time-sensitive, come ad esempio i sistemi di transizione e i database. Per questo motivo se il vostro sistema necessita di tempi precisi, Red Hat consiglia fortemente una impostazione del kernel in modo da utilizzare un timer diverso (per esempio HPET).
Il tentativo di esecuzione di sniff potrebbe generare un errore. Tale comportamento è causato poichè alcuni pacchetti essenziali non sono stati installati con dogtail.
Per evitare una situazione simile installate manualmente i seguenti pacchetti:
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.
In /etc/multipath.conf, l'impostazione di max_fds su unlimited impedirà l'avvio corretto del demone multipathd. Per questo motivo è consigliato usare un valore sufficientemente alto per questa impostazione.
SystemTap utilizza attualmente GCC per analizzare gli eventi dello spazio utente. Tuttavia GCC non è in grado di fornire ai debugger le informazioni esatte sull'elenco delle posizioni dei parametri. In alcuni casi GCC non è in grado di fornire la visibilità di alcuni parametri. Come conseguenza gli script di SystemTap che analizzano lo spazio utente potrebbero ritornare delle letture non accurate.
Il portatile IBM T41 non inserisce correttamente il ; per questo motivo continuerà a consumare normalmente la batteria. Tale comportamento si verifica poichè Red Hat Enterprise Linux 5 non include ancora il modulo radeonfb.
Per risolvere questo problema aggiungere lo script hal-system-power-suspend su /usr/share/hal/scripts/ che contiene le seguenti righe:
chvt 1
radeontool light off
radeontool dac off
Questo script assicura che il portatile IBM T41 sia in grado di inserire correttamente il . Per assicurare che il sistema riprenda correttamente le normali funzioni, aggiungere lo script restore-after-standby anche alla stessa directory che contiene le seguenti righe:
radeontool dac on
radeontool light on
chvt 7
Se il modulo edac è stato caricato, il riporto sulla memoria del BIOS non funzionerà. Tale comportamento si verifica poichè il modulo edac ripulisce il registro usato dal BIOS per il riporto degli errori sulla memoria.
Il Red Hat Enterprise Linux Driver Update Model corrente indica al kernel di caricare tutti i moduli disponibili (incluso il modulo edac) per default. Se si desidera assicurare un riporto della memoria del BIOS sul proprio sistema, sarà necessario inserire manualmente nella blacklist i moduli edac. Per fare questo aggiungere le seguenti righe su /etc/modprobe.conf:
blacklist edac_mc
blacklist i5000_edac
blacklist i3000_edac
blacklist e752x_edac
Red Hat Enterprise Linux 5.3 è in grado di rilevare l'aumento o la diminuzione di un dispositivo a blocchi. Tuttavia non vi è alcun metodo per rilevare automaticamente il cambiamento della dimensione di un dispositivo, per questo motivo saranno necessarie alcune fasi manuali per riconoscere il cambiamento, e ridimensionare qualsiasi file system che risiede sul dispositivo interessato. Una volta rilevata la modifica di un dispositivo a blocchi, un messaggio simile al seguente apparirà nei log del sistema:
VFS: busy inodes on changed media or resized disk sdi
Se il dispositivo a blocchi è aumentato in dimensione allora sarà possibile ignorare questo messaggio. Tuttavia se la dimensione del dispositivo a blocchi è diminuita senza però rimpicciolire i dati impostati sul dispositivo a blocchi, i dati presenti sul dispositivo in questione potrebbero essere corrotti.
È possibile eseguire solo un ridimensionamento di un file system creato sull'intero LUN (o dispositivo a blocchi). Se è presente una tabella delle partizioni sul dispositivo a blocchi, allora il file system devrà essere smontato per poter aggiornare la tabella delle partizioni.
Se è stato montato un file system GFS2 sul sistema, un nodo potrebbe entrare in uno stato di sospensione se un inode salvato sulla cache viene accesso in un nodo e rimosso dal link di un altro nodo. Se si verifica una situazione simile il nodo sospeso non sarà disponibile fino a quando non verrà isolato e ripristinato tramite un meccanismo normale di recupero del cluster. La funzione richiama gfs2_dinode_dealloc e shrink_dcache_memory apparirà nelle tracce dello stack di qualsiasi processo presente nel nodo sospeso.
Questo problema non interesserà alcun file system GFS2 con un solo nodo.
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'implementazione corrente di in ipmitool permette di configurare i dispositivi ma non il ripristino delle impostazioni correnti dei suddetti dispositivi.
L'utilizzo del parametro swap --grow in un file kickstart senza l'impostazione del parametro --maxsize, permette ad anaconda di imporre una restrizione sulla dimensione massima della partizione di swap, non permettendogli un aumento della dimensione in modo da riempire il dispositivo.
Per sistemi con meno di 2GB di memoria fisica, il limite imposto è due volte la quantità di memoria fisica. Per sistemi con più di 2GB, il limite imposto è la dimensione di memoria fisica più 2GB.
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).
