From sarge to etch: cronaca di un dist--upgrade annunciato

Premessa

Questa cronaca si basa su due esperienze fatte per l'aggiornamento di due macchine casalinghe, sulle quali è installato Debian GNU/Linux e che andavano aggiornate dalla versione 3.1 alla versione 4.0.

Le due macchine si chiamano rispettivamente elaion e kubrick. Sulla prima ho fatto l'aggiornamento per vedere che danni riuscivo a combinare, sulla seconda ho ripetuto il tutto annotandomi i passi seguiti e le schermate di output che vedrete in questa cronaca. Buona lettura!

Scopo del gioco

Lo scopo di queste note e' quello di mostrare come effettuare l'aggiornamento di un sistema Debian Sarge sulla macchina kubrick alla nuova release candidata "stabile" che ha nome in codice "Etch". In sostanza aggiorniamo da Debian 3.1 a Debian 4.0

Replica della cache dei pacchetti

Per prima cosa ci allochiamo sulla macchina in questione e facciamo in modo da sfruttare, per le varie operazioni di aggiornamento, una cache dei pacchetti gia' presente su un altro sistema (elaion) per il quale e' gia' stato fatto in precedenza l'aggiornamento. Questo permette di velocizzare le cose e di risparmiare banda di rete, in quanto l'altro sistema si trova sulla stessa rete locale del nodo che si vuole aggiornare. Se il motivo di cio' non fosse ancora chiaro, basti pensare che un'aggiornamento di pacchetti da una release "stabile" ad una release "testing" per un sistema di tipo server, quindi senza molti fronzoli relativi ai desktop manager, comporta il download dalla rete di centinaia di megabyte di dati, il che non e' proprio agevole se si dispone di una connessione a banda limitata, come nel caso delle ADSL o peggio dei modem 56k (esiste ancora qualcuno che li usa...?).

fm@gridfm:~$ ssh fm@kubrick
Password:
Linux kubrick 2.6.8-15.k6.2.cic #1 Tue Dec 6 22:07:11 CET 2005 i586 GNU/Linux
                  _   _  _   _  ____   ____   _   ____  _   _
                 |_ _-  |_  |_ |_   - |_   - |_  -     |_ _-
Welcome to ..... |_-    |_  |_ |___-  |___-  |_ |-     |_-
                 |_-_   |_  |_ |_  -_ |_-_   |_ |-     |_-_
Have a good day! |_  -_  |___  |___-  |_  -_ |_  -____ |_  -_

No mail.

Last login: Mon Jan  1 09:42:06 2007 from 192.168.1.4

fm@kubrick:~$ mkdir cacheapt
fm@kubrick:~$ cd cacheapt/
fm@kubrick:~/cacheapt$ rsync -e ssh -avzp fm@elaion:/var/cache/apt/archives/ .
Password:

receiving file list ... done
./
adduser_3.100_all.deb
afterstep_2.2.2-2_i386.deb
...

Come si nota, per sincronizzare la cache remota con una lista locale di file, utilizziamo il comando rsync su protocollo ssh, che non fa altro che fare una copia dei file simile a quanto avviene con il comando scp, con la differenza che si occupa di copiare solo i file che sono stati aggiunti/variati nella locazione remota rispetto a quelli nella directory locale.

Eseguo il comando da utente normale, poi mi alloco come superutente per popolare la cache effettiva dei pacchetti del sistema:

fm@kubrick:~/cacheapt$ su -
Password:
kubrick:~# cd /var/cache/apt/archives/
kubrick:/var/cache/apt/archives# cp /home/fm/cacheapt/* .
kubrick:/var/cache/apt/archives# cd

Aggiornamento della release corrente

A questo punto possiamo procedere con le operazioni di aggiornamento, che prevedono dapprima l'aggiornamento dei pacchetti della release corrente alle ultime versioni, e poi le fasi che descriveremo in seguito:

kubrick:~# apt-get update
Ign file: debs/ Release
Get:1 http://security.debian.org stable/updates/main Packages [421kB]
...
Fetched 421kB in 23s (18.0kB/s)
Reading Package Lists... Done
kubrick:~# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded:
  gzip imagemagick info libapache2-mod-php4 libdevmapper1.01 libdps1 libfreetype6 libgcc1 libgnutls11 libice6
  libmagick6 libmysqlclient14 libmysqlclient14-dev libsm6 libssl0.9.7 libx11-6 libxaw7 libxext6 libxft1 libxi6 libxmu6
  libxmuu1 libxp6 libxpm4 libxrandr2 libxt6 libxtrap6 libxtst6 mozilla-firefox mysql-client-4.1 mysql-common-4.1
  mysql-server-4.1 openssl php4-cli php4-common php4-gd php4-imap php4-ldap php4-mcal php4-mhash php4-mysql php4-odbc
  php4-pear php4-recode php4-snmp php4-sybase ssh tar xfree86-common xlibs xlibs-data xutils
