Introduzione

In questo documento vengono trattati i seguenti argomenti:

  • Note relative all'installazione

  • Aggiornamento dei contenuti

  • Aggiornamenti del kernel

  • Aggiornamenti del driver

  • Technology Preview

  • Problematiche risolte

  • Problematiche conosciute

Alcuni aggiornamenti di Red Hat Enterprise Linux 4.8 potrebbero non essere inclusi in questa versione delle note di rilascio. Una versione aggiornata delle suddette note di Red Hat Enterprise Linux 4.8 è disponibile anche sul seguente URL:

http://www.redhat.com/docs/manuals/enterprise/

Ciclo di vita

Il ciclo di vita di Red Hat Enterprise Linux 4 è disponibile su: https://www.redhat.com/security/updates/errata/

Come precedentemente annunciato la versione di Red Hat Enterprise Linux 4.8 segna l'inizio della 2 Fase di produzione di Red Hat Enterprise Linux 4. Non sarà presente alcun nuovo tipo di hardware durante questa fase.

https://www.redhat.com/archives/nahant-list/2008-July/msg00059.html

Da notare che le sottoscrizioni dei clienti forniscono l'accesso necessario a tutte le versioni attualmente supportate di Red Hat Enterprise Linux.

Note relative all'installazione

La sezione seguente include le informazioni specifiche all'installazione di Red Hat Enterprise Linux e del programma di installazione Anaconda.

Nota Bene

Per l'aggiornamento di una versione minore di Red Hat Enterprise Linux 4 (come ad esempio da 4.6 a 4.7) a Red Hat Enterprise Linux 4.8, è consigliato utilizzare il Red Hat Network attraverso una hosted web user interface o Red Hat Network Satellite.

Se state eseguendo l'aggiornamento di un sistema senza connettività di rete, utilizzate la funzione "Upgrade" di Anaconda. Tuttavia ricordate che Anaconda presenta dei limiti nella gestione delle problematiche relative alle dipendenze su repositori aggiuntivi o su applicazioni di terzi. Altresì Anaconda riporta gli errori d'installazione all'interno di un file di log, e non in modo interattivo.

Per questo motivo Red Hat consiglia durante l'aggiornamento di sistemi offline, di provare e poi verificare l'integrità della vostra configurazione di aggiornamento. Assicuratevi di controllare attentamente il log di aggiornamento prima di applicarlo al vostro ambiente di produzione.

Gli 'In-place upgrade' tra versioni importanti di Red Hat Enterprise Linux (per esempio un aggiornamento da Red Hat Enterprise Linux 3 a Red Hat Enterprise Linux 4.8) non è supportato. Anche se l'opzione "Upgrade" di Anaconda vi permette di eseguire tale procedimento, non vi è alcuna garanzia che tale processo risulterà in una installazione funzionante. Questo tipo di aggiornamento tra release importanti non conservano tutte le impostazioni del sistema. Per questo motivo Red Hat consiglia vivamente l'esecuzione di una nuova installazione se desiderate eseguire un aggiornamento tra versioni importanti.

  • Se state copiando i contenuti dei CD-ROM di Red Hat Enterprise Linux 4.8 (per esempio, in preparazione per una installazione basata sulla rete), assicuratevi di copiare i CD-ROM solo per il sistema operativo. Non copiate i CD-ROM aggiuntivi, o qualsiasi altro CD-ROM, in quanto tale operazione sovrascriverà i file necessari per il corretto funzionamento di Anaconda.

    I suddetti CD-ROM devono essere installati dopo l'installazione di Red Hat Enterprise Linux.

  • La versione di GRUB presente con Red Hat Enterprise Linux 4 (e tutti gli aggiornamenti) non supporta il mirroring del software (RAID1). Per questo motivo se installate Red Hat Enterprise Linux 4 su di una partizione RAID1, il bootloader verrà installato nel primo disco fisso e non sul master boot record (MBR). Tale processo renderà il sistema non avviabile.

    Se desiderate installare Red Hat Enterprise Linux 4 su di una partizione RAID1 è consigliato cancellare prima qualsiasi bootloader esistente dal MBR.

  • Quando installate Red Hat Enterprise Linux 4 in modalità di testo su sistemi che utilizzano monitor a schermi piatti e alcune schede ATI, l'area dello schermo potrebbe apparire spostata. In tal caso alcune aree verranno oscurate.

    Se verifica tale comportamento eseguite l'installazione con il parametro linux nofb.

  • Durante l'aggiornamento di Red Hat Enterprise Linux 4.6 a questa release, minilogd potrebbe registrare numerose negazioni SELinux. Questi errori sono innocui e possono essere ignorati.

  • Precedentemente all'interno della documentazione kickstart di Anaconda (situata in: /usr/share/doc/anaconda-<anaconda-version>/kickstart-docs.txt), la sezione contenente l'opzione--driveorder in un file kickstart indicava:

    Specify which drive is first in the BIOS boot order.
                                            

    Tuttavia l'opzione --driveorder necessita di un elenco di tutte le unità presenti sul sistema riportando nell'elenco stesso prima il boot device. Con questo aggiornamento la documentazione è stata migliorata e riporta ora:

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

    Quando si utilizza l'opzione --driveorder in un file kickstart, l'elenco deve includere tutte le unità presenti nel sistema.

