Upgrade prehistorycznego Ubuntu

Na jednej z pomocniczych maszyn pozostało mi stareńkie Ubuntu 9.04. Aktualizacja do bieżącej wersji wiązała się z kilkoma komplikacjami, dlatego zanotuję.

Zwykłe upgrade nie działa

Standardowa metoda dla tej wersji już nie działa:

$ sudo do-release-upgrade

Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tool
Done downloading            
extracting 'lucid.tar.gz'
authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg'
tar: Removing leading `/' from member names

Reading cache

Checking package manager

Can not upgrade

An upgrade from 'jaunty' to 'lucid' is not supported with this tool.

Komunikat błędu jest lakoniczny ale powody są dość logiczne – Ubuntu nie obsługuje upgrade z przeskokiem (poza aktualizacjami między kolejnymi LTS) a bezpośredni następca 9.04 (czyli 9.10) zakończył żywot i został już zdjęty z serwerów pakietów.

Przejście na 9.10

Działa inna technika aktualizacji: przy pomocy obrazu CD. Skoro konieczne było przejście 9.04 → 9.10, pobrałem plik ubuntu-9.10-alternate-i386.iso z http://old-releases.ubuntu.com/releases/karmic/, zapisałem na aktualizowanej maszynie i zamontowałem go jako system plików:

$ sudo mkdir /media/cdrom
$ sudo mount -o loop ~/ubuntu-9.10-alternate-i386.iso /media/cdrom

Po powyższym standardowo przebiegającą aktualizację uruchamiłem prostym

$ /media/cdrom/cdromupgrade

Na pytanie, czy używać sieci, odpowiedziałem n, następnie cały proces przebiegł standardowo, po końcowym reboocie wstała wersja 9.10.

Aktualizacja przy pomocy alternate-cd może być warta rozważenia także w normalnych warunkach (dla bieżących dystrybucji) – jeden duży download często przebiega szybciej niż seria małych a późniejsza instalacja nie jest opóźniana pobieraniem pakietów.

Przejście na 10.04

Przejście 9.10 → 10.04 jest już supportowane, zatem

# do-release-upgrade 
Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tool
Done downloading            
extracting 'lucid.tar.gz'
authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg' 
tar: Removing leading `/' from member names

Reading cache

Checking package manager
Reading package lists: Done
Reading state information: Done

(…)

Do you want to start the upgrade? 

4 packages are going to be removed. 90 new packages are going to be 
installed. 560 packages are going to be upgraded. 

You have to download a total of 444M. This download will take about 
56 minutes with a 1Mbit DSL connection and about 17 hours with a 56k 
modem. 

Fetching and installing the upgrade can take several hours. Once the 
download has finished, the process cannot be cancelled. 

 Continue [yN]  Details [d]d
 Continue [yN]  Details [d]y

Fetching
[66%] 146kB/s 17min 1s s 3s   

Proces trwał, trwał i … ostatecznie zawisł po pobraniu ok. 90% danych. Przegląd logów (te trafiają do /var/log/dist-upgrade) pozwolił znaleźć notki takie, jak

WARNING updateStatus: dlFailed on 'http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-4.4/libstdc++6-4.4-dev_4.4.3-4ubuntu5.1_i386.deb' 

Ponowna próba do-release-upgrade zakończyła się tym samym, a ręczne pobranie pliku:

# cd /var/cache/apt/archives
# wget http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-4.4/libstdc++6-4.4-dev_4.4.3-4ubuntu5.1_i386.deb

powiodło się ale doprowadziło do ponownego zwisu na jednym z dalszych pakietów.

Trochę dla zasady spróbowałem

# apt-get -d dist-upgrade

(opcja -d oznacza download only, tj. nakazuje pobrać pakiety bez instalacji). Polecenie działało dość powoli ale skutecznie dociągnęło serię brakujących plików.

