Upgrade na serwerze do Ubuntu 9.10

Bieda

Krzywdę zrobiłem sobie (a raczej mekk.waw.pl-owi) bezmyślnie akceptując w trakcie do-release-upgrade sugestię zainstalowania gruba na głównej partycji (czyli na wirtualnym dysku mojego linode). Mea culpa, choć - jeśli dobrze pamiętam -wyrazisty warning o ryzykowności instalacji gruba na partycji pojawił się już ... po wykonaniu się tej operacji.

Upgrade zakończyło się rebootem a po reboocie system nie wstał. A lishowa konsola pokazała błędy wskazujące na problemy z rozpoznawaniem partycji.

Ratunek

Po chwili jałowych kombinacji (reboot w single mode, reboot z inną wersją jądra) ochłonąłem, przypomniałem sobie, że mam parę gigabajtów nie wykorzystanego dysku i po prostu (przy pomocy interfejsu webowego linode) zadeployowałem dystrybucję (Ubuntu 9.10) od nowa (na nowy wirtualny dysk).

Do powstałej konfiguracji dopiąłem jako pomocnicze wszystkie stare dyski (/home i /database tak samo jak dotychczas, stary root pod nową literkę) i nakazałem reboot do niej.

System wstał - co oczywiście nie było szczególnie zaskakujące, było to równoważne robieniu nowego VPSa.

Następnie spróbowałem ręcznie podmontować stary root (mnt /dev/xvde /mnt). Uff. Podmontował się poprawnie. Inne partycje - także. Wszystkie dane pozostały.

Nie byłem pewien czy z wnętrza VPSa uda mi się gruba posprzątać, przeniosłem zatem dane (na /mnt stary root, na / nowy):

rsync --progress  -axH /mnt/var/ /var/
rsync --progress  -axH /mnt/usr/ /usr/
rsync --progress  -axH /mnt/opt/ /opt/
rsync --progress  -axH /mnt/root/ /root/
rsync --progress  -axH /mnt/srv/ /srv/
rsync --progress  -axH /mnt/lib/ /lib/
rsync --progress  -axH /mnt/bin/ /bin/
rsync --progress  -axH /mnt/sbin/ /sbin/
rsync --progress  -axH /mnt/etc/ /etc/

Kopiowałem po jednym katalogu, a nie całość, bo wolałem przenoszenie /lib, /bin, /sbin i /etc zostawić na koniec, nie chciałem też - profilaktycznie - przenosić /boot.

Reboot, chwila niepokoju i ... system wstał, zamykając przygodę na nieco ponad godzinie niedostępności. Zostaje jeszcze do skasowania stary dysk root, ale to zrobię za parę dni, gdy upewnię się, że o niczym nie zapomniałem.

W tym wszystkim plusik dla Linode za dostępne w webowym interfejsie narzędzia, dzięki którym mogłem sobie poradzić sam (stworzyć nowego roota z preinstalowaną dystrybucją, ustalić jak mają zostać udostępnione poszczególne dyski, robić rebooty, korzystać z awaryjnej konsoli) bez szukania pomocy adminów.

Gdybym nie miał wolnego dysku ... też miałbym szanse sobie poradzić - webowy interfejs pozwala na zmiany rozmiaru wirtualnych dysków, mógłbym zatem wygospodarować potrzebne miejsce zmniejszając stare urządzenia.

A na koniec Linode przysłało mi maila o niepokojąco dużym disk io rate.

Wnioski

Co mogłem zrobić lepiej i co mogę zrobić, by takich problemów w przyszłości uniknąć?

Cóż - uważać. mekk.waw.pl nie jest serwisem na tyle ważnym, by był wart redundancji, testowania procedur administracyjnych przed wykonaniem czy utrzymywania skryptów reanimujących system od zera.

Trochę się zastanawiam nad wypróbowaniem przy następnej okazji pełzającego upgrade z wykorzystaniem stworzonego na chwilę - przez sklonowanie - drugiego VPSa.

Obserwacje o upgrade

Samo upgrade niczego nie zepsuło (tj. wszystkie potrzebne mi programy działają nadal, pojawił się Postgres 8.4 ale Postgres 8.3 też jest dostępny i nadal działa nie wymuszając natychmiastowego upgrade) ... z jednym drobnym wyjątkiem. Z niewiadomych przyczyn w /etc/default/memcached pojawiło się ENABLE_MEMCACHED=no i memcached przestało startować. Trywialne do poprawienia ale dziwne.