[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ successivo ]
Suggeriamo che prima di aggiornare si leggano anche le informazioni in Problematiche di cui bisogna essere al corrente per etch, Capitolo 5. Tale capitolo copre potenziali problematiche non direttamente collegate al processo di aggiornamento, ma che potrebbe comunque essere importante conoscere prima di cominciare.
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 su o
sudo per ottenere i diritti di accesso necessari.
L'aggiornamento ha alcune precondizioni: le si dovrebbe verificare prima di espletare effettivamente l'operazione.
È saggio informare in anticipo tutti gli utenti di qualunque aggiornamento si
stia pianificando, sebbene gli utenti che accedono al sistema tramite una
connessione ssh non dovrebbero notare granché durante
l'aggiornamento, e dovrebbero poter continuare a lavorare.
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 etch si dovrà anche fare un aggiornamento del kernel, cosicché sarà normalmente necessario riavviare. Tipicamente, questo sarà fatto dopo la fine dell'aggiornamento.
A causa dei molti cambiamenti nel kernel tra sarge e etch 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 ssh è
altamente raccomandato che si prendano le necessarie precauzioni per poter
accedere al server tramite un terminale seriale remoto. Vi è il rischio che,
dopo l'aggiornamento del kernel e il riavvio, alcuni dispositivi siano
rinominati (come descritto in Riordino della
numerazione dei dispositivi, Sezione 4.6.4) 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 chroot per investigare e correggere il problema.
Un'altra opzione di cui vorremmo raccomandare l'utlizzo è quella di usare la
modalità di ripristino (rescue mode) dell'Installatore Debian di etch.
Il vantaggio di utilizzare l'installatore è che si può scegliere fra i suoi
molti metodi di installazione quello che meglio si adatta alla situazione. Per
maggiori informazioni si consultino la sezione "Recupero di un sistema
danneggiato" nel capitolo 8 della Guida
all'Installazione e le FAQ dell'Installatore
Debian.
initramfs-tools include una shell di debug[6] 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 dmesg per errori nel caricamento dei driver. L'output
di dmesg mostrerà anche quali file device sono stati assegnati a
quali dischi; si dovrebbe verificare ciò rispetto all'output di echo
$ROOT per accertarsi che il filesystem radice sia sul dispositivo
atteso.
Se si riesce a risolvere il problema, digitando exit si uscirà della shell di debug e il processo di avvio riprenderà dal punto in cui il problema è incorso. Naturalmente si dovrà anche risolvere il problema a monte e rigenerare l'initrd così che il prossimo avvio non fallisca nuovamente.
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 ssh.
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 screen, che consente la riconnessione sicura
ed assicura che il processo di aggiornamento non sia interrotto anche qualora
il processo di connessione remota si interrompa.
Importante! Non si dovrebbe effettuare
l'aggiornamento utilizzando telnet, rlogin,
rsh, o da una sessione di X gestita da xdm,
gdm o kdm etc. sulla macchina che si sta
aggiornando. Questo perché ciascuno di tali servizi potrebbe essere terminato
durante l'aggiornamento, il che può risultare in un sistema
inaccessibile che si troverebbe aggiornato solo a metà.
Nel caso in cui si utilizzi un kernel precedente al 2.4.1, è necessario
aggiornare (almeno) alla serie 2.4 prima di aggiornare le glibc.
Ciò dovrebbe essere fatto prima di cominciare con l'aggiornamento. Si
raccomanda di aggiornare direttamente al kernel 2.6.8 disponibile in sarge,
anziché aggiornare ad un kernel 2.4.
Il processo di aggiornamento descritto nel presente capitolo è stato progettato
per aggiornamenti da sistemi sarge 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 (Transizione da XFree86 a X.Org, Sezione
5.3). 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 sarge. Se non lo si è fatto o non se ne è certi, si seguano le istruzioni in Aggiornamento del proprio sistema sarge, Sezione A.1.
In alcuni casi, l'utilizzo di apt-get per installare pacchetti in
luogo di aptitude potrebbe far sì che aptitude
consideri un pacchetto come "inutilizzato" e ne programmi la
rimozione. In generale, ci si dovrebbe assicurare che il sistema sia
completamente aggiornato e "pulito" prima di procedere con
l'aggiornamento.
A causa di ciò bisognerebbe controllare se vi sono azioni in sospeso nel
gestore dei pacchetti aptitude. Se di un pacchetto è programmata
la rimozione o l'aggiornamento nel gestore dei pacchetti, esso potrebbe avere
un impatto negativo sulla procedura di aggiornamento. Si noti che la
correzione è possibile soltanto se il file sources.list punta
ancora a sarge, e non a stable o a etch: si veda Controllo della lista delle fonti,
Sezione A.2.
Per fare questo, si dovrebbe eseguire l'interfaccia utente di
aptitude e premere 'g' ("Go"). Se questo visualizza
delle azioni, si dovrebbero controllare queste ultime e correggere o
implementare le azioni suggerite. Se non è suggerita alcuna azione sarà
presentato un messaggio che dice "No packages are scheduled to be
installed, removed, or upgraded".
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
apt_preferences(5).
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 dselect, aptitude, o comandi come
# 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 utilizza un metodo differente per registrare
i pacchetti tenuti bloccati rispetto ad apt-get e a
dselect. Si possono identificare pacchetti tenuti bloccati per
aptitude con
# aptitude search "~ahold" | grep "^.h"
Volendo controllare quali pacchetti sono bloccati per apt-get, si
dovrebbe utilizzare il comando
# 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 può essere cambiato con il comando:
# aptitude hold nome_del_pacchetto
Si sostituisca hold con unhold per rimuovere lo stato “bloccato”.
Se c'è bisogno di sistemare qualcosa, è sempre meglio assicurarsi che il
proprio sources.list faccia ancora riferimento a sarge come
spiegato in Controllo della lista
delle fonti, Sezione A.2.
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 etch 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 sono in Debian sarge. Tali pacchetti sono i primi candidati a causare problemi durante un aggiornamento, dal momento che essi potrebbero far risultare conflitti tra file[7]. La sezione Problematiche che potrebbero emergere durante l'aggiornamento, Sezione 4.5.8 contiene delle informazioni su come comportarsi di fronte a conflitti fra file nel caso in cui si dovessero verificare.
Per impedire ad aptitude di rimuovere alcuni pacchetti che sono
stati selezionati tramite dipendenze, li si dovrà smarcare manualmente come
pacchetti auto. Ciò comprende OpenOffice.org e Vim per installazioni
di desktop:
# 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 auto in aptitude eseguendo:
# aptitude search 'i~M <nome pacchetto>'
Prima di cominciare l'aggiornamento si deve predisporre per le liste dei
pacchetti il file di configurazione di apt,
/etc/apt/sources.list.
apt prenderà in considerazione tutti i pacchetti che possono
essere trovati tramite le righe “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. sarge, etch) 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.
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
http://www.debian.org/distrib/ftplist
(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 http://mirrors.kernel.org/debian/. Ispezionando tale mirror con un browser web o con un client FTP, si noterà che le directory principali sono organizzate nel modo seguente:
http://mirrors.kernel.org/debian/dists/etch/main/binary-alpha/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-alpha/...
Per utilizzare questo mirror con apt, si aggiungerà al proprio
file sources.list la seguente riga:
deb http://mirrors.kernel.org/debian etch 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
“deb” preesistenti in sources.list
ponendo davanti ad esse un simbolo 'cancelletto' (#).
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/etch/main/binary-alpha/...
/var/ftp/debian/dists/etch/contrib/binary-alpha/...
Per utilizzare questo mirror con apt, si aggiungerà al proprio
file sources.list la seguente riga:
deb file:/var/ftp/debian etch 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
“deb” preesistenti in sources.list
ponendo davanti ad esse un simbolo 'cancelletto' (#).
Se si vogliono utilizzare soltanto CD-ROM, si disabilitino,
commentandole, le righe “deb” preesistenti in
/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
(apt-cdrom richiede che il filesystem sia montato esattamente su
/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 nessuno spazio tra le parole 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.
Il metodo raccomandato per l'aggiornamento dai precedenti rilasci di Debian
GNU/Linux 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
"etch" o a "stable". Non vi
dovrebbero essere voci di fonti che puntino a sarge. Nota: le righe delle
fonti per un CD-ROM faranno spesso riferimento ad
"unstable"; sebbene ciò possa generare confusione,
non le si dovrebbe modificare.
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-etch.time -a ~/upgrade-etch.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 Alt-F2) e, dopo aver effettuato il log-in, utilizzare il comando less ~root/upgrade-to-etch.typescript per visionare il file.
Dopo aver completato l'aggiornamento, si può arrestare script
digitando al prompt exit.
Se si è utilizzato il parametro -t per script si può
utilizzare il programma scriptreplay per un replay dell'intera
sessione:
# scriptreplay ~/upgrade-etch.time ~/upgrade-etch.script
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.
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 Aggiornamento del resto del sistema, Sezione
4.5.6. 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, sia apt mostreranno informazioni
dettagliate sullo spazio su disco necessario per l'installazione. Prima di
eseguire effettivamente l'aggiornamento si può vedere questa stima con:
# 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.
[8]
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
popularity-contest installato, si può utilizzare
popcon-largest-unused per avere un elenco dei pacchetti che non si
utilizzano nel sistema che occupano la maggior quantità di spazio. Si può
anche utilizzare deborphan o debfoster per trovare
pacchetti obsoleti (si veda Pacchetti obsoleti, Sezione
4.10). In alternativa si può avviare aptitude in
"modalità visuale" e trovare pacchetti obsoleti sotto la voce
"Pacchetti obsoleti e creati localmente".
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 dpigs
(disponibile nel pacchetto debian-goodies) o con
wajig (eseguendo 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 sarge, come descritto in Controllo della lista delle fonti,
Sezione A.2.
A causa di alcuni necessari conflitti tra pacchetti tra sarge e etch, 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 libc6 e
locales e farà rientrare le librerie di supporto a SELinux
(libselinux1). A questo punto, alcuni servizi in esecuzione
saranno riavviati, inclusi xdm, gdm e
kdm. Di conseguenza saranno disconnesse le sessioni locali di
X11.
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
base-config, hotplug, xlibs,
netkit-inetd, python2.3, xfree86-common
e xserver-common. Per un elenco più completo di pacchetti resi
obsoleti in etch, si veda Pacchetti obsoleti, Sezione
4.10.
Questo percorso si aggiornamento è stato verificato funzionare su sistemi con
installato il task desktop di sarge. È 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 libfam0c102 e xlibmesa-glu installati:
# 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
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 xfree86-common installato,
compresi alcuni sistemi server che hanno task per server di
tasksel installati, dato che alcuni task comprendono strumenti di
gestione grafici. Sarà probabilmente il metodo corretto da utilizzare su
sistemi su cui è eseguito X, ma che non hanno il task desktop
completo installato.
# dpkg -l xfree86-common | grep ^ii
Si verifichi per prima cosa se si hanno i pacchetti libfam0c102 e
xlibmesa-glu installati.
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Se non si ha libfam0c102 installato, non si includa
libfam0 nella seguente riga di comando. Se non si ha
xlibmesa-glu installato, non lo si includa nella seguente riga di
comando.[9]
# aptitude install x11-common libfam0 xlibmesa-glu
Si noti che l'installazione di libfam0 installerà anche il File
Alteration Monitor (fam), nonché il RPC portmapper
(portmap), se non già disponibili nel sistema. Entrambi i
pacchetti abiliteranno un nuovo servizio di rete nel sistema, sebbene siano
entrambi configurati per essere collegati al dispositivo di rete (interno) di
loopback.
Su un sistema senza X, non dovrebbero essere richiesti comandi aptitude install aggiuntivi, e si può passare al passaggio successivo.
La versione di udev in etch non supporta versioni del kernel
precedenti alla 2.6.15 (fra cui i kernel 2.6.8 di sarge), e la versione di
udev in sarge non funzionerà correttamente con gli ultimi kernel.
Inoltre, l'installazione della versione di udev in etch forzerà la
rimozione di hotplug, utilizzato dai kernel Linux 2.4.
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 udev è stato aggiornato, ma
non è stato installato l'ultimo kernel. Se il sistema si dovesse riavviare a
questo punto, nel mezzo dell'aggiornamento, potrebbe non essere avviabile a
causa del non corretto rilevamento e caricamento dei driver. (Si veda Preparazione di un ambiente sicuro per
l'aggiornamento, Sezione 4.1.4 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 Installazione del metapacchetto del kernel, Sezione 4.6.1 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 udev, per cui vi è una finestra di tempo di durata non nota
in cui il sistema avrà il pieno supporto ad hotplug senza alcun
kernel installato. Si veda Aggiornare il kernel e i
pacchetti collegati, Sezione 4.6 per informazioni su come configurare il
proprio sistema perché non dipenda da hotplug per l'avvio.
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.
Dopo l'aggiornamento, con la nuova versione di apt si può ora
aggiornare le informazioni dei pacchetti, che comprenderanno il nuovo
meccanismo di verifica delle firme dei pacchetti:
# 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, apt stamperà avvertimenti relativi alla sua
incapacità di confermare che i pacchetti scaricati da esse siano legittimi e
non siano stati alterati. Per maggiori informazioni si veda Gestione dei pacchetti, Sezione
2.1.1.
Si noterà che, dal momento in cui si utilizza la nuova versione di
apt, esso scaricherà file di differenze di pacchetti
(pdiff) anziché la lista completa dei pacchetti. Per maggiori
informazioni su questa caratteristica si legga Aggiornamenti più lenti dei file
degli indici dei pacchetti per APT, Sezione 5.1.4.
Se un'operazione che utilizza aptitude, apt-get o
dpkg termina con l'errore
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
APT::Cache-Limit in /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 APT::Force-LoopBreak
perché APT possa rimuovere temporaneamente un pacchetto essenziale, per via di
un un circolo “è in conflitto con”/“pre-dipende da”.
Di norma aptitude emetterà un avviso e cesserà l'aggiornamento.
Si può evitare ciò specificando l'opzione -o
APT::Force-LoopBreak=1 nella riga di comando di aptitude.
C'è la possibilità che la struttura delle dipendenze di un sistema sia talmente
corrotta da richiedere un intervento manuale. Solitamente ciò significa usare
aptitude o
# 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 etch 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 aptitude descritti in precedenza.
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 .dpkg-old.
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 script.
Questa sezione spiega come aggiornare il kernel ed identifica potenziali
problematiche relative a tale aggiornamento. Si può o installare uno dei
pacchetti linux-image-* forniti da Debian, o compilare un kernel
personalizzato dai sorgenti.
Si noti che molte informazioni in questa sezione sono basate sull'assunzione
che si userà uno dei pacchetti modulari di Debian, insieme con
initramfs-tools e udev. Se si sceglie di usare un
kernel personalizzato che non richiede un initrd o se si utilizza un generatore
di initrd differente, alcune delle informazioni potrebbero non essere
attinenti.
Si noti poi che se udev non è installato sul sistema,
rimane possibile utilizzare hotplug per il rilevamento
dell'hardware.
Se si sta utilizzando un kernel 2.4, si dovrebbe anche leggere attentamente Aggiornamento ad un kernel 2.6, Sezione 5.2.
Allorché si effettua un dist-upgrade da sarge a etch, è 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
linux-image-2.6-686. 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 aptitude install per installarlo. Una volta che questo nuovo pacchetto è installato si dovrebbe avviare alla prossima opportunità che si presenta per beneficiare della nuova versione del kernel.
Per i più avventurosi, esiste un modo agevole per compilare il proprio kernel
personalizzato su Debian GNU/Linux. Si installi lo strumento
kernel-package e si legga la documentazione contenuta in
/usr/share/doc/kernel-package.
Se si sta attualmente facendo girare un kernel della serie 2.6 di sarge, questo aggiornamento avrà luogo automaticamente dopo un aggiornamento completo del sistema (come descritto in Aggiornamento dei pacchetti, Sezione 4.5).
Se possibile, conviene aggiornare il pacchetto del kernel separatamente dal dist-upgrade per ridurre le possibilità di ritrovarsi con un sistema temporaneamente non avviabile. Si veda Aggiornamento del kernel, Sezione 4.5.5 per una descrizione di tale processo. Si noti che ciò dovrebbe essere fatto soltanto dopo il processo di aggiornamento minimo descritto in Aggiornamento minimo del sistema, Sezione 4.5.4.
Si può anche comprendere questo passaggio se si sta usando il proprio kernel
personalizzato e si vuole utilizzare il kernel disponibile in etch. Se la
versione del proprio kernel non è supportata da udev, si
raccomanda l'aggiornamento completo dopo quello minimo. Se la versione è
supportata da udev si può attendere in sicurezza finché non sia
stato aggiornato l'intero sistema.
Se si ha un kernel 2.4 installato, e il sistema si affida a
hotplug per il rilevamento del suo hardware, si dovrebbe
preliminarmente aggiornare ad un kernel della serie 2.6 di sarge prima di
tentare l'aggiornamento. Ci si accerti che il kernel della serie 2.6 avvii il
sistema e che tutto l'hardware sia correttamente rilevato prima di effettuare
l'aggiornamento. Il pacchetto hotplug è rimosso dal sistema (a
favore di udev) quando si esegue un aggiornamento completo del
sistema. Se non si esegue l'aggiornamento del kernel prima di questo, il
sistema potrebbe di qui in avanti non avviarsi correttamente. Una volta
eseguito un aggiornamento ad un kernel della serie 2.6 in sarge si può eseguire
un aggiornamento del kernel come descritto in Aggiornamento da un kernel 2.6, Sezione 4.6.2.
Se il sistema non si affida a hotplug[10], si può rimandare
l'aggiornamento del kernel a dopo che si sia eseguito un aggiornamento completo
del sistema, come descritto in Aggiornamento del
resto del sistema, Sezione 4.5.6. 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>
etch 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 etch 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.rules[11]. In alternativa è possibile
utilizzare l'utility ifrename per collegare dispositivi fisici a
specifici nomi all'avvio. Per maggiori informazioni si vedano
ifrename(8) e iftab(5). 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
initramfs-tools e configurandolo perché carichi i driver dei
dispositivi di archiviazione nel medesimo ordine in cui sono attualmente
caricati. Per fare ciò, si identifichi l'ordine in cui i moduli di
archiviazione sul proprio sistema sono caricati guardando l'output di
lsmod. lsmod elenca i moduli nell'ordine inverso di
quello in cui sono stati caricati, p.e. il primo modulo della lista è l'ultimo
che è stato caricato.
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
sarge a etch. 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 etch e udev, si
può riconfigurare il proprio sistema perché acceda ai dischi tramite un alias
che non dipenda dall'ordine di caricamento dei driver. Tali alias risiedono
nella gerarchia /dev/disk/.
Se per l'avvio del sistema è utilizzato un initrd creato con
initramfs-tools, in alcuni casi la creazione dei file dei
dispositivi ad opera di udev può accadere troppo tardi perché gli
script di avvio possano agire su di essi.
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=9. Il valore per il timeout (in secondi) potrebbe necessitare un aggiustamento.
Quando aptitude dist-upgrade è giunto al termine, l'aggiornamento “formale” è concluso, ma vi sono alcune altre cose di cui ci si dovrebbe preoccupare prima del successivo riavvio.
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 etch.
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 #341152.
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 http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file;
lo si consulti in caso di problemi.
Prima dell'aggiornamento vi sono diverse cose che si possono fare per preparare per il prossima rilascio.
Se si sta utilizzando grub, si editi
/etc/kernel-img.conf e si corregga l'ubicazione del programma
update-grub modificando /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 sarge 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 Pacchetti obsoleti, Sezione 4.10. 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.
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.
Introducendo svariate migliaia di nuovi pacchetti, etch ritira e tralascia al tempo stesso più di duemila vecchi pacchetti che erano in sarge; 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 etch[12], 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 etch 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 sarge, 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 Sistema di tracciamento dei bug
(BTS) di Debian 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
pseudo-pacchetto
ftp.debian.org.
Alcuni pacchetti di sarge sono stati suddivisi in diversi pacchetti in etch, spesso per migliorare la manutenibilità del sistema. Per facilitare in tali casi il percorso di aggiornamento, etch fornisce spesso pacchetti “virtuali”: pacchetti vuoti che hanno il medesimo nome del pacchetto in sarge 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.
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ successivo ]
Note di Rilascio per Debian GNU/Linux 4.0 ("etch"), Alpha
$Id: release-notes.it.sgml,v 1.32 2007/08/10 15:34:46 jseidel Exp $debian-doc@lists.debian.orglucab83@infinito.it