Aggiornamento dei contenuti

  • Systemtap è ora completamente supportato con Red Hat Enterprise Linux 4. systemtap fornisce una infrastruttura (GPL) di software libero, in grado di semplificare la raccolta delle informazioni sul sistema Linux in esecuzione. Tale processo aiuta nella diagnosi dei problemi sulla prestazione e funzionalità del sistema. Con l'ausilio di systemtap, gli sviluppatori non hanno più bisogno di seguire processi lunghi e laboriosi di ricompilazione, installazione e riavvio, che potrebbero essere invece necessari per la raccolta dei dati.

    Alcune funzioni di systemtap per sistemi più recenti di Red Hat Enterprise Linux o Linux, non funzioneranno su Red Hat Enterprise Linux 4 a causa della mancanza delle funzioni relative al kernel. L'assenza del kernel utrace esclude il supporto per qualsiasi probing dello spazio utente.

  • dmidecode fornisce le informazioni relative ai BIOS e alle revisioni della sceda madre. La versione di kernel-utils presente con questa informativa, aggiorna dmidecode dalla versione 2.2 alla versione 2.9. Questa versione identifica i processori più recenti, gli slot PCI-express ed i dispositivi, ed il blade chassis. Offre altresì un supporto migliorato per la specifica SMBIOS v2.6.

  • è inclusa con questa release una nuova versione di kernel-utils, la quale aggiorna il file Intel microcode alla versione 20080910, in modo da supportare i processori Intel più recenti.

  • smartmontools è stato esteso per il supporto di controllori CCISS più recenti presenti in HP ProLiant hardware più recenti.

  • Il pacchetto Samba è stato modificato alla versione dell'upstream 3.0.33. La versione 3.0.x è un bugfix per il branch del codice di base di Samba. Modificando la versione alla 3.0.33, verranno inclusi un certo numero di bug fix e di correzioni relative alla sicurezza. Questa versione non aggiunge alcuna nuova funzione.

    Per maggiori informazioni sulle correzioni dell'upstream presenti in questa versione consultate le Note di rilascio di Samba: http://samba.org/samba/history/samba-3.0.33.html

  • ipmitool è stato aggiornato alla versione upstream 1.8.11, la quale fornisce numerose bug fix e miglioramenti rispetto alla versione precedente, incluso:

    • Aggiornamento della documentazione

    • Bugfix per SDR/FRU, SOL e molti altri

    • Nuovi comandi e opzioni

    Si prega di notare che il comportamento dello switch della linea di comando -K è stato modificato da prompt for Kg key a read Kg key from environment variable. Il flag -Y si comporta come -K prima di questo aggiornamento.