52 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 27.3MB/50.2MB of archives.
After unpacking 713kB of additional disk space will be used.
Do you want to continue? [Y/n] y

come si vede, il fatto di aver usato la cache di un altro sistema, anche se non configurato in maniera proprio identica, ha portato a risparmiare il download di circa la meta' dei 50 MB di pacchetti necessari per aggiornare il sistema...

OK facciamo andare questo aggiornamento e nel frattempo concediamoci una fetta di panettone

Adesso abbiamo un sistema "sarge" up-to date, pronto per essere aggiornato ad "etch".

Modifica dei repository

Il passo successivo da fare e' quello di cambiare gli indirizzi dei repository dei pacchetti modificando il file /etc/apt/sources.list

Prima delle modifiche avevamo:

deb http://security.debian.org/ stable/updates main contrib non-free
deb ftp://ftp.it.debian.org/debian/ sarge main contrib non-free

mentre dopo, le due righe precedenti diventano:

deb http://security.debian.org/ etch/updates main contrib non-free
deb ftp://ftp.it.debian.org/debian/ etch main contrib non-free

Inoltre se nel file /etc/apt/apt.conf vi fosse una riga del tipo:

APT::Default-Release "sarge";

essa andrebbe aggiornata di conseguenza.

Inizio aggiornamento ad etch

Possiamo ora aggiornare il database dei pacchetti in modo che rispecchi quello della nuova release:

kubrick:~# apt-get update
Ign file: debs/ Release
...
Fetched 5840kB in 1m15s (77.4kB/s)
Reading Package Lists... Done

e quindi procedere all'upgrade dei pacchetti:

kubrick:~# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back:
  adduser anacron apache2 apache2-mpm-prefork apache2-utils apt apt-utils aptitude at base-passwd bash bc binutils
  bsdmainutils bsdutils bzip2 console-common console-tools coreutils cpio cpp cpp-3.3 cron curl cvs debhelper
...
The following packages will be upgraded:
  apache2-doc asr-manpages autoconf automake1.4 autotools-dev base-files console-data debconf debconf-i18n
...
62 upgraded, 0 newly installed, 0 to remove and 249 not upgraded.
Need to get 16.0MB/42.3MB of archives.
After unpacking 3662kB disk space will be freed.
Do you want to continue? [Y/n] y

come si nota, anche in questo caso gran parte dei pacchetti da aggiornare vengono presi dalla cache locale che abbiamo provveduto a popolare in precedenza, ed il download dalla rete e' limitato a 16 MB di dati, su un totale di 42 MB...

Con questo upgrade vengono aggiornati solo quei pacchetti che non hanno dipendenze critiche derivanti dal passaggio alla nuova versione. Ad esempio pacchetti di documentazione, o manpages etc...

Il fatto di procedere all'aggiornamento in piu' passi puo' costituire un vantaggio, dal momento che se qualcosa va storto si limitano i danni.... Ma questo non significa che qualcosa debba andare storto... dopo tutto Debian e i suoi sistemi di aggiornamento sono infallibili, non e' vero?

Aggiornamento del kernel

Il passo successivo sarebbe quello di lanciare il comando:

apt-get dist-upgrade

ed incrociare le dita.... Tuttavia molti in rete consigliano di lanciare prima l'aggiornamento del kernel e poi procedere con il dist-upgrade (a dire la verità anche nelle release notes di etch alla data odierna --2-1-2007-- non viene presa una posizione netta su come sia giusto procedere). Tutto cio' sempre nella logica di procedere per passi all'aggiornamento della distribuzione, ed anche per un motivo che andiamo di seguito ad illustrare...

Il kernel di default della "Etch" ha numero di versione 2.6.18. Il pacchetto relativo richiede le libc6, le quali vanno in conflitto con gli "initrd-tools", che potrebbero essere richiesti affinche' un kernel 2.6.8 (quello di default di Sarge) possa rimanere installato sul sistema (ovviamente cio' non vale se non si usa initrd per l'avvio). Conseguenza: se tentiamo di installare un kernel 2.6.18 su un sistema che usa un kernel 2.6.8 ed un disco ram iniziale per il caricamento dei moduli, APT tentera' di rimuovere i pacchetti di tutti i kernel 2.6.8 installati sul sistema che facciano uso degli initrd-tools, compreso quello in uso! APT avvisa che questa puo' essere una operazione catastrofica....

Questo e' quanto mi e' capitato sul sistema elaion al quale stavo facendo l'aggiornamento e che aveva un kernel installato preso dai repository ufficiali di sarge (tali kernel usano un disco ram iniziale, detto anche initrd, per fare in modo da poter essere adatti alla maggior parte dei sistemi su cui andra' a girare. Il disco ram iniziale, infatti contiene niente altro che moduli del kernel per i piu' disparati dispositivi hardware...)

