Note di Rilascio per &debian; &release; ("&releasename;"), &arch-title;

%dynamicdata; %shareddata; ]> Note di Rilascio per &debian; &release; ("&releasename;"), &arch-title; Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (attuale), Andreas Barth (attuale), Javier Fernández-Sanguino Peña (attuale), Steve Langasek (attuale) debian-doc@lists.debian.org Luca Brivio (traduzione italiana)lucab83@infinito.it &docid; Introduzione

I principali scopi di queste Note di Rilascio sono quelli di informare gli utenti dei principali cambiamenti introdotti in questo rilascio della distribuzione &debian;, di fornire informazioni su come aggiornare in sicurezza dal rilascio precedente a quello attuale ed infine di informare gli utenti delle potenziali problematiche note che essi potrebbero incontrare aggiornando al rilascio &releasename; o utilizzandolo.

Si noti che è impossibile elencare ogni problematica nota e che perciò è stata fatta una selezione basata su una combinazione di prevalenza attesa e impatto delle problematiche.

La versione più recente di questo documento è sempre disponibile presso . Se la versione che si sta leggendo data a più di un mese fa Come segnato sul frontespizio della versione PDF e nel pie' di pagina della versione HTML., si potrebbe voler ottenere l'ultima versione.

Si noti che supportiamo e documentiamo l'aggiornamento solamente a partire dal precedente rilascio di Debian (in questo caso, l'aggiornamento da &oldreleasename;). Se si necessita di eseguire aggiornamenti da rilasci anteriori, suggeriamo di leggere le precedenti versioni delle note di rilascio e di aggiornare prima a &oldreleasename;.

Segnalare errori per questo documento

Abbiamo provato tutti i diversi passaggi per l'aggiornamento e abbiamo anche cercato di anticipare tutte le possibili problematiche che i nostri utenti potrebbero incontrare.

Cionondimeno, se si pensa di aver trovato un errore in questa documentazione (informazioni imprecise o mancanti), si invii una segnalazione al riguardo il pacchetto release-notes.

Fornire resoconti di aggiornamenti

Gradiamo informazioni dagli utenti riguardanti aggiornamenti da &oldreleasename; a &releasename;. Se si desidera mettere in comune delle informazioni si compili una segnalazione nel riguardo il pacchetto upgrade-reports con i propri commenti. Richiediamo che eventuali allegati siano compressi (con

La segnalazione dell'errore dovrebbe comprendere le seguenti informazioni:

Lo stato del database dei pacchetti prima e dopo l'aggiornamento: database dello stato di /var/lib/dpkg/status e informazioni sullo stato dei pacchetti di /var/lib/aptitude/pkgstates. Si dovrebbe aver fatto un backup prima dell'aggiornamento, come descritto in , ma si può anche trovare un backup di tali informazioni in /var/backups.

I log delle sessioni ottenuti con .

I log di /var/log/aptitude.

Nota: ci si dovrebbe prendere il tempo necessario per rimuovere ogni informazione sensibile e/o confidenziale dai log prima di includerli nella segnalaione, dal momento che le informazioni saranno disponibili in un database pubblico.

Sorgenti per questo documento

Questo documento è generato con debiandocsgml. I sorgenti per le Note di Rilascio sono disponibili nel repository CVS del Debian Documentation Project (Progetto per la Documentazione di Debian). Si può utilizzare l' per accedere a ciascuno dei loro file tramite il web e vedere le loro modifiche. Per maggiori informazioni su come accedere al CVS si consultino le .

Che cosa c'è di nuovo in &debian; &release;

Il presente rilascio aggiunge il supporto ufficiale per l'architettura AMD64, che supporta i processori a 64 bit sia di Intel (EM64T), sia di AMD (AMD64). Durante il precedente rilascio, &debian 3.1 ("sarge"), era disponibile una versione non ufficiale di questo port.

Il supporto ufficiale per l'architettura Motorola 680x0 ("m68k") è stato cessato poiché non soddisfaceva i criteri stabiliti dai Release Manager di Debian. Le più importanti ragioni alla base di ciò sono le prestazioni ed il limitato supporto a monte per componenti essenziali della toolchain. Cionondimeno, ci si aspetta che il port m68k rimanga attivo e disponibile per l'installazione anche se non come parte di questo rilascio stabile ufficiale.

Sono di seguito elencate le architetture ufficialmente supportate da &debian; &releasename;:

Intel x86 ("i386")

Alpha ("alpha")

SPARC ("sparc")

PowerPC ("powerpc")

ARM ("arm")

MIPS ("mips" (big-endian) e "mipsel" (little-endian))

Intel Itanium ("ia64")

HP PA-RISC ("hppa")

S/390 ("s390")

AMD64 ("amd64")

Si può leggere di più circa lo stato dei port e reperire informazioni specifiche sul port per la propria architettura presso le .

Questo è soltanto il secondo rilascio ufficiale di &debian; per l'architettura &arch-title;. Riteniamo che abbia raggiunto uno stato di collaudo sufficiente per la distribuzione. Tuttavia, dal momento che non è stato in circolazione quanto i rilasci precedenti su altre architetture (e non è quindi stata altrettanto testata dagli utenti), si potrebbe incontrare qualche bug. Si prega di usare il nostro per segnalare qualunque problema; ci si assicuri di menzionare il fatto che il bug è riscontrato sulla piattaforma &architecture;.

]]> Che cosa c'è di nuovo per &arch-title;?

Il supporto per RiscPC (RPC) è incompleto e sarà rimosso dopo etch. Mentre in etch è comunque fornito un kernel per RiscPC, l'installatore non supporta tale sistema.

È stato aggiunto il supporto per la piattaforma di Intel IXP4xx. L'installatore comprende il supporto per il Linksys NSLU2, un dispositivo piccolo ed economico che consente l'utilizzo di dispositivi di archiviazione tramite USB. Sono disponibili maggiori informazioni riguardo Debian sul NSLU2 presso .

È stato anche aggiunto il supporto per la piattaforma di Intel I/O Processor (IOP). Nello specifico, &debian; &release; supporta dispositivi basati su IOP 32x. Nell'installatore sono supportati due dispositivi di archiviazione di rete (NAS) basati su un chip IOP: il GLAN Tank di IO-Data e il Thecus N2100. Si veda .

]]> Che cosa c'è di nuovo per &arch-title;? Il supporto per DECstation è incompleto e non testato in etch e sarà rimosso completamente dopo questo rilascio. Questo comprende sia entrambe le varianti di DECstation precedentemente supportate in Debian, r3k-kn02 e r4k-kn04.

Sono ora possibili installazioni su macchine Cobalt basate su MIPS (Qube 2700, RaQ2) senza l'utilizzo di una console seriale. Di base, le installazioni su Cobalt sono ora fatte via SSH. Si veda per maggiori informazioni .

]]> È stato aggiunto il supporto per la piattaforma di SGI IP32. La piattaforma IP32 consiste di macchine SGI O2 con processori R5000, R5200 o RM7000. L'installazione è possibile tramite il framebuffer o la console seriale.

]]>

È stato aggiunto sia al kernel sia all'installatore il supporto per la scheda di sviluppo per SB1A di Broadcom BCM91480B ("BigSur"), che è basata sul chip quad-core BCM1480. Tale scheda è supportata sia in modalità sia little endian, sia big endian.

È stato aggiunto il supporto per una macchina Qemu. La macchina Qemu/MIPS emula una classica macchina ISA ISA PC style con una CPU MIPS 4Kx.

]]> Che cosa c'è di nuovo per &arch-title;?

Questo rilascio aggiunge il supporto per architettura PowerPC a 64 bit (IBM pSeries, Apple G5 Powermacs). È stato tolto il supporto per la sottoarchitettura Apple Apus; anche la sottoarchitettura Apple Nubus non è supportata.

Le tastiere di iBook e Powerbook su &arch-title; sono ora pienamente supportate (in X) e (contrariamente a quanto accadeva in &oldreleasename;) non sono più necessarie xmodmap personalizzate.

]]> Che cosa c'è di nuovo nella distribuzione?

Questo nuovo rilascio di Debian esce ancora una volta con molto software in più che la precedente &oldreleasename;: la distribuzione comprende oltre &packages-new; nuovi pacchetti, per un totale di oltre &packages-total; pacchetti. Per la maggior parte il software nella distribuzione è stato aggiornato: oltre &packages-updated; pacchetti software (che costituiscono il &packages-update-percent;% di tutti i pacchetti in &oldreleasename;). È anche stato rimosso per varie ragioni dalla distribuzione un numero significativo di pacchetti (oltre &packages-removed;, il &packages-removed-percent;% dei pacchetti in &oldreleasename;). Non si vedranno aggiornamenti per tali pacchetti ed essi saranno marcati come 'obsoleti' nelle interfacce per la gestione dei pacchetti.

Con questo rilascio, &debian; passa da XFree86 al rilascio 7.1 di X.Org, che comprende il supporto per un più vasto spettro di hardware e un migliore rilevamento automatico. Questo consente l'utilizzo di Compiz, che è uno dei primi gestori di finestre per X con funzioni di compositing, e si avvantaggia pienamente dall'accelerazione hardware OpenGL per i dispositivi supportati.

&debian; fornisce ancora un cospicuo numero di applicazioni ed ambienti per desktop. Tra gli altri include ora gli ambienti desktop GNOME 2.14Con alcuni moduli di GNOME 2.16., KDE 3.5.5a ed Xfce 4.4. Sono state aggiornate anche le applicazioni per la produttività, comprese le suite per ufficio OpenOffice.org 2.0.4a e KOffice 1.6 nonché GNUcash 2.0.5, GNUmeric 1.6.3 ed Abiword 2.4.6.

Gli aggiornamenti alle altre applicazioni per desktop comprendono l'aggiornamento a Evolution 2.6.3 e Gaim 2.0. È stata aggiornata anche la suite Mozilla, con nuovi nomi per i principali programmi: iceweasel (versione 2.0.0.2) è il browser web Firefox senza il marchio originale e

Fra molti altri aggiornamenti, questo rilascio comprende anche quelli dei seguenti software:

la libreria C GNU, versione 2.3.6 la GNU Compiler Collection (libreria di compilatori GNU) 4.1 come compilatore di default interpreti di linguaggi: Python 2.4, PHP 5.2 software per server:

server di posta elettronica: Exim 4.63 (server di posta elettronica di default per nuove installazioni), Postfix 2.3, Courier 0.53, Cyrus 2.2 server web: Apache 2.2, fnord 1.10. server per database: MySQL 5.0.32, PostgreSQL 8.1. il server OpenSSH, versione 4.3. server per nomi di dominio: Bind 9.3, maradns 1.2. server per directory: OpenLDAP 2.3.

