[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ dalej ]
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.
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.
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.
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.
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.
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.
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.
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.
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".
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).
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.
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 są 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.
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>'
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.
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-alpha/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-alpha/...
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 (#).
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-alpha/...
/var/ftp/debian/dists/etch/contrib/binary-alpha/...
Ż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 (#).
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.
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ć.
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
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.
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:
Usunąć pakiety, które zostały uprzednio ściągnięte do instalacji (w
/var/cache/apt/archive). Czyszczenie cache pakietów przez
wykonanie apt-get clean lub aptitude clean usunie
wszystkie wcześniej pobierane pakiety.
Usunąć stare pakiety, które już nie są używane. Jeśli masz zainstalowany
popularity-contest, możesz sprawdzić listę nieużywanych pakietów,
które zajmują większość miejsca za pomocą popcon-largest-unused.
Możesz też użyć deborphan lub debfoster, żeby znaleźć
przestarzałe pakiety (zobacz Przestarzałe pakiety,
Rozdział 4.10). Jako alternatywę możesz uruchomić aptitude w
"trybie wizualnym" i znaleźć przestarzałe pakiety w sekcji
"Pakiety przestarzałe i utworzone lokalnie".
Usunąć pakiety zabierające dużo miejsca, które obecnie nie są potrzebne (możesz
je zawsze doinstalować po aktualizacji). Możesz sprawdzić listę pakietów
zajmujących najwięcej miejsca za pomocą dpigs (z pakietu
debian-goodies) lub wajig (polecenie wajig
size).
Tymczasowo przenieść na inny system lub całkiem usunąć logi systemowe z
katalogu /var/log/.
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.
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.
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
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.
On a system with no X, no additional aptitude install command should be required, and you can move on to the next step.
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.
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.
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.1.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.
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.
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.
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.
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.
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>
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/.
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.
Kiedy zakończy się działanie aptitude dist-upgrade, aktualizacja "formalnie" jest gotowa, ale warto pamiętać o kilku rzeczach przed zrebootowaniem maszyny.
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.
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.
Po upgrade można zrobić jeszcze kilka rzeczy, aby całkowicie przygotować się do używania nowego wydania.
Jeżeli używasz grub, wyedytuj plik
/etc/kernel-img.conf i popraw położenie programu
update-grub z /sbin/update-grub na
/usr/sbin/update-grub.
Jeśli nowy obraz jądra został poprzez zależności wpisany na miejsce starego, zostanie on zaznaczony jako automatycznie zainstalowany, co trzeba poprawić:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Usuń metapakiety jądra sarge poprzez:
# aptitude purge kernel-image-2.6-<flavor>
Move any configuration options from /etc/network/options to
/etc/sysctl.conf. Please see
/usr/share/doc/netbase/README.Debian for details.
Usuń przestarzałe i nieużywane pakiety, jak to opisano w Przestarzałe pakiety, Rozdział 4.10. Powinieneś przejrzeć, których plików konfiguracyjnych one używały i rozważyć wyczyszczenie (purge) tych pakietów w celu usunięcia zbędnych plików.
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:
apache (1.x), successor is apache2
bind8, successor is bind9
php4, successor is php5
postgresql-7.4, successor is postgresql-8.1
exim 3, successor is exim4
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.
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"), Alpha
$Id: release-notes.en.sgml,v 1.312 2007/08/16 22:24:38 jseidel Exp $debian-doc@lists.debian.org