Problemy z ściąganiem wybranych plików były niemal na pewno związane z specyfiką firmowego proxy HTTP ale pewna nauczka z całej sytuacji jest interesująca ogólnie: do-release-upgrade ściąga pliki inaczej niż apt-get upgrade i to drugie może zadziałać, gdy to pierwsze ma problemy.

Później do-release-upgrade poszło już bez komplikacji (nie musząc już niczego dociągać).

Przeszedłem typową serię pytań (konflikty w konfiguracji, o ile były złożone, głównie notowałem do przejrzenia po upgrade) i proces instalacji przeszedł bez większych zakłóceń.

(...)
System upgrade is complete.

Restart required 

To finish the upgrade, a restart is required. 
If you select 'y' the system will be restarted. 

Continue [yN] 

W tym momencie popełniłem błąd – wcisnąłem y bez weryfikacji stanu plików konfiguracyjnych gruba. Maszyna nie wstała.

Tradycyjne problemy z konfiguracją gruba

Na szczęście miałem możliwość skorzystania z webowej konsoli która natychmiast potwierdziła moje pierwsze podejrzenia: problem dotyczył konfiguracji gruba,

a następnie pozwoliła rozwiązać problem (reboot, wciśnięcie Esc w celu wyświetlenia menu gruba i e w celu edycji parametrów w trakcie startu, zamiana root=numeryczne-id na na root=/dev/sda1, wciśnięcie b w celu startu z zmienionymi parametrami).

Po uruchomieniu przejrzałem /boot/grub/menu.lst, zmieniłem

# kopt=root=UUID=bf7c79e9-c177-4ea1-9790-e40f6aff144c ro

na

# kopt=root=/dev/sda1 ro

uruchomiłem

# update-grub

i uzyskałem działający system.

Powyższe to wariant dla 10.04, w nowszych Ubuntu należy w celu pozbycia się UUID w pliku /etc/default/grub odkomentować lub dodać

GRUB_DISABLE_LINUX_UUID=true

(a następnie, jak zwykle, uruchomić update-grub)

Na koniec jeszcze

# apt-get clean

(zwolnienie miejsca w /var przez skasowanie niepotrzebnej już masy plików .deb).

Dygresja o UUID

Pomysł identyfikowania partycji przy pomocy UUID stosowany jest od paru lat i w konfiguracji gruba, i przy opisywaniu montowanych filesystemów w /etc/fstab, i w paru bardziej zaawansowanych zastosowaniach. Zasadniczo jest bardzo trafny i skuteczny: taka konfiguracja jest niewrażliwa na zmiany kolejności dysków (po przepięciu kabli czy dołożeniu nowego urządzenia) czy zmiany numerów partycji, a z odnajdywaniem urządzeń praktycznie nie ma problemów.

Niestety problemy zdarzają się z drugiej strony: w trakcie tworzenia, konwersji i aktualizacji plików konfiguracyjnych, skrypty instalacyjne potrafią wpisywać niewłaściwe UUID. O ile na desktopach zazwyczaj wszystko jest dobrze, o tyle przy pracy na różnego typu wirtualnych partycjach (ten przykład dotyczył dysku Vmware, miewałem też podobne problemy przy wykorzystaniu linuksowego RAID i LVM) w konfiguracji gruba i/lub fstab potrafią pojawić się nieodpowiednie identyfikatory.

Rozwiązaniem jest rutynowe sprawdzanie: polecenie

$ sudo blkid

wypisuje na ekran identyfikatory wszystkich dostępnych partycji. Następnie wystarczy sprawdzić, czy numerki wpisane przez upgrade do /etc/fstab i konfiguracji gruba (/boot/grub/menu.lst w starszych, /boot/grub/grub.cfg w nowszych wersjach) odpowiadają właściwym partycjom.

10.04 → 12.04

12.04 ciągle jest jeszcze betą ale dopieszczanie dotyczy głównie komponentów desktopowych, część serwerowa jest raczej stabilna (a z bety do wersji finalnej to po prostu rutynowa aktualizacja pakietów). Ponieważ maszyna tak czy siak wymagała przeglądu konfiguracji wszystkich aplikacji, zdecydowałem się nie robić tego dla 10.04 ale przejść od razu na 12.04.

