Parę dni temu Debian ogłosił wydanie nowego stabilnego wydania o nazwie kodowej Buster. Skoro aktualizacja do Buster stała się możliwa, zacząłem ją natychmiast, ale dopiero teraz mogę nieco o niej napisać.
Przede wszystkim, pospieszyłem się. Szóstego lipca tylko zerknąłem na newsy i… pomyliłem poprzedniego newsa, dotyczącego wydania wersji 9.9 z wydaniem Bustera. Co prawda rzecz działa się już w trakcie wydawania (co widać było na Twitterze), ale zrobiłem lekki falstart.
Lekko zdziwił mnie brak release notes (zasługa falstartu). Ale większość rzeczy mam odseparowanych w kontenerach LXC, więc aktualizacje powinny proste, poza tym, który to już raz? Wziąłem na warsztat przy kawie jedną maszynkę fizyczną i kontenery LXC na niej. Kontenery poszły od kopa w stylu apt-get update && apt-get upgrade && apt-get update && apt-get dist-upgrade. Nie jest to zalecany sposób – w release notes jest napisane, by korzystać z apt. Nie wiedziałem o tym i… nie miało to znaczenia.
Aktualizacja hypervisora również gładka, kontrolny reboot i… kontenery się nie podnoszą. Co prawda apt-listchanges (polecam!) pisał, że LXC 3 got some significant changes from LXC 2, ale pozwoliłem zmienić konfigurację do nowej wersji, stosowane brakujące linie też były dodane. Wyszukiwarka nie pomagała, ludzie na kanale też nie. Z szybkiego upgrade od kawy zrobiła się godzinna walka z debugiem. Okazało się, że czyste, nowe kontenery z Busterem z minimalnym konfigiem także nie startują (error w loglevel INFO, hmm…):
# create lxc-create -n test3 -t download -- -d debian -r buster -a amd64 # run lxc-start -n test3 -l debug -o /tmp/debuuug.txt # logs tail -n 8 /tmp/debuuug.txt lxc-start test3 20190706132233.984 NOTICE start - start.c:start:2037 - Exec'ing "/sbin/init" lxc-start test3 20190706132233.985 NOTICE start - start.c:post_start:2048 - Started "/sbin/init" with pid "8584" lxc-start test3 20190706132233.985 NOTICE start - start.c:signal_handler:430 - Received 17 from pid 8582 instead of container init 8584 lxc-start test3 20190706132233.985 DEBUG lxccontainer - lxccontainer.c:wait_on_daemonized_start:830 - First child 8580 exited lxc-start test3 20190706132233.999 DEBUG start - start.c:signal_handler:447 - Container init process 8584 exited lxc-start test3 20190706132233.999 INFO error - error.c:lxc_error_set_and_log:49 - Child <8584> ended on error (255) lxc-start test3 20190706132233.999 DEBUG network - network.c:lxc_delete_network:3180 - Deleted network devices lxc-start test3 20190706132234.152 INFO conf - conf.c:run_script_argv:356 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "test3", config section "lxc"
O dziwo kontenery w wersji ze Squeeze startowały. Doraźnie wróciłem w kontenerach do Squeeze (z backupu, nie downgrade) i na pewien czas zostawiłem sprawę. Mimo, że okazało się, że startują dość kulawo. Nie podnosiła się sieć ani nie uruchamiały usługi, trzeba to było robić ręcznie po każdym restarcie kontenera. Niefajne, ale do czasu znalezienia rozwiązania docelowego można wytrzymać, tym bardziej, że restarty są rzadkością.
Ostatecznie właśnie problemy ze startem i porównanie działania LXC na innym, świeżym hypervisorze z Buster, gdzie wszystko działało bez problemu naprowadziły mnie na rozwiązanie. Przy diagnostyce przy pomocy systemctl status otrzymywałem komunikat:
System has not been booted with systemd as init system (PID 1). Can't operate
Rozwiązaniem okazało się przejście na systemd i odinstalowanie pakietów związanych ze starym systemem init (niestety nie zapisałem nazw). IIRC na hypervisorze i w kontenerach. Po tym zabiegu wszystko działa poprawnie i startuje automatycznie, zarówno ze Squeeze w kontenerach, jak i po aktualizacji do Bustera.
Nie zaktualizowałem jeszcze wszystkich maszyn[1], ale z godnych odnotowania zmian – kontener generujący Planetę Joggera dostał aktualzację do Bustera bezpośrednio z Jessie zresztą[2]. Z działaniem na Squeeze był problem, na wersji testowej czy unstable także wtedy nie działało. Na szczęście jest już poprawione, co oznacza, że planeta ma szansę istnieć kolejne parę lat.
Ogólnie póki co aktualizacja całkiem przyjemna i prosta, o ile się ma systemd.
UPDATE: Na ostatnim serwerze napotkałem kolejny problem – skrypty w Pythonie korzystające z virtualenv przestały działać. Rozwiązanie łatwe do znalezienia po wpisaniu komunikatu – trzeba usunąć i utworzyć virtualenv na nowo. Dotyczyło zarówno Pythona 2 jak i Pythona 3.
[1] Został jeden serwer i jakieś desktopy na których akurat nie mam unstable i RPi robiące za router. Trochę boję się go zdalnie aktualizować, bo to zdalny system i nie mam żadnej alternatywnej łączności.
[2] Aktualizacja z przeskokiem wersji nie jest zalecanym sposobem. Jednak skoro to tylko okrojony kontener, który mogę w każdej chwili przywrócić z backupu, to czemu by nie spróbować?
