[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ weiter ]


Hinweise zur Debian GNU/Linux 4.0-Veröffentlichung (»Etch«) auf IA-64
Kapitel 4 - Aktualisieren von früheren Versionen


4.1 Vorbereiten des Upgrades

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.


4.1.1 Sichern von Daten und Konfigurationsinformationen

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.


4.1.2 Informieren Sie Ihre Benutzer im Vorfeld

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.


4.1.3 Vorbereiten der Wiederherstellung

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.


4.1.3.1 Debug-Shell während des Systemstarts mit initrd

Das Paket initramfs-tools fügt eine Debug-Shell[6] den erstellten initrds hinzu. Sollte beispielsweise die initrd das root-Dateisystem nicht einbinden können, wird diese Debug-Shell gestartet, und es stehen grundlegende Befehle zur Verfügung, die helfen, das Problem aufzuspüren und möglicherweise zu beheben.

Grundlegende Dinge, die Sie prüfen sollten, sind: Das Vorhandensein der korrekten Gerätedateien in /dev; welche Module geladen wurden (cat /proc/modules) und ob die Ausgabe von dmesg Fehler beim Laden von Treibern auflistet. Die Ausgabe von dmesg wird Ihnen auch zeigen, welche Gerätedateien welcher Festplatte zugeordnet wurden; Sie sollten dies mit der Ausgabe von echo $ROOT vergleichen, um sicherzustellen, dass das root-Dateisystem auch auf dem richtigen Gerät erwartet wird.

Wenn das Problem behoben ist, kann mit exit die Debug-Shell verlassen, und mit dem Boot-Prozess an der Stelle fortgefahren werden, an der er hängen geblieben war. Natürlich sollte auch das zugrundeliegende Problem behoben und die initrd neu erstellen werden, so dass der nächste Start des Systems nicht erneut fehlschlägt.


4.1.4 Vorbereiten einer sicheren Umgebung für die Aktualisierung

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.


4.1.5 Unterstützung für 2.2er Kernel wurde entfernt

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.


4.2 Prüfen des Systemstatus

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.


4.2.1 Durchsehen schwebender Aktionen der Paketverwaltung

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.


4.2.2 APT-Pinning deaktivieren

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).


4.2.3 Prüfen des Paketstatus

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.


4.2.4 Inoffizielle Paketquellen und Backports

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[7]. 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.


4.3 Manuelles Abwählen von Paketen

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'

4.4 Vorbereiten der Quellen für APT

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.


4.4.1 Angabe von zusätzlichen APT-Internet-Quellen

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-ia64/...
     http://mirrors.kernel.org/debian/dists/etch/contrib/binary-ia64/...

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.


4.4.2 Hinzufügen von lokalen Spiegelquellen für APT

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-ia64/...
     /var/ftp/debian/dists/etch/contrib/binary-ia64/...

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.


4.4.3 Hinzufügen von CD-ROM- oder DVD-APT-Quellen

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.


4.5 Paketaktualisierung

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.


4.5.1 Aufnehmen der Sitzung

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

4.5.2 Auffrischen der Paketliste

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.


4.5.3 Stellen Sie sicher, dass Sie genug Speicherplatz für das Upgrade haben

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.

[8]

Falls nicht genügend Platz für das Upgrade frei ist, muss vorher Platz geschaffen werden. Möglichkeiten:

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.


4.5.4 Minimale Systemaktualisierung

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.


4.5.4.1 Aktualisieren eines Desktop-Systems

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

4.5.4.2 Upgrading eines Systems mit ein paar installierten X-Paketen

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.[9]

     # 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.


4.5.4.3 Aktualisieren eines Systems ohne installiertes X

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.


4.5.5 Aktualisieren des Kernels

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.


4.5.6 Aktualisieren des restlichen Systems

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.


4.5.7 Paketsignaturen erhalten

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.1.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.


4.5.8 Mögliche Probleme während der Aktualisierung

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.


4.6 Aktualisieren Ihres Kernels und zugehöriger Pakete

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.

Viele Informationen dieses Abschnittes gehen von der Annahme aus, dass ein modularer Kernel von Debian zusammen mit initramfs-tools und udev verwendet wird. Falls ein angepasster Kernel verwendet wird, benötigt dieser keine initrd. Falls ein anderer initrd-Generator verwendet wird, könnten einige dieser Informationen irrelevant sein.

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.


4.6.1 Installieren des Kernel-Metapakets

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.


4.6.2 Aktualisieren von einem 2.6er Kernel

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.


4.6.3 Aktualisieren von einem 2.4er Kernel

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[10] 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>

4.6.4 Andere Reihenfolge der Gerätebezeichnungen

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[11]. 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/.


4.6.5 Andere Reihenfolge der Bezeichnungen für serielle Geräte

Falls Sie eine HP-Maschine haben und den MP Serial Console-Port benutzen (der Anschluss, der an dem 3-fach-Kabel mit »console« bezeichnet ist), wird durch dieses Kernel-Upgrade Ihre Konsole funktionsunfähig!

Während eines Neustarts wird das System die Meldung »Loading initrd....« anzeigen und dann stehen bleiben. Beachten Sie, dass Systeme mit veralteter Firmware ähnliche Symptome zeigen werden, obwohl der Grund bei Inkompatibilitäten des Kernels liegt (siehe Auf einen 2.6er Kernel aktualisieren, Abschnitt 5.2).

Lesen Sie bitte vor dem Upgrade die folgenden Informationen.

Sie finden mehr Details über diese Änderungen und Hinweise zur Fehlersuche unter http://lists.debian.org/debian-ia64/2005/01/msg00008.html.


4.6.6 Zeitabhängige Probleme beim Starten

Falls eine mit initramfs-tools erstellte initrd benutzt wird, erfolgt in manchen Fällen das Erstellen der Geräte durch udev zu spät.

Die üblichen Symptome sind ein Fehlschlagen des Starts, da das root-Dateisystem nicht eingebunden werden kann und eine Debug-Shell gestartet wird, aber dort dann alle benötigten Geräte in /dev vorhanden sind. Dies tritt häufig in Fällen auf, in denen das root-Dateisystem auf einer USB-Platte oder auf einem RAID liegt, insbesondere, wenn lilo verwendet wird.

Eine Abhilfe für dieses Problem ist der Boot-Parameter rootdelay=9. Dieser Wert für die Zeitüberschreitung (in Sekunden) muss unter Umständen angepasst werden.


4.7 Was Sie vor dem nächsten Neustart tun sollten

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.


4.7.1 Konvertieren von devfs

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.


4.7.2 mdadm aktualisieren

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.


4.8 Vorbereiten auf die nächste Veröffentlichung

Nach der Aktualisierung gibt es ein paar Dinge, die Sie als Vorbereitung für die nächste Veröffentlichung tun können.


4.9 Missbilligte Pakete

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:


4.10 Veraltete Pakete

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[12] 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.


4.10.1 Pseudo-Pakete

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 IA-64

$Id: release-notes.de.sgml,v 1.69 2007-08-16 22:36:22 jseidel Exp $

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