Dopo aver squadrato in lungo e in largo il problema, non ho trovato altra soluzione se non quella di accettare la disinstallazione del pacchetto del kernel in uso e lasciar fare l'aggiornamento al nuovo kernel, riservandomi di riavviare il sistema immediatamente dopo... Si intuisce che questa operazione e' abbastanza critica, in quanto se dovesse essere interrotta per qualche motivo... le conseguenze potrebbero essere davvero catastrofiche per il sistema. Ma per mia fortuna tutto e' andato liscio

Ritornando al nostro sistema kubrick, oggetto di questa cronaca, va detto che esso utilizza un kernel 2.6.8 ma che mi sono compilato dai sorgenti ufficiali debian. E nel fare questo ho omesso la creazione del disco ram iniziale, che e' abbastanza inutile per un kernel compilato per una sola macchina. Il pacchetto risultante quindi NON dipende dagli initrd-tools e quindi non dovrebbe verificarsi la situazione di criticita' descritta per la mia precedente esperienza di aggiornamento. Posso procedere allora con piu' tranquillita' all'installazione del nuovo kernel.

kubrick:~# apt-get install kernel-image-2.6-686
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  busybox initramfs-tools klibc-utils libc6 libc6-dev libklibc libselinux1 libsepol1 libvolume-id0 linux-image-2.6-686
  linux-image-2.6.18-3-686 locales lsb-base module-init-tools tzdata udev
Suggested packages:
  linux-doc-2.6.18 grub
Recommended packages:
  libc6-i686
The following packages will be REMOVED:
  base-config hotplug
The following NEW packages will be installed:
  busybox initramfs-tools kernel-image-2.6-686 klibc-utils libklibc libselinux1 libsepol1 libvolume-id0
  linux-image-2.6-686 linux-image-2.6.18-3-686 lsb-base tzdata udev
The following packages will be upgraded:
  libc6 libc6-dev locales module-init-tools
4 upgraded, 13 newly installed, 2 to remove and 245 not upgraded.
Need to get 0B/29.6MB of archives.
After unpacking 55.0MB of additional disk space will be used.
Do you want to continue? [Y/n] y

Come si nota, questa volta APT non incontra problemi di dipendenze che coinvolgono il kernel attualmente in uso, dal momento che esso non fa uso di un disco ram iniziale. Quindi APT NON tenta di rimuovere il pacchetto del kernel che si sta usando.

Questa volta inoltre non e' necessario scaricare nemmeno un byte dai repository in rete

...
Setting up linux-image-2.6-686 (2.6.18+5) ...
Setting up kernel-image-2.6-686 (2.6.18+5) ...

OK tutto sembra andato per il meglio. Riavviamo con il nuovo kernel prima di procedere al restante upgrade dei pacchetti...

kubrick:~# reboot

Al riavvio notiamo subito che qualcosa e' cambiato. Il messaggio di issue in console presenta un bel:

Debian GNU/Linux 4.0 kubrick tty1

kubrick login:

invece del "vecchio" numero di versione 3.1 che aveva la Sarge.

Completamento degli upgrade

Adesso non mi resta che riallocarmi come utente root e completare l'operazione di aggiornamento tramite il comando:

kubrick:~# apt-get dist-upgrade

che installa le nuove versioni dei restanti pacchetti, affinche' possiate avere un sistema 'etch' nuovo fiammante!

Considerazioni finali

Infine aggiungo una piccola nota: ad essere sinceri il nuovo kernel 2.6.18 non funzionava "out of the box" cosi' come scaricato dai repository. Infatti esso presentava un problema di compatibilita' con il mio processore (AMD K6 II a 400 Mhz). Il problema deriva dal fatto che il pacchetto del kernel che ho utilizzato, ovvero linux-image-2.6-686, viene compilato di default con il supporto SMP abilitato. Questo fatto non influisce sul funzionamento con processori di classe pentium ma crea problemi se si va ad utilizzare questo kernel su processori con architettura 486 od anche AMD K6. Per aggirare questo problema si puo' installare l'apposito pacchetto del kernel linux-image-2.6-486, che risulta essere compilato senza il supporto SMP.

FrancescoLovergine: in alternativa si può aggiungere nosmp come argomento di boot.

Tuttavia ho preferito scaricare i sorgenti e ricompilarli ottimizzando per AMD K6 II, disabilitando l'uso del disco ram iniziale ed aggiustando alcune altre cosette.

Alla prossima!

Bibliografia

Release Notes for Debian GNU/Linux 4.0 ("etch"), Intel x86

Debian Reference

-- FrancescoMinafra - 02 Jan 2007