[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ dalej ]


Uwagi do wydania Debian GNU/Linux 4.0 ("etch"), PowerPC
Część 4 - Upgrade z poprzednich wydań


4.1 Przygotowanie aktualizacji

Zalecamy przed aktualizacją przeczytać także informację Kwestie, o których warto wiedzieć mając etch, Część 5. Ten rozdział opisuje potencjalne problemy niebezpośrednio związane z procesem upgrade'u. Wiedza o nich jest jednak ważna przed rozpoczęciem tego procesu.


4.1.1 Zrób kopię wszelkich danych i informacji konfiguracyjnych

Przed aktualizacją systemu zdecydowanie zalecamy zrobienie pełnej kopii zapasowej (backup) albo przynajmniej najważniejszych danych i zbiorów konfiguracyjnych, które nie powinny zostać utracone. Narzędzia aktualizujące są zasadniczo niezawodne, ale wszelkie awarie sprzętowe w czasie aktualizacji mogą spowodować poważne uszkodzenie systemu.

The main things you'll want to back up are the contents of /etc, /var/lib/dpkg, /var/lib/aptitude/pkgstates and the output of dpkg --get-selections "*" (the quotes are important).

Proces aktualizacji nie wprowadza modyfikacji w katalogu /home. Jednak niektóre aplikacje (np. programy Mozilla suite, środowiska GNOME czy KDE) nadpisują ustawienia użytkowników nowymi wartościami w momencie pierwszego użycia przez użytkownika. Profilaktycznie można zrobić kopie plików i katalogów ukrytych ("dotfiles") z katalogów domowych użytkowników. Pozwoli to na ewentualne odzyskanie starych ustawień. Można też poinformować o tym użytkowników.

Operacje instalacji pakietów muszą być wykonywane z uprawnieniami superużytkownika, czyli że musisz zalogować się jako root lub też użyć su lub sudo, aby otrzymać odpowiednie uprawnienia.

Aktualizacja ma kilka warunków wstępnych, powinieneś sprawdzić je przed wykonywaniem upgrade'u.


4.1.2 Poinformuj użytkowników zawczasu

Warto też wcześniej poinformować wszystkich użytkowników o rozpoczęciu planowanego upgrade'u, chociaż użytkownicy dostający się do systemu poprzez ssh powinni zobaczyć w czasie upgrade'u tylko krótką uwagę na ten temat i móc kontynuować pracę.

Jeśli chcesz przedsięwziąć dodatkowe środki ostrożności, zrób backup lub odmontuj partycje użytkowników (/home) przed upgrade'm.

Prawdopodobnie będziesz też musiał dokonać aktualizacji jądra podczas upgrade'u do etch, tak więc konieczny będzie restart maszyny. Zwykle może być to zrobione po zakończeniu aktualizacji.


4.1.3 Przygotowanie do odzyskiwania

Ze względu na mnogość zmian w jądrze pomiędzy sarge a etch dotyczących sterowników, wykrywania sprzętu, nazewnictwa i kolejności plików urządzeń, istnieje realne niebezpieczeństwo, że będziesz miał problemy z reboot'em systemu po dokonaniu aktualizacji. Wiele z potencjalnych problemów jest opisanych w tym i następnych rozdziałach niniejszych Uwag.

Z tego powodu zalecamy podjąć działania mające na celu umożliwienie przywrócenie stanu sprzed reboot'u zakończonego niepowodzeniem, a dla systemów zdalnych sprzed utraty połączenia sieciowego.

Jeśli wykonujesz upgrade zdalnie przez ssh, gorąco zalecamy zapewnić sobie dostęp do serwera również przez zdalny terminal szeregowy. Istnieje prawdopodobieństwo, że po aktualizacji jądra i reboocie, niektóre urządzenia zmienią swoje nazwy (jak opisano w Przeorganizowanie nazw urządzeń, Rozdział 4.6.4) i będziesz musiał poprawić konfigurację systemu poprzez lokalną konsolę. Również w przypadku, kiedy system zostanie zrestartowany w środku aktualizacji, musisz mieć szansę powrotu (recovery) poprzez lokalną konsolę.

Najbardziej oczywistą rzeczą, jako pierwsze podejście, jest próba reboot'u ze starym jądrem. Jednak, z wielu powodów opisanych w tym dokumencie, nie ma gwarancji sukcesu tej próby.

Jeśli to zawiedzie, musisz mieć jakąś alternatywę startu systemu, dostępu do niego i możliwości naprawy. Pierwszą możliwością jest użycie płyty naprawczej (rescue) lub płyty Linux Live. Po starcie z takiej płyty powinno być możliwe zamontowanie filesystemu root i przejście na niego za pomocą chroot w celu zdiagnozowania i naprawienia problemu.

Drugim sposobem, który chcemy zarekomendować, jest użycie rescue mode (trybu ratunkowego) instalatora etch. Zaletą użycia instalatora jest możliwość wyboru pomiędzy wieloma metodami instalacji w sposób najoptymalniejszy w Twojej sytuacji. Więcej informacji znajduje się w sekcji "Recovering a Broken System" rozdziału 8. Installation Guide i w Debian Installer FAQ.


4.1.3.1 Powłoka debugująca w czasie bootowania za pomocą initrd

Pakiet initramfs-tools zawiera powłokę debugującą [6] w initrd. Jeśli np. initrd nie może zamontować filesystemu root, zostanie uruchomiona powłoka, z której możesz wywołać proste polecenia, pomagające wykryć problem i, być może, naprawić go.

Podstawowe rzeczy do sprawdzenia to: obecność prawidłowych plików w katalogu /dev; załadowane moduły (cat /proc/modules); wyjście programu dmesg z błędami ładowania sterowników. dmesg pokazuje też, które pliki urządzeń są dowiązane do których dysków; powinieneś porównać to z wyjściem polecenia echo $ROOT, upewniając się, że filesystem root jest na odpowiednim urządzeniu.

Jeśli naprawiłeś problem, możesz napisać exit opuszczając powłokę debugowania i kontynuując proces bootowania od miejsca, w którym został przerwany. Oczywiście, dla rozwiązania problemu może być też konieczne odbudowanie initrd, tak że dopiero następny boot przebiegnie bez błędu.


4.1.4 Przygotuj bezpieczne środowisko dla aktualizacji

Aktualizacja dystrybucji powinna być wykonywana albo lokalnie przez virtualną konsolę tekstową (ewentualnie bezpośrednio przyłączony terminal szeregowy), albo zdalnie poprzez ssh.

W celu zwiększenia marginesu bezpieczeństwa podczas upgrade'u zdalnego, sugerujemy wykonywać ten proces w wirtualnej konsoli udostępnianej przez program screen, który posiada możliwość bezpiecznego przełączania i zapewnia nieprzerywalny proces aktualizacji, nawet gdyby zawiodły procesy zdalnego połączenia.

Ważna uwaga: Nie powinieneś dokonywać upgrade'u za pomocą programów: telnet, rlogin, rsh, ani sesji X zarządzanych przez xdm, gdm czy kdm na maszynie, którą aktualizujesz. Jest tak dlatego, że każdy z tych serwisów może zostać zatrzymany w czasie upgrade'u, co może spowodować, że system stanie się niedostępny w połowie aktualizacji.


4.1.5 Brak wsparcia dla jądra 2.2

Jeśli używasz jądra o wersji wcześniejszej niż 2.4.1, powinieneś je zaktualizować do (co najmniej) serii 2.4 przed upgrade'm glibc. Powinno to być zrobione przed rozpoczęciem aktualizacji systemu. Zalecamy bezpośrednią aktualizację do jądra wersji 2.6.8 dostępnego w sarge, a nie do jądra 2.4.


4.2 Sprawdzenie statusu systemu

The upgrade process described in this chapter has been designed for upgrades from "pure" sarge systems without third-party packages. In particular, there are known problems with third-party packages which install programs under /usr/X11R6/bin/ causing problems with upgrades due to the X.Org transition (Przejście z XFree86 na X.Org, Rozdział 5.3). For greatest reliability of the upgrade process, you may wish to remove third-party packages from your system before you begin upgrading.

Zakładamy również, że aktualizujemy system z najnowszego sarge. Jeśli tak nie jest, lub nie jesteś pewien, postępuj według instrukcji w Aktualizacja systemu sarge, Rozdział A.1.


4.2.1 Przejrzyj akcje przewidywane przez menadżera pakietów

W niektórych przypadkach, jeśli używano apt-get do instalowania pakietów zamiast aptitude, może się zdarzyć, że aptitude ropozna pakiet jako "nieużywany" i zaznaczy go do usunięcia. Ogólnie biorąc, powinieneś upewnić się, że system jest w pełni aktualny i "czysty", zanim rozpoczniesz aktualizację.

Z tego powodu powinieneś przejrzeć, czy aptitude nie wykona jakichś niespodziewanych akcji. Jeśli pakiet jest zaznaczony do usunięcia lub update'u w zarządcy pakietów, może mieć to negatywny wpływ na przebieg upgrade'u. Naprawienie tego jest możliwe tylko, jeśli plik sources.list wskazuje na sarge;, a nie na stable lub etch; zobacz Sprawdzenie listy źródeł, Rozdział A.2.

Aby to uczynić, musisz uruchomić aptitude i nacisnąć klawisz 'g' ("Go"). Jeśli pokażą się jakieś akcje, powinieneś przejrzeć je i albo poprawić, albo przeprowadzić zgodnie z wyświetlanymi sugestiami. Jeśli nie ma żadnych sugerowanych akcji, zostanie wyświetlony komunikat "Brak pakietów do instalacji, usunięcia lub aktualizacji".


4.2.2 Wyłączenie pinningu APT

Jeśli APT został skonfigurowany do instalowania pakietów z dystrybucji innej niż stabilna (np. testing), powinieneś zmienić ustawienia pinningu APT (przechowywanego w /etc/apt/preferences), aby umożliwić aktualizację pakietów z nowej wersji stabilnej. Dalsze informacje nt. pinningu APT można znaleźć w apt_preferences(5).


4.2.3 Sprawdzenie statusu pakietów

Niezależnie od metody użytej przy aktualizacji, zalecamy sprawdzić najpierw status wszystkich pakietów, weryfikując, że wszystkie są w stanie umożliwiającym upgrade. Następujące polecenie pokaże pakiety, które są połowicznie zainstalowane (Half-Installed) lub błędnie skonfigurowane (Failed-Config) i te, które mają dowolny status wskazujący na błąd.

     # dpkg --audit

Można także sprawdzić stan wszystkich pakietów w systemie używając dselect, aptitude, lub poleceń takich jak

     # dpkg -l | pager

lub

     # dpkg --get-selections "*" > ~/curr-pkgs.txt

Przed upgrede'm warto usunąć pakiety o statusie 'hold' (utrzymane, aktualizacja niedozwolona). Jeśli jakiś ważny z punktu widzenia upgrade'u pakiet ma status 'hold', cała aktualizacja nie powiedzie się.

Zwracamy uwagę, że aptitude używa innej metody rejestracji stanu 'hold' pakietów niż apt-get i dselect. Możesz zidentyfikować stan 'hold' pakietów dla aptitude poprzez

     # aptitude search "~ahold" | grep "^.h"

Jeśli chcesz sprawdzić pakiety w stanie 'hold' dla apt-get, powinieneś użyć

     # dpkg --get-selections | grep hold

Jeśli lokalnie zmieniłeś i zrekompilowałeś jakiś pakiet bez zmiany nazwy albo przez wstawienie wersji 'epoch', musisz nadać mu status 'hold', aby zapobiec jego aktualizacji.

Status "hold" dla pakietu aptitude może być zmieniony za pomocą:

     # aptitude hold package_name

Zamień hold na unhold w celu zlikwidowania statusu "hold".

Jeśli znajdziesz tam coś, co wymaga naprawienia, najlepiej upewnij się, że plik sources.list odwołuje się do sarge, jak to opisano w Sprawdzenie listy źródeł, Rozdział A.2.


4.2.4 Źródła nieoficjalne i backporty

Jeśli na Twoim systemie znajdują się pakiety nie-Debianowe, powinieneś wiedzieć, że mogą one zostać usunięte w czasie aktualizacji ze względu na konflikty zależności. Jeśli pakiety te zostały zainstalowane poprzez dodanie archiwum w pliku /etc/apt/sources.list, powinieneś sprawdzić, czy to archiwum oferuje także pakiety skompilowane dla etch i zmienić linię w źródle odpowiednio na ten sam czas w stosunku do linii źródeł dla pakietów Debiana.

Niektórzy użytkownicy mają wydane nieoficjalnie (ang. backported) "nowsze" wersje pakietów, które zainstalowane na ich wersji sarge systemu. Pakiety te są najczęściej źródłem problemów w czasie upgrade'u ze względu na konflikty zależności[7]. Sekcja Możliwe problemy podczas upgrade'u, Rozdział 4.5.8 zawiera informacje o tym, jak sobie poradzić w takich wypadkach.


4.3 Ręczne usunięcie znaczników pakietów

Aby zopobiec usunięciu niektórych pakietów przez aptitude, które zostały zaznaczone do usunięcia ze względu na zależności, może okazać się niezbędne ręczne usunięcie ich znacznika auto. Dotyczy to OpenOffice i Vim dla instalacji graficznych:

     # aptitude unmarkauto openoffice.org vim

oraz obrazów jądra 2.6, jeśli instalowałeś je używając metapakietu jądra:

     # aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)

Uwaga: Możesz sprawdzić, które pakiety są oznaczone jako auto w aptitude przez wykonanie:

     # aptitude search 'i~M <package name>'

4.4 Przygotowanie źródeł dla APT

Zanim rozpoczniesz upgrade, musisz zmodyfikować pliki konfiguracyjne apt zawierające listy pakietów /etc/apt/sources.list.

apt przeszukuje wszystkie pakiety, które mogą zostać znalezione w liniach "deb" i instaluje pakiet z najwyższym numerem wersji, dając pierwszeństwo pierwszej takiej linii (czyli w przypadku istnienia kilku mirrorów, zwykle używa się najpierw lokalnego dysku, potem CD-ROM'u, a potem serwerów HTTP/FTP).

Odwołanie do wydania może odbywać się zarówno poprzez jego nazwę kodową (np. sarge, etch), jak też nazwę statusu (czyli oldstable, stable, testing, unstable). Odwołanie przez nazwę kodową ma tę zaletę, że użytkownik nie jest zaskoczony nowym wydaniem i z tego powodu przyjmujemy tu takie podejście. Oznacza to oczywiście, że samodzielnie musisz śledzić ogłaszane nowe wydania. Jeśli używasz nazwy statusu, zaobserwujesz po prostu ładowanie i aktualizowanie nowych pakietów, tak szybko, jak zostaną one wydane.


4.4.1 Dodanie do APT źródeł internetowych

Domyślna konfiguracja jest ustawiona na instalację z głównych serwerów internetowych Debiana, ale możesz zmienić /etc/apt/sources.list, aby używać innych mirrorów, najlepiej sieciowo najbliższych Twojej lokalizacji.

Adresy mirrorów HTTP lub FTP można znaleźć na http://www.debian.org/distrib/ftplist (w sekcji "Full list of mirrors" - pełna lista mirrorów). Serwery HTTP są generalnie szybsze niż FTP.

Załóżmy, że Twoim najbliższym mirrorem jest http://mirrors.kernel.org/debian/. Podczas sprawdzania tego mirroru za pomocą przeglądarki lub programu FTP, znajdziesz na nim katalogi zorganizowane w taki sposób:

     http://mirrors.kernel.org/debian/dists/etch/main/binary-powerpc/...
     http://mirrors.kernel.org/debian/dists/etch/contrib/binary-powerpc/...

Aby użyć mirroru programem apt, trzeba dodać linię do pliku sources.list:

     deb http://mirrors.kernel.org/debian etch main contrib

Zauważ, że `dists' jest dodawane domyślnie, a argument po nazwie wydania jest używany do rozwinięcia ścieżki na wiele katalogów.

Po dodaniu nowych źródeł, zdeaktywuj poprzednio istniejące linie "deb" w sources.list, poprzez umieszczenie przed nimi znaku hash (#).


4.4.2 Dodanie źródeł APT dla lokalnego mirrora

Zamiast używać serwerów HTTP czy FTP, można zmodyfikować /etc/apt/sources.list, aby mieć mirror na dysku lokalnym (np. zamontowany poprzez NFS).

Na przykład mirror może być w katalogu /var/ftp/debian/ i mieć główne katalogi:

     /var/ftp/debian/dists/etch/main/binary-powerpc/...
     /var/ftp/debian/dists/etch/contrib/binary-powerpc/...

Żeby użyć ich programem apt, dodaj linię do pliku sources.list:

     deb file:/var/ftp/debian etch main contrib

Zauważ, że `dists' jest dodawane domyślnie, a argument po nazwie wydania jest używany do rozwinięcia ścieżki na wiele katalogów.

Po dodaniu nowych źródeł, zdeaktywuj poprzednio istniejące linie "deb" w sources.list, poprzez umieszczenie przed nimi znaku hash (#).


4.4.3 Dodanie źródeł APT z CD-ROM'u lub DVD

Jeśli używasz tylko płyt, zakomentuj istniejące linie "deb" w /etc/apt/sources.list przez umieszczenie przed nimi znaku hash (#).

Upewnij się, że w pliku /etc/fstab jest linia, która umożliwia zamontowanie CD-ROM'u w punkcie montowania /cdrom (wymagany jest dokładnie /cdrom dla apt-cdrom). Jeśli np. plik /dev/hdc reprezentuje napęd CD-ROM, /etc/fstab powinien zawierać linię:

     /dev/hdc /cdrom auto defaults,noauto,ro 0 0

Zauważ, że pomiędzy defaults,noauto,ro w czwartym polu nie ma spacji.

Żeby sprawdzić, czy to zadziała, włóż płytkę i uruchom

     # mount /cdrom    # montuje CD w punkcie montowania
     # ls -alF /cdrom  # wyświetla zawartość katalogu głównego CD
     # umount /cdrom   # odmontowuje CD-ROM

A następnie uruchom:

     # apt-cdrom add

dla każdego CD-ROM'u z binariami Debiana, aby dodać dane nt. każdej z płyt do bazy danych APT.


4.5 Aktualizacja pakietów

Rekomendowanym sposobem aktualizacji z poprzednich edycji jest użycie narzędzia do zarządzania pakietami aptitude. Program ten podejmuje lepsze decyzje dot. instalacji pakietów, niż sam apt-get.

Nie zapomnij zamontować wszystkich niezbędnych partycji (zwłaszcza roota i /usr) jako zapisywalnych, poleceniem:

     # mount -o remount,rw /mountpoint

Następnie upewnij się dwa razy, że źródła APT (w pliku /etc/apt/sources.list) odwołują się do "etch" lub do "stable". Nie powinno być linii odwołujących się do sarge. Uwaga: linie dotyczące CD-ROM'u często odwołują się do "unstable"; pomimo, że wydaje się to dziwne, nie powinieneś tego zmieniać.


4.5.1 Nagranie sesji

Jest bardzo zalecane użycie programu /usr/bin/script do zapisania przebiegu sesji upgrade'u. Jeśli wystąpiłby jakiś problem, będziesz miał log zawierający wszystko, co się działo i, jeśli to konieczne, może udostępnić dokładne informacje do raportu o błędzie. Zapis rozpoczynamy przez:

     # script -t 2>~/upgrade-etch.time -a ~/upgrade-etch.script

albo podobnie. Nie należy kierować pliku wynikowego na katalogi tymczasowe, takie jak /tmp czy /var/tmp (pliki z tych katalogów mogą zostać skasowane podczas aktualizacji lub restartu).

Skrypt może również posłużyć do przejrzenia informacji, które zostały przewinięte poza ekran. W tym celu przełącz się na VT2 (za pomocą Alt-F2) i po zalogowaniu wykonaj less -R ~root/upgrade-etch.script, aby zobaczyć plik.

Po zakończeniu aktualizacji możesz zatrzymać script przez napisanie exit po znaku zachęty.

Jeśli użyłeś parametru -t w script, możesz zastosować scriptreplay do odtworzenia całej sesji:

     # scriptreplay ~/upgrade-etch.time ~/upgrade-etch.script

4.5.2 Aktualizacja listy pakietów

Najpierw konieczne jest ściągnięcie listy dostępnych pakietów nowego wydania. Robimy to przez wykonanie:

     # aptitude update

Jeśli robisz to pierszy raz, nowopobierane źródła będą powodować wyświetlanie ostrzeżeń dotyczących ich dostępności. Ostrzeżenia te są nieszkodliwe i nie będą się pojawiać, jeśli powtórzysz polecenie.


4.5.3 Upewnij się, że jest dość miejsca na dysku

Musisz upewnić się przed aktualizacją, że masz wystarczającą przestrzeń dyskową, zanim rozpoczniesz pełny upgrade systemu opisany w Upgrade reszty systemu, Rozdział 4.5.6. Każdy ściągany z sieci pakiet jest najpierw przechowywany w katalogu /var/cache/apt/archives (i podkatalogu partial/ w czasie ściągania), więc musisz mieć wystarczająco dużo miejsca na partycji systemowej /var/, gdzie są przechowywane tymczasowo pakiety, które zostaną zainstalowane w systemie. Po ich ściągnięciu prawdopodobnie będzie potrzebne dodatkowe miejsce na innych partycjach, zarówno na zaktualizowanie istniejących pakietów (które mogą zawierać większe binaria lub dane), jak też na nowe pakiety ściągnięte do upgrade'u. Jeśli Twój system nie ma wystarczającej przestrzeni, aktualizacja może zakończyć niecałkowicie i być trudna do odratowania.

Zarówno aptitude jak apt pokazują szczegółowe informacje o przestrzeni dyskowej niezbędnej do instalacji. Przed rozpoczęciem aktualizacji, możesz sprawdzić to przez wykonanie:

     # aptitude -y -s -f --with-recommends dist-upgrade
     [ ... ]
     XXX zaktualizowanych, XXX nowoinstalowanych, XXX do usunięcia i XXX nie aktualizowanych.
     Potrzebne ściągnięcie xx.xMB/yyyMB archiwów. Po rozpakowaniu zostanie użyte AAAMB.
     Zostaną ściągnięte/zainstalowane/usunięte pakiety.

[8]

Jeśli nie ma wystarczającej przestrzeni na upgrade, musisz przedtem zwolnić miejsce. Możesz:

Aby bezpiecznie usunąć niepotrzbne pakiety, dobrze jest sprawdzić, czy plik sources.list odwołuje się z powrotem do sarge, jak to opisano w Sprawdzenie listy źródeł, Rozdział A.2.


4.5.4 Wstępny upgrade systemu

Ponieważ niektóre ważne pakiety są w konflikcie pomiędzy edycjami sarge i etch, wykonanie polecenia aptitude dist-upgrade może spwodować usunięcie znacznej liczby pakietów. Z tego powodu zalecamy przeprowadzenie upgrade'u w dwóch fazach, faza wstępna zapobiegnie tym konfliktom, a po niej nastąpi pełen upgrade dist-upgrade.

Najpierw uruchom:

     # aptitude upgrade

Spowoduje to zaktualizowanie tych pakietów, które mogą zostać zaktualizowane bez potrzeby usuwania lub instalowania innych pakietów.

Przeprowadź upgrade wstępny poprzez:

     # aptitude install initrd-tools

Ten krok spowoduje aktualizację pakietów libc6 i locales, a także zainstaluje biblioteki obsługi SELinuxa (libselinux1). W tym momencie niektóre serwisy zostaną zrestartowane, np. xdm, gdm i kdm. W konsekwencji zostaną też odłączone lokalne sesje X11.

Następny krok zależy w znacznym stopniu od tego, jakie pakiety są zainstalowane w systemie. Niniejsze uwagi zawierają ogólne porady dotyczące metod postępowania, w razie wątpliwości zalecamy sprawdzenie, które pakiety zostaną usunięte przed wykonaniem poszczególnych czynności.

Spodziewaj się usunięcia pakietów takich jak: base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common i xserver-common. Pełną listę przestarzałych pakietów etch można znaleźć tu Przestarzałe pakiety, Rozdział 4.10.


4.5.4.1 Upgrade środowiska graficznego (desktop system)

Ten sposób upgrade'u został przetestowany na systemach z zainstalowanym zadaniem desktop. Prawdopodobnie jest to najlepsza metoda dla systemów z zainstalowanymi zadaniami (pakietami) desktop, gnome lub kde.

Prawdopodobnie nie jest to dobra metoda, jeśli masz zainstalowane pakiety libfam0c102 i xlibmesa-glu:

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Jeśli masz zainstalowany pełen system środowiska graficznego, wykonaj:

     # aptitude install libfam0 xlibmesa-glu

4.5.4.2 Aktualizowanie systemu z częściowo zainstalowanym systemem X

Systemy z zainstalowanymi pakietami X, ale bez wykonanego zadania desktop, wymagają innej metody. Metoda ta dotyczy w ogólności systemów z zainstalowanym pakietem xfree86-common, łącznie z niektórymi serwerami, które mają zainstalowane zadania serwera tasksel, jak zadania wymagające graficznych narzędzi zarządzania. Jest poprawną metodą do użycia w systemach, które używają X-ów, ale nie mają zainstalowanego pełnego zadania desktop.

     # dpkg -l xfree86-common | grep ^ii

Najpierw sprawdź, czy są zainstalowane pakiety libfam0c102 i xlibmesa-glu.

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Jeśli libfam0c102 nie jest zainstalowany, nie włączaj libfam0 do podanego polecenia. Jeśli nie jest zainstalowany xlibmesa-glu, nie włączaj go do tego polecenia. [9]

     # aptitude install x11-common libfam0 xlibmesa-glu

Zauważ, że instalacja libfam0 spowoduje zainstalowanie File Alteration Monitor (fam), jak też RPC portmapera (portmap), jeśli nie było ich w systemie. Oba pakiety powodują włączenie nowej usługi sieciowej, chociaż mogą być skonfigurowane tak, aby używać wewnętrznego (loopback) urządzenia sieciowego.


4.5.4.3 Aktualizacja systemu bez X-ów

On a system with no X, no additional aptitude install command should be required, and you can move on to the next step.


4.5.5 Upgrade jądra

Wersja udev z etch nie wspiera wcześniejszych wersji jądra niż 2.6.15 (co obejmuje jądro 2.6.8 z sarge) i odwrotnie, wersja udev z sarge nie będzie pracować poprawnie z najnowszym jądrem. W dodatku zainstalowanie pakietu udev z etch wymusza usunięcie pakietu hotplug, używanego przez jądro 2.4.

Jako konsekwencja, poprzednia wersja jądra nie zbootuje się prawidłowo po aktualizacji. Analogicznie, istnieje pewien moment w czasie upgrade'u, w którym pakiet udev zostanie zaktualizowany, ale nie zostanie zainstalowana jeszcze najnowsza wersja jądra. Jeśli w tym czasie system zostanie zresetowany, w środku upgrade'u, może on przestać się bootować ze względu na brak możliwości prawidłowej detekcji i ładowania sterowników (zobacz Przygotuj bezpieczne środowisko dla aktualizacji, Rozdział 4.1.4 zalecenia dotyczące przygotowania się na tę okoliczność w czasie zdalnej aktualizacji).

Jeżeli system nie ma zainstalowanego zadania desktop lub innych pakietów, które spowodowałyby znaczną liczbę usunięć, zalecamy upgrade jądra w tym momencie.

Upgrade jądra wykonujemy poprzez:

     # aptitude install linux-image-2.6-flavor

Zobacz Instalacja metapakietu jądra, Rozdział 4.6.1, aby określić, który obraz jądra powinienieś zainstalować.

W przypadku środowiska graficznego niestety nie jest możliwe określenie, który pakiet jądra został zainstalowany bezpośrednio po instalacji nowego pakietu udev, tak więc mamy do czynienia z nieokreślonym przedziałem czasu, w którym nie ma zainstalowanego jądra z pełną obsługą hotplug. Zobacz Aktualizacja jądra i jego pakietów, Rozdział 4.6 informacje nt. konfiguracji niezależnej od hotplug w celu zbootowania.


4.5.6 Upgrade reszty systemu

Teraz jesteśmy gotowi na przeprowadzenie głównej części aktualizacji. Wykonujemy:

     # aptitude dist-upgrade

Zostanie wykonana pełna aktualizacja systemu, to jest instalacja najnowszych dostępnych wersji wszystkich pakietów, rozwiązanie wszystkich możliwych konfliktów zależności pomiędzy pakietami w różnych wydaniach. Jeśli konieczne, instalacja nowych pakietów (zwykle nowych wersji bibliotek lub pakietów przenazwanych) oraz usunięcie pakietów przestarzałych pozostających w konfliktach.

Jeśli aktualizujesz ze zbioru płyt CD, będziesz proszony o wkładanie różnych płyt w wielu momentach aktualizacji. Możliwe jest wkładanie tych samych płyt wiele razy z powodu zależnych od siebie pakietów umieszczonych na różnych płytach.

Nowe wersje bieżąco instalowanych pakietów, które nie mogą zostać zaktualizowane bez zmiany statusu innego pakietu, zostaną pozostawione w ich obecnych wersjach (wyświetlanych jako "held back" - utrzymane). Rozwiązaniem jest wtedy albo użycie aptitude do wybrania tych pakietów do instalacji, albo próba zastosowania aptitude -f install package.


4.5.7 Pobranie podpisów pakietów

Po aktualizacji, mając mową wersję apt, można dokonać update'u informacji o pakietach, włączając w to uruchomienie nowego mechanizmu kontroli podpisów:

     # aptitude update

Po aktualizacji są już dostępne i włączone klucze do podpisywania archiwów pakietów Debiana. Jeśli dodasz inne (nieoficjalne) źródło pakietów, apt będzie wyświetlał ostrzeżenia dotyczące niezgodności w pochodzeniu pakietów. Więcej informacji Zarządzanie pakietami, Rozdział 2.2.1.

Zostaniesz ostrzeżony, że od momentu, w którym zaczniesz używać nowej wersji apt, będą ściągane pliki różnicowe (pdiff) zamiast pełnej listy indeksu pakietów. Więcej informacji o tej funkcjonalności jest na Spowolnione update'y plików indeksowych APT, Rozdział 5.1.4.


4.5.8 Możliwe problemy podczas upgrade'u

Jeśli operacja używająca aptitude, apt-get lub dpkg zakończy się błędem

     E: Dynamic MMap ran out of room

domyślna przestrzeń cache jest niewystarczająca. Możesz naprawić to albo przez usunięcie lub zakomentowanie linii, które nie są potrzebne w /etc/apt/sources.list, albo poprzez zwiększenie przestrzeni cache. Może ona zostać powiększona przez ustawienie APT::Cache-Limit w pliku /etc/apt/apt.conf. Następujące polecenie ustawia jej wartość na wystarczającą do aktualizacji:

     # echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Przyjęto, że zmienna ta nie była jeszcze ustawiana w pliku.

Czasem konieczne jest włączenie opcji APT::Force-LoopBreak, żeby umożliwić tymczasowe usunięcie jakiegoś ważnego pakietu ze względu na konflikty zależności. aptitude będzie ostrzegać o tym i przerywać aktualizację. Możesz kontynuować pracę przez dodanie opcji -o APT::Force-LoopBreak=1 przy wywołaniu aptitude.

Jest możliwe, że struktura zależności w systemie jest uszkodzona, tak że wymaga ręcznej interwencji. Zwykle oznacza to użycie aptitude lub

     # dpkg --remove package_name

aby wyeliminować jakieś przeszkadzające pakiety lub

     # aptitude -f install
     # dpkg --configure --pending

W wyjątkowych przypadkach konieczne może być wymuszenie reinstalacji poleceniem typu

     # dpkg --install /path/to/package_name.deb

Konflikty plików nie powinny wystąpić, jeśli aktualizujesz "czysty" system sarge, ale mogą zdarzyć się, jeśli masz zainstalowane nieoficjalne backporty. Konflikt pliku objawia się błędem:

     Unpacking <package-foo> (from <package-foo-file>) ...
     dpkg: error processing <package-foo> (--install):
      trying to overwrite `<some-file-name>',
      which is also in package <package-bar>
     dpkg-deb: subprocess paste killed by signal (Broken pipe)
      Errors were encountered while processing:
      <package-foo>

Możesz próbować rozwiązać konflikt przez wymuszenie usunięcia pakietu wymienionego w ostatniej linii komunikatu o błędzie:

     # dpkg -r --force-depends package_name

Po naprawie powinieneś móc powrócić do aktualizacji przez powtórzenie opisanych wcześniej poleceń aptitude.

W czasie aktualizacji będziesz proszony o podanie odpowiedzi na pytania dotyczące konfiguracji lub rekonfiguracji niektórych pakietów. Jeśli będziesz pytany, czy jakiś plik z katalogów /etc/init.d lub /etc/terminfo lub plik /etc/manpath.config ma być zastąpiony, należy dać odpowiedź 'tak' ('yes'), aby zapewnić spójność systemu. Zawsze możesz przywrócić starą wersję, gdyż są one zachowywane z rozszerzeniem .dpkg-old.

Jeśli nie jesteś pewien, co zrobić, zapisz sobie nazwę pakietu lub pliku i pozostaw sprawy do przemyślenia. Możesz też sprawdzić skrypt wykonania i stamtąd uzyskać informacje, które pojawiały się na ekranie w czasie aktualizacji.


4.6 Aktualizacja jądra i jego pakietów

Ta sekcja wyjaśnia, w jaki sposób dokonać upgrade'u jądra i omawia ptencjalne zagrożenia odnoszące się do tego. Możesz albo zainstalować jeden z pakietów linux-image-* udostępnianych przez Debiana, lub też skompilować jądro ze źródeł.

Informacje podane w tej sekcji opierają się na założeniu, że używasz jednego z dostępnych modularnych jąder Debiana łącznie z pakietami initramfs-tools i udev. Jeśli wybrałeś możliwość kompilacji jądra, które nie używa initrd, lub też używasz innego generatora initrd, niektóre z podanych są dla Ciebie nieprzydatne.

Jeśli pakiet udev nie jest instalowany w Twoim systemie, możliwe jest użycie pakietu hotplug do wykrywania sprzętu.

Jeśli używasz jądra 2.4, powinieneś przeczytać dokładnie także Upgrade do jądra 2.6, Rozdział 5.2.


4.6.1 Instalacja metapakietu jądra

W czasie upgrade'u z sarge do etch, gorąco zalecamy zainstalować nowy metapakiet linux-image-2.6-*. Może on zostać zainstalowany automatycznie w czasie procesu upgrade'u. Można to sprawdzić przez uruchomienie:

     # dpkg -l "linux-image*" | grep ^ii

Jeśli nie ma wyniku, powinieneś zainstalować nowy pakiet linux-image ręcznie. Aby sprawdzić listę dostępnych metapakietów linux-image-2.6 wykonaj:

     # apt-cache search linux-image-2.6- | grep -v transition

Jeśli nie jesteś pewien, który pakiet wybrać, wykonaj uname -r i wybierz pakiet o podobnej nazwie. Np. jeśli widzisz u siebie '2.4.27-3-686', najlepiej zainstaluj linux-image-2.6-686. Możesz też użyć apt-cache, aby przeczytać opisy każdego z pakietów i w ten sposób wybrać najbardziej odpowiedni. Przykładowo:

     # apt-cache show linux-image-2.6-686

Powinieneś użyć aptitude install do zainstalowania pakietu. Od momentu zainstalowania nowego jądra i zrestartowania maszyny przy najbliższej okazji, możesz korzystać z zalet nowej wersji jądra.

Jeszcze więcej zalet ma skompilowanie na Debian GNU/Linuxie jądra dostosowanego do Twoich zasobów. Zainstaluj narzędzie kernel-package i przeczytaj dokumentację w /usr/share/doc/kernel-package.


4.6.2 Aktualizacja wewnątrz serii 2.6

Jeśli obecnie używasz jądra serii 2.6 z sarge ta aktualizacja będzie miała miejsce automatycznie po wykonaniu pełnego upgrade'u pakietów systemu (jak opisano w Aktualizacja pakietów, Rozdział 4.5).

Jeśli jest to możliwe, zyskasz sporo robiąc upgrade pakietu jądra oddzielnie od głównego dist-upgrade, co zredukuje czas, w którym system jest niebootowalny. Zobacz Upgrade jądra, Rozdział 4.5.5, gdzie opisano ten proces. Prosimy zwrócić uwagę, że powinno to być robione po wykonaniu fazy wstępnej upgrade'u, opisanej w Wstępny upgrade systemu, Rozdział 4.5.4.

Możesz także wykonać ten krok, jeśli używasz swojego własnego jądra i chcesz używać jądra z wersji etch. Jeśli Twoje jądro nie jest wspierane przez udev, zalecamy jego aktualizację po wstępnej fazie upgrade'u. Jeśli Twoja wersja jest wspierana przez udev, możesz bezpiecznie poczekać, aż zakończy się pełna aktualizacja systemu.


4.6.3 Upgrade z jądra 2.4

Jeśli masz zainstalowane jądro 2.4 i system wykrywa sprzęt używając pakietu hotplug, powinieneś najpierw dokonać upgrede'u jądra do wersji 2.6 z sarge, zanim przystąpisz do aktualizacji. Upewnij się, że system bootuje się z jądrem 2.6 i cały sprzęt jest wykrywany poprawnie, zanim przystąpisz do aktualizacji. Pakiet hotplug jest usuwany z systemu (na rzecz pakietu udev), kiedy wykonujesz pełną aktualizację systemu. Jeśli nie wykomasz przedtem upgrade'u jądra, system może nie zbootować się prawidłowo. Jeśli wykonałeś już upgrade do jądra serii 2.6 w sarge, możesz aktualizować jądro, jak to jest opisane w Aktualizacja wewnątrz serii 2.6, Rozdział 4.6.2.

Jeśli system nie bazuje na pakiecie hotplug[10], możesz opóźnić upgrade jądra i wykonać go po pełnej aktualizacji systemu, jak to zostało opisane w Upgrade reszty systemu, Rozdział 4.5.6. Jeśli system został już zaktualizowany, możesz wykonać, co następuje (zmiana nazwy pakietu jądra na bardziej odpowiednią, poprzez zastąpienie <obrazu>):

     # aptitude install linux-image-2.6-<obraz>

4.6.4 Przeorganizowanie nazw urządzeń

etch posiada bardziej wydajny mechanizm wykrywania sprzętu, niż poprzednie wydania. Jednak może to skutkować zmianami w przyporządkowaniu wyszukiwanych urządzeń do odpowiadających im nazw. Na przykład jeśli masz dwie karty sieciowe, które korzystają z różnych sterowników, odwołania do urządzeń eth0 i eth1 mogą zostać zamienione. Zauważ, że nowy mechanizm powoduje również, że jeśli np. zmieniasz karty sieciowe w pracującym etch, system może przyporządkować nowej karcie nową nazwę interfejsu.

Dla urządzeń sieciowych można zapobiec takim zamianom za pomocą reguł pakietu udev, a zwłaszcza definicjom reguł zawartym w /etc/udev/rules.d/z25_persistent-net.rules[11]. Jako alternatywę możesz użyć programu ifrename do dowiązania urządzeń fizycznych do nazw używanych podczas bootowania. Zobacz ifrename(8) i iftab(5). Obie możliwości (udev i ifrename) nie powinny być używane jednocześnie.

Dla urządzeń przechowywania danych (ang. storage devices) możesz ominąć zmianę kolejności za pomocą pakietu initramfs-tools skonfigurowanego w taki sposób, aby ładował sterowniki urządzeń w kolejności, w jakiej są obecnie załadowane. Aby to zrobić, musisz zidentyfikować kolejność, w jakiej sterowniki są ładowane wywołując lsmod. lsmod pokazuje listę modułów w kolejności odwrotnej do kolejności ładowania, czyli pierwszy moduł na liście został załadowany na końcu. Działa to jednak tylko dla urządzeń, które jądro wykrywa w stałej kolejności (np. karty PCI).

Zwróć uwagę, że usunięcie i powtórne załadowanie modułów po starcie systemu, spowoduje zmiany w ich kolejności. Oprócz tego, niektóre sterowniki są łączone (link) przez jądro statycznie i nie zostaną wyświetlone przez lsmod. Możesz odcyfrować ich nazwy i kolejność ładowania albo z pliku /var/log/kern.log, albo programem dmesg.

Dodaj nazwy tych modułów do pliku /etc/initramfs-tools/modules w kolejności, w jakiej powinny się ładować w czasie bootu. Niektóre nazwy mogły ulec zmianie pomiędzy sarge a etch. Np. sym53c8xx_2 stało się sym53c8xx.

Trzeba też zregenerować obraz(y) initramfs przez wykonanie update-initramfs -u -k all.

Jeśli używasz już jądra etch i udev, możesz przekonfigurować system, aby uzyskać dostęp do dysków za pomocą aliasów, co uniezależnia go od kolejności ładowania sterowników. Aliasy znajdują się w plikach /dev/disk/.


4.6.5 Problemy z bootowaniem

Jeśli do bootowania jest używane initrd utworzone przy pomocy pakietu initramfs-tools, w niektórych przypadkach tworzenie plików urządzeń przez pakiet udev może następować zbyt późno, aby były przydatne dla skrtyptu bootowania.

The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell, but that when you check afterwards, all devices that are needed are present in /dev. This has been observed in cases where the root file system is on a USB disk or on RAID, especially if lilo is used.

Rozwiązaniem tego problemu jest użycie parametru bootowania rootdelay=9. Wartość opóźnienia (w sekundach) może być zmieniona.


4.6.6 PCILynx FireWire driver is broken

The PCILynx driver is horribly broken and might result in driver crashes on PowerPC. We encourage users who need FireWire to avail themselves of one of the cheap OHCI1394 cards and blacklist PCILynx driver.


4.7 Zadania przed restartem komputera

Kiedy zakończy się działanie aptitude dist-upgrade, aktualizacja "formalnie" jest gotowa, ale warto pamiętać o kilku rzeczach przed zrebootowaniem maszyny.


4.7.1 Konwersja z devfs

Jądro Debiana nie wspiera już devfs, tak więc użytkownicy devfs muszą ręcznie skonwertować swój system, zanim zbootują jądro etch.

Jeśli w pliku /proc/mounts widać napis 'devfs', oznacza to zwykle, że używasz devfs. Wszystkie pliki konfiguracyjne, które odwołują się do nazw używanych przez devfs, powinny zostać zmienione i używać nazw odpowiednich dla pakietu udev. Przede wszystkim są to pliki /etc/fstab, /etc/lilo.conf, /boot/grub/menu.lst i /etc/inittab.

Więcej informacji na temat potencjalnych problemów znajduje się w raporcie o błędzie #341152.


4.7.2 Aktualizacja mdadm

mdadm wymaga obecnie pliku konfiguracyjnego do złożenia macieży MD (RAID) z inicjalnego ramdysku podczas sekwencji inicjalizacji systemu. Prosimy przeczytać i wykonać instrukcje zawarte w pliku /usr/share/doc/mdadm/README.upgrading-2.5.3.gz po aktualizacji pakietu, a przed rebootem. Najnowsza wersja tego pliku jest dostępna na http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file; prosimy przeczytać w razie problemów.


4.8 Przygotowanie do nowej edycji

Po upgrade można zrobić jeszcze kilka rzeczy, aby całkowicie przygotować się do używania nowego wydania.


4.9 Deprecated packages

With the release of Lenny a bigger number of server packages will be deprecated, thus updating to newer versions of those now will save you from trouble when updating to Lenny.

This includes the following packages:


4.10 Przestarzałe pakiety

Wprowadzając tysiące nowych pakietów etch usuwa i pomija ponad dwa tysiące starych pakietów, które były w sarge. Dla tych pakietów aktualizacja nie jest przewidziana. Aby nie pozbawiać bezpieczeństwa tych pakietów, projekt Debian jak zwykle zaprzestanie wspierać je w zakresie bezpieczeństwa po roku od wydania etch[12] i nie będzie prowadził żadnego innego wsparcia w tym czasie. Jeśli to możliwe, należy zastąpić je dostępnymi alternatywami.

Jest wiele powodów, dla których pakiety mogły zostać usunięte z dystrybucji: zakończono wydawanie ich wersji pierwotnych, nie ma już Deweloperów Debiana zainteresowanych pielęgnacją danego pakietu, funkcjonalność została przejęta przez inne oprogramowanie (lub nową wersję) lub też zadecydowano, że nie jest ona już opowiednia dla etch ze względu na błędy. W tym ostatnim przypadku, pakiet może być dostępny w dystrybucji "unstable".

Sprawdzenie, które pakiety w aktualizowanym systemie są "przestarzałe" jest proste, gdyż programy obsługi pakietów pokazują to odpowiednim znacznikem. Jeśli używasz aptitude, zobaczysz listę tych pakietów w sekcji "Pakiety przestarzałe i utowrzone lokalnie". dselect oferuje zbliżoną sekcję, choć przedstawiona lista może się różnić. Jeśli więc użyłeś aptitude do ręcznej instalacji pakietów w sarge, będzie ona trzymać do nich ścieżkę i będzie mogła oznaczyć jako przestarzałe te pakiety, z których zależności wynika, że nie są już potrzebne lub powinny zostać usunięte. Wynika z tego, że aptitude, inaczej niż deborphan, nie zaznaczy jako przestarzałe pakietów, które zainstalowałeś ręcznie, w przeciwieństwie do instalowanych automatycznie ze względu na zależności.

Istnieją też dodatkowe narzędzia, którymi możesz znaleźć przestarzałe pakiety, takie jak deborphan, debfoster czy cruft. deborphan jest usilnie zalecany, chociaż (w trybie standardowym) raportuje tylko przestarzałe biblioteki: pakiety w sekcjach "libs" lub "oldlibs", które nie są używane przez inne pakiety. Nie należy wyrzucać bez zastanowienia pakietów pokazywanych przez te narzędzia, zwłaszcza jeśli używasz agresywnych, niestandardowych opcji, które mogą generować tzw. fałszywe pozytywy. Bardzo prosimy ręcznie sprawdzić pakiety sugerowane do usunięcia (ich zawartość, rozmiar i opis), zanim je wyrzucisz.

Strona System Śledzenia Błędów Debiana często zawiera dodatkowe informacje nt. przyczyn usunięcia danego pakietu. Powinieneś przejrzeć zarówno archiwa błędów samiego pakietu jak i raporty dla ftp.debian.org pseudopakietów.


4.10.1 Ślepe pakiety

Niektóre pakiety z sarge zostały połączone w inne w etch, często po to, aby ułatwić opiekę nad systemem. Aby ułatwić sposób aktualizacji w takich przypadkach, etch często wprowadza "ślepe" pakiety: puste pakiety, które mają taką samą nazwę, jak te stare w sarge z zależnościami, które wprowadzają nowe pakiety do instalacji. Te "ślepe" pakiety stają się przestarzałe po upgrade i mogą być bezpiecznie usunięte.

Większość (ale nie wszystkie) opisów ślepych pakietów pokazuje ich przeznaczenie. Opisy ślepych pakietów nie są ujednolicone, ale za pomocą deborphan z opcją --guess możesz wyszukać je w swoim systemie. Dodajmy, że ślepe pakiety nie są przeznaczone do usunięcia po upgrade systemu, ale odwrotnie, trzymają one ślad do obecnie dostępnych wersji programów.


[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ dalej ]


Uwagi do wydania Debian GNU/Linux 4.0 ("etch"), PowerPC

$Id: release-notes.en.sgml,v 1.312 2007-08-16 22:24:38 jseidel Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (obecny), Andreas Barth (obecny), Javier Fernández-Sanguino Peña (obecny), Steve Langasek (obecny)
debian-doc@lists.debian.org