Aggiornamenti del Kernel

  • Precedentemente una estensione nel codice ptrace di x86_64 risultava mancante, e poteva causare il fallimento di gdb sull'architettura x86_64 durante il debugging dell'applicazione i386. Con questo aggiornamento l'estensione mancante è stata corretta risolvendo così questa problematica.

  • Non è sicuro caricare il modulo ibmphp. In precedenza il meccanismo che impediva la rimozione del modulo ibmphp non era sufficiente e comportava una fase d'arresto. Con questo aggiornamento il processo che impediva la rimozione di questo modulo è stato corretto e migliorato, impedendo così il verificarsi di questo problema. Tuttavia, il tentativo di rimuovere il modulo potrebbe generare un messaggio di avvertenza il quale indica che la sua rimozione non è un processo sicuro. Questo messaggio può essere ignorato.

  • Con questo aggiornamento la memoria virtuale verrà limitata a 64GB per i kernel x86 a 32-bit in esecuzione sui sistemi con più di 64GB. Il kernel divide la memoria in due sezioni separate: Lowmem e Highmem. Lowmem viene mappata nello spazio per l'indirizzo del kernel. Highmem, tuttavia, viene mappata nella finestra virtuale del kernel, la mappatura si verifica una pagina per volta in base alle esigenze. Se gli I/O della memoria possono oltrepassare 64GB, la misura mem_map (conosciuta anche come array della pagina) può raggiungere o superare la misura di Lowmem. In tale circostanza si verificherà un panic del kernel durante il boot oppure si verificherà un suo avvio prematuro. Nel secondo caso il kernel non riuscirà ad assegnare la memoria del kernel dopo il processo d'avvio e si verificherà un panic o uno stato di sospensione.

  • In precedenza se un utente pigiava ripetutamente i tasti freccetta su di un Hardware Virtual Machine (HVM) si verificava un ' interrupt race condition' (condizione di corsa critica) tra l'hardware ed il timer. Ne risultavano una serie di eventi sconosciuti del keycode riportati dal driver della tastiera. Con questo aggiornamento i8042 polling timer è stato rimosso, risolvendo così questa problematica.

  • Con questo aggiornamento l'utilità diskdump (la quale fornisce la possibilità di creare e raccogliere i dump del kernel vmcore) è ora supportata per l'utilizzo con il driver sata_svw.

  • Con questo aggiornamento il parametro "swap_token_timeout" è stato aggiunto a /proc/sys/vm.

    Questo file contiene un valore 'hold' valido del token di protezione responsabile per lo swap. Il sottosistema Linux Virtual Memory (VM) possiede un meccanismo di controllo per l'utilizzo eccessivo basato sul token, ed utilizza il token stesso per evitare la presenza di errori non necessari della pagina in situazioni di utilizzo eccessivo. Il valore è espresso in `secondi`. Il valore sarà utile per regolare il comportamento durante un uso molto intenso, impostandolo su 0 verrà disabilitato il meccanismo del token per lo swap.

  • Precedentemente se si verificavano alcune problematiche relative al client NFSv4 (Network File System Version 4) durante la processazione di una directory utilizzando readdir(), veniva ritornato un errore per l'intera chiamata readdir(). Con questo aggiornamento il flag fattr4_rdattr_error viene ora impostato durante l'esecuzione di una chiamata readdir(), indicando al server di continuare le sue funzioni e di riportare solo l'errore sulla voce della directory specifica che causava l'errore.

  • Precedentemente il client NFS (Network File System) non gestiva le risposte malformate della funzione readdir(). Di conseguenza, la risposta del server indicava che la chiamata per la funzione readdir() aveva avuto successo anche se la risposta non conteneva alcuna voce. Con questo aggiornamento la logica di analisi della risposta readdir() è stata modificata, in modo tale che in presenza di una risposta malformata il client ritorna un errore I/O.

  • Il client RPC conserva il risultato di una chiamata portmap in una posizione all'interno della memoria in grado di essere liberata e riutilizzata in circostanze specifiche. Tuttavia in casi specifici, rimuovendo la chiamata portmap dalla memoria troppo presto si poteva causare una corruzione della memoria. Con questo aggiornamento è stato aggiunto un conteggio di riferimento alla posizione della memoria all'interno della quale viene conservato il risultato di portmap, liberandolo solo dopo il suo utilizzo.

  • In alcune circostanze l'assegnazione di determinate strutture dati per le chiamate RPC poteva essere bloccata quando la memoria del sistema risultava bassa. Di conseguenza si potevano verificare deadlock in condizioni di uso intenso della memoria in presenza di un numero molto grande di pagine NFS in attesa per il writeback. Con questo aggiornamento l'assegnazione delle strutture dati è ora 'non-blocking' e risolve così questo problema.

  • In precedenza era possibile avere livelli di prestazione molto bassi durante la scrittura simultanea su di un volume speculare LVM (utilizzando il flag O_SYNC). Di conseguenza ogni I/O di scrittura su di un volume speculare veniva ritardato di 3ms, rallentando il volume speculare di circa 5-10 volte rispetto ad un volume lineare. Con questo aggiornamento è stato aggiunto l'I/O queue unplugging al driver dm-raid1, migliorando così le prestazioni dei volumi speculari rendendoli compatibili con quelle dei volumi lineari.

  • È stato aggiunto un nuovo parametro per la regolazione il quale permette agli amministratori di sistema di modificare il numero massimo di pagine modificate, scritte da kupdate sul disco per iterazione ad ogni sua esecuzione. Questo nuovo parametro (/proc/sys/vm/max_writeback_pages) imposta come default un valore di 1024 (4MB), così facendo un massimo di 1024 pagine verranno trascritte ad ogni iterazione di kupdate. Aumentando questo valore verrà modificato il comportamento di kupdate nei confronti delle pagine modificate, diminuendo la quantità di dati persi eventuale se il sistema si arresta inaspettatamente durante le esecuzioni di kupdate. Tuttavia l'aumento del valore max_writeback_pages porebbe avere una ripercussione negativa sulle prestazioni dei sistemi sensibili ai carichi I/O.

  • È stato aggiunto un nuovo valore al parametro regolabile /proc/sys/kernel/wake_balance. L'impostazione di wake_balance su di un valore pari a 2, indicherà allo scheduler di eseguire il thread su qualsiasi CPU disponibile invece di programmarlo sulla CPU ottimale. L'impostazione di questo parametro del kernel su 2, forzerà lo scheduler a ridurre la latenza generale anche a scapito delle prestazioni del sistema.

  • Durante il controllo di un albero della directory il modulo del kernel potrebbe in alcuni casi decidere incorrettamente che l'albero in questione non è occupato. Un offset mount attivo con una gestione del file aperto usata per controllare la sua scadenza, non eseguiva il conteggio durante il controllo del suo stato di occupato. Venivano così generate richieste di montaggio per offset già montati. Con questo aggiornamento il controllo da parte del modulo del kernel è stato corretto e le richieste non corrette non vengono più generate.

  • Durante l'inizializzazione del sistema il rivenditore della CPU veniva rilevato dopo l'inizializzazione di Advanced Programmable Interrupt Controller (APIC). Di conseguenza sui sistemi x86_64 AMD con più di 8 core veniva utilizzata la modalità clusterizzata APIC, diminuendo così le prestazioni del sistema. Con questo aggiornamento il rivenditore della CPU viene rilevato prima del processo di inizializzazione di APIC, utilizzando per impostazione predefinita una modalità physical flat di APIC e risolvendo così il problema.

  • Il codice Common Internet File System (CIFS) è stato aggiornato in Red Hat Enterprise Linux 4.8, e corregge così un certo numero di bug precedentemente corretti nell'upstream, incluso:

    In passato durante il montaggio di un server senza estensioni Unix era possibile modificare la modalità di un file. Tuttavia questo cambiamento non poteva essere salvato in modo permanente, con un conseguente cambiamento alla modalità originaria in qualsiasi momento. Con questo aggiornamento la modalità del file non può essere momentaneamente modificata per default; le chiamate chmod() ritorneranno messaggi che confermano la modifica senza però avere alcun risultato. È necessario usare una nuova opzione di montaggio, dynperm, se desiderate instaurare la modalità precedente.

  • In passato all'interno del kernel era possibile avere una condizione di corsa critica tra dio_bio_end_aio() e dio_await_one(). In questi casi l'I/O diretto era in attesa in modo indefinito su di un processo I/O completato. Con questo aggiornamento le operazioni di conteggio sono ora bloccate in modo tale che i percorsi di sottomissione e di completamento visualizzano uno stato unico, risolvendo così questo problema.

  • In precedenza il processo di aggiornamento di un sistema guest completamente virtualizzato da Red Hat Enterprise Linux 4.6 (con il pacchetto kmod-xenpv installato) ad una nuova versione di Red Hat Enterprise Linux 4, risultava in una dipendenza non corretta del modulo tra i moduli del kernel interni: xen-vbd.ko & xen-vnif.ko ed il modulo più vecchio xen-platform-pci.ko. Di conseguenza i file system montati tramite il block driver xen-vbd.ko, ed il networking del guest utilizzando il driver della rete xen-vnif.ko fallivano.

    In Red Hat Enterprise Linux 4.7 la funzione presente nel modulo xen-platform-pci.ko era interna al kernel. Tuttavia quando un modulo caricabile precedente del kernel diventa parte del kernel, il controllo del riferimento della dipendenza per la presenza di moduli caricabili non viene preso in considerazione in modo corretto in module-init-tools. Con questo aggiornamento la funzione xen-platform-pci.ko è stata rimossa dal kernel interno e posizionata sul modulo caricabile, permettendo a module-init-tools di controllare e creare le dipendenze corrette durante l'aggiornamento del kernel.

  • In precedenza il tentativo di montare i dischi o le partizioni in un guest completamente virutalizzato a 32-bit di Red Hat Enterprise Linux 4.6 utilizzando un block driver paravirtualizzato (xen-vbd.ko) su di un host a 64-bit, falliva. Con questo aggiornamento il block front driver (block.c) è stato aggiornato in modo da informare il block back driver che il guest utilizza il protocollo a 32-bit. Tale modifica risolve questo problema.

  • In precedenza l'installazione dei driver pv-on-hvm su di un kernel bare-metal, creava automaticamente la directory /proc/xen. Di conseguenza, le applicazioni che verificavano l'esecuzione del kernel virtualizzato su di un sistema tramite l'esistenza della directory /proc/xen, potevano assumere erroneamente che il kernel virtualizzato era in uso. Con questo aggiornamento i driver pv-on-hvm non creano più la directory /proc/xen risolvendo così questo problema.

  • In passato i guest paravirtualizzati potevano avere un massimo di 16 dispositivi a disco. Con questo aggiornamento il suddetto limite è stato aumentato ad un massimo di 256 dispositivi.