La distribuzione ufficiale &debian; viene ora distribuita in 19-23 CD di binari (a seconda dell'architettura) e un numero simile di CD di sorgenti. È anche disponibile una versione della distribuzione su DVD.

Gestione dei pacchetti

Per &releasename; è stato implementato in

In &releasename; è ora disponibile debian-archive-keyring.

Nella sua configurazione di base,
Per maggiori informazioni si legga , il capitolo del .

Un'altra caratteristica che è stata aggiunta in .
debian-volatile ora servizio ufficiale
Il servizio
Questo significa che esso utilizza ora un indirizzo Il vecchio indirizzo . Ci si accerti di aggiornare corrispettivamente il proprio file /etc/apt/sources.list se si sta già utilizzando questo servizio.
dell'archivio.Miglioramenti del sistema Vi è un numero di cambiamenti nella distribuzione di cui beneficeranno nuove installazioni di &releasename;, ma che potrebbero non applicarsi automaticamente ad aggiornamenti da &oldreleasename;. Questa sezione dà un sommario dei cambiamenti più rilevanti. Priorità abbassata per pacchetti di base per lo sviluppo Parecchi pacchetti per lo sviluppo che avevano in precedenza priorità gcc, così come qualche altro software (dpkg-dev, flex, o make) e gli header per lo sviluppo (libc6-dev, linux-kernel-headers). Se si desidera avere tali pacchetti sul proprio sistema, il modo migliore di installarli è tramite l'installazione di SELinux con priorità standard, ma non abilitato di default I pacchetti necessari per il supporto a SELinux sono stati promossi a priorità # aptitude install selinux-basics Si noti che il supporto a SELinux . Nuovo superdemone di inet predefinito Il superdemone di inet predefinito per &releasename; è openbsd-inetd anziché netkit-inetd. Esso non sarà avviato se non vi saranno servizi configurati, il che è di default vero. Il nuovo demone predefinito sarà installato automaticamente con l'aggiornamento. Cambio del clone di Il clone di Cambio nelle caratteristiche predefinite per ext2/ext3 I nuovi filesystem ext2 e ext3 saranno creati con le caratteristiche Utenti che aggiornino da &oldreleasename; potrebbero prendere in considerazione l'aggiunta manuale del parametro Il flag ; il parametro La codifica predefinita per &releasename; è UTF-8 La codifica predefinita per nuove installazioni di &debian; è UTF-8. Anche parecchie applicazioni saranno impostate per l'utilizzo di UTF-8 per default. Utenti che con l'aggiornamento a &releasename; desiderino passare a UTF-8 necessiteranno di riconfigurare il loro ambiente e le definizioni delle locale. Il default di sistema può essere cambiato con Il pacchetto Si noti che alcune applicazioni potrebbero non funzionare ancora correttamente in un ambiente UTF-8, soprattutto a causa di problemi di visualizzazione. Il contiene delle informazioni aggiuntive sui cambiamenti tra &oldreleasename; e &releasename;. Importanti cambiamenti concernenti il kernel &debian; &release; è distribuita con la versione del kernel &kernelversion; per tutte le architetture; questo rilascio è comunque per lo più Alcuni singoli pacchetti potrebbero non funzionare più correttamente con un kernel 2.4: si veda . ]]> compatibile con kernel 2.4, ma Debian non fornisce ne supporta più pacchetti del kernel 2.4. Vi sono stati importanti cambiamenti sia nel kernel stesso, sia nella pacchettizzazione del kernel per Debian. Alcuni di questi cambiamenti complicano la procedura di aggiornamento e possono potenzialmente causare problemi durante il riavvio del sistema dopo l'aggiornamento a &releasename;. Questa sezione fornisce un sommario dei cambiamenti più importanti; potenziali problematiche ed informazioni su come aggirarle sono contenute in capitoli successivi. Se si sta attualmente facendo girare un kernel 2.4, si dovrebbe leggere attentamente . ]]> Cambiamenti nella pacchettizzazione del kernel Pacchetti del kernel rinominati Tutti i pacchetti del kernel Linux sono stati rinominati da Flavor "386" sostituito con "486" Essendo stato eliminato con &oldreleasename; il supporto per processori 80386, anche il flavor 386 del kernel è stato eliminato e sostituito da un nuovo flavor 486. ]]> Singolo kernel generico per &arch-title; In &oldreleasename; vi erano flavor di kernel separati per differenti famiglie di processori di questa architettura. A causa dei cambiamenti nel kernel che ottimizzeranno automaticamente il kernel per il processore (o i processori) nel sistema, non c'è più alcuna reale necessità di separare i flavor del kernel. ]]> I kernel standard hanno capacità SMP I sistemi multiprocessore non necessitano più di un flavor ]]> flavor r5k-ip22 del kernel eliminato L'immagine del kernel per macchine IP22 con una CPU R5000 è stata eliminata poiché l'immagine r4k-ip22 supporta ora macchine IP22 con una CPU R4x000 o R5000. ]]> Dove possibile, sono stati forniti per i pacchetti eliminati pacchetti vuoti di transizione che dipendono dai nuovi pacchetti. Nuove utility per la generazione di initrd L'immagine del kernel di Debian per &arch-title; non necessita di un initrd per l'avvio del sistema. Ciò significa che le informazioni in questa sezione potrebbero non avere rilevanza per il lettore, ma sono comunque incluse per completezza. ]]> A causa di cambiamenti nel kernel, l'utility utilizzata per generare initrd in &oldreleasename;, . Entrambe genereranno un initrd utilizzando il filesystem L'aggiornamento a un kernel di &releasename; causerà automaticamente l'installazione di Se si sta passando da un kernel 2.4 a un kernel Debian 2.6, si deve usare Il pacchetto ]]> Gestione dinamica di /dev e rilevamento dell'hardware &releasename; non fornisce più il supporto per devfs. /dev e popolerà tale directory con i dispositivi supportati dal kernel. Esso inoltre aggiungerà e rimuoverà dinamicamente i dispositivi rispettivamente al caricamento e de-caricamento dei moduli, in base ad eventi generati dal kernel. In combinazione con il kernel, Se si installa un'immagine del kernel di Debian, Si può evitare l'installazione di ]]> Sistema di installazione L'Installatore Debian è il sistema ufficiale di installazione per Debian. Esso offre una varietà di metodi di installazione. Quali metodi sono disponibili per l'installazione del sistema dipende dall'architettura. Si possono trovare immagini dell'installatore per &releasename; insieme alla Guida all'installazione sul . La Guida all'Installazione è anche compresa nel primo CD/DVD dei set ufficiali di CD/DVD di Debian, con percorso: /doc/install/manual/lingua/index.html Si potrebbe anche voler verificare le per debian-installer per un elenco di problematiche note. L'installatore può essere usato soltanto per installare sistemi alpha che supportano la console SRM. Ci si assicuri di far passare il proprio sistema a SRM prima di dare inizio all'installazione. Se la macchina supporta soltanto la console AlphaBIOS/ARC, il modo consigliato per l'installazione di &releasename; è installare innanzitutto un sistema woody (minimale), aggiornare quindi a &oldreleasename; ed infine a &releasename; Per maggiori informazioni riguardo le differenti console si leggano i riferimenti sulle . ]]> Problematiche con il framebuffer su &arch-title; A causa dei problemi di visualizzazione su alcuni sistemi, il supporto al framebuffer è disabilitato per default per &arch-title; per la maggior parte delle schede grafiche. Ciò può avere per effetto una brutta visualizzazione su sistemi che pure supportano propriamente il framebuffer. Se si notano problemi di visualizzazione nell'installatore, si può cercare di avviare l'installatore con il parametro framebuffer=true. Ci si faccia sapere se il framebuffer funziona su hardware su cui per default non è utilizzato. Problematiche con l'avvio su &arch-title; Numerosi utenti hanno riferito che il CD di installazione fallisce il corretto avvio con il comando PROM 'boot cdrom', visualizzando l'errore 'Illegal Instruction'. L'apparente spiegazione per questo problema è che il mancato funzionamento dipende dal fatto che la macchina è stata precedentemente riavviata da Solaris. Il trucco è togliere completamente l'alimentazione, e quindi avviare direttamente con il CD di installazione. Il problema è stato riferito da utenti di vari sistemi (in particolare, Enterprise 450, Blade 2000, Fire V420, Enterprise 250, Blade 100 e Enterprise 220R, al momento in cui scriviamo), per cui si crede sia generico. Ci si faccia sapere se si osservano problematiche simili con il proprio hardware. Problemi con l'avvio da qla2xxx su &arch-title; Diversi utenti hanno riferito che il sistema di installazione non riesce a riconoscere dischi fissi su macchine che hanno i dischi connessi a un controller SCSI fibre-channel QLogic. Sono interessati i server Sun Fire 280R. Il driver qla2xxx si carica, ma non riesce a caricare il firmware, il che lo rende inutile. La spiegazione di questo problema è che il firmware del controller QLogic non è libero, e deve essere spostato in un pacchetto separato non-free () che non è utilizzato dal sistema di installazione. Non v'è alcuna soluzione semplice e lineare, sfortunatamente; bisogna prima fornire l'immagine del firmware al sistema di installazione, e quindi in seguito fare lo stesso nel sistema installato. Per ottenere il caricamento del firmware da parte del server, bisogna avere connettività di rete mentre la macchina viene installata per poter scaricare il pacchetto udeb firmware-qlogic con wget, installarlo con udpkg, e quindi ricaricare il modulo qla2xxx. Dopo il completamento dell'installazione, si monterà la nuova partizione, vi si eseguirà chroot, si scaricherà il pacchetto deb firmware-qlogic, lo si installerà con dpkg, e quindi si eseguirà update-initramfs per includerlo nell'immagine del ramdisk iniziale utilizzata dal kernel. In alternativa, si installi da un altro CD di installazione (in cui sia stato comunque integrato quel firmware non-free) e quindi si aggiorni. Dimensione del disco fisso non rilevata correttamente Se un disco fisso è stato utilizzato in precedenza sotto Solaris, il partizionatore potrebbe non rilevare correttamente la dimensione del drive. La creazione di una nuova partizione non risolve questa problematica. Ciò che serve è rendere "zero" i primi settori del drive: # dd if=/dev/zero of=/dev/hdX bs=512 count=2; sync Si noti che ciò rendera inaccessibili eventuali dati presenti su quel disco. ]]> Che cosa c'è di nuovo nel sistema di installazione? C'è stato un notevole sviluppo sull'Installatore Debian dal suo primo rilascio ufficiale con &oldreleasename;, sviluppo che ha per risultato un migliorato supporto all'hardware ed alcune nuove interessanti funzionalità. In queste Note di Rilascio elencheremo soltanto i principali cambiamenti nell'installatore. Se si è interessati ad una panoramica dei cambiamenti nel dettaglio a partire da &oldreleasename;, si controllino gli annunci di rilascio per i rilasci beta e RC di &releasename; disponibili nella dell'Installatore di Debian. Principali cambiamenti Nessun riavvio durante l'installazione In precedenza, l'installazione era divisa in due parti: configurare il sistema di base e renderlo avviabile, quindi un riavvio, e dopo di questo l'esecuzione di Per &releasename;, il secondo passaggio è stato integrato nello stesso Installatore Debian. Ciò comporta diversi benefici, compresi un'accresciuta sicurezza ed il fatto che dopo il riavvio alla fine dell'installazione il sistema dovrebbe già avere il corretto fuso orario e, se si è installato l'ambiente Desktop, avvierà in un'unica volta l'interfaccia utente grafica. Codifica UTF-8 predefinita per nuovi sistemi L'installatore imposterà i sistemi per l'utilizzo della codifica UTF-8 piuttosto che delle vecchie codifiche legate alla lingua (come ISO 8859-1, EUC-JP o KOI-8). Partizionamento più flessibile È ora possibile definire filesystem su un volume LVM utilizzando il partizionamento guidato. L'installatore può anche definire filesystem criptati. Utilizzando il partizionamento manuale si avrà la scelta fra /boot) come volumi logici. Interfaccia utente grafica Se si preferisce un'interfaccia utente grafica, si provi ad avviare l'installatore con il parametro ]]> Per &arch-title; è disponibile su base sperimentale un'immagine per l'installazione separata che utilizza un'interfaccia utente grafica. È nota funzionare sulla maggior parte dei sistemi CHRP che hanno una scheda grafica ATI, ma è stata testata in modo insufficiente su &arch-title; perché la si includesse sul normale CD di installazione. Se si volesse provare l'installatore grafico, si cerchi l'immagine "gtk-miniiso". ]]> La funzionalità dell'installatore grafico è quasi identica a quella dell'installatore tradizionale, differisce soltanto la presentazione. Vi è un'eccezione: il frontend grafico non supporta la creazione di partizioni criptate che utilizzino chiavi casuali. Il vantaggio importante dell'interfaccia utente grafica è che essa supporta più lingue che l'interfaccia utente normale ("newt"). Informazioni intorno all'installatore grafico sono disponibili in un'appendice della Guida all'installazione. Nota: l'interfaccia utente grafica non è disponibile per tutte le architetture. ]]> Modalità di ripristino Si può utilizzare l'installatore per risolvere problemi con il proprio sistema, per esempio quando non si avvia. I primi passaggi saranno esattamente come per un'installazione normale, ma l'installatore non avvierà lo strumento di partizionamento. Offrirà invece all'utente un menù di opzioni di ripristino. Si attivi la modalità di ripristino facendo avviare l'installatore con il parametro rescue/enable=true. Utilizzo di sudo al posto dell'account di root Durante l'installazione per esperti è possibile scegliere di non stabilire un account di root (esso sarà bloccato), ma invece impostare Verifica crittografica dei pacchetti scaricati I pacchetti scaricati con l'installatore sono ora verificati crittograficamente con l'utilizzo di Configurazione semplificata per la posta elettronica Se è installato il "sistema standard", l'installatore stabilisce una configurazione di base per il server di posta elettronica del sistema che fornirà soltanto la consegna locale. Il server di posta elettronica non sarà disponibile per altri sistemi connessi alla medesima rete. Se si vuole configurare il proprio sistema perché gestisca posta elettronica non locale rispetto al sistema (invii posta o la riceva), si deve riconfigurare il sistema di posta elettronica dopo l'installazione. Selezione del desktop Il sistema di installazione installerà un desktop GNOME come desktop di default qualora l'utente ne domandi uno. Tuttavia, gli utenti che desiderino installare ambienti desktop alternativi lo possono fare facilmente aggiungendo i parametri di avvio: tasks="standard, kde-desktop" per KDE e tasks="standard, xfce-desktop" per Xfce. Si noti che ciò non funzionerà allorché si installerà da un'immagine CD completa senza utilizzare un mirror di rete come fonte di pacchetti aggiuntiva; funzionerà con l'utilizzo di un'immagine DVD o con ogni altro metodo di installazione. Sono disponibili anche immagini CD separate che installano per default l'ambiente desktop KDE o Xfce. Nuove lingue Grazie agli enormi sforzi dei traduttori, Debian può ora essere installata in 47 lingue diverse. Sono sei lingue in più di quelle in &oldreleasename;. Le lingue aggiunte comprendono il Bielorusso, l'Esperanto, l'Estone, il Kurdo, il Macedone, il Tagalog, il Vietnamita e il Wolof. A causa della mancanza di aggiornamenti alle traduzioni, in questo rilascio sono state eliminate due lingue: il Persiano e il Gallese. Se si utilizza l'interfaccia grafica, sono supportate undici ulteriori lingue. Tali lingue possono essere selezionate soltanto se si utilizza con tale interfaccia, poiché le loro codifiche dei caratteri non possono essere visualizzate in un ambiente non grafico. Le nuove lingue sono: Bengalese, Dzongkha, Gujarati, Hindi, Georgiano, Khmer, Malayalam, Nepalese, Punjabi, Tamil e Thailandese. ]]> Gli utenti che non desiderino utilizzare alcuna locale possono ora selezionare . Localizzazione e selezione del fuso orario semplificate La configurazione della lingua, dei Paesi e del fuso orario è stata semplificata al fine di ridurre la quantità di informazioni necessarie all'utente. L'installatore supporrà ora quali siano il Paese ed il fuso orario del sistema in base alla lingua selezionata, o se impossibilitato fornirà una selezione limitata. Gli utenti possono comunque introdurre qualsiasi combinazione se necessario. Localizzazione a livello di sistema migliorata Per la maggior parte, i compiti di internazionalizzazione e localizzazione che erano in precedenza gestiti dallo strumento localization-config sono ora inclusi nell'installatore di Debian di base o nei pacchetti medesimi. Ciò significa che la selezione di una lingua comporterà l'installazione automatica dei pacchetti necessari per quella lingua (dizionari, documentazione, font...) sia in ambienti standard, sia in ambienti desktop. La configurazione che non è più gestita automaticamente comprende la configurazione del formato della carta ed alcune impostazioni avanzate per la tastiera in Xorg per alcune lingue. Si noti che pacchetti specifici per la lingua saranno installati automaticamente soltanto se saranno disponibili durante l'installazione. ]]> Installazione automatizzata Parecchi dei cambiamenti menzionati nella sezione precedente implicano anche cambiamenti nel supporto dell'installatore per l'installazione automatizzata mediante l'utilizzo di file di preconfigurazione. Ciò significa che se si hanno file di preconfigurazione che funzionavano con l'installatore di &oldreleasename; non ci si può aspettare che funzionino con il nuovo installatore senza alcuna modifica. La buona notizia è che la ha ora un'appendice separata con un'estesa documentazione sull'utilizzo della preconfigurazione. L'installatore di &releasename; introduce alcune nuove interessanti caratteristiche che consentono un'ulteriore e più semplice automazione delle installazioni. Esso aggiunge anche il supporto per il partizionamento avanzato con l'utilizzo di RAID, LVM e LVM criptato. Per i dettagli si veda la documentazione. Gara di popolarità Il sistema di installazione offrirà ancora l'installazione del pacchetto Le informazioni provenienti da Aggiornamenti da precedenti rilasci Preparazione all'aggiornamento Suggeriamo che prima di aggiornare si leggano anche le informazioni in . Tale capitolo copre potenziali problematiche non direttamente collegate al processo di aggiornamento, ma che potrebbe comunque essere importante conoscere prima di cominciare. Backup di dati e informazioni di configurazione Prima di aggiornare il proprio sistema, si raccomanda vivamente di effettuare un backup completo, o almeno la copia di tutti quei dati e informazioni di configurazione che non ci si può permettere di perdere. Gli strumenti ed i processi di aggiornamento sono piuttosto affidabili, ma un problema all'hardware nel corso di un aggiornamento potrebbe risultare in un sistema fortemente danneggiato. Le principali cose di cui si vorrà mantenere una copia sono i contenuti di /etc, di /var/lib/dpkg e di /var/lib/aptitude/pkgstates e l'output di dpkg --get-selections "*" (le virgolette sono importanti). Di per sé, il processo di aggiornamento non modifica nulla nella directory /home. È tuttavia noto che alcune applicazioni (p.e. alcune parti della suite Mozilla e gli ambienti desktop GNOME e KDE) sovrascrivono impostazioni preesistenti dell'utente con nuovi valori predefiniti quando un utente avvia per la prima volta una nuova versione dell'applicazione. Si potrebbe voler fare per precauzione un backup di file e directory nascosti (“dotfile”, cioè file i cui nomi iniziano con un punto, NdT) delle directory home degli utenti. Tale backup potrebbe aiutare a ripristinare o ricreare le vecchie impostazioni. Si potrebbe anche voler informare gli utenti di questo argomento. Ogni installazione di pacchetti deve essere eseguita con i privilegi di superutente, dunque si effettui il login come root o si usi L'aggiornamento ha alcune precondizioni: le si dovrebbe verificare prima di espletare effettivamente l'operazione. Informare gli utenti in anticipo È saggio informare in anticipo tutti gli utenti di qualunque aggiornamento si stia pianificando, sebbene gli utenti che accedono al sistema tramite una connessione Se si desidera prendere ulteriori precauzioni, si esegua un backup delle partizioni degli utenti (/home) o le si smonti prima di un aggiornamento. Probabilmente con l'aggiornamento a &releasename; si dovrà anche fare un aggiornamento del kernel, cosicché sarà normalmente necessario riavviare. Tipicamente, questo sarà fatto dopo la fine dell'aggiornamento. Preparazione per il ripristino A causa dei molti cambiamenti nel kernel tra &oldreleasename; e &releasename; riguardanti i driver, il rilevamento dell'hardware e l'assegnamento e l'ordinamento dei file device, c'è un reale rischio che si incontrino problemi al riavvio del sistema dopo l'aggiornamento. Molte potenziali problematiche sono documentate in questo capito delle presenti Note di Rilascio e nei successivi. Per tale ragione è sensato assicurarsi di poter effettuare un ripristino nel caso in cui il sistema dovesse non riuscire a riavviarsi o, nel caso di sistemi controllati da remoto, non riuscire a raggiungere la rete. Se si sta aggiornando da remoto tramite un collegamento ) e si dovrà sistemare la configurazione del sistema tramite una console locale. Inoltre, se il sistema è riavviato accidentalmente nel mezzo di un aggiornamento, vi sono possibilità che lo si debba ripristinare utilizzando una console locale. La cosa più ovvia da fare per prima è riavviare con il vecchio kernel. Tuttavia, per varie ragioni documentate altrove nel presente documento, non è garantito che ciò funzioni. Se ciò fallisce, si necessiterà di un modo alternativo per avviare il sistema in modo tale da poter accedere ad esso e ripararlo. Un'opzione è quella di utilizzare una speciale immagine di ripristino o un live CD con linux. Dopo l'avvio da esso, si dovrebbe poter montare il filesystem radice ed entrarvi con Un'altra opzione di cui vorremmo raccomandare l'utlizzo è quella di usare la modalità di ripristino ( e le . Shell di debug durante l'avvio con initrd Questa caratteristica può essere disabilitata con l'aggiunta del parametro negli initrd che genera. Se per esempio l'initrd non è in grado di montare il filesystem radice, si sarà rimandati in questa shell di debug che rende disponibili comandi di base per aiutare a rintracciare il problema e se possibile risolverlo. Le cose di base da controllare sono: la presenza dei file device corretti in /dev; quali moduli sono caricati (cat /proc/modules); l'output di Se si riesce a risolvere il problema, digitando ]]> Preparazione di un ambiente sicuro per l'aggiornamento L'aggiornamento della distribuzione dovrebbe essere effettuato o in locale da una console virtuale in modalità testo (o da un terminale seriale direttamente connesso), o in remoto attraverso un collegamento Al fine di ottenere un margine di sicurezza extra nell'aggiornamento da remoto, suggeriamo che si eseguano i processi di aggiornamento nella console virtuale fornita dal programma Il supporto per i kernel 2.2 è stato interrotto Nel caso in cui si utilizzi un kernel precedente al 2.4.1, è necessario aggiornare (almeno) alla serie 2.4 prima di aggiornare le Verifica dello stato del sistema Il processo di aggiornamento descritto nel presente capitolo è stato progettato per aggiornamenti da sistemi &oldreleasename; puri senza pacchetti di terze parti. In particolare, vi sono noti problemi con pacchetti di terze parti che installano programmi in /usr/X11R6/bin/, causando problemi con gli aggiornamenti a causa della transizione di X.org (). Per la massima affidabilità del processo di aggiornamento, si potrebbe desiderare di rimuovere pacchetti di terze parti dal sistema prima di cominciare con l'aggiornamento. La procedura assume anche che il sistema sia stato aggiornato fino all'ultimo rilascio anche minore di &oldreleasename;. Se non lo si è fatto o non se ne è certi, si seguano le istruzioni in . Controllare le azioni in sospeso nel gestore dei pacchetti In alcuni casi, l'utilizzo di A causa di ciò bisognerebbe controllare se vi sono azioni in sospeso nel gestore dei pacchetti . Per fare questo, si dovrebbe eseguire l'interfaccia utente di Disattivare il pinning di APT Se si è configurato APT per installare alcuni pacchetti da una distribuzione diversa da stable (p.e. da testing), si potrebbe dover modificare la propria configurazione dei pin APT (salvata in /etc/apt/preferences) per consentire l'aggiornamento di tali pacchetti alle versioni contenute nel nuovo rilascio stable. Maggiori informazioni sui pin APT possono essere reperite in . Verifica dello stato dei pacchetti Indipendentemente dal metodo utilizzato per l'aggiornamento, si raccomanda di controllare prima lo stato di tutti i pacchetti, e di verificare che tutti i pacchetti siano in uno stato che ne consente l'aggiornamento. Il seguente comando visualizzerà eventuali pacchetti che siano in uno stato “Half-Installed” o “Failed-Config”, e quelli che abbiano uno status problematico. # dpkg --get-selections | grep hold Si può anche ispezionare lo stato di tutti i pacchetti del proprio sistema utilizzando # dpkg -l | pager o # dpkg --get-selections "*" > ~/curr-pkgs.txt È desiderabile la rimozione di qualunque blocco prima dell'aggiornamento. Se qualche pacchetto che è essenziale per l'aggiornamento è bloccato [“on hold”], l'aggiornamento non andrà a buon fine. Si noti che # aptitude search "~ahold" | grep "^.h" Volendo controllare quali pacchetti sono bloccati per # dpkg --get-selections | grep hold Se si è modificato e ricompilato un pacchetto localmente, e non lo si è rinominato né lo si è contrassegnato nella versione, lo si dovrà bloccare per impedire che venga aggiornato. Lo stato “bloccato” [“hold”] dei pacchetti per # aptitude hold nome_del_pacchetto Si sostituisca Se c'è bisogno di sistemare qualcosa, è sempre meglio assicurarsi che il proprio . Fonti non ufficiali e backport Se si hanno pacchetti non-Debian sul proprio sistema, si dovrebbe essere al corrente del fatto che essi potrebbero essere rimossi durante l'aggiornamento a causa di dipendenze in conflitto. Se tali pacchetti fossero stati installati tramite l'aggiunta di un archivio extra di pacchetti in /etc/apt/sources.list, si dovrebbe verificare se quell'archivio offra anche pacchetti compilati per &releasename; e modificare rispettivamente le righe delle fonti nel momento stesso in cui si modifichino le righe delle fonti per i pacchetti Debian. Alcuni utenti potrebbero avere installate nel loro sistema versioni non ufficiali “più recenti” da backport di pacchetti che Il sistema di gestione dei pacchetti di Debian non consente normalmente ad un pacchetto la rimozione o sostituzione di un file controllato da un altro pacchetto, a meno che sia stato definito di rimpiazzare quel pacchetto. La sezione contiene delle informazioni su come comportarsi di fronte a conflitti fra file nel caso in cui si dovessero verificare. Smarcare manualmente i pacchetti Per impedire ad # aptitude unmarkauto openoffice.org vim E immagini di kernel 2.6 qualora siano state installate con l'utilizzo di un metapacchetto: # aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1) Nota: Si può controllare quali pacchetti sono marcati come # aptitude search 'i~M <nome pacchetto>' Preparazione delle fonti per APT Prima di cominciare l'aggiornamento si deve predisporre per le liste dei pacchetti il file di configurazione di /etc/apt/sources.list. deb”, ed installerà il pacchetto con il numero di versione più alto, dando la priorità alle righe menzionate per prime (in questo modo, nel caso in cui siano presenti varie fonti equivalenti, si dovrebbe menzionare per primo un disco fisso locale, poi CD-ROM, infine mirror HTTP/FTP). Si fa spesso riferimento ad un rilascio sia tramite il uso nome in codice (p.e. &oldreleasename;, &releasename;) sia tramite la denominazione del suo stadio (cioè oldstable, stable, testing, unstable). Fare riferimento ad un rilascio attraverso il suo nome in codice presenta il vantaggio che non si sarà mai sorpresi da un nuovo rilascio, e per questa ragione è il modo adottato qui. Questo naturalmente significa che si dovrà fare attenzione agli annunci di rilascio. Se si utilizza invece la denominazione dello stadio, si vedrà la grande quantità di aggiornamenti disponibili per i propri pacchetti non appena avvenga un rilascio. Aggiunta di fonti Internet per APT La configurazione predefinita è predisposta per l'installazione dai principali server Debian su Internet, ma si potrebbe desiderare di modificare /etc/apt/sources.list per utilizzare altri mirror, preferibilmente un mirror più “vicino” (dal punto di vista della rete). Gli indirizzi dei mirror HTTP o FTP di Debian possono essere reperiti presso (si guardi la sezione “elenco dei mirror”). I mirror HTTP sono in genere più rapidi dei mirror FTP. Ad esempio, si supponga che il proprio mirror Debian più vicino sia &url-debian-mirror-eg;/. Ispezionando tale mirror con un browser web o con un client FTP, si noterà che le directory principali sono organizzate nel modo seguente: &url-debian-mirror-eg;/dists/&releasename;/main/binary-&architecture;/... &url-debian-mirror-eg;/dists/&releasename;/contrib/binary-&architecture;/... Per utilizzare questo mirror con deb &url-debian-mirror-eg; &releasename; main contrib Si noti che “dists” è aggiunto implicitamente, e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su multiple directory. Dopo aver aggiunto le proprie nuove fonti, si disabilitino le righe “ Aggiunta di fonti da mirror locale per APT Al posto di utilizzare mirror HTTP o FTP dei pacchetti, si potrebbe desiderare di modificare /etc/apt/sources.list per utilizzare un mirror su un disco locale (possibilmente montato su NFS) (NFS: filesystem di rete, NdT). Ad esempio, il proprio mirror dei pacchetti potrebbe essere sotto /var/ftp/debian/, e si potrebbe avere directory principali come le seguenti: /var/ftp/debian/dists/&releasename;/main/binary-&architecture;/... /var/ftp/debian/dists/&releasename;/contrib/binary-&architecture;/... Per utilizzare questo mirror con deb file:/var/ftp/debian &releasename; main contrib Si noti che “dists” è aggiunto implicitamente, e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su multiple directory. Dopo aver aggiunto le proprie nuove fonti, si disabilitino le righe “ Aggiunta di fonti su CD-ROM o DVD per APT Se si vogliono utilizzare /etc/apt/sources.list, ponendo davanti ad esse un simbolo 'cancelletto' ( Ci si accerti che vi sia in /etc/fstab una riga che abilitai l'accesso al proprio drive CD-ROM su /cdrom (/cdrom). Ad esempio, se il drive del CD-ROM è chiamato /dev/hdc, /etc/fstab dovrebbe contenere una riga come la seguente: /dev/hdc /cdrom auto defaults,noauto,ro 0 0 Si noti che non deve essere presente defaults,noauto,ro nel quarto campo. Per verificare il funzionamento, si inserisca un CD e si provi ad eseguire # mount /cdrom # con questo comando si monterà il CD sul mount point # ls -alF /cdrom # con questo comando si dovrebbe visualizzare la directory di root del CD # umount /cdrom # con questo comando si smonterà il CD Quindi, si esegua: # apt-cdrom add per ciascun CD-ROM di binari di Debian che si possiede, per aggiungere i dati su ciascun CD al database di APT. Aggiornamento dei pacchetti Il metodo raccomandato per l'aggiornamento dai precedenti rilasci di &debian; prevede l'utilizzo del gestore dei pacchetti aptitude. Tale programma rende le decisioni riguardanti le installazioni dei pacchetti più sicure che l'esecuzione diretta di apt-get. Non ci si dimentichi di montare tutte le partizioni necessarie (in particolar modo le partizioni root e /usr) in lettura-scrittura, con un comando come: # mount -o remount,rw /mountpoint Si dovrebbe poi controllare bene che le voci sulle sorgenti di APT (contenute in /etc/apt/sources.list) facciano riferimento a "stable". Non vi dovrebbero essere voci di fonti che puntino a &oldreleasename;. Nota: le righe delle fonti per un CD-ROM faranno spesso riferimento ad " Registrazione della sessione Si raccomanda vivamente di utilizzare il programma /usr/bin/script per registrare una trascrizione della sessione di aggiornamento. In tal modo, se si verificasse un problema, si disporrà di una registrazione di quanto accaduto, e, ove necessario, si potrà fornire le informazioni esatte in un'eventuale segnalazione su un bug. Per avviare la registrazione, si digiti: # script -t 2>~/upgrade-&releasename;.time -a ~/upgrade-&releasename;.script completo o un simile comando. Non si collochi il file della registrazione in una directory temporanea come /tmp o /var/tmp (i file in queste directory potrebbero venir cancellati durante l'aggiornamento o durante un qualunque riavvio). Il file generato permetterà anche di rileggere informazioni scorse fuori dalla schermata. Basta passare a VT2 (con less ~root/upgrade-to-&releasename;.typescript per visionare il file. Dopo aver completato l'aggiornamento, si può arrestare Se si è utilizzato il parametro -t per # scriptreplay ~/upgrade-&releasename;.time ~/upgrade-&releasename;.script Aggiornamento della lista dei pacchetti Innanzitutto dev'essere recuperata la lista dei pacchetti disponibili per il nuovo rilascio. Lo si fa eseguendo: # aptitude update Eseguire questo la prima volta che le nuove fonti sono aggiornate provocherà la stampa a schermo di alcuni avvisi relativi alla disponibilità delle fonti. Tali avvisi sono innocui e non appariranno se si eseguirà nuovamente il comando. Assicurarsi di avere spazio a sufficienza per l'aggiornamento Prima di aggiornare il proprio sistema ci si deve accertare di avere sufficiente spazio libero sull'hard disk al momento di fare partire l'aggiornamento completo del sistema descritto in . Per prima cosa, ogni pacchetto necessario per l'installazione prelevato dalla rete è immagazzinato in /var/cache/apt/archives (e nella sottodirectory partial/, durante lo scaricamento), onde ci si dovrebbe accertare di avere spazio a sufficienza sulla partizione del filesystem che contiene /var per il temporaneo scaricamento dei pacchetti che saranno installati nel sistema. Dopo lo scaricamento,altre partizioni sarà probabilmente necessario ulteriore spazio in altre partizioni del filesystem al fine di installare sia i pacchetti aggiornati (che potrebbero contenere file binari più grossi o più dati), sia nuovi pacchetti che saranno introdotti con l'aggiornamento. Se il sistema non ha spazio a sufficienza, si potrebbe finire con un aggiornamento incompleto dal quale potrebbe risultare difficile ripristinare. Sia # aptitude -y -s -f --with-recommends dist-upgrade [ ... ] XXX pacchetti aggiornati, XXX installati, XXX da rimuovere e XXX non aggiornati. È necessario prelevare xx.xMB/yyyMB di archivi. Dopo l'estrazione, verranno occupati AAAMB. Saranno scaricati/installati/rimossi pacchetti. L'esecuzione di tale comando all'inizio del processo di aggiornamento potrebbe restituire un errore, per le ragioni descritta nella sezione seguente. In tal caso in cui si desidererà attendere finché si sia fatto l'aggiornamento minimo del sistema come descritto in e si sia aggiornato il kernel come descritto in prima di eseguire il comando per avere una stima dello spazio libero su disco. Se non si ha abbastanza spazio per l'aggiornamento, ci si accerti di liberare dapprima dello spazio. Si può: rimuovere pacchetti che sono stati precedentemente scaricati per l'installazione (in /var/cache/apt/archive). Ripulendo la cache dei pacchetti mediante esecuzione di apt-get clean o aptitude clean si rimuoveranno tutti i file pacchetto precedentemente scaricati. rimuovere vecchi pacchetti non più utilizzati. Se si ha ). In alternativa si può avviare rimuovere pacchetti che occupano troppo spazio, che non siano attualmente necessari (li si può sempre reinstallare dopo l'aggiornamento). Si possono elencare i pacchetti che occupano più spazio su disco con wajig size). spostare temporaneamente su un altro sistema o rimuovere permanentemente i log di sistema risiedenti sotto /var/log. Si noti che per una rimozione sicura dei pacchetti è consigliabile riportare il file sources.list a &oldreleasename;, come descritto in . Aggiornamento minimo del sistema A causa di alcuni necessari conflitti tra pacchetti tra &oldreleasename; e &releasename;, l'esecuzione diretta di aptitude dist-upgrade rimuoverà spesso grandi quantità di pacchetti che si vorranno mantenere. Raccomandiamo dunque un processo di aggiornamento in due parti: prima un aggiornamento minimo che risolva questi conflitti, poi un dist-upgrade completo. Si esegua in primo luogo: # aptitude upgrade Questo ha l'effetto di aggiornare i pacchetti che possono essere aggiornati senza richiedere la rimozione o l'installazione di altri pacchetti. Si segua la procedura di aggiornamento minimo con: # aptitude install initrd-tools Questo passaggio aggiornerà automaticamente I seguenti passaggi dipendono dall'insieme di pacchetti che si hanno installati. Queste note di rilascio forniscono consigli generici riguardo quale metodo utilizzare, ma se si è in dubbio si raccomanda di esaminare le rimozioni di pacchetti proposte da ciascun metodo prima di procedere. Alcuni pacchetti comuni che ci si aspetta siano rimossi comprendono . Aggiornamento di un sistema desktop Questo percorso si aggiornamento è stato verificato funzionare su sistemi con installato il task desktop di &oldreleasename;. È probabilmente il metodo che darà i migliori risultati su sistemi con il task desktop installato, o con i pacchetti gnome o kde installati. Non è probabilmente il metodo corretto da usare se on si hanno già i pacchetti # dpkg -l libfam0c102 | grep ^ii # dpkg -l xlibmesa-glu | grep ^ii Se si ha un sistema desktop completo installato, si esegua: # aptitude install libfam0 xlibmesa-glu Aggiornamento di un sistema con alcuni pacchetti di X installati Sistemi con alcuni pacchetti di X installati, ma non il task desktop completo, richiedono un metodo differente. Tale metodo si applica in generale ai sistemi con desktop completo installato. # dpkg -l xfree86-common | grep ^ii Si verifichi per prima cosa se si hanno i pacchetti # dpkg -l libfam0c102 | grep ^ii # dpkg -l xlibmesa-glu | grep ^ii Se non si ha Questo comando determinerà se si necessita di libfam0 e xlibmesa-glu installati, e li autoselezionerà per l'utente: # aptitude install x11-common \ $(dpkg-query --showformat '${Package} ${Status}\n' -W libfam0c102 xlibmesa-glu \ | grep 'ok installed$' | sed -e's/ .*//; s/c102//') # aptitude install x11-common libfam0 xlibmesa-glu Si noti che l'installazione di Aggiornamento di un sistema senza supporto a X installato Su un sistema senza X, non dovrebbero essere richiesti comandi Aggiornamento del kernel La versione di Di conseguenza, il precedente pacchetto del kernel probabilmente non si avvierà correttamente dopo questo aggiornamento. In modo simile, vi è una finestra di tempo durante l'aggiornamento in cui per raccomandazioni su come premunirsi per questa eventualità se si sta aggiornando da remoto.) A meno che il sistema abbia il task desktop installato, o altri pacchetti che causarebbero un numero inaccettabile di rimozioni di pacchetti, è dunque raccomandato che si aggiorni a questo punto il solo kernel. Per procedere con questo aggiornamento del kernel, si esegua: # aptitude install linux-image-2.6-flavor Si veda per un aiuto nella determinazione del flavor del pacchetto del kernel da installare. Nel caso dei desktop, non è purtroppo possibile assicurare che il nuovo pacchetto del kernel sia installato immediatamente dopo l'installazione del nuovo per informazioni su come configurare il proprio sistema perché non dipenda da hotplug per l'avvio. Aggiornamento del resto del sistema Si è ora pronti per continuare con la parte principale dell'aggiornamento. Si esegua: # aptitude dist-upgrade Questo comando farà eseguire l'aggiornamento completo del sistema, che comprenderà p.e. l'installazione delle ultime versioni disponibili di tutti i pacchetti, e la risoluzione di tutti i possibili cambiamenti di dipendenze fra pacchetti di rilasci differenti. Se necessario, saranno installati alcuni nuovi pacchetti (solitamente nuove versioni di librerie, o pacchetti rinominati), e sarà rimosso qualunque pacchetto obsoleto che crei conflitti. In caso di aggiornamento da una serie di CD-ROM, verrà chiesto di inserire uno specifico CD in parecchi momenti dell'aggiornamento. Potrebbe capitare di dover inserire più volte lo stesso CD: ciò è dovuto a pacchetti intercorrelati tra loro che sono stati distribuiti tra diversi CD. Pacchetti attualmente installati disponibili in nuove versioni alle quali non possano essere aggiornati senza cambiare lo stato di installazione di un altro pacchetto, saranno lasciati alla loro attuale versione (contrassegnati come “held back”; “bloccàti indietro”, NdT). Questo fatto può essere risolto o utilizzando aptitude per designare tali pacchetti per l'installazione, o provando con aptitude -f install pacchetto. Ottenere le firme dei pacchetti Dopo l'aggiornamento, con la nuova versione di # aptitude update L'aggiornamento avrà già recuperato ed abilitato le chiavi di firma per gli archivi di pacchetti di Debian. Se si aggiungono altre fonti (non ufficiali) di pacchetti, . Si noterà che, dal momento in cui si utilizza la nuova versione di . Problematiche che potrebbero emergere durante l'aggiornamento Se un'operazione che utilizza E: Dynamic MMap ran out of room lo spazio predefinito della cache è insufficiente. È possibile risolvere questo problema rimuovendo o riducendo a commenti righe inutili in /etc/apt/sources.list o aumentando la grandezza della cache. Si può aumentare la grandezza della cache dando un opportuno valore alla variabile /etc/apt/apt.conf. Il seguente comando la imposterà ad un valore che dovrebbe essere sufficiente per l'aggiornamento: # echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf Questo assume che la variabile non sia ancora stata impostata in quel file. A volte è necessario abilitare l'opzione Di norma -o APT::Force-LoopBreak=1 nella riga di comando di C'è la possibilità che la struttura delle dipendenze di un sistema sia talmente corrotta da richiedere un intervento manuale. Solitamente ciò significa usare # dpkg --remove nome_pacchetto per eliminare alcuni dei pacchetti problematici, o # aptitude -f install # dpkg --configure --pending In casi estremi si dovrebbe poter forzare la reinstallazione con un comando simile a # dpkg --install /percorso/di/nomepacchetto.deb Non dovrebbero esserci conflitti tra file se si aggiorna da una &releasename; pura, ma si potrebbero avere se sono stati installati backport non ufficiali. Un conflitto tra file causerà un errore simile al seguente: Spacchettamento di <pacchetto-tizio> (da <file-del-pacchetto-tizio>) ... dpkg: errore nel processamento di <pacchetto-tizio> (--unpack): tentativo di sovrascrivere `<nome-di-qualche-file>', che è anche nel pacchetto <pacchetto-caio> dpkg-deb: sottoprocesso paste ucciso da un segnale (Pipe rotta) Sono stati incontrati errori durante il processamento di: <pacchetto-tizio> Si può cercare di risolvere un conflitto tra file rimuovendo forzatamente il pacchetto menzionato nell'ultima riga del messaggio di errore: # dpkg -r --force-depends nome_pacchetto Dopo aver sistemato le cose, si dovrebbe poter riprendere l'aggiornamento ripetendo i comandi Durante l'aggiornamento verranno poste domande riguardanti la configurazione o riconfigurazione di parecchi pacchetti. Quando venga chiesto se un qualsivoglia file nelle directory /etc/init.d e /etc/terminfo o il file /etc/manpath.config debba venir rimpiazzato con quello fornito dal manutentore del pacchetto, di solito è necessario rispondere affermativamente, per garantire la coerenza del sistema. Si può sempre ritornare alle versioni precedenti, dal momento che verranno salvate con l'estensione Se non si è sicuri sul da farsi, ci si annoti il nome del pacchetto o del file da sistemare, e si sistemino le cose in un momento successivo. Le informazioni presentate sullo schermo durante l'aggiornamento possono essere riesaminate dopo esser state cercate nel file generato da Aggiornare il kernel e i pacchetti collegati Questa sezione spiega come aggiornare il kernel ed identifica potenziali problematiche relative a tale aggiornamento. Si può o installare uno dei pacchetti Si noti che molte informazioni in questa sezione sono basate sull'assunzione che si userà uno dei pacchetti modulari di Debian, insieme con ]]> Si noti che questa sezione contiene molte informazioni relative all'utilizzo di ]]> Si noti poi che se Se si sta utilizzando un kernel 2.4, si dovrebbe anche leggere attentamente . ]]> Installazione del metapacchetto del kernel Allorché si effettua un dist-upgrade da &oldreleasename; a &releasename;, è fortemente raccomandato che si installi un nuovo metapacchetto linux-image-2.6-*. Tale pacchetto potrebbe essere installato automaticamente dal processo di dist-upgrade. Lo si può verificare eseguendo: # dpkg -l "linux-image*" | grep ^ii Se non si vede alcun output, si dovrà installare un nuovo pacchetto linux-image a mano. Per vedere un elenco dei metapacchetti linux-image-2.6 disponibili, si esegua: # apt-cache search linux-image-2.6- | grep -v transition Se non si è sicuri riguardo quale pacchetto selezionare, si esegua uname -r e si cerchi un pacchetto con un nome simile. Ad esempio, se si vede '2.4.27-3-686', è consigliata l'installazione di Si può anche utilizzare aptitude per vedere una lunga descrizione di ciascun pacchetto che aiuti a scegliere il migliore disponibile. Ad esempio: # apt-cache show linux-image-2.6-686 Si dovrebbe quindi utilizzare Per i più avventurosi, esiste un modo agevole per compilare il proprio kernel personalizzato su &debian;. Si installi lo strumento kernel-package e si legga la documentazione contenuta in /usr/share/doc/kernel-package. Aggiornamento da un kernel 2.6 Se si sta attualmente facendo girare un kernel della serie 2.6 di &oldreleasename;, questo aggiornamento avrà luogo automaticamente dopo un aggiornamento completo del sistema (come descritto in ). Se possibile, conviene aggiornare il pacchetto del kernel separatamente dal per una descrizione di tale processo. Si noti che ciò dovrebbe essere fatto soltanto dopo il processo di aggiornamento minimo descritto in . Si può anche comprendere questo passaggio se si sta usando il proprio kernel personalizzato e si vuole utilizzare il kernel disponibile in &releasename;. Se la versione del proprio kernel non è supportata da Aggiornamento da un kernel 2.4 Se si ha un kernel 2.4 installato, e il sistema si affida a . Se il sistema non si affida a Si possono avere i moduli del kernel necessari al sistema caricati staticamente tramite una corretta configurazione di /etc/modules, si può rimandare l'aggiornamento del kernel a dopo che si sia eseguito un aggiornamento completo del sistema, come descritto in . Una volta che il sistema è stato aggiornato si può fare quanto segue (modificando il nome del pacchetto del kernel in quello più adatto al proprio sistema sostituendo <flavor>): # aptitude install linux-image-2.6-<flavor> ]]> Riordino della numerazione dei dispositivi &releasename; si caratterizza per un meccanismo di rilevamento dell'hardware più robusto di quelli dei precedenti rilasci. Questo potrebbe tuttavia causare cambiamenti nell'ordine in cui i dispositivi vengono rilevati sul sistema, interessando l'ordine in cui i nomi dei dispositivi sono assegnati. Ad esempio, se si hanno due adattatori di rete, i dispositivi cui eth0 e eth1 fanno riferimento potrebbero venire scambiati. Si noti che il nuovo meccanismo significa che se p.e. si sostituiscono gli adattatori ethernet in un sistema &releasename; in funzione il nuovo adattatore riceverà anche un nuovo nome di interfaccia. Per i dispositivi di rete, si può evitare questo riordino utilizzando le regole di udev, più specificamente, tramite le definizioni in /etc/udev/rules.d/z25_persistent-net.rulesLe regole ivi contenute sono generate automaticamente dallo script /etc/udev/rules.d/z45_persistent-net-generator.rules tali da avere nomi persistenti per le interfacce di rete. Si elimini questo link simbolico per disattivare l'assegnazione di nomi di dispositivo persistenti per i NIC tramite . In alternativa è possibile utilizzare l'utility ifrename per collegare dispositivi fisici a specifici nomi all'avvio. Per maggiori informazioni si vedano e . Le due alternative (ifrename e udev) non dovrebbero essere utilizzate entrambe allo stesso tempo. Per i dispositivi di archiviazione, si può evitare questo riordino utilizzando Rimuovere e ricaricare i pacchetti dopo l'avvio iniziale avrà tuttavia effetto su tale ordine. Inoltre, il kernel potrebbe avere alcuni moduli collegati staticamente, e i loro nomi non appariranno nell'output di lsmod. Si potrebbe riuscire a ricavare i nomi di tali driver e l'ordine del loro caricamento guardando il file /var/log/kern.log, o l'output di dmesg. Si aggiungano i nomi di tali moduli al file /etc/initramfs-tools/modules nell'ordine in cui essi dovrebbero essere caricati all'avvio. Alcuni nomi di moduli potrebbero essere cambiati da &oldreleasename; a &releasename;. Ad esempio, sym53c8xx_2 è diventato sym53c8xx. Si dovrà quindi rigenerare la/e propria/e immagine/i initramfs eseguendo update-initramfs -u -k all. Una volta che si siano messi in funzione un kernel &releasename; e /dev/disk/. Riordino dei dispositivi seriali Se si possiede una macchina HP e si sta utilizzando la porta per la console seriale MP (il connettore targato "console" sul cavo a tre teste), questo aggiornamento del kernel farà cessare il funzionamento della console! In seguito al riavvio, il sistema mostrerà il messaggio "Loading initrd....", ma si fermerà lì. Si noti che sistemi con firmware non aggiornati mostreranno sintomi simili, sebbene la problematica sia relativa a incompatibilità del kernel (si veda ). Si prega di leggere le seguenti informazioni prima dell'aggiornamento. Il dispositivo della console cambierà da ttyS0 a ttyS1, ttyS2 o ttyS3, quindi: si editi /etc/inittab per aggiungere una voce getty per /dev/ttyS1 (rx4640, rx5670, rx7620, rx8620, Superdome), /dev/ttyS2 (rx1600) o /dev/ttyS3 (rx2600); si editi /etc/securetty per aggiungere ttyS1, ttyS2, o ttyS3; si lascino le voci ttyS0 esistenti in /etc/inittab e /etc/securetty così da poter sempre avviare con vecchi kernel. Si editi /etc/lilo.conf per rimuovere ogni argomento "console=". Si esegua Si riavvii e si usi il Boot option maintenance menu di EFI per selezionare esattamente un dispositivo per l'output, l'input e lo standard error della console. Quindi si riavvii a freddo perché le modifiche abbiano effetto. Per la console MP, si faccia attenzione a selezionare il dispositivo con "Acpi(HWP0002,700)/Pci(...)/Uart" nel percorso. Maggiori dettagli in merito a questi cambiamenti e consigli per la risoluzione dei problemi sono disponibili all'indirizzo . ]]> Problemi di temporizzazione dell'avvio Se per l'avvio del sistema è utilizzato un initrd creato con I sintomi consueti sono che l'avvio fallirà poiché il filesystem radice non può essere montato e si sarà rinviati ad una shell di debug, ma che quando in seguito si effettuerà una verifica tutti i dispositivi necessari saranno presenti in /dev. Ciò è stato osservato in casi in cui il filesystem radice è su un disco USB o in RAID, specialmente ove sia utilizzato lilo. Un trucco per questa problematica è quello di utilizzare il parametro di avvio rootdelay=. Il valore per il timeout (in secondi) potrebbe necessitare un aggiustamento. ]]> Il driver firewire PCILynx è malfunzionante Il driver PCILynx è orribilmente malfunzionante, e ciò potrebbe causare crash del driver su PowerPC. Incoraggiamo gli utenti che necessitino del firewire a procurarsi un'economica scheda OHCI1394 e mettere in blacklist il driver PCILynx. ]]> Cose da fare prima di riavviare Quando aptitude dist-upgrade è giunto al termine, l'aggiornamento “formale” è concluso, ma vi sono alcune altre cose di cui ci si dovrebbe preoccupare Conversione da devfs I kernel Debian non includono più il supporto per devfs, cosicché gli utenti di devfs dovranno convertire i loro sistemi manualmente prima di avviare un kernel di &releasename;. Se si vede la stringa "devfs" in /proc/mounts, si sta nel caso più probabile utilizano devfs. Tutti i file di configurazione che facciano riferimento a nomi di dispositivo nello stile di devfs dovranno essere corretti così che utilizzino nomi nello stile di udev. I file che potrebbero verosimilmente fare riferimento a nomi di dispositivo nello stile di devfs comprendono /etc/fstab, /etc/lilo.conf, /boot/grub/menu.lst e /etc/inittab. Sono disponibili maggiori informazioni sulle potenziali problematiche nella segnalazione . Possibili driver mancanti nell'initrd I kernel di &releasename; non hanno ancora un completo supporto a sysfs per lo sbus sparc nativo. Se il sistema utilizza il modulo /etc/initramfs-tools/modules e di rigenerare l'initrd prima di riavviare il sistema. L'initrd può essere rigenerato con: # update-initramfs -u -k all ]]> Possibili driver mancanti nell'initrd I kernel &releasename; non hanno ancora un supporto a sysfs per il bus HP nativo. Se il sistema utilizza il modulo /etc/initramfs-tools/modules e di rigenerare l'initrd prima di riavviare il sistema. L'initrd può essere rigenerato con: # update-initramfs -u -k all ]]> Rieseguire lilo Se si sta utilizzando lilo dopo l'aggiornamento: # /sbin/lilo Si noti che ciò è necessario anche se non si è aggiornato il kernel del sistema, dal momento che il secondo stage di lilo cambierà a causa dell'aggiornamento del pacchetto. Si controllino inoltre i contenuti del file /etc/kernel-img.conf e ci si accerti di avervi do_bootloader = Yes. In tal modo il bootloader sarà sempre rieseguito dopo un aggiornamento del kernel. Se si incontrano problematiche durante l'esecuzione di / a vmlinuz e a initrd e i contenuti di /etc/lilo.conf per eventuali discrepanze. Se ci si dimentica di rieseguire Per maggiori informazioni sui codici di errore dell'avvio di .. Per informaioni su come ripristinare da questa condizione, si veda . ]]> Configurazione dell'hardware su S/390 Non tutto l'hardware di S/390 può essere configurato automaticamente. Per i kernel di &releasename; viene utilizzata una nuova utility, /etc/sysconfig/. Specialmente se il sistema sta facendo attualmente girare un kernel 2.4, sistemare la configurazione può essere complicato. Se si necessità di aiuto, si contatti senz'altro la . Si installi in primo luogo l'utility e si rigeneri l'initrd di initramfs, poiché l'utility fornisce alcuni script che necessitano di essere inclusi nell'initrd: # aptitude install sysconfig-hardware # update-initramfs -u -k all Configurazione per i dischi Questo si fa modificando /etc/zipl.conf. L'utility sysconfig può utilizzare il percorso del dispositivo per il dispositivo root per abilitarlo, il che significa che tale percorso deve essere passato nei parametri di avvio del kernel. Per un normale dasd, il percorso è composto come segue: <bus>-<dispositivo> Per il parametro root=/dev/dasda1 si includerebbe in /etc/zipl.conf nella riga root=/dev/disks/by-path/ccw-0.0.0122-part1 O, in alternativa, si può utilizzare il parametro root=/dev/dasda1 enable=ccw-0.0.0122 I percorsi da usare possono variare per dispositivi differenti. Per esempio, per dischi su un zFCP fiberchannel host adapter, il percorso consiste di bus, dispositivo, driver, wwpn e lun. Il parametro per un RAID1 apparirebbe così (su un'unica riga): root=/dev/md0 enable=ccw-0.0.2900-zfcp-0x21000020371c93a5:0 enable=ccw-0.0.2900-zfcp-0x21000020371d8f94:0 Altri dispositivi dasd (dasd non necessari per il caricamento del filesystem radice) sono abilitati tramite i file di configurazione in /etc/sysconfig/hardware/. Per un normale dasd, sarà semplicemente necessario creare un file vuoto con il percorso del dispositivo nel suo nome: # cd /etc/sysconfig/hardware # touch config-ccw-0.0.0122 Per dischi su un zFCP fiberchannel host adapter i singoli dispositivi sono elencati all'interno del file. Utilizzando lo stesso esempio di sopra, si crei un file ZFCP_DEVICES=(0x21000020371c93a5:0x0000000000000000 0x2100...:0x...) Configurazione per i dispositivi di rete I dispositivi di rete sono abilitati tramite file di configurazione in /etc/sysconfig/hardware/. Per un dispositivo di rete ctc con canale di lettura CCWGROUP_CHANS=(0.0.0a00 0.0.0a01) CTC_PROTOCOL=0 Per un dispositivo di rete qeth con la modalità layer2 abilitata, questo potrebbe essere un file CCWGROUP_CHANS=(0.0.0600 0.0.0601 0.0.0602) QETH_OPTIONS=(layer2) Le opzioni supportate per ctc sono Dal momento che i dispositivi di rete su S/390 non hanno un MAC address stabile, non è possibile utilizzare l'assegnazione persistente dei nomi di ]]> Aggiornamento di mdadm mdadm necessita ora di un file di configurazione per l'assemblaggio di array MD (RAID) dal ramdisk iniziale e durante la sequenza di inizializzazione del sistema. Ci si accerti di leggere il file /usr/share/doc/mdadm/README.upgrading-2.5.3.gz e di leggere le istruzioni in esso contenute dopo l'aggiornamento del pacchetto e prima di riavviare. L'ultima versione di tale file è reperibile all'indirizzo ; lo si consulti in caso di problemi. Conflitto tra i driver tulip e dfme Su alcuni Netra (p.e. sul Netra X1) udev carica entrambi i driver tulip e dfme, che dichiarano di supportare gli stessi ID PCI (). Il driver tulip è quello giusto per Netra. Se ciò accade, si dovrebbe mettere in blacklist il dfme-driver e riavviare, e/o rimuovere sia dmfe sia tulip (con modprobe -r) e quindi caricare con modprobe soltanto tulip. ]]> Preparazione per il prossimo rilascio Prima dell'aggiornamento vi sono diverse cose che si possono fare per preparare per il prossima rilascio. Se si sta utilizzando /etc/kernel-img.conf e si corregga l'ubicazione del programma /sbin/update-grub in /usr/sbin/update-grub. Se il nuovo metapacchetto dell'immagine del kernel è stato incluso come dipendenza del vecchio, esso sarà marcato come automaticamente installato, il che andrebbe corretto: # aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1) Si rimuovano i metapacchetti di kernel di &oldreleasename; con: # aptitude purge kernel-image-2.6-<flavor> Si spostino le opzioni di configurazione da /etc/network/options a /etc/sysctl.conf. Si consulti per i dettagli il file /usr/share/doc/netbase/README.Debian. Si rimuovano i pacchetti obsoleti e non utilizzati come descritto in . Si dovrebbe controllare quali file di configurazione utilizzano e considerare l'opportunità di effettuare un "purge" dei pacchetti per rimuovere i loro file di configurazione. Pacchetti deprecati Con il rilascio di Lenny saranno resi deprecati un maggior numero di pacchetti per server, dunque aggiornare ora a versioni più nuove di essi salverà da problemi chi aggiornerà poi a Lenny. Ciò include i seguenti pacchetti: apache (1.x), cui subentra apache2; bind8, cui subentra bind9; php4, cui subentra php5; postgresql-7.4, cui subentra postgresql-8.1; exim 3, cui subentra exim4. Pacchetti obsoleti Introducendo svariate migliaia di nuovi pacchetti, &releasename; ritira e tralascia al tempo stesso più di duemila vecchi pacchetti che erano in &oldreleasename;; non fornisce più aggiornamenti per tali pacchetti obsoleti. Mentre nulla impedisce che si continui ove lo si desideri ad utilizzare un pacchetto obsoleto, il progetto Debian interromperà solitamente il supporto per la sicurezza per lo stesso un anno dopo il rilascio di &releasename;O per il tempo in cui non vi sia un altro rilascio in quel lasso di tempo. Tipicamente in un dato momento sono supportati soltanto due rilasci stabili., e non fornirà normalmente nel frattempo altro supporto. Si raccomanda di sostituirlo con le alternative disponibili, se ve ne sono. Vi sono molte ragioni per cui dei pacchetti potrebbero essere stati rimossi dalla distribuzione: non sono più mantenuti a monte; non c'è più uno sviluppatore Debian interessato al mantenimento dei pacchetti; la funzionalità che forniscono è stata superata da altro software (o da una nuova versione); o non sono più considerati idonei per &releasename; a causa di bug in essi. Nell'ultimo caso, i pacchetti potrebbero tuttavia essere presenti nella distribuzione “unstable”. Determinare quali pacchetti sono “obsoleti” in un sistema aggiornato è semplice, visto che le interfacce di gestione dei pacchetti li marcheranno come tali. Se si sta usando aptitude, si vedrà un elenco di tali pacchetti alla voce “Pacchetti Obsoleti e Creati Localmente”. dselect fornisce una sezione simile ma l'elenco che presenta potrebbe differire. Inoltre, se si è utilizzato aptitude per installare manualmente dei pacchetti in &oldreleasename;, esso avrà tenuto traccia di quei pacchetti che si sono installati manualmente e potrà marcare come obsoleti quei pacchetti introdotti dalle sole dipendenze che non sono più necessari se un pacchetto è stato rimosso. In più, aptitude, diversamente da deborphan, non marcherà come obsoleti pacchetti che siano stati installati manualmente, al contrario di quelli che siano stati installati automaticamente attraverso dipendenze. Vi sono strumenti aggiuntivi che si possono usare per trovare pacchetti obsoleti come deborphan, debfoster o cruff. deborphan è altamente raccomandato, anche se (nella modalità predefinita) avvertirà solamente di librerie obsolete: i pacchetti nelle sezioni “libs” o “oldlibs” che non sono utilizzati da alcun altro pacchetto. Non si rimuovano a occhi chiusi i pacchetti che tali strumenti indicano, specialmente se si stanno utilizzando opzioni aggressive non predefinite che tendono a produrre falsi positivi. È altamente raccomandata una revisione manuale dei pacchetti di cui è suggerita la rimozione (p.e. contenuti, grandezza e descrizione) prima della rimozione stessa. Il fornisce spesso informazioni aggiuntive sul perché un determinato pacchetto è stato rimosso. Si dovrebbero visionare sia i rapporti per il pacchetto stesso sia i rapporti archiviati dei bug per lo . Pacchetti virtuali Alcuni pacchetti di &oldreleasename; sono stati suddivisi in diversi pacchetti in &releasename;, spesso per migliorare la manutenibilità del sistema. Per facilitare in tali casi il percorso di aggiornamento, &releasename; fornisce spesso pacchetti “virtuali”: pacchetti vuoti che hanno il medesimo nome del pacchetto in &oldreleasename; con dipendenze che causano l'installazione dei nuovi pacchetti. Tali pacchetti “virtuali” sono considerati pacchetti obsoleti dopo l'aggiornamento e possono essere rimossi in tutta sicurezza. Le descrizioni della maggior parte dei pacchetti virtuali (ma non di tutti) indicano il loro scopo. Le descrizioni dei pacchetti per i pacchetti virtuali non sono comunque uniformi, sicché si potrebbe anche trovare utile deborphan con l'opzione --guess per individuarli nel proprio sistema. Si noti che alcuni pacchetti virtuali non sono concepiti per la rimozione dopo un aggiornamento ma sono, invece, utilizzati per tenere traccia della versione attualmente disponibile di un programma nel tempo.Problematiche di cui bisogna essere al corrente per &releasename; Problemi potenziali A volte i cambiamenti hanno effetti collaterali che non possiamo ragionevolmente evitare, o si espongono bug presenti altrove. Documentiamo qui le problematiche di cui siamo al corrente. Si leggano anche le errata, la documentazione dei pacchetti interessati, le segnalazioni di bug e le altre informazioni menzionate in . Problemi con i dispositivi correlati a udev Sebbene /dev/video e /dev/radio). e /etc/udev. Alcune applicazioni potrebbero non funzionare più con un kernel 2.4 Alcune applicazioni in &releasename; potrebbero non funzionare più con un kernel 2.4, ad esempio perché necessitano del supporto a Un esempio è il proxy HTTP ]]> Alcuni siti del network non possono essere raggiunti tramite TCP Dal rilascio 2.6.17, Linux utilizza in modo aggressivo il TCP window scaling specificato in RFC 1323. Alcuni server hanno un comportamento scorretto, e annunciano per se stessi dimensioni di finestra errate. Per maggiori dettagli, si vedano i bug , e Vi sono solitamente due trucchi per aggirare questi problemi: o riportare le dimensioni massime consentite per le finestre TCP a un valore inferiore (l'opzione da preferire) o disattivare completamente il TCP window scaling (sconsigliato). Si vedano i comandi d'esempio nella . Lo spegnimento automatico smette di funzionare Su alcuni vecchi sistemi, shutdown -h potrebbe non spegnere più il sistema (ma soltanto fermarlo). Questo accade poiché vi si deve usare apm. L'aggiunta di acpi=off apm=power_off alla riga di comando del kernel, p.e. nei file di configurazione di . ]]> Aggiornamenti più lenti dei file degli indici dei pacchetti per APT Di default, la version di apt in &releasename; utilizza un nuovo modo di aggiornare i file degli indici dei pacchetti per APT (quando si esegue Acquire::Pdiffs "false"; al file di configurazione /etc/apt/apt.conf. Questo cambiamento interessa soprattutto gli utenti dei rami Supporto ad ACPI disabilitato per alcuni modelli di portatili HP nel kernel &releasename; Alcuni modelli di portatili HP hanno un BIOS ACPI incompatibile con il kernel Linux 2.6.18 fornito in &releasename;, che impedirebbe alle ventole di entrare in funzione, causando un inutile stress termico. Le ventole potrebbero inoltre non funzionare dopo la sospensione del sistema. Il kernel disabilita quindi il supporto ad ACPI internamente quando rileva alcune versioni di BIOS ACPI. I modelli che si sanno essere interessati da questo cambiamento comprendono i modelli HP nx6125, nx6120, nx6325, nc6120 e nc6000. Gli utenti che necessitano del supporto di ACPI su tali sistemi potrebbero installare un kernel Linux 2.6.19 o successivo, Si vedano per maggiori informazioni le segnalazioni di Debian e , e i bug del kernel Linux e . ]]> L'inizializzazione asincrona della rete potrebbe causare comportamenti imprevedibili Su sistemi che utilizzano /etc/init.d/networking sia eseguito all'avvio del sistema. Sebbene l'inclusione di /etc/network/interfaces (in aggiunta a Problemi con l'utilizzo di reti senza fili con dispositivo di sicurezza WPA In &oldreleasename;, il pacchetto /etc/default/wpasupplicant e un file /etc/wpasupplicant.conf fornito dall'utente. In &releasename;, /etc/init.d/wpasupplicant è stato eliminato ed il pacchetto di Debian si integra ora con /etc/network/interfaces, in modo simile ad alttri pacchetti come Per informazioni circa la configurazione di wpasupplicant si faccia riferimento al file /usr/share/doc/wpasupplicant/README.modes.gz, che fornisce esempi di file /etc/network/interfaces. Si possono reperire informazioni aggiornate riguardo l'utilizzo del pacchetto . ]]> Problemi con caratteri non-ASCII nei nomi dei file Montando filesystem vfat, ntfs o iso9660 con file che comprendono caratteri non-ASCII nei loro nomi si avranno insuccessi quando si cercherà di utilizzare i nomi dei file, a meno che li si monti con l'opzione utf8. Un'indicazione potrebbe essere l'errore seguente: "Invalid or incomplete multibyte or wide character". Si noti che il kernel Linux non supporta una gestione non case-sensitive dei nomi dei file per vfat quando è utilizzata l'opzione utf8. Corruzione dei dati con hardware IOMMU su chipset Nvidia È stato identificato un problema su sistemi &arch-title; con chipset Nvidia e più di 3 GB di RAM che causa sporadicamente corruzione dei dati quando si utilizza l'hardware IOMMU. Tale problema è ancora sotto investigazione da parte degli sviluppatori del kernel Linux e dei produttori dell'hardware, e non è stata rilasciata alcuna correzione ufficiale upstream. Per proteggere l'integrità dei propri dati, gli utenti di tali sistemi sono invitati a disabilitare manualmente l'utilizzo di hardware IOMMU all'avvio aggiungendo iommu=soft alle loro opzioni di avvio del kernel finché non possa essere trovata una corretta soluzione. Sono disponibili maggiori informazioni circa questa problematica nel bug di Debian e nel bug del kernel Linux . ]]> Il suono smette di funzionare In rari casi il suono potrebbe smettere di funzionare dopo l'aggiornamento. Se ciò accade, si segua la checklist di alsa: si esegua alsaconf come utente root, si utilizzi alsamixer e ci si assicuri che i livelli siano alzati e non ci sia il mute, ci si accerti che arts o esound siano fermi, ci si accerti che i moduli per OSS non siano caricati, ci si accerti che le casse siano accese, si verifichi che il comando cat /dev/urandom > /dev/dsp da root funzioni. Aggiornamento ad un kernel 2.6 La serie di kernel 2.6 contiene importanti cambiamenti rispetto alla serie 2.4. I moduli sono stati rinominati e molti driver sono stati parzialmente o a volte quasi completamente riscritti. L'aggiornamento ad un kernel 2.6 non è dunque un processo da intraprendersi con leggerezza. Questa sezione mira a mettere l'utente al corrente di alcune delle problematiche che potrebbero incontrare. Se si compila il proprio kernel dai sorgenti, ci si assicuri di installare Se si usa Se il file /etc/modules (la lista dei moduli che devono essere caricati durante l'avvio del sistema) non è vuoto, si sappia che alcuni nomi di moduli potrebbero essere cambiati. In tal caso si dovrà aggiornare il file con i nuovi nomi dei moduli. Con alcuni controller per dischi SATA, il nome del file device assegnato ad un supporto ed alle sue partizioni potrebbe cambiare da /dev/hdX a /dev/sdX. In tal caso si dovrà modificare il proprio /etc/fstab e la configurazione del bootloader in modo di rispecchiare il cambiamento. Se tali modifiche non sono effettuate correttamente, il sistema potrebbe non avviarsi correttamenteAvvierà il kernel ma non riuscirà a montare il filesystem radice ed abortirà con un errore waiting for root filesystem seguito da unable to mount /dev/hdX ..not found. Si può usare la shell di /dev/disk/.. ]]> I sistemi HP Itanium che eseguono vecchi firmware sono incompatibili con il kernel 2.6 in &oldreleasename;. Ciò significa che si dovrebbe aggiornare il proprio sistema all'ultimo firmware prima di aggiornare il kernel. Si raccomanda di fare ciò prima dell'aggiornamento del sistema, poiché se si sta già facendo girare un kernel 2.6 si otterrà automaticamente l'ultimo kernel con l'aggiornamento del resto del sistema (si veda ). Se ciò non va a buon fine ci si ritroverà con un sistema che non si avvia. ]]> Una volta installato il proprio kernel 2.6, ma prima di riavviare, ci si assicuri di avere un metodo di ripristino. Per prima cosa ci si assicuri che la configurazione del bootloader contenga voci sia per il nuovo kernel sia per il vecchio kernel 2.4 funzionante. Ci si dovrebbe anche assicurare di avere un dischetto floppy o CD-ROM di “soccorso” a portata di mano, da utilizzare nel caso in cui una errata configurazione del bootloader impedisse di fare avviare il vecchio kernel. Configurazione della tastiera Il cambiamento più invasivo nei kernel 2.6 è una fondamentale modifica del livello di input. Tale modifica fa apparire tutte le tastiere come tastiere “normali” da PC. Ciò significa che se si ha attualmente selezionato un tipo diverso di tastiera (p.e. una tastiera USB-MAC o Sun) si finirà molto probabilmente con l'avere dopo il riavvio con il nuovo kernel 2.6 una tastiera non funzionante. Se si può avere accesso tramite SSH da un altro sistema, si può risolvere questo problema con l'esecuzione di dpkg-reconfigure console-data, scegliendo l'opzione “Scegliere la mappa della tastiera dalla lista completa” e selezionando una tastiera “da pc”. Se la tastiera è interessata da questo problema, si avrà probabilmente bisogno di riconfigurare la tastiera anche per l'X Window System. Lo si può fare o eseguendo dpkg-reconfigure xserver-xorg o modificando direttamente il file /etc/X11/xorg.conf. Non ci si dimentichi di leggere la documentazione a cui si fa riferimento in . Questa problematica non dovrebbe interessare l'architettura &arch-title; dal momento che tutte le tastiere PS/2 e la maggior parte delle tastiere USB saranno riconosciute come tastiera “normale” da PC. ]]> Si noti che se si sta utilizzando una tastiera USB essa potrebbe essere configurata o come tastiera “normale” da PC o come tastiera USB-MAC. Nel primo caso non si sarà interessati dalla problematica descritta. ]]> Configurazione del mouse Sempre a causa dei cambiamenti nel livello di input, si potrebbe aver bisogno di riconfigurare l'X Window System e Se attualmente si ha X configurato per /dev/sunmouse, sarà probabilmente necessario cambiare tale voce in /dev/psaux ]]> Configurazione del suono Per la serie di kernel 2.6 si raccomandano i driver del suono ALSA rispetto ai più datati driver del suono OSS. I driver del suono ALSA sono sempre forniti. Perché il suono funzioni, si debbono caricare i moduli ALSA appropriati per la propria scheda audio. Ciò avverrà in generale automaticamente se si ha installato, in aggiunta al pacchetto alsa-base, o il pacchetto hotplug o il pacchetto discover. Il pacchetto alsa-base dovrebbe anche bloccare i moduli OSS per impedire che hotplug e discover li carichino. Se si hanno moduli OSS elencati in modules, li si dovrebbe rimuovere. ]]> ]]> Transizione da XFree86 a X.Org La transizione a X.Org coinvolge alcuni cambiamenti strutturali. Nel caso in cui tutti i pacchetti installati provengano da Debian e sono anche inclusi in &releasename;, l'aggiornamento dovrebbe funzionare senza problemi. Tuttavia l'esperienza ha mostrato che vi sono alcuni cambiamenti di cui bisogna essere al corrente, dal momento che essi possono potenzialmente causare problematiche durante l'aggiornamento. Il cambiamento più importante risiede nel fatto che /usr/X11R6/bin non esiste più se non come link simbolico a /usr/bin. Ciò significa che la directory deve essere vuota quando vengono installati nuovi pacchetti. I nuovi pacchetti confliggono con la maggior parte dei pacchetti che utilizzavano /usr/X11R6/bin, ma in alcuni casi potrebbe essere necessario un intervento manuale. Ci si ricordi di non aggiornare la distribuzione da una sessione di X. Nel caso in cui l'aggiornamento fallisca durante l'installazione di X.Org, si dovrebbe verificare se siano ancora rimasti file in /usr/X11R6/bin. Si può quindi usare dpkg -S per trovare quale pacchetto Debian ha installato un eventuale file, e rimuovere tali pacchetti con dpkg --remove. Ci si annoti quali pacchetti si rimuovono, così da potere più tardi installare i pacchetti che li sostituiscono. Prima di proseguire con l'aggiornamento, è necessario rimuovere tutti i file in /usr/X11R6/bin. Per maggiori dettagli e per altre problematiche, si legga . Se si incontrano problemi con X.org dopo il riavvio, potrebbe valere la pena di riavviare il server dei font: /etc/init.d/xfs restart. Questo accade quando /etc/X11/fs/xfs.options contiene una riga con no-restart-on-upgrade, ma i percorsi dei font sono cambiati. Nessun supporto per display a 8 bit in molte applicazioni Dopo l'aggiornamento di Xorg e delle ultime librerie, i terminali X che possono rappresentare colori soltanto con una profondità di 8 bit non funzioneranno. Questo perché la librerie di grafica vettoriale 2D Cairo ( I sistemi che si sanno essere interessati da ciò comprendono alcune macchine Sun e terminali per X di Tektronix, NCD, IBM and SGI, nonché alcuni altri sistemi a finestre X remoti. Si dovrebbero configurare tali terminali perché utilizzino colori a 16 bit, ove possibile. Maggiori informazioni sono disponibili nel di Freedesktop. Aggiornamento da exim a exim4 Uno dei pacchetti che sono stati resi obsoleti dal rilascio &releasename; è il Mail Tranfer Agent (MTA) Si noti che, a seconda della propria configurazione di I pacchetti di sul Wiki di Debian, e si può trovare il file README all'indirizzo , oltre che all'interno dei pacchetti. Il file README ha un capitolo riguardante la pacchettizzazione, che spiega le differenti variazioni che offriamo per il pacchetto, ed ha un capitolo riguardante l'aggiornamento da Aggiornamento di apache2 Apache è stato aggiornato alla nuova versione 2.2. Per quanto ciò non dovrebbe avere un impatto sull'utente medio, vi sono alcune potenziali problematiche di cui occorre essere al corrente. contiene i cambiamenti a monte. Si legga tale pagina, e ci si ricordi in special modo che: tutti i moduli devono essere ricompilati; i moduli di autorizzazione sono stati riordinati e rinominati; alcune opzioni di configurazione sono state rinominate. I cambiamenti specifici per Debian comprendono il fatto che la stringa SSL non è più definita, poiché il pacchetto di default supporta ora ssl. Se si sta utilizzando il MPM sperimentale ITK (dal pacchetto # cd /etc/apache2/mods-enabled # rm cgid.conf cgid.load # ln -s ../mods-available/cgi.load . # /etc/init.d/apache2 force-reload Aggiornamento di Zope e Plone Zope e tutti i prodotti relativi sono stati aggiornati. Molti prodotti sono anche stati eliminati dalla distribuzione (o perché erano divenuti obsoleti, o perché sono incompatibili con il nuovo Zope, CMF o Plone). Sfortunatamente, non vi è un modo facile e garantito per aggiornare un complesso server Per tale ragione, si raccomanda agli utenti di impostare i sistemi così che possano continuare ad eseguire l'installazione di &oldreleasename; di Zope/Plone insieme con le nuove versioni di &releasename; mentre testeranno la migrazione. Il modo più facile e veloce per ottenere ciò e quello di fare una copia del sistema &oldreleasename; su un altro disco fisso o partizione, e quindi aggiornare soltanto una delle due copie. Si può quindi utilizzare Non è possibile avere la versione vecchia e quella nuova di Zope/Plone installate insieme su un sistema &releasename; in parte perché il vecchio pacchetto dipende da Espansione delle wildcard ("globbing") con GNU tar Le precedenti versioni di GNU tar xf foo.tar '*.c' estrarrebbe tutti i file il cui nome termina con ".c". Tale comportamento non era documentato, ed era incompatibile con implementazioni tradizionali di Per maggiori informazioni, si legga il file /usr/share/doc/tar/NEWS.gz. NIS e Network Manager La versione di Ciò può essere fatto o disinstallando il pacchetto /etc/default/nis per aggiungere L'utilizzo di Configurazioni insicure di php rese deprecate Per molti anni si è saputo essere insicuro e pericoloso attivare l'impostazione A partire da questo rilascio, il team di sicurezza di Debian non fornisce il supporto di sicurezza a una quantità di configurazioni di PHP che si sanno essere insicure. In particolar modo non si risponderà più a problematiche derivanti dall'attivazione di Se si eseguono vecchie applicazioni che necessitano di README.Debian.security nella directory della documentazione di PHP (/usr/share/doc/php4, /usr/share/doc/php5). Stato della sicurezza dei prodotti Mozilla I programmi Mozilla firefox e thunderbird (rimarchiati in Debian rispettivamente iceweasel e icedove) sono strumenti importanti per molti utenti. Sfortunatamente la politica di sicurezza degli autori è di spingere gli utenti ad aggiornare a nuove versioni fornite dagli autori stessi, il che contrasta con la politica di Debian di non immettere grosse modifiche funzionali negli aggiornamenti di sicurezza. Non possiamo prevederlo oggi, ma durante il ciclo di vita di &releasename; il gruppo per la sicurezza di Debian potrebbe giungere a un punto in cui non sia più possibile supportare i prodotti Mozilla ed annunciare la fine del supporto di sicurezza per i prodotti Mozilla. Si dovrebbe tenere in considerazione ciò al momento di impiegare Mozilla e considerare le alternative disponibili in Debian se l'assenza del supporto di sicurezza dovesse costituire un problema. Desktop KDE La gestione dei media in KDE è cambiata nella versione disponibile in &releasename; passando dall'utilizzo di device:/ all'utilizzo di media:/. Ad alcune configurazioni di utenti potrebbero essere stati aggiungi link device:/, cosicché li si dovrebbe adattare. Si noti il fatto che ~/.kde/share/apps/konqsidebartng/virtual_folders/services contiene tale riferimento e può essere eliminato senza problemi dal momento che non sarà più creato con l'impostazione di nuovi utenti. Vi sono stati molti cambiamenti nell'ambiente desktop KDE dalla versione rilasciata in &oldreleasename; alla versione in &releasename;, è possibile trovare maggiori informazioni nelle (in lingua inglese). Cambiamenti nel desktop GNOME e supporto Se si è utilizzato il desktop GNOME in &oldreleasename;, si beneficerà ora di alcuni dei cambiamenti introdotti nella configurazione predefinita in Debian per &releasename;. In alcuni casi estremi il desktop GNOME potrebbe non gestire correttamente la vecchia configurazione e potrebbe comportarsi in modo non corretto. Se non si è pesantemente investito nella configurazione del desktop GNOME si potrebbe voler dare alla directory .gconf nelle directory home degli utenti un nome differente (come .gconf.old) così che esso venga nuovamente creato, con la configurazione predefinita per &releasename;, all'avvio di una nuova sessione. Con il rilascio di &releasename;, Debian non contiene più pacchetti per la maggior parte dell'obsoleto rilascio 1 di GNOME, sebbene alcuni pacchetti rimangono alfine di supportare alcuni pacchetti di Debian che non sono stati aggiornati a GNOME 2. I pacchetti per GTK1.2 rimangono pienamente mantenuti. Vi sono stati molti cambiamenti nell'ambiente desktop GNOME dalla versione uscita in &releasename;, è possibile trovare maggiori informazioni nelle (in lingua inglese). Editor predefinito Se si sta utilizzando Amministratori che desiderino cambiare l'editor predefinito per tutti gli utenti dovranno aggiornare il sistema delle alternative con: # update-alternatives --config editor Utenti che desiderino cambiare l'editor predefinito possono definire la variabile d'ambiente EDITOR introducendo le seguenti righe nei propri profili: EDITOR=vi export EDITOR alias editor=$EDITOR Messaggio del giorno /etc/motd è ora ricreato da /etc/init.d/bootmisc.sh a partire da un template, /etc/motd.tail, ad ogni riavvio. Ciò significa che modifiche apportate a /etc/motd saranno perse. Modifiche fatte in /etc/motd.tail non sono applicate automaticamente a /etc/motd in fasi differenti dal riavvio. Unicode non supportato di default in emacs21* emacs21 e emacs21-nox non sono configurati per utilizzati Unicode per default. Per maggiori informazioni e per come aggirare il problema si veda il . Maggiori informazioni su &debian; Letture aggiuntive Oltre al presente documento e alla guida all'installazione, ulteriore documentazione su &debian; è disponibile da parte del Debian Documentation Project (DDP), il cui scopo è di creare documentazione di alta qualità per gli utenti e gli sviluppatori di Debian. È disponibile una documentazione che comprende la Guida Debian, la Guida per il nuovo Maintainer, le FAQ di Debian, e molto altro. Per un completo dettaglio delle risorse esistenti si consulti il . La documentazione per i singoli pacchetti viene installata sotto /usr/share/doc/pacchetto. Ciò comprende informazioni di copyright, questioni specifiche di Debian ed ogni documentazione a monte. Come ottenere aiuto Ci sono molti posti dove gli utenti Debian possono ottenere aiuto, notizie e supporto, ma si dovrebbe tenerne conto solamente se la ricerca nella documentazione sull'argomento ha esaurito tutte le risorse. La presente sezione fornisce una breve introduzione a risorse che potrebbero risultare d'aiuto per i nuovi utenti Debian. Liste di messaggi Le mailing list di maggior interesse per gli utenti Debian sono la lista debian-user (in inglese) e le liste di utenti nelle varie lingue, debian-user-. Prima di inviare un messaggio si cerchino negli archivi le risposte alla propria domanda, e comunque si ponga cura nell'osservare la “netiquette” standard delle liste. Internet Relay Chat Debian ha un canale IRC dedicato al supporto e all'aiuto agli utenti di Debian sulla rete IRC OFTC. Per accedere al canale, ci si colleghi con il proprio client IRC preferito a &debian-irc-server; e si acceda al canale #debian (il canale italiano di supporto è rimasto sulla rete IRC Freenode, #debian-it, NdT). Si prega di seguire le linee guida del canale, nel pieno rispetto degli altri utenti. Le linee guida sono disponibili sul . Per maggiori informazioni su OFTC si visiti il . Rapporti sui bug Facciamo ogni sforzo per rendere Debian GNU/Linux un sistema operativo di alta qualità; ciò non significa tuttavia che i pacchetti che forniamo siano totalmente esenti da problemi. Coerentemente con la filosofia dello “sviluppo aperto” di Debian e come nostro servizio per i nostri utenti, forniamo sul nostro sistema di tracciamento dei bug (BTS, Bug Tracking System) tutte le informazioni disponibili sui bug scoperti. Il BTS è consultabile all'indirizzo . Se si trova un bug nella distribuzione o in un software pacchettizzato che ne fa parte, si è pregati di segnalarlo, in modo che possa essere opportunamente risolto per i rilasci futuri. Per la segnalazione dei bug è richiesto un indirizzo e-mail valido. Chiediamo ciò per poter tenere traccia dei bug e perché gli sviluppatori possano mettersi in contatto con gli autori delle segnalazioni nel caso fossero necessarie maggiori informazioni. Si può segnalare un bug utilizzando il programma reportbug o utilizzando l'e-mail manualmente. Si possono ottenere maggiori informazioni sul Bug Tracking System e su come utilizzarlo leggendo le schede di riferimento (disponibili presso /usr/share/doc/debian se si ha installato doc-debian) o in linea presso il . Fornire il proprio contributo a Debian Non è necessario essere degli esperti per contribuire a Debian. Assistendo gli utenti con i problemi che espongono sulle varie di supporto per gli utenti, si fornisce un contributo alla comunità. Identificare (ed anche risolvere) problemi relativi allo sviluppo della distribuzione attraverso la partecipazione alle per lo sviluppo è un'altra attività estremamente utile. Per mantenere l'alta qualità della distribuzione Debian si possono , in modo di aiutare gli sviluppatori a tenerne traccia e correggerli. Se si è portati per il testo, si potrebbe voler fornire più attivamente un contributo aiutando a scrivere la o nella propria lingua la documentazione esistente. Se si ha più tempo da dedicare, si può provvedere alla gestione di un pezzo della collezione di Software Libero contenuta in Debian. È particolarmente utile che delle persone adottino o mantengano elementi che altre persone hanno richiesto di includere in Debian. I dettagli a tal proposito si trovano nel . Se si ha un interesse verso qualche area specifica, si potrebbe essere interessati a fornire un contributo a qualcuno fra i sottoprogetti di Debian, che comprendono port ad architetture particolari, e . In ogni caso, se si sta lavorando all'interno della comunità del software libero in un qualunque ambito, come utente, programmatore, scrittore o traduttore, si sta già dando un contributo. Contribuire è remunerativo e divertente, ed oltre a permettere di incontrare nuove persone dà quella certa sensazione interiore di benessere... Gestione del proprio sistema &oldreleasename; Quest'appendice contiene informazioni su come assicurarsi la possibilità di installare o aggiornare pacchetti di &oldreleasename; prima di aggiornare a &releasename;. Questo dovrebbe essere necessario soltanto in specifiche situazioni. Aggiornamento del proprio sistema &oldreleasename; In linea di massima non c'è niente di diverso da ogni altro aggiornamento di &oldreleasename; si sia fatto. La sola differenza è che bisogna prima assicurarsi che la lista dei pacchetti contenga ancora pacchetti di &oldreleasename;, come spiegato in . Se si aggiorna il proprio sistema utilizzando un mirror di Debian, esso sarà automaticamente aggiornato all'ultimo rilascio minore di &oldreleasename;. Controllo della lista delle fonti Se una delle righe del proprio /etc/apt/sources.list fa riferimento a "stable", si sta effettivamente già “utilizzando” &releasename;. Se si è già eseguito apt-get update, si può comunque tornare indietro senza problemi seguendo la procedura sotto indicata. Se si sono già installati pacchetti da &releasename;, probabilmente non ha più molto senso installare pacchetti da &oldreleasename;. In questo caso si dovrà decidere se si vuole continuare o no. È possibile il “downgrade” dei pacchetti, ma non è un argomento coperto in questa sede. Si apra il file /etc/apt/sources.list con il proprio editor preferito (come root) e si esaminino tutte le righe a cominciare da deb http: o deb ftp: cercando un riferimento a “ Se vi sono righe che cominciano con deb file:, si deve controllare da sé se gli indirizzi cui si riferiscono contengono un archivio di &oldreleasename; o di &releasename;. deb cdrom:. Facendolo si invaliderebbe la riga e si dovrebbe eseguire nuovamente Se si sono fatte delle modifiche, si salvi il file e si esegua # apt-get update per rinnovare la lista dei pacchetti.