Tym razem

# do-release-upgrade -d

(-d zezwala na instalację wersji przedpremierowej) przeszło niemal bez problemów.

Jedyny kłopot dotyczył starej wersji PostgreSQLa:

An unresolvable problem occurred while calculating the upgrade: 
The package 'postgresql-contrib-8.3' is marked for removal but it is 
in the removal blacklist. 

przy czym nie pomogło i usunięcie powyższego pakietu:

An unresolvable problem occurred while calculating the upgrade: 
The package 'postgresql-8.3' is marked for removal but it is in the 
removal blacklist. 

Musiałem zrobić upgrade postgresowej bazy danych do pośredniej wersji:

# apt-get install postgresql-8.4
# pg_dropcluster --stop 8.4 main
# pg_upgradecluster 8.4 main
# pg_dropcluster 8.3 main
# dpkg --remove postgresql-8.3 postgresql-client-8.3

(pierwotnie miałem nadzieję pominąć 8.4 i przejść od razu na 9.1, jako że baza jest niewielka, machnąłem jednak ręką).

Ubuntu stosuje (za Debianem) bardzo rozsądną metodę aktualizowania PostgreSQL: nowe wersje mogą bezproblemowo koegzystować ze starszymi (np. można doinstalować 8.4 nie usuwając 8.3 i nawet uruchamiać obie wersje naraz) a przeniesienie baz danych jest osobną operacją którą wykonujemy w odpowiednio wybranym czasie po instalacji. Dystrybucyjne pg_upgradecluster po prostu robi dump starej bazy i odtwarza go w nowej wersji (co jest dobrą techniką przy relatywnie niedużych bazach i gdy dopuszczalny jest pewien okres niedostępności), w trudniejszych przypadkach można stosować inne techniki.

Problem z wyliczeniem upgrade pod obecność 8.3 jest jakoś uzasadniony (8.3 to wersja historyczna w sytuacji, w której przechodzimy między Ubuntu Lucid zawierającym PostgreSQL 8.4 a Ubuntu Precise z jego 9.1) ale i tak wygląda na usterkę.

Po aktualizacji Postgresa do-releaseupgrade -d zadziałało już bez żadnych problemów i zakończyło udanym uruchomieniem 12.04.

Porządki poinstalacyjne

... objęły:

• kolejne upgrade Postgresowej bazy (z 8.4 do 9.1),

• przegląd zanotowanych konfliktów w konfiguracjach programów,

• rutynowe przejrzenie (a następnie usunięcie) wszelkich plików *.dpkg-new, *.dpkg-old, *.ucf-dist i *.ucf-old w /etc

Pliki new lub dist powstają, gdy w trakcie upgrade na pytanie o obsługę konfliktu nakażę zachować poprzednią konfigurację jakiegoś programu, wówczas w xxxxxx pozostaje to, co tam wcześniej było (i co nie musi pasować do aktualnej wersji programu) a w xxxxxx.dpkg-new jest wzorcowa wersja maintainera.

Analogicznie pliki old powstają, gdy na pytanie o konflikt konfiguracji nakażę wgrać wersję maintainera. Wówczas xxxxxx zawiera wersję z dystrybucji (nie dostosowaną do lokalnych potrzeb) a xxxxxx.dpkg-old to moja poprzednia konfiguracja.

W obu wypadkach mam do dyspozycji starą indywidualnie dopieszczoną konfigurację dostosowaną do starej wersji programu i nową wersję maintainera, przeglądam je (zaczynając od zrobienia diffa) i tworzę nowy plik konfiguracyjny.

• faktyczne testy wszystkich istotnych aplikacji uruchomionych na maszynie (począwszy od wysyłki testowego maila i testowe zapytania na kluczowych bazach danych, przez przeklikanie wszystkich aplikacji a po weryfikację działania skryptów robiących backupy i pomocniczych cronjobów).