Aggiornamenti del driver

  • Il driver Intel® High Definition Audio (HDA) in ALSA è stato aggiornato. Questo aggiornamento migliora il supporto audio per nuovi hardware con audio integrato HDA.

  • In precedenza i dispositivi di rete che utilizzavano il driver forcedeth potevano non rispondere durante l'emissione del comando rcp dai client multipli. Con questo aggiornamento il driver forcedeth è stato aggiornato, risolvendo così questo problema.

  • In passato la modalità Automatic Direct Memory Access (ADMA) veniva abilitata per default nel driver sata_nv. Di conseguenza, era possibile avere errori del dispositivo e timeout con alcuni dispositivi che utilizzavano il driver sata_nv. Con questo aggiornamento la modalità ADMA è stata disabilitata, risolvendo così questo problema.

  • I driver di virtio, la piattaforma per la virtualizzazione I/O in KVM, sono stati implementati su Red Hat Enterprise Linux 4.8 dal Linux Kernel 2.6.27. I suddetti driver permetteranno ai client KVM di raggiungere livelli più elevati di prestazioni I/O. Vari componenti dello spazio utente come ad esempio: anaconda, kudzu, lvm, selinux e mkinitrd sono stati aggiornati per il supporto dei dispositivi virtio.

  • Il driver r8169 è stato aggiornato e fornisce un supporto per i nuovi chipset di rete. Con questo aggiornamento tutte le varianti di RTL810x/RTL8168(9) sono ora supportate in Red Hat Enterprise Linux 4.8.

  • Il driver mptsas è stato aggiornato alla versione 3.12.29.00. Questo aggiornamento include i bug fix e abilita le seguenti nuove funzioni:

    • Supproto Dual Port

    • Gestione alimentazione del chip SAS

  • Il driver lpfc è stato aggiornato alla versione 8.0.16.46. Questo aggiornamento presenta numerosi bug fix e miglioramenti incluso:

    • supporto per FCoE LP21000 HBA

    • supporto per HBAnyware 4.0

  • Il driver megaraid_sas per i controller RAID basati su SAS è stato aggiornato alla versione 4.01-RH1. Questo aggiornamento applica numerosi bug fix e miglioramenti, incluso:

    • Supporto aggiunto per i Controller LSI Generation 2 (0078, 0079)

    • Aggiunto un comando per lo spegnimento del DCMD nella routine di spegnimento, per migliorare il processo di shutdown del firmware.

    • È stato corretto un bug che causava delle interruzioni inaspettate all'interno del driver hardware di Linux.

  • Il driver del dispositivo ethernet eHEA per IBM eServer System P è stato aggiornato alla versione 0078-08.

  • Il driver del dispositivo EHCA infinband non verrà più supportato con Red Hat Enterprise Linux 4.8 e tutte le release future di Red Hat Enterprise Linux 4.

Technology Preview

Le Technology Preview non sono attualmente supportate con i servizi di sottoscrizione di Red Hat Enterprise Linux 4.8 poichè le stesse potrebbero essere funzionalmente non complete, e quindi generalmente non idonee per ambienti di produzione. Tuttavia le suddette caratteristiche sono incluse per convenienza per l'utente, e per fornire alle funzioni una esposizione più ampia.

Gli utenti potrebbero utilizzare queste caratteristiche all'interno di un ambiente non di produzione. Altresì, è possibile fornire suggerimenti sulla loro funzionalità, in modo da migliorarle e successivamente supportarle. Ricordiamo che verranno emessi alcuni errata per problematiche che riguardano la sicurezza.

Durante il processo di sviluppo di una funzione della technology preview, componenti aggiuntivi potrebbero esser resi disponibili al pubblico al solo scopo di prova. È intenzione di Red Hat supportare pienamente le caratteristiche di technology preview in una release futura.

Per maggiori informazioni sulle Technology Preview di Red Hat Enterprise Linux, si prega di consultare la pagina Technology Preview Features Support Scope del sito web di Red Hat.

