[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ weiter ]
Wir empfehlen, vor dem Upgrade die Informationen in Probleme, die Sie bei Etch beachten sollten, Kapitel 5 zu lesen. Das Kapitel behandelt potenzielle Probleme, die nicht direkt mit dem Upgrade-Prozess zu tun haben, deren Bekanntheit vor der Aktualisierung aber wichtig sind.
Es ist empfehlenswert, vor der Aktualisierung des Systems ein Backup aller Daten zu erstellen, oder zumindest jener Daten und Konfigurationsinformationen, die nicht verloren gehen dürfen. Die Aktualisierungswerkzeuge sind sehr verlässlich, dennoch könnte ein Hardware-Fehler während des Aktualisierens Ihr System schwer beschädigen.
Unbedingt sollten die Inhalte von /etc,
/var/lib/dpkg, /var/lib/aptitude/pkgstates und die
Ausgabe von dpkg --get-selections "*" (die
Anführungszeichen sind wichtig) gesichert werden.
Der Aktualisierungsprozess selbst verändert nichts im Verzeichnis
/home, manche Programme jedoch (zum Beispiel Teile der
Mozilla-Suite und der GNOME- und KDE-Desktop-Umgebungen) sind dafür bekannt,
existierende Einstellungen der Benutzer mit neuen Standardwerten zu
überschreiben, wenn eine neue Version dieser Anwendung zum ersten Mal vom
Benutzer gestartet wird. Als Vorsichtsmaßnahme sollten daher vielleicht die
versteckten Dateien und Verzeichnisse (»dotfiles«, Dateien und Verzeichnisse,
die mit einem Punkt beginnen) in den Home-Verzeichnissen der Benutzer gesichert
werden. Diese Sicherung kann helfen, alte Einstellungen wieder herzustellen.
Auch eventuelle Benutzer sollten über dieses Problem informiert werden.
Alle Operationen zur Paketinstallation benötigen die Privilegien des
Superusers. Sie müssen sich also entweder als root anmelden oder
su oder sudo benutzen, um die nötigen Rechte zu
erlangen.
Es gibt diverse Voraussetzungen zur Aktualisierung; Sie sollten diese überprüfen, bevor Sie die Aktualisierung durchführen.
Es ist klug, alle Benutzer von der geplanten Aktualisierung in Kenntnis zu
setzen, auch wenn Benutzer, die das System über ssh nutzen, davon
nicht viel mitbekommen dürften und es ihnen möglich sein sollte, einfach
weiterzuarbeiten.
Als zusätzliche Sicherungsmaßnahme kann die Home-Partition (/home)
vor der Aktualisierung gesichert (oder aus dem Dateisystem ausgehängt) werden.
Sie werden wahrscheinlich den Kernel aktualisieren müssen, wenn Sie zu Etch aktualisieren. Dies erfordert normalerweise auch einen Neustart. Typischerweise wird dieser durchgeführt, wenn die Aktualisierung fertig ist.
Wegen der vielen Änderungen im Kernel zwischen Sarge und Etch bezüglich Treiber, Hardware-Erkennung und der Benennung und Sortierung der Gerätedateien besteht das Risiko, dass Sie während des Neustarts nach der Aktualisierung auf Probleme stoßen. Viele bekannte, mögliche Probleme sind in diesem und im nächsten Kapitel dokumentiert.
Aus diesem Grund ist es sinnvoll sicherzustellen, dass das System wieder hergestellt werden kann, falls der Neustart schief geht oder – bei ferngewarteten Systemen – das die Netzverbindung nicht wieder korrekt hergestellt wird.
Falls das Upgrade aus der Ferne (remotely) über eine
ssh-Verbindung durchgeführt wird, empfehlen wir, die notwendigen
Vorkehrungen zu treffen, um auf den Server über ein serielles Terminal
zugreifen zu können. Es könnte möglich sein, dass nach dem Kernel-Upgrade und
dem Neustart einige Geräte umbenannt sind (wie dies in Andere Reihenfolge der Gerätebezeichnungen, Abschnitt
4.6.4 beschrieben ist) und daher die Systemkonfiguration über eine lokale
Konsole repariert werden muss. Auch falls das System in der Mitte des Upgrades
versehentlich neu gestartet wird, besteht die Möglichkeit, dass es über eine
lokale Konsole wiederhergestellt werden muss.
Die offensichtlichste Maßnahme besteht darin, zunächst zu probieren, Ihren alten Kernel wieder zu starten. Jedoch kann dies aus den hier dokumentierten Gründen nicht garantiert werden.
Sollte dies schief gehen, benötigen Sie eine alternative Methode, zum Starten und zum Zugriff auf das System, um es zu reparieren. Eine Option besteht darin, ein spezielles Rettungssystem oder eine Linux-Live-CD zu benutzen. Nachdem Sie von dieser gestarteten haben, sollten Sie das root-Dateisystem einbinden und mit chroot hinein wechseln, um das Problem zu untersuchen und zu beheben.
Eine andere Möglichkeit, die wir gerne empfehlen, besteht darin, den
Rettungs-Modus des Etch-Debian-Installers zu verwenden. Der Vorteil
dieser Methode besteht darin, dass Sie zwischen den vielen
Installationsmethoden wählen können, je nachdem, welche Ihrer Situation
angemessen ist. Weitere Informationen hierzu finden Sie im Kapitel »Ein
kaputtes System reparieren« in Kapitel 8 des Installations-Leitfadens
und den Debian
Installer FAQ.
Eine Aktualisierung der Distribution sollte am besten am lokalen Rechner über
die Textkonsole ausgeführt werden (bzw. über ein direkt angeschlossenes
serielles Terminal) oder entfernt über eine ssh-Verbindung.
Bei einer Fern-Aktualisierung schlagen wir für erhöhte Sicherheit vor, den
Aktualisierungsprozess in einer virtuellen Konsole des Programms
screen durchzuführen. Dieses erlaubt eine sichere Wiederaufnahme
der Verbindung und stellt sicher, dass der Aktualisierungs-Prozess nicht
unterbrochen wird, falls die Verbindung abreißen sollte.
Wichtig! Für die Aktualisierung sollten nicht die
Programme telnet, rlogin oder rsh
benutzt werden. Außerdem sollte die Aktualisierung auch nicht aus einer
X-Sitzung gestartet werden, die von xdm, gdm oder
kdm verwaltet wird. Diese Dienste können bei einer Aktualisierung
neu gestartet oder gar abgeschaltet werden, was zu einem
unbenutzbaren, nur halb-aktualisierten System führen kann.
Falls ein Kernel vor Version 2.4.1 verwendet wird, muss dieser (mindestens) auf
die aktuelle Version der 2.4-Serie aktualisiert werden, bevor
glibc aktualisiert wird, also am besten bevor das Upgrade
gestartet wird. Es wird empfohlen, direkt auf den Kernel 2.6.8 aus Sarge zu
aktualisieren, statt einen Kernel der 2.4er Serie zu verwenden.
Der in diesem Kapitel beschriebene Aktualisierungsprozess wurde für
Aktualisierungen von »reinen« Sarge-Systemen ohne Pakete von Dritten
entwickelt. Insbesondere kann es zu Problemen mit von Dritten entwickelten
Paketen kommen, falls diese Programme nach /usr/X11R6/bin/
installieren. Dies führt zu Aktualisierungs-Problemen während des Übergangs zu
X.Org (Wechsel von XFree86 nach X.Org,
Abschnitt 5.3). Um die größte Zuverlässigkeit des
Aktualisierungs-Prozesses zu erzielen, sollte überlegt werden, Pakete Dritter
von Ihrem System zu entfernen, bevor die Aktualisierung gestartet wird.
Diese Prozedur geht auch davon aus, dass bereits auf die aktuellste Punkt-Veröffentlichung von Sarge aktualisiert wurde. Falls dies noch nicht erledigt ist (oder Zweifel bestehen), bitte zuerst die Aktualisierung gemäß Aktualisieren Ihres Sarge-Systems, Abschnitt A.1 vornehmen.
In manchen Fällen kann die Nutzung von apt-get statt
aptitude zur Paketinstallation dazu führen, dass
aptitude ein Paket als »unbenutzt« einstuft und zum Entfernen
vorsieht. Im Allgemeinen sollte sichergestellt sein, dass das System
vollständig »sauber« und aktuell ist, bevor die Aktualisierung erfolgt.
Sie sollten daher auch prüfen, ob es irgendwelche schwebenden Aktionen im
Paket-Manager aptitude gibt. Falls ein Paket zum Entfernen oder
Aktualisieren vorgesehen ist, könnte es das Upgrade negativ beeinträchtigen.
Dies kann nur korrigiert werden, falls die sources.list weiterhin
auf Sarge; und nicht auf stable oder Etch verweist;
siehe Prüfen Ihrer
sources.list, Abschnitt A.2.
Hierzu muss aptitudes Benutzerschnittstelle aufgerufen werden und
»g« (für »Go«, »ausführen«) gedrückt werden. Sollten dort irgendwelche
Aktionen vorgeschlagen werden, so sollten Sie diese durchsehen und entweder
Korrekturen vornehmen oder die vorgeschlagenen Aktionen durchführen. Falls
keine Aktionen vorgeschlagen werden, wird eine Nachricht mit dem Inhalt »Es
wurden keine Pakete zum Installieren, Entfernen oder Aktualisieren ausgewählt.«
angezeigt.
Falls APT so konfiguriert ist, bestimmte Pakete aus einer anderen Distribution
als Stable (zum Beispiel aus Testing) zu installieren, muss die
APT-Pinning-Konfiguration (befindet sich in /etc/apt/preferences)
möglicherweise geändert werden, um eine Paketaktualisierung zu einer Version in
der neuen Stable-Veröffentlichung zu ermöglichen. Weitere Informationen zu
APT-Pinning findet sich in apt_preferences(5).
Unabhängig von der Methode, die für die Aktualisierung verwendet wird, ist es empfehlenswert, als erstes den Status aller Pakete zu prüfen, um sicherzugehen, dass alle Pakete in einem aktualisierbaren Zustand sind. Der folgende Befehl gibt alle Pakete mit dem Status »halb-installiert«, »Konfiguration fehlgeschlagen« oder mit einem Fehlerstatus aus.
# dpkg --audit
Der Status aller Pakete auf dem System kann auch kontrolliert werden, indem
dselect, aptitude oder andere Kommandos benutzt
werden, wie
# dpkg -l | pager
oder
# dpkg --get-selections "*" > ~/curr-pkgs.txt
Es ist wünschenswert, alle Halten-Markierungen vor dem Upgrade zu entfernen. Sollte eines der für das Upgrade wichtigen Pakete auf Halten stehen, würde das Upgrade nicht funktionieren.
Beachten Sie, dass aptitude eine andere Methode als
apt-get und dselect benutzt, um Pakete als gehalten
zu markieren. Sie können alle Pakete, die auf Halten stehen, mit
# aptitude search "~ahold" | grep "^.h"
identifizieren.
Falls Sie überprüfen möchten, welche Pakete Sie für apt-get auf
Halten stehen hatten, sollten Sie Folgendes benutzen:
# dpkg --get-selections | grep hold
Falls Sie ein Paket lokal verändert und neu kompiliert haben und es nicht umbenannt oder die Versionsnummer mit einer Epoche versehen haben, müssen Sie es auf Halten setzen, um eine Aktualisierung zu verhindern.
Der Paketstatus »Halten« kann mittels aptitude geändert werden:
# aptitude hold Paketname
Ersetzen Sie hold durch unhold, um den »Halten«-Zustand aufzuheben.
Sollten Sie irgendetwas reparieren müssen, ist es am besten sicherzustellen,
dass sources.list immer noch auf Sarge verweist, wie es in Prüfen Ihrer
sources.list, Abschnitt A.2 erklärt wird.
Falls Sie auf Ihrem System Pakete haben, die nicht von Debian stammen, sollte
Ihnen bewusst sein, dass diese im Laufe des Upgrades aufgrund von
Abhängigkeitskonflikten entfernt werden könnten. Falls Sie diese Pakete
installiert haben, indem Sie ein zusätzliches Paketarchiv in Ihre
/etc/apt/sources.list aufgenommen haben, sollten Sie prüfen, ob
dieses Archiv auch für Etch kompilierte Pakete bereit stellt, und diese Zeile
gleichzeitig mit den anderen Änderungen der Quellen für Debian-Pakete anpassen.
Einige Benutzer haben vielleicht inoffizielle, zurückportierte »neuere« Versionen von Paketen, die in Debian auf Ihrem Sarge-System installiert sind. Diese Pakete verursachen höchstwahrscheinlich aufgrund von Dateikonflikten Probleme während einer Aktualisierung[6]. Der Abschnitt Mögliche Probleme während der Aktualisierung, Abschnitt 4.5.8 enthält ein paar Informationen darüber, wie mit Dateikonflikten umgegangen werden kann, falls sie auftreten sollten.
Um zu verhindern, dass aptitude ein paar Pakete entfernt, die
durch Abhängigkeiten installiert wurden, müssen Sie bei diesen manuell die
auto-Markierung entfernen. Dies schließt OpenOffice.org und Vim bei
Desktop-Installationen ein:
# aptitude unmarkauto openoffice.org vim
Gleiches gilt für 2.6er Kernel-Pakete, falls sie durch ein Kernel-Metapaket installiert wurden:
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
Beachten Sie: aptitude kann mit dem folgenden Befehl die Pakete
anzeigen, die mit auto markiert wurden:
# aptitude search 'i~M Paketname'
Vor dem Start der Aktualisierung muss zunächst die
apt-Konfiguration /etc/apt/sources.list für die
Paketlisten angepasst werden.
apt verwendet alle Pakete, die über eine »deb«-Zeile
gefunden werden können, und installiert die Pakete mit der höchsten
Versionsnummer, wobei die zuerst angeführten Zeilen bevorzugt werden (im Falle
von mehreren angegebenen Orten würde typischerweise als erstes eine lokale
Festplatte angeben werden, dann CD-ROMs und schließlich
HTTP/FTP-Spiegelserver).
Auf eine Veröffentlichung kann oft sowohl durch ihren Codenamen (zum Beispiel sarge, etch) als auch durch seinen Statusnamen (zum Beispiel oldstable, stable, testing, unstable) verwiesen werden. Mit dem Codenamen auf eine Veröffentlichung zu verweisen, hat den Vorteil, dass Sie nie durch eine neue Veröffentlichung überrascht werden, und aus diesem Grund werden wir hier diesen Ansatz verfolgen. Dies heißt natürlich, dass Sie selbst auf Bekanntmachungen neuer Veröffentlichungen achten müssen. Verwenden Sie stattdessen den Statusnamen, werden Sie lediglich viele, viele Aktualisierungen für Pakete sehen, sobald eine Veröffentlichung stattgefunden hat.
Die standardmäßige Konfiguration ist auf die Installation von den
Haupt-Debian-Internet-Servern ausgerichtet, Sie können jedoch nach Belieben in
der Datei /etc/apt/sources.list andere Spiegel eintragen. Am
besten sind Spiegel geeignet, die netztopologisch am nächsten sind.
Die Adressen der HTTP- oder FTP-Spiegel sind unter http://www.debian.org/distrib/ftplist
(im Abschnitt »Liste der Debian-Spiegel«) aufgeführt. HTTP-Spiegel sind für
gewöhnlich schneller als FTP-Spiegel.
Nehmen wir zum Beispiel an, Ihr nächstgelegener Debian-Spiegel ist http://mirrors.kernel.org/debian/. Wenn Sie sich diesen Spiegel mit einem Browser oder einem FTP-Programm genauer ansehen, werden Sie feststellen, dass die Hauptverzeichnisse auf die folgende Art und Weise angeordnet sind:
http://mirrors.kernel.org/debian/dists/etch/main/binary-mipsel/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-mipsel/...
Um diesen Spiegel mit apt zu verwenden, muss die Datei
sources.list um die folgende Zeile ergänzt werden:
deb http://mirrors.kernel.org/debian etch main contrib
Beachten Sie, dass »dists« implizit hinzugefügt wird und die Argumente, die der Veröffentlichung folgen, verwendet werden, um Pfade in mehrere Verzeichnisse zu erstrecken.
Nachdem Sie die neuen Quellen angegeben haben, deaktivieren Sie die vorherigen
»deb«-Zeilen in sources.list, indem Sie eine Raute
(#) an den Beginn der Zeilen setzen.
Anstatt HTTP- oder FTP-Paketspiegel zu verwenden, können Sie, falls Sie
möchten, auch /etc/apt/sources.list so anpassen, dass ein Spiegel
auf der lokalen Festplatte (eventuell über NFS eingebunden) verwendet wird.
Nehmen wir an, Ihr Paketspiegel liegt auf /var/ftp/debian/ und hat
Hauptverzeichnisse, die wie folgt aussehen:
/var/ftp/debian/dists/etch/main/binary-mipsel/...
/var/ftp/debian/dists/etch/contrib/binary-mipsel/...
Um dies mit apt zu verwenden, fügen Sie folgende Zeile zu
sources.list hinzu:
deb file:/var/ftp/debian etch main contrib
Beachten Sie, dass »dists« implizit hinzugefügt wird und dass die Argumente, die der Veröffentlichung folgen, verwendet werden, um Pfade in mehrere Verzeichnisse zu erstrecken.
Nachdem Sie neue Quellen hinzugefügt haben, deaktivieren Sie die vorherigen »deb«-Zeilen, indem Sie eine Raute (#) an den Beginn der Zeilen setzen.
Falls Sie ausschließlich CDs verwenden möchten, kommentieren Sie die
bestehenden »deb«-Zeilen in /etc/apt/sources.list
aus, indem Sie eine Raute (#) an den Beginn der Zeilen setzen.
Vergewissern Sie sich, dass es eine Zeile in der Datei /etc/fstab
gibt, die das Einhängen Ihres CD-ROM-Laufwerks unter /cdrom
ermöglicht (der exakte /cdrom-Einhängepunkt wird für
apt-cdrom benötigt). Nehmen wir an, bei Ihnen sei
/dev/hdc das CD-ROM-Laufwerk, dann sollte /etc/fstab
folgende Zeile beinhalten:
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
Beachten Sie: Es darf kein Leerzeichen zwischen den Wörtern defaults,noauto,ro im vierten Feld stehen.
Um zu kontrollieren, dass es funktioniert, legen Sie eine CD ein und versuchen Sie diese ins Dateisystem einzuhängen:
# mount /cdrom # Dies hängt die CD unter dem Einhängepunkt ein
# ls -alF /cdrom # Dies sollte das Wurzelverzeichnis der CD anzeigen
# umount /cdrom # Dies hängt die CD wieder aus
Als nächstes führen Sie
# apt-cdrom add
für jede Debian Binär-CD-ROM die Sie haben, aus, um die Daten von jeder CD zur APT-Datenbank hinzuzufügen.
Die empfohlene Methode, von früheren Debian GNU/Linux-Veröffentlichungen zu
aktualisieren, ist die Benutzung des Paketmanagement-Werkzeugs
aptitude. Dieses Werkzeug trifft sicherere und bessere
Entscheidungen über Pakete als apt-get.
Vergessen Sie nicht, alle benötigten Partitionen (vor allem die Root- und die
/usr-Partition) mit Lese- und Schreibberechtigung einzuhängen.
Dies geht zum Beispiel mit folgendem Befehl:
# mount -o remount,rw /Einhängepunkt
Stellen Sie als nächstes sicher, dass Ihre APT-Quelleinträge (in
/etc/apt/sources.list) entweder auf »etch« oder auf
»stable« verweisen. Es sollte keine Quellzeile geben, die auf
Sarge verweist. Beachten Sie, dass Quellzeilen für CD-ROMs oft auf
»unstable« verweisen – obwohl dies verwirrend sein mag,
sollte dies nicht geändert werden.
Es wird dringendst empfohlen, das Programm /usr/bin/script zu
benutzen, um ein Protokoll des Upgrades anzufertigen. Sollten irgendwelche
Probleme auftreten, haben Sie so ein Protokoll des Geschehenen und können
gegebenenfalls exakte Informationen in einem Fehlerbericht angeben. Um das
Protokollieren zu starten, verfahren Sie wie folgt:
# script -t 2>~/upgrade-etch.time -a ~/upgrade-etch.script
oder ähnlich. Lassen Sie das Skript nicht in ein temporäres Verzeichnis wie
/tmp oder /var/tmp schreiben, da diese beim
Aktualisieren oder bei einem Neustart gelöscht werden könnten.
Das Skript erlaubt Ihnen ebenfalls, Informationen, die über den Bildschirm gelaufen sind, wieder abzurufen. Wechseln Sie einfach auf die virtuelle Konsole 2 (indem Sie Alt-F2 drücken) und benutzen Sie, nachdem Sie sich angemeldet haben, less -R ~root/upgrade-etch.script, um sich die Datei anzeigen zu lassen.
Nachdem die Aktualisierung beendet wurde, kann script beendet
werden, indem auf der Eingabeaufforderung exit eingegeben wird.
Falls Sie den Schalter -t des Programms script verwendet
haben, können Sie das Programm scriptreplay verwenden, um sich die
gesamte Sitzung wieder anzeigen zu lassen:
# scriptreplay ~/upgrade-etch.time ~/upgrade-etch.script
Zunächst muss eine Liste der in der neuen Veröffentlichung verfügbaren Pakete heruntergeladen werden. Dies macht der folgende Befehl:
# aptitude update
Beim ersten Ausführen dieses Befehls mit neuen Quellen werden ein paar Warnungen wegen der Verfügbarkeit der Quellen ausgegeben. Diese Warnungen sind harmlos und werden beim erneuten Aufrufen des Befehls nicht wieder auftauchen.
Vor der Aktualisierung muss sichergestellt sein, dass genügend Speicherplatz
auf der Festplatte frei ist, wenn Sie das System-Upgrade starten, wie in Aktualisieren des restlichen Systems, Abschnitt
4.5.6 beschrieben. Zunächst werden alle Pakete, die via Netzwerk
heruntergeladen werden, in /var/cache/apt/archives (bzw. während
des Herunterladens im Unterverzeichnis partial/) gespeichert.
Also muss genug Platz auf der Partition vorhanden sein, die /var/
enthält, um die Pakete herunterzuladen und vorübergehend zu speichern, die
installiert werden. Danach wird vielleicht noch mehr Platz in anderen
Partitionen benötigt, um sowohl die zu aktualisierenden Pakete zu installieren
(die größere Binärdateien oder mehr Daten enthalten könnten) als auch um neue
Pakete zu installieren, die durch das Upgrade mit ins System kommen. Falls auf
dem System nicht genügend Platz frei ist, könnte das zu einem unvollständigen
Upgrade führen, was schwierig zu beheben sein könnte.
Sowohl aptitude als auch apt zeigen detaillierte
Informationen an, wie viel Festplattenplatz für die Installation benötigt wird.
Die Schätzung kann mit folgendem Befehl angezeigt werden:
# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX Pakete aktualisiert, XXX zusätzlich installiert, XXX werden
entfernt und XXX nicht aktualisiert.
Muss xx.xMB/yyyMB an Archiven herunterladen. Nach dem Entpacken
werden AAAMB zusätzlich belegt sein.
[7]
Falls nicht genügend Platz für das Upgrade frei ist, muss vorher Platz geschaffen werden. Möglichkeiten:
Löschen von Paketen, die früher für Installationen heruntergeladen wurden (in
/var/cache/apt/archive), indem mit apt-get clean oder
aptitude clean der Paketpuffer geleert wird.
Alte Pakete vom System entfernen, die nicht mehr benutzt werden. Falls
popularity-contest installiert ist, kann
popcon-largest-unused verwendet werden, um die Pakete im System
aufzulisten, die nicht benutzen werden und die den meisten Platz belegen. Die
Programme deborphan und debfoster bieten die
Möglichkeit, veraltete Pakete aufzuspüren (siehe Veraltete Pakete, Abschnitt 4.10). Alternativ kann auch
aptitude im »visuellen Modus« gestartet werden; veraltete Pakete
sind unter »Veraltete und selbst erstellte Pakete« zu finden.
Entfernen Sie Pakete vom System, die zu viel Platz belegen und die zurzeit
nicht genutzt werden (Sie können sie nach dem Upgrade wieder installieren).
Sie können die Pakete, die den meisten Platz belegen, mit dpigs
(aus dem Paket debian-goodies) oder mit wajig (führen
Sie wajig size aus) auflisten.
Verschieben Sie Systemprotokolldateien, die in /var/log/ liegen,
vorübergehend auf ein anderes System oder löschen Sie sie.
Achtung: Es ist ratsam, während des Entfernens der Pakete die
sources.list wieder auf sarge zeigen zu lassen; dies ist in Prüfen Ihrer
sources.list, Abschnitt A.2 beschrieben.
Aufgrund bestimmter notwendiger Paketkonflikte zwischen Sarge und Etch kann ein direktes Ausführen von aptitude dist-upgrade eine große Zahl von Paketen entfernen, die Sie eigentlich behalten möchten. Wir empfehlen daher einen zweigeteilten Aktualisierungsprozess. Zunächst ein minimales System-Upgrade und dann das vollständige dist-upgrade.
Führen Sie zunächst
# aptitude upgrade
aus.
Dies hat zur Folge, dass alle Pakete, bei denen ein Upgrade durchgeführt werden kann, ohne dass andere Pakete entfernt oder dazu installiert werden müssen, aktualisiert werden.
Folgen Sie weiter einem minimalen Upgrade mit:
# aptitude install initrd-tools
Dies wird automatisch libc6 und locales aktualisieren
und SELinux-Unterstützungs-Bibliotheken installieren
(libselinux1). Zu diesem Zeitpunkt werden einige Dienste,
einschließlich xdm, gdm und kdm, neu
gestartet. Die Konsequenz hiervon ist, dass lokale X11-Sitzungen ihre
Verbindung verlieren werden.
Der nächste Schritt hängt sehr von der Menge Ihrer installierten Pakete ab. Diese Hinweise zur Veröffentlichung geben allgemeine Ratschläge über die empfohlene Art und Weise, aber im Zweifelsfall ist es empfehlenswert, die Liste der zum Entfernen vorgeschlagenen Pakete bei jeder Methode von Hand durchzusehen.
Auf vielen Systemen sind folgende Pakete vorhanden und werden entfernt:
base-config, hotplug, xlibs,
netkit-inetd, python2.3, xfree86-common
und xserver-common. Eine längere Liste veralteter Pakete für Etch
ist in Veraltete Pakete, Abschnitt 4.10 enthalten.
Dieser Upgrade-Pfad wurde auf Systemen überprüft, die den Desktop-Task unter Sarge installiert haben. Es ist wahrscheinlich die Methode, die die besten Resultate auf einem System erzielt, auf dem der Desktop-Task oder die Pakete gnome oder kde installiert sind.
Es ist wahrscheinlich nicht die korrekte Methode, wenn nicht bereits
die Pakete libfam0c102 und xlibmesa-glu installiert
sind:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Falls ein vollständiges Desktop-System installiert ist, führen Sie Folgendes aus:
# aptitude install libfam0 xlibmesa-glu
Systeme, die ein paar X-Pakete, aber keinen vollständigen
Desktop-Task installiert haben, benötigen eine andere Methode.
Diese Methode funktioniert im Allgemeinen für Systeme, die
xfree86-common installiert haben, einschließlich einiger
Server-Systeme, auf denen mit tasksel Server-Tasks installiert
wurden, da manche dieser Tasks grafische Verwaltungswerkzeuge installieren. Es
ist wahrscheinlich die korrekte Methode für Systeme, auf denen X läuft, die
aber keinen vollständigen Desktop-Task installiert haben.
# dpkg -l xfree86-common | grep ^ii
Prüfen Sie zunächst, ob Sie die Pakete libfam0c102 und
xlibmesa-glu installiert haben:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Falls das Paket libfam0c102 nicht installiert ist, schließen Sie
libfam0 nicht in dem folgenden Befehl ein. Falls das Paket
xlibmesa-glu nicht installiert ist, lassen Sie es in dem folgenden
Befehl weg.[8]
# aptitude install x11-common libfam0 xlibmesa-glu
Beachten Sie, dass die Installation von libfam0 ebenfalls den
Datei-Veränderungs-Monitor (»File Alteration Monitor«, fam) sowie
den RPC-Portmapper (portmap) auf Ihrem System installieren wird,
falls sie nicht bereits installiert sind. Beide Pakete aktivieren neue Dienste
auf Ihrem System, aber sie können beide konfiguriert werden, lediglich auf die
(interne) loopback-Netzwerk-Schnittstelle zu achten.
Auf Systemen, die kein X installiert haben, sollten keine weiteren aptitude install-Befehle notwendig sein und Sie können mit dem nächsten Schritt fortfahren.
Die Version von udev in Etch unterstützt keine Kernel vor Version
2.6.15 (einschließlich der 2.6.8er Kernel aus Sarge) und die Version von
udev in Sarge wird nicht mit dem aktuellen Kernel
zusammenarbeiten. Zusätzlich wird die Installation von udev unter
Etch das Entfernen von hotplug erzwingen, welches von Linux 2.4er
Kerneln verwendet wird.
Als eine Konsequenz werden vorherige Kernel-Pakete wahrscheinlich nicht mehr
nach dieser Aktualisierung booten. Ähnlich gibt es ein Zeitfenster während der
Aktualisierung, in dem udev bereits aktualisiert, aber der neuste
Kernel noch nicht installiert wurde. Falls das System zu diesem Zeitpunkt,
mitten in der Aktualisierung, neu gestartet werden sollte, kann es sein, dass
es nicht mehr startet, da Treiber nicht korrekt erkannt und geladen werden.
(Siehe Vorbereiten einer sicheren Umgebung
für die Aktualisierung, Abschnitt 4.1.4 für Empfehlungen, sich auf diese
Möglichkeit vorzubereiten, falls eine Fernaktualisierung erfolgt.)
Sofern das System den Desktop-Task installiert hat oder andere Pakete, die eine nicht akzeptable Anzahl von Paketentfernungen erfordern, ist es an dieser Stelle empfohlen, zunächst den Kernel separat zu aktualisieren.
Um mit der Aktualisierung des Kernels fortzufahren, geben Sie folgenden Befehl ein:
# aptitude install linux-image-2.6-Variante
Siehe Installieren des Kernel-Metapakets, Abschnitt 4.6.1 für eine Hilfe, welche Variante des Kernel-Pakets installiert werden sollte.
Im Falle eines Desktops kann unglücklicherweise nicht garantiert werden, dass
das neue Kernel-Paket sofort nach der Installation des neuen udev
installiert wird. Es gibt daher ein Zeitfenster unbekannter Länge, in dem Ihr
System keinen Kernel mit voller Hotplug-Fähigkeit hat. Im Abschnitt Aktualisieren Ihres Kernels und zugehöriger Pakete,
Abschnitt 4.6 ist beschrieben, wie das System so konfiguriert werden kann,
dass es nicht hotplug zum Starten benötigt.
Nun kann der Hauptteil der Aktualisierung mit folgendem Befehl erfolgen:
# aptitude dist-upgrade
Dies führt eine vollständige Aktualisierung Ihres Systems durch, d.h. es installiert die neueste verfügbare Version aller Pakete und löst alle möglichen Änderungen der Abhängigkeiten zwischen den Releases auf. Falls notwendig, wird es ein paar neue Pakete installieren (normalerweise neue Bibliotheken oder umbenannte Pakete) und alle überholten Pakete entfernen.
Wenn Sie von CD-ROMs aktualisieren, werden Sie zu unterschiedlichen Zeitpunkten dazu aufgefordert, CDs einzulegen. Vielleicht werden Sie auch dazu aufgefordert, eine CD mehrmals einzulegen. Dies ergibt sich aus der Verteilung voneinander abhängiger Pakete über die CDs.
Neue Versionen derzeit installierter Pakete, die nicht aktualisiert werden
können, ohne den Installationsstatus eines anderen Paketes zu ändern, werden
bei ihrer installierten Version belassen (und als »held back« (zurückgehalten)
angezeigt). Dies können Sie entweder dadurch lösen, dass Sie diese Pakete in
aptitude als zu installieren markieren, oder indem Sie
aptitude -f install Paket versuchen.
Nach der Aktualisierung können Sie mit der neuen Version von apt
nun die Paketinformationen aktualisieren, was den neuen Mechanismus zum Prüfen
der Paketsignaturen einschließt:
# aptitude update
Die Aktualisierung wird bereits die Schlüssel zur Signierung von Debians
Paketarchiv enthalten und aktiviert haben. Falls Sie andere (inoffizielle)
Paketquellen hinzugefügt haben, wird apt nun Warnungen ausgeben,
dass es nicht in der Lage war, die Legitimation der heruntergeladenen Quellen
zu überprüfen und nicht manipulationssicher ist. Weitere Informationen hierzu
sind in Paketverwaltung, Abschnitt
2.2.1 zu finden.
Die neue Version von apt erlaubt es, lediglich die Unterschiede
zwischen den Paketindex-Dateien herunterzuladen (pdiff) statt des
gesamten Paketindex. Weitere Informationen hierzu sind unter Langsames Auffrischen von
APT-Paketindex-Dateien, Abschnitt 5.1.4 aufgeführt.
Falls eine Operation von aptitude, apt-get oder
dpkg mit der Fehlermeldung
E: Dynamic MMap ran out of room
scheitert, ist die Standardgröße des Zwischenspeichers unzureichend. Sie
können dies entweder durch Auskommentieren nicht benötigter Zeilen in
/etc/apt/sources.list lösen, oder indem Sie die Größe des
Zwischenspeichers erhöhen. Den Zwischenspeicher können Sie mit der Einstellung
APT::Cache-Limit in /etc/apt/apt.conf vergrößern: Der
folgende Befehl setzt ihn auf einen für das Upgrade passenden Wert:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
Dies setzt allerdings voraus, dass diese Variable nicht bereits in dieser Datei gesetzt ist.
Manchmal ist es notwendig die APT::Force-LoopBreak-Option in APT
zu aktivieren, damit bei eventuell auftretenden Conflicts/Pre-Depends-Schleifen
temporär wichtige Pakete entfernt werden können. aptitude wird
Sie darüber informieren und die Aktualisierung abbrechen. Sie können das
umgehen, indem Sie die Option -o APT::Force-LoopBreak=1 für
aptitude benutzen.
Es ist auch möglich, dass die Abhängigkeitsstruktur des Systems so kaputt ist,
dass ein manueller Eingriff notwendig wird. Für gewöhnlich bedeutet dies, dass
aptitude verwendet werden muss oder
# dpkg --remove Paketname
um einige der kaputten Pakete zu löschen, oder
# aptitude -f install
# dpkg --configure --pending
In extremen Fällen müssen Sie vielleicht mit einem Befehl wie dem folgenden eine Neuinstallation erzwingen:
# dpkg --install /Pfad/zum/Paket/Paketname.deb
Dateikonflikte sollten bei einer Aktualisierung eines »reinen« Sarge-Systems nicht vorkommen, können aber auftreten, falls Sie inoffizielle Rückportierungen (Backports) installiert haben. Ein Dateikonflikt resultiert in einem Fehler wie diesem:
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>
Sie können versuchen, diesen Dateikonflikt zu lösen, indem Sie das Entfernen des Paketes, das in der letzten Zeile der Fehlermeldung erwähnt wird, erzwingen:
# dpkg -r --force-depends Paketname
Nachdem dies alles repariert ist, sollten Sie die Aktualisierung fortsetzen können, indem Sie die vorher beschriebenen aptitude-Befehle wiederholen.
Während der Aktualisierung werden Ihnen einige Fragen zur Konfiguration oder
Neukonfiguration verschiedener Pakete gestellt. Wenn Sie gefragt werden, ob
eine Datei in den Verzeichnissen /etc/init.d oder
/etc/terminfo oder die Datei /etc/manpath.config
durch die Datei des Paketbetreuers ersetzt werden soll, so ist es normalerweise
notwendig mit »ja« bzw. »yes« zu antworten, um sicherzustellen, dass das
System in einem konsistenten Zustand ist. Sie können die alte Version immer
wiederherstellen, da sie mit der Erweiterung .dpkg-old gesichert
wird.
Falls Sie sich nicht sicher sind, was Sie tun sollen, schreiben Sie den Namen des Pakets oder der Datei auf und kümmern Sie sich später darum. Sie können immer noch in der Skript-Datei nach der Meldung suchen, die am Bildschirm während der Aktualisierung ausgegeben wurde.
Dieser Abschnitt erklärt, wie Sie Ihren Kernel aktualisieren und mögliche
Probleme bezüglich dieser Aktualisierung erkennen. Sie können entweder ein von
Debian angebotenes linux-image-*-Paket installieren, oder einen
angepassten Kernel aus den Quellen kompilieren.
Dieser Abschnitt enthält viele Informationen in Verbindung mit
initramfs-tools und udev. Jedoch benutzen die Kernel
der mipsel-Architektur keine initrd, um das System zu starten. Einige dieser
Informationen sind also nicht relevant. Diese Informationen sind trotzdem
aufgeführt, da aus anderen Gründen udev installiert sein könnte.
Es ist weiterhin möglich, hotplug zur Hardware-Erkennung zu
verwenden, wenn udev nicht installiert ist.
Falls derzeit ein 2.4er Kernel verwendet wird, lesen Sie bitte Auf einen 2.6er Kernel aktualisieren, Abschnitt 5.2 sorgfältig durch.
Es wird dringend empfohlen, bei der Aktualisierung von Sarge nach Etch ein neues linux-image-2.6-*-Metapaket zu installieren. Dieses Paket könnte bei einem dist-upgrade automatisch mit installiert werden. Dies kann mit folgendem Befehl geprüft werden:
# dpkg -l "linux-image*" | grep ^ii
Falls hier keine Ausgabe erfolgt, so muss das linux-image-Paket von Hand installiert werden. Eine Liste der verfügbaren linux-image-2.6-Metapakete kann mit folgendem Befehl angezeigt werden:
# apt-cache search linux-image-2.6- | grep -v transition
Falls Sie sich nicht sicher sind, welches Paket Sie auswählen sollen, rufen Sie
uname -r auf, und wählen Sie das Paket mit ähnlichen Namen. Falls
Sie beispielsweise »2.4.27-3-686« sehen, so lautet die Empfehlung, das Paket
linux-image-2.6-686 zu installieren. Sie können sich auch mit
apt-cache die lange Beschreibung jedes Paketes anzeigen lassen, um
die beste verfügbare Variante auszuwählen. Beispiel:
# apt-cache show linux-image-2.6-686
Sie sollten aptitude install verwenden, um es zu installieren. Sobald Sie diesen neuen Kernel installiert haben, sollten Sie bei der nächsten sich bietenden Gelegenheit das System neu starten, um von den Vorteilen der neuen Kernel-Version zu profitieren.
Für die eher Abenteuerlustigen gibt es einen einfachen Weg, einen angepassten
Kernel unter Debian zu kompilieren. Installieren Sie das Werkzeug
kernel-package und lesen Sie die Dokumentation unter
/usr/share/doc/kernel-package.
Falls Sie derzeit einen Kernel der 2.6er Serie aus Sarge benutzen, wird diese Aktualisierung automatisch durchgeführt werden, nachdem Sie die vollständige Aktualisierung der Systempakete durchgeführt haben (wie es unter Paketaktualisierung, Abschnitt 4.5 beschrieben ist).
Falls es möglich ist, sollten Sie die Aktualisierung des Kernels separat vom Haupt-dist-upgrade vornehmen, um die Chancen eines zeitweilig nicht startbaren Systems zu minimieren. Lesen Sie dazu bitte Aktualisieren des Kernels, Abschnitt 4.5.5 für weitere Informationen, die diesen Prozess beschreiben. Beachten Sie, dass dies erst nach dem minimalen Aktualisierungsprozess, wie er unter Minimale Systemaktualisierung, Abschnitt 4.5.4 beschrieben wird, durchgeführt werden sollte.
Dieser Schritt kann auch durchgeführt werden, falls ein eigener angepasster
Kernel verwendet wird, und zu dem Kernel aus Etch gewechselt werden soll.
Falls die installierte Version von udev nicht unterstützt wird,
dann ist dies nach der minimalen Aktualisierung empfehlenswert. Falls die
installierte Version von udev unterstützt wird, kann damit bis
nach der vollständigen Aktualisierung gewartet werden.
Falls ein 2.4er Kernel installiert und das System auf hotplug
angewiesen ist, um seine Hardware zu erkennen, sollte zunächst auf den 2.6er
Kernel von Sarge aktualisiert werden, bevor die Aktualisierung des
Gesamtsystems erfolgt. Jedoch ist es empfehlenswert, zuerst zu testen, ob der
Kernel der 2.6er Serie erfolgreich startet und die gesamte Hardware erkennt,
bevor die Aktualisierung durchgeführt wird. Das Paket hotplug
wird (zugunsten von udev) bei der vollständigen Aktualisierung
entfernt. Falls der Kernel dann noch nicht aktualisiert ist, könnte das System
ab diesem Zeitpunkt möglicherweise nicht mehr korrekt starten. Sobald der
2.6er Kernel aus Sarge verwendet wird, kann die Aktualisierung des Kernels, wie
unter Aktualisieren von einem 2.6er Kernel,
Abschnitt 4.6.2 beschrieben, erfolgen.
Falls das System nicht auf hotplug angewiesen ist[9] kann das Aktualisieren des
Kernels nach dem vollständigen Aktualisieren des Systems erfolgen, wie in Aktualisieren des restlichen Systems, Abschnitt
4.5.6 beschrieben. Sobald das System aktualisiert wurde, kann durch den
folgenden Befehl ein neuer Kernel installiert werden (bitte dabei den zum
System passenden Paketnamen verwenden, in dem <Variante> passend
ersetzt wird):
# aptitude install linux-image-2.6-<Variante>
Etch enthält einen robusteren Mechanismus zur Hardware-Erkennung als frühere Versionen. Allerdings könnte dies dazu führen, dass Geräte in Ihrem System in einer anderen Reihenfolge erkannt werden als früher, was sich auf die Reihenfolge der Gerätenamen auswirken könnte, die zugewiesen werden. Falls Sie zum Beispiel zwei Netzwerkkarten haben, die von verschiedenen Treibern bedient werden, könnte es sein, dass die Gerätenamen eth0 und eth1 verglichen mit mit der früheren Situation vertauscht sind. Bitte beachten Sie, dass die Verwendung des neuen Mechanismus auch bedeutet, dass, falls Sie in einem laufenden Etch-System z.B. Netzwerkkarten austauschen, die neue Karte auch einen neuen Schnittstellennamen bekommt.
Bei Netzwerkkarten können Sie diese Umsortierung vermeiden, indem Sie Regeln
für udev verwenden; genauer durch die Definitionen in
/etc/udev/rules.d/z25_persistent-net.rules[10]. Alternativ können Sie das
Programm ifrename verwenden, um ein physikalisches Gerät zur
Boot-Zeit einem bestimmten Namen zuzuordnen. Siehe ifrename(8)
und iftab(5) für nähere Informationen. Diese beiden Alternativen
(udev und ifrename) sollten nicht gleichzeitig
verwendet werden.
Bei Speichergeräten vermeiden Sie die Änderung der Gerätenamen, indem Sie mit
initramfs-tools die Treibermodule für Speichergeräte so
konfigurieren, dass sie in der gleichen Reihenfolge geladen werden wie auf dem
laufenden (alten) System. Um die alte Reihenfolge herauszufinden, in der die
Module geladen werden, schauen Sie sich die Ausgabe von lsmod an.
lsmod listet Module in der umgekehrten Reihfolge auf, in der sie
geladen wurden, d.h. das Modul, das an erster Stelle in der Liste steht, wurde
als letztes geladen. Beachten Sie, dass dies nur bei Geräten funktioniert, die
einer gleichbleibenden Nummerierung unterliegen (beispielsweise PCI-Geräte).
Allerdings wird diese Reihenfolge beeinflusst, wenn Module nach dem Systemstart
entladen oder geladen werden. Außerdem könnte Ihr Kernel bestimmte Treiber
fest einkompiliert haben, so dass diese Namen nicht in der Ausgabe von
lsmod erscheinen. Sie können diese Treibernamen und die
Reihenfolge, in der sie geladen werden, vielleicht identifizieren, indem Sie
die Datei /var/log/kern.log oder die Ausgabe von
dmesg durchforsten.
Fügen Sie diese Modulnamen in der Reihenfolge zu
/etc/initramfs-tools/modules hinzu, in der sie beim Systemstart
geladen werden sollen. Einige Modulnamen könnten sich von Sarge nach Etch
geändert haben. Zum Beispiel heißt »sym53c8xx_2« jetzt »sym53c8xx«.
Sie müssen dann mit update-initramfs -u -k all Ihre initramfs-Images neu erzeugen.
Sobald Sie nach dem Upgrade dann einen Etch-Kernel und udev am
Laufen haben, können Sie Ihr System neu konfigurieren, so dass die Geräte über
einen Alias angesprochen werden, der nicht von der Reihenfolge abhängt, in der
die Treiber geladen werden. Diese Aliase befinden sich unterhalb von
/dev/disk/.
Wenn aptitude dist-upgrade beendet wurde, ist die »formale« Aktualisierung fertig, aber es gibt noch ein paar Kleinigkeiten, um die Sie sich vor dem nächsten Neustart kümmern sollten.
Die von Debian erstellten Kernel unterstützen kein devfs mehr. Benutzer von devfs müssen daher das System manuell konvertieren, bevor ein Etch-Kernel verwendet wird.
Falls in /proc/mounts die Zeichenkette »devfs« vorhanden ist, wird
sehr wahrscheinlich devfs benutzt. Eine Konfigurationsdatei, die
Namen im Stil von devfs referenziert, muss angepasst werden, damit
sie Namen im udev-Stil enthält. Dateien, die am
wahrscheinlichsten devfs-artige Namen enthalten, sind
/etc/fstab, /etc/lilo.conf,
/boot/grub/menu.lst und /etc/inittab.
Weitere Informationen zu möglichen Problemen sind im Fehlerbericht #341152 verfügbar.
mdadm benötigt jetzt eine Konfigurationsdatei, um MD-Arrays (RAID) von der
Initial-Ramdisk und während der Initialisierungssequenz des Systems zu
assemblieren. Bitte lesen und befolgen Sie die Anweisungen in
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz, nachdem das Paket
aktualisiert wurde, jedoch vor dem Reboot. Die neueste
Version dieser Datei finden Sie auch unter http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file;
bitte konsultieren Sie sie, falls Probleme auftreten sollten.
Nach der Aktualisierung gibt es ein paar Dinge, die Sie als Vorbereitung für die nächste Veröffentlichung tun können.
Falls Sie grub benutzen, editieren Sie
/etc/kernel-img.conf und passen Sie den Pfad des Programms
update-grub von /sbin/update-grub zu
/usr/sbin/update-grub an.
Falls ein neues Kernel-Image-Metapaket aufgrund von Abhängigkeiten eines älteren mitgezogen wurde, wird es als automatisch installiert markiert. Dies sollte korrigiert werden:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Sarge-Kernel-Metapakete sollten mit diesem Befehl entfernt werden:
# aptitude purge kernel-image-2.6-<Variante>
Verschieben Sie jegliche Konfigurationsoptionen von
/etc/network/options nach /etc/sysctl.conf. Bitte
lesen Sie /usr/share/doc/netbase/README.Debian für Details.
Entfernen Sie alte und unbenutzte Pakete, wie es unter Veraltete Pakete, Abschnitt 4.10 beschrieben wird. Sie sollten prüfen, welche Konfigurationsdateien diese Pakete benutzen und sie dann vollständig entfernen (»purgen«), um auch ihre Konfigurationsdateien zu entfernen.
Mit der Veröffentlichung von Lenny wird eine größere Anzahl von Server-Paketen missbilligt werden. Deswegen führt eine Aktualisierung dieser zu neueren Versionen zum jetzigen Zeitpunkt zu weniger Problemen bei der Aktualisierung zu Lenny.
Dies schließt die folgenden Pakete ein:
apache (1.x), Nachfolger ist apache2
bind8, Nachfolger ist bind9
php4, Nachfolger ist php5
postgresql-7.4, Nachfolger ist postgresql-8.1
exim 3, Nachfolger ist exim4
Mehrere tausend neue Pakete werden mit Etch neu eingeführt, aber es werden ebenfalls mehr als zweitausend Pakete, die in Sarge enthalten waren, entfernt. Es gibt keinen Weg, diese veralteten Pakete zu aktualisieren. Während auf Ihrer Seite nichts dagegen spricht, ein veraltetes Paket weiter zu benutzen, falls Sie dies möchten, wird das Debian-Projekt dafür normalerweise ein Jahr[11] nach der Veröffentlichung von Etch die Sicherheitsunterstützung einstellen und wird in der Zwischenzeit auch keine andere Unterstützung dafür anbieten. Es wird empfohlen, falls möglich auf eine Alternative umzusteigen.
Es gibt viele Gründe, warum ein Paket aus der Distribution entfernt werden könnte: es wird vom ursprünglichen Autor nicht mehr weiterentwickelt; es ist kein Debian-Entwickler mehr an der Betreuung dieses Paketes interessiert; die Funktionalität wurde von einer anderen Software (oder einer neueren Version) übernommen oder es wird aufgrund von Fehlern nicht mehr für Etch in Erwägung gezogen. Ist Letzteres der Fall, könnten diese Pakete noch in der »Unstable«-Distribution enthalten sein.
Festzustellen, welche Pakete in einem aktualisierten System »veraltet« sind,
ist einfach, da die Paketverwaltungs-Oberflächen diese als solche markieren.
Falls Sie aptitude verwenden, werden Sie eine Liste dieser Pakete
im Abschnitt »Obsolete and Locally Created Packages« (bzw. »Veraltete und
selbst erstellte Pakete«) finden. dselect hat einen ähnlichen
Abschnitt, aber die dargestellte Liste kann sich unterscheiden. Falls Sie
aptitude bereits in Sarge benutzt haben, hat es beobachtet, welche
Pakete Sie selbst installiert haben, und wird nur jene als »veraltet«
markieren, die lediglich aufgrund von Abhängigkeiten installiert wurden und die
nun nicht mehr benötigt werden, da das darauf aufbauende Paket inzwischen
entfernt wurde. Im Gegensatz zu deborphan wird
aptitude nicht jene Pakete als »obsolete« markieren, die Sie
selbst installiert haben, sondern nur jene, die automatisch durch
Abhängigkeiten nachgezogen wurden.
Es gibt zusätzliche Werkzeuge, die Sie zum Aufspüren veralteter Programme
benutzen können, wie zum Beispiel deborphan,
debfoster und cruft. deborphan ist
wärmstens zu empfehlen, obwohl es (im Standardmodus) lediglich veraltete
Bibliotheken auflistet: Pakete aus den Abschnitten »libs« oder »oldlibs«, die
von keinem anderen Paket benutzt werden. Entfernen Sie nicht einfach blind die
Pakete, die diese Werkzeuge vorschlagen, insbesondere falls Sie aggressive,
Nicht-Standard-Optionen benutzen, die dazu neigen, Fehlalarme zu erzeugen. Es
wird im höchsten Maße nahegelegt, dass Sie zum Entfernen vorgeschlagene Pakete
noch einmal manuell nachkontrollieren (zum Beispiel ihre Beschreibung, ihren
Inhalt und ihre Größe), bevor Sie sie entfernen.
Debians Fehlerdatenbank
enthält oft zusätzliche Informationen, warum ein Paket entfernt wurde. Sie
sollten sowohl die archivierten Fehlerberichte des Paketes selbst als auch die
archivierten Fehler des Pseudo-Pakets
ftp.debian.org durchsehen.
Manche Pakete aus Sarge wurden in Etch in mehrere Pakete aufgeteilt, was oft die Wartungsfähigkeit verbessert. Um die Aktualisierung dieser Pakete in solchen Fällen zu vereinfachen, enthält Etch einige Pseudo-Pakete (engl. dummy packages): Leere Pakete, die den gleichen Namen wie die alten Pakete aus Sarge haben, mit Abhängigkeiten, die eine Installation der neuen Pakete erzwingen. Diese Pseudo-Pakete werden als »obsolete« (veraltet) angesehen und könnten nach der Aktualisierung gefahrlos entfernt werden.
In den meisten (aber nicht allen) Beschreibungen der Pseudo-Pakete ist ihr
Zweck angegeben. Paketbeschreibungen von Pseudo-Paketen sind nicht
vereinheitlicht, Sie werden allerdings deborphan mit den
--guess-*-Parametern nützlich finden, um solche Pakete auf Ihrem
System zu finden. Beachten Sie, dass manche Pseudo-Pakete nicht dazu gedacht
sind, nach dem Aktualisieren von Ihrem System entfernt zu werden, sondern um
die derzeit verfügbare Version eines Programms über die Zeit hinweg zu
beobachten.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ weiter ]
Hinweise zur Debian GNU/Linux 4.0-Veröffentlichung (»Etch«) auf Mipsel
$Id: release-notes.de.sgml,v 1.69 2007-08-16 22:36:22 jseidel Exp $debian-doc@lists.debian.org