Problematiche risolte

  • In precedenza se il Red Hat Network applet veniva usato per registrare nuovamente il client su un Red Hat Satellite Server diverso, l'applet continuava a mostrare gli aggiornamenti disponibili sul server precedente anche se gli stessi non erano disponibili sul server corrente. In tale circostanza /etc/sysconfig/rhn/rhn-applet non veniva modificato per riflettere le informazioni del nuovo server. La versione dell'applet fornita con questo aggiornamento associa una cache di aggiornamenti con un url del server, assicurando così che gli aggiornamenti mostrati all'utente sono effettivamente disponibili. Questa versione è in grado di rilevare altresì quando il proprio file di configurazione è stato modificato. Se tale modifica viene rilevata, l'applet ricaricherà automaticamente le variabili di configurazione e creerà nuovi collegamenti server.

  • sysreport.legacy utilizzava $HOME come propria directory root. Nel caso in cui questa variabile dell'ambiente non era disponibile o se la directory in questione non poteva essere modificata, sysreport.legacy non era in grado di generare il proprio riporto ed usciva mostrando il seguente messaggio Cannot make temp dir. Sysreport.legacy utilizza ora una directory creata in modo randomico come directory root, e quindi è in grado di generare un riporto anche su di un sistema senza una $HOME utilizzabile.

  • Il demone automount utilizzava buffer con una dimensione fissa di 128 byte, per ricevere le informazioni da SIOCGIFCONF ioctl relative alle interfacce locali durante il test per la vicinanza di un host corrispondente ad un determinato mount. Poichè le informazioni di ogni interfaccia sono di 40 byte, il demone è in grado di ricevere le informazioni utilizzando non più di tre interfacce locali. Se l'host corrispondente al mount era in possesso di un indirizzo locale ma non corrispondeva ad una delle tre interfacce, in tal caso la vicinanza veniva classificata in modo incorretto.

    Il demone automount assegna ora automaticamente un buffer, assicurandosi che sia sufficientemente grande da contenere le informazioni su tutte le interfacce presenti sul sistema, conferendo l'abilità di rilevare correttamente la vicinanza di un host ad un mount NFS.

  • Automount mappa le voci che si riferiscono agli host multipli nella posizione di mount (mount replicato), il demone di automount esamina un elenco degli host remoti per la verifica della loro prossimità e della rispettiva versione NFS. Nel caso in cui nessuno degli host risponde, essi verranno rimossi dall'elenco. Di conseguenza se nessuno degli host invia una risposta, l'elenco risulterà vuoto. In precedenza il demone non eseguiva alcun controllo dell'elenco e non era a conoscenza se lo stesso fosse vuoto, tale comportamento generava un errore di segmentazione (NULL pointer dereference). A tal proposito è stato aggiunto questo tipo di controllo.

  • il pacchetto ttfonts-zh_CN includeva il carattere Zhong Yi Song TrueType. Il copyright per questo tipo di carattere appartiene a Beijing Zhong Yi Electronics Co., il quale ha permesso a Red Hat Inc. di distribuirlo solo sui prodotti e sul software di Red Hat. L'inclusione di questo carattere in ttfonts-zh_CN, impedisce una distribuzione gratuita, da parte di Red Hat, di questo pacchetto. Il carattere Zhong Yi Song TrueType è ancora disponibile ai clienti di Red Hat tramite Red Hat Network ed il CD Supplementare nel pacchetto fonts-chinese-zysong.

  • In precedenza multipathd si arrestava inaspettatamente con uno stato multipathd dead but pid file exists quando multipath era configurato su 1024 o maggiore, poichè esso non era in grado di aprire un descrittore di file per ogni percorso. Tale comportamento poteva causare errori error calling out /sbin/mpath_prio_ontap /dev/[device]. Ora un nuovo parametro di multipath.conf, max_fds, permette agli utenti finali di impostare un numero massimo di descrittori di file che il processo multipathd è in grado di aprire, o permette di utilizzare max per impostare il suddetto numero sul valore massimo accettato dal sistema. Impostando max_fds ad un valore sufficientemente alto o su max, è possibile impedire un arresto inaspettato di multipathd.

  • In passato durante l'utilizzo del driver accraid con un controller Adaptec 2120S o Adaptec 2200S, il sistema non era in grado di eseguire il processo d'avvio e ritornava il seguente errore: aac_srb:aac_fib_send failed with status 8195. Con questo aggiornamento il driver accraid è stato migliorato e non causa più questo tipo di comportamento.

  • SOS è un set di tool in grado di raccogliere le informazioni relative alla configurazione corrente e all'hardware del sistema. Le informazioni possono essere usate per processi di diagnosi e di debugging.

    Con questo aggiornamento i riporti generati da sosreport includono ora cinque tipi di informazioni precedentemente non incluse:

    • il contenuto di /var/log/cron* e l'output di crontab -l per visualizzare ciò che era in esecuzione al momento dell'errore.

    • le informazioni relative alla partizione di parted e non le informazioni precedentemente raccolte da fdisk, poichè parted è in grado di raccogliere le informazioni della partizione in situazioni nelle quali fdisk non era in grado di eseguire (per esempio, per partizioni GUID).

    • output di dumpe2fs -l.

    • il contenuto di /etc/inittab.

    • output di "/sbin/service --status-all" per mostrare lo stato corrente dei servizi. Precedentemente venivano raccolte solo le rispettive impostazioni al momento dell'avvio (di "chkconfig --list").

  • automount utilizza umount(8) al momento delle scadenze dei mount e umount(8) attenderà senza alcun limite la risposta del server. Tale comportamento è in grado di provocare un blocco della scadenza, in questo caso il processo di montaggio scadrà solo dopo un periodo molto lungo all'interno dello stesso processo /usr/sbin/automount (cioè, il processo di montaggio gestito da automount). Di conseguenza, se un server non è raggiungibile, automount non eseguirà alcun processo di smontaggio dei mount scaduti, tale comportamento si verificherà anche nei confronti dei server in grado di rispondere. In tal caso i sistemi presenteranno un numero molto elevato di processi di montaggio che possono scadere. Automount include ora una opzione della linea di comando in grado di specificare il periodo di attesa di automount prima di passare ai mount successivi. I mount scaduti possono quindi essere rimossi anche se alcuni server non sono in grado di rispondere.

  • Il pacchetto netpbm è stato aggiornato in modo da correggere i seguenti bug:
    • Numerose utilità presenti con netpbm non accetavano in passato i file provenienti da input standard anche se questo metodo era conforme alla documentazione. Con questo aggiornamento la suddetta problematica è stata risolta.

    • Numerose utilità presenti in netpbm potevano arrestarsi inaspettatamente durante la processazione dei file immagine. Con questo aggiornamento questo problema è stato risolto.

  • i server del protocollo della messaggistica di Internet ICQ sono stati modificati ed ora necessitano di client per l'utilizzo di una nuova versione del protocollo ICQ. L'esecuzione di un login su ICQ con Pidgin 2.5.2 (la versione precedentemente fornita con Red Hat Enterprise Linux 4) falliva, generando un messaggio d'errore. Con questo aggiornamento Pidgin è stato aggiornato alla versione 2.5.5 e risolve quindi questo tipo di problema.

  • In precedenza l'articolo del Red Hat Knowledgebase relativo al Fibre Channel rescan in Red Hat Enterprise Linux 4 non era accurato. Questo processo è stato ora aggiornato e può essere consultato su: http://kbase.redhat.com/faq/docs/DOC-3942

  • Dopo aver eseguito un collegamento ad un server SSH, il server è in grado di ritornare al client SSH un banner basato sul testo. Per questo motivo se gftp (un cleint ftp grafico) cercava di collegarsi (tramite SFTP) ad un server SSH, il quale a sua volta ritornava un banner, gftp poteva interpretare il suddetto banner come un errore, chiudendo così il collegamento. Con questo aggiornamento gftp è stato aggiornato alla versione 2.0.18, e permette l'instaurazione dei collegamenti ai suddetti server.

  • Durante il caricamento di un singolo file su di una directory NFS, il timestamp che indica i tempi di accesso e di modifica del file potevano essere registrati incorrettamente. Ora invece il timestamp è sempre aggiornato e risolve così questo tipo di problema

  • Il probing code in kudzu per i dispositivi PCI potrebbe non trovare correttamente alcuni moduli che operano tramite il legame alle classi PCI specifiche, ed in particolare, il driver sgiioc4 sui sistemi SGI Altix. Senza il caricamento dei suddetti moduli il sistema non sarà in grado di rilevare i dispositivi che dipendono dal driver. Una nuova versione del probing code viene inclusa in questo pacchetto aggiornato, ed è in grado di localizzare i moduli interessati.

Problematiche conosciute

  • Il Logical Volume Manager in Red Hat Enterprise Linux 4.8 riporta alcune perdite dei descrittori di file con una conseguente presenza di un errore nell'output d'installazione:

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

    Questo messaggio può essere ignorato.

  • Durante l'installazione di Red Hat Enterprise Linux 4 attraverso un server Network File System (NFS), il programma d'installazione non è in grado di chiudere correttamente i mount point NFS. Ciò potrebbe causare un comportamento non corretto del server NFS. In questi casi Red Hat consiglia di utilizzare un server HTTP per i processi d'installazione.

  • Sui sistemi dove il BIOS è in grado di eseguire un PCI hotplugging di tipo legacy (acpiphp) e native (pciehp), è necessaria una scelta da parte dell'amministratore di un metodo preferito e di impedire al tempo stesso il caricamento del modulo relativo al metodo indesiderato da parte di Red Hat Enterprise Linux 4. Per eseguire questo processo inserire il modulo indesiderato all'interno della blacklist in /etc/modprobe.conf.

  • Prove hardware per Mellanox MT25204 hanno rivelato la presenza di un errore interno sotto alcune condizioni di carico elevato. Quando il driver ib_mthca riporta un errore catastrofico su questo hardware, esso si verifica generalmente a causa di una lunghezza insufficiente della coda di attesa relativa al numero delle richieste di lavoro sospese generate dall'applicazione utente.

    Anche se il driver resetterà l'hardware e ripristinerà le normali funzioni dopo tale evento, tutti i collegamenti esistenti al momento dell'errore verranno perduti. Tale comportamento genera normalmente un errore di segmentazione all'interno dell'applicazione utente. Ed ancora, se opensm è in esecuzione al momento dell'errore, allora sarà necessario riavviarlo manualmente per ripristinare le normali funzioni.

  • Un bug nelle versioni precedenti di openmpi e lam potrebbe impedire l'aggiornamento di questi pacchetti. Lo stesso bug potrebbe causare il fallimento di up2date durante l'aggiornamento di tutti i pacchetti.

    Questo bug genera il seguente errore durante il tentativo di aggiornamento di openmpi o lam:

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

    Questo bug si manifesta anche nel seguente errore (registrato in /var/log/up2date) durante il tentativo di aggiornamento di tutti i pacchetti tramite up2date:

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

    Per evitare questi errori è necessario rimuovere prima manualmente le versioni più vecchie di openmpi e lam. Per fare questo usate il comando rpm:

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

  • Se rimuovete un LUN da un sistema di storage configurato, tale modifica non verrà riportata sull'host. In questi casi i comandi lvm verranno sospesi indefinitivamente se utilizzate dm-multipath, poichè il LUN è in uno stato stale.

    Per risolvere questo problema cancellate tutte le voci del link mpath e del dispositivo in /etc/lvm/.cache specifici a stale LUN. Per sapere quali sono le voci in questione eseguite il seguente comando:

    ls -l /dev/mpath | grep <stale LUN>

    Per esempio se <stale LUN> è 3600d0230003414f30000203a7bc41a00, potrebbero apparire i seguenti risultati:

    lrwxrwxrwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
    lrwxrwx--rwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
                                    

    Ciò significa che 3600d0230003414f30000203a7bc41a00 è 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
                                    
  • In una configurazione due-sistemi HA-RAID, due adattatori SAS vengono collegati su due sistemi e connessi ad un SAS disk drawer condiviso. L'impostazione dell'attributo Preferred Dual Adapter State su Primary su entrambi gli adattatori SAS, potrebbe generare una condizione di corse critiche ed un failover infinito tra i due adattatori SAS. Per questo motivo è possibile impostare solo un adattatore SAS su Primary.

    Per evitare questo tipo di errore assicuratevi che l'attributo Preferred Dual Adapter State di un adattatore SAS sia stato impostato su None, se il secondo adattatore SAS deve essere impostato su Primary.

  • Se avete bisogno di utilizzare il modulo del kernel hp_sw, installate il pacchetto device-mapper-multipath aggiornato.

    È necessario anche configurare correttamente l'array HP per utilizzare correttamente la modalità attiva/passiva e riconoscere i collegamenti provenienti da macchine Linux. Per fare questo eseguite le fasi di seguito riportate:

    1. Determinate il world wide port name (WWPN) di ogni collegamento utilizzando show connections. Di seguito viene riportato un esempio di output per show connections su di un array HP MSA1000 con due collegamenti:

      Connection Name: <Unknown>
      Host WWNN = 200100E0-8B3C0A65
      Host WWPN = 210100E0-8B3C0A65
      Profile Name = Default
      Unit Offset = 0
      Controller 2 Port 1 Status = Online
      
      Connection Name: <Unknown>
      Host WWNN = 200000E0-8B1C0A65
      Host WWPN = 210000E0-8B1C0A65
      Profile Name = Default
      Unit Offset = 0
      Controller 1 Port 1 Status = Online
                                                      
    2. Configurare correttamente ogni collegamento utilizzando il seguente comando:

      add connection [connection name] WWPN=[WWPN ID] profile=Linux OFFSET=[unit offset]

      Da notare che [connection name] può essere impostato in modo arbitrario.

      Utilizzando l'esempio fornito, il comando corretto dovrebbe essere:

      add connection foo-p2 WWPN=210000E0-8B1C0A65 profile=Linux OFFSET=0

      add connection foo-p1 WWPN=210100E0-8B3C0A65 profile=Linux OFFSET=0

    3. Eseguite ancora una volta show connections per verificare che ogni collegamento sia stato configurato. In base all'esempio fornito la configurazione corretta dovrebbe essere:

      Connection Name: foo-p2
      Host WWNN = 200000E0-8B1C0A65
      Host WWPN = 210000E0-8B1C0A65
      Profile Name = Linux
      Unit Offset = 0
      Controller 1 Port 1 Status = Online
      
      Connection Name: foo-p1
      Host WWNN = 200100E0-8B3C0A65
      Host WWPN = 210100E0-8B3C0A65
      Profile Name = Linux
      Unit Offset = 0
      Controller 2 Port 1 Status = Online
                                                      
  • Red Hat sconsiglia l'utilizzo dei quota sui file system EXT3. Questo perchè in alcuni casi si potrebbe generare un deadlock.

    Alcune prove hanno rivelato che kjournald potrebbe bloccare alcune chiamate specifiche a EXT3 usate quando il quota è in esecuzione. Per questo motivo Red Hat non intende correggere questo problema in Red Hat Enterprise Linux 4, poichè le modifiche potrebbero essere troppo invasive.

    Da notare che questo problema non è presente in Red Hat Enterprise Linux 5.

  • Prove hardware per Mellanox MT25204 hanno rivelato la presenza di un errore interno sotto alcune condizioni di carico elevato. Quando il driver ib_mthca riporta un errore catastrofico su questo hardware, esso è generalmente dovuto ad una lunghezza insufficiente della coda di attesa, relativo al numero delle richieste di lavoro sospese generate dall'applicazione utente.

    Anche se il driver resetterà l'hardware e ripristinerà le normali funzioni dopo tale evento, tutti i collegamenti esistenti al momento dell'errore verranno perduti. Tale comportamento genera normalmente un errore di segmentazione all'interno dell'applicazione utente. Ed ancora, se opensm è in esecuzione al momento dell'errore, allora sarà necessario riavviarlo manualmente per ripristinare le normali funzioni.

  • L'icona di collegamento del Desktop Sharing visualizza il proprio menu se eseguite un doppio clic sull'icona stessa, e non facendo un clic con il pulsante destro. Al contrario tutte le altre icone mostrano i propri menu quando eseguite il clic con il tasto destro.

  • Se il driver InfiniBand ib_ehca viene caricato in modalità port auto-detection (utilizzando il parametro del modulo nr_ports=-1), le interfacce di rete IP-over-InfiniBand (ibX) potrebbero risultare disponibili troppo tardi. In tal caso il comando ifup ibX emesso dallo script di startup openibd fallirà; di conseguenza l'interfaccia ibX non diventerà disponibile.

    In tal caso utilizzare il comando rcnetwork restart per correggere questo problema.

  • Nel manuale IBM Redbook "Implementazione di InfiniBand in IBM System p (SG247351), la tabella 6-3 (sulla pagina 220 della versione in formato PDF) descrive le definizioni del bit del codice di debug insieme ad un numero di bit degli indicatori d'errore HCA.

    Da notare che con gli adattatori eHCA2, bit 46 e 47 di questi indicatori d'errore possono ritornare dei falsi positivi.

  • Sulle workstation HP ICH10, l'audio viene abilitato solo attraverso jack da 3.5mm frontali. Per questo motivo per ricevere qualsiasi input audio o utilizzare la registrazione, sarà necessario inserire le vostre cuffie, casse o microfoni usando jack frontali. Al momento i jack posteriori, le casse interne ed il volume master per questa workstation non funzionano.

  • Con questo aggiornamento il rilevamento del PCI predefinito e l'ordine per i seguenti modelli sono stati modificati:

    • HP Proliant DL 580 G5

    • HP Proliant DL 385 G2

    • HP Proliant DL 585 G2

    Questi modelli utilizzano una modalità di enumerazione e di scansione del dispositivo non predefinite per Red Hat Enterprise Linux 4 o 5. La modalità usata da questi modelli HP Proliant può comportare una rilevazione e l'aggiunta di schede supplementari prima dei dispositivi onboard/interni. Il suddetto ordine potrebbe causare alcuni problemi durante l'installazione di nuove istanze di Red Hat Enterprise Linux, durante l'aggiunta di nuovo hardware e durante il processo di gestione.

    La numerazione dei network interface card (NIC) per i suddetti modelli HP Proliant potrebbe cambiare dopo un aggiornamento del kernel Red Hat Enterprise Linux 4.7. Il programma d'installazione modifica la numerazione dei NIC se il parametro HWADDR=MAC ADDRESS non è stato definito in /etc/sysconfig/network-scripts/ifcfg-eth[X] per ogni NIC installato. Per questo motivo Red Hat consiglia la definizione di questo parametro per evitare qualsiasi problema duvoto ad una enumerazione NIC non prevista.

    Per evitare qualsiasi modifica della enumerazione NIC dopo aver aggiornato questi modelli HP Proliant a Red Hat Enterprise Linux 4.7, aggiungere il parametro d'avvio del kernel pci=nobfsort su /boot/grub/grub.conf.

  • Quando un gruppo di volumi contiene un mirror o una snapshot, l'emissione del comando lvchange con un parametro del gruppo di volumi potrebbe risultare nei seguenti messaggi d'errore:

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

    Questi messaggi possono essere ignorati.

  • I sistemi Dell PowerEdge SC1435s possono entrare in una fase di sospensione durante il processo d'avvio. Per avitare questo comportamento modificate la riga terminal in grub.conf e sostituite la stringa serial console con console serial.

  • Il driver aggiornato ixgbe non supporta Intel 82598AT (Copper Pond 10GbE).

  • Red Hat Enterprise Linux 5.3 è in grado di rilevare l'aumento o la diminuzione online di un dispositivo a blocchi sottostante. Tuttavia, non è disponibile alcun metodo per rilevare automaticamente la variazione di dimensione di un dispositivo, per questo motivo è necessario seguire manualmente alcune fasi per riconoscere questo cambiamento e modificare la dimensione di qualsiasi file system che risiede sul dispositivo dato. Quando un dispositivo a blocchi è stato modificato e viene rilevato, apparirà un messaggio simile al seguente sui log del sistema:

    VFS: busy inodes on changed media or resized disk sdi
                                    

    Se la dimensione dei dispositivo a blocchi è aumentata allora è possibile ignorare questo messaggio. Tuttavia se la dimensione del dispositivo a blocchi è diminuita senza diminuire i dati impostati sul dispositivo a blocchi, i dati che risiedono sul dispositivo stesso potrebbero essere corrotti.

    È possibile solo eseguire una modifica della dimensione online di un filesystem creato sull'intero LUN (o dispositivo a blocchi). Se è presente una tabella delle partizioni sul dispositivo a blocchi, allora il file system devrà essere rimontato per aggiornare la tabella stessa.

  • È presente una pardita di memoria con la famiglia res_n* dei resolver routine (es res_nquery, res_nsearch e res_nmkquery). I programmi che utilizzano queste funzioni avranno una perdita di memoria col passare del tempo. Questa tendenza è stata corretta con le versioni più recenti di glibc, tuttavia la correzione è troppo invasiva per essere applicata su Red Hat Enterprise Linux 4. I programmi che utilizzano queste funzioni potrebbero aver bisogno di un riavvio occasionale per rendere disponibile un pò di memoria.

  • Il numero dei dispositivi gestibili durante l'installazione di Red Hat Enterprise Linux 4 dipende dalla dimensione dell'immagine d'installazione di initrd. Per questo motivo in situazioni dove sono presenti numerosi dispositivi collegati ad una macchina (come ad esempio per impostazioni di Fibre Channel molto popolati), non sarà possibile eseguire alcuna installazione se non viene ridotto il numero di dispositivi visibili.

  • L'aggiornamento del driver aacraid introdotto con Red Hat Enterprise Linux 4.7 necessita di un Adaptec PERC3/Di aggiornato. Aggiornamenti successivi di Red Hat Enterprise Linux 4 (incluso l'aggiornamento al 4.8), necessitano di una versione del firmware PERC3/Di di 2.8.1.7692, A13 o più recente. Per ottenere il firmware necessario utilizzate quanto di seguito riportato:

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

  • Durante l'installazione anaconda potrebbe non rimuovere tutti i metadati Logical Volume Manager (LVM) presenti sul sistema precedenti all'installazione stessa. I suddetti metadati potrebbero causare il riporto di gruppi di volumi o volumi logici mancanti da parte dei tool LVM dopo l'installazione. Per risolvere questo problema rimuovete i metadati LVM vecchi dopo l'installazione.

  • multipath non elimina i messaggi d'errore mostrati da qualsiasi programma di chiamata. Per questo motivo se multipath viene eseguito quando i percorsi non sono attivi sarà possibile visualizzare diversi messaggi d'errore. I messaggi visualizzati dipendono dai programmi di chiamata specifici utilizzati da multipath. Per esempio, se multipath viene eseguito durante la presenza di dispositivi scsi falliti, scsi_id mostrerà

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

    Oppure, se multipath -ll viene eseguito mentre un EMC CLARiiON risulta non attivo, la chiamata mpath_prio_emc priority mostrerà query command indicates error

( amd64 )