Wir empfehlen Ihnen nachdrücklich, ein komplettes Backup durchzuführen oder zumindest alle Daten und Konfigurationsinformationen zu sichern, die Sie nicht verlieren möchten, bevor Sie das Upgrade Ihres Systems durchführen. Die Upgrade-Werkzeuge und der zugehörige Prozess sind recht zuverlässig, aber ein Versagen der Hardware während des Upgrades könnte zu einem schwer beschädigten System führen.

Am wichtigsten für das Backup sind die Inhalte von /etc, /var/lib/dpkg, /var/lib/aptitude/pkgstates und die Ausgabe von dpkg --get-selections "*" (die Anführungszeichen sind wichtig).

Der Upgrade-Prozess ändert nichts im Verzeichnisbaum /home. Allerdings ist bekannt, dass einige Anwendungen (z.B. Teile der Mozilla-Suite und die GNOME- und KDE-Desktop-Umgebungen) existierende Benutzereinstellungen mit neuen Vorgaben überschreiben, wenn eine neue Version der Anwendung das erste Mal von einem Benutzer gestartet wird. Zur Vorsicht sollten Sie überlegen, die versteckten Dateien und Verzeichnisse (Dateien und Verzeichnisse, die mit einem Punkt beginnen, auch „dotfiles“ genannt) in den Home-Verzeichnissen der Benutzer zu sichern. Dieses Backup könnte Ihnen dabei helfen, die alten Einstellungen wiederherzustellen. Auch sollten Sie die Benutzer des Systems darüber informieren.

Jede Paketinstallation muss mit den Rechten des Superusers ausgeführt werden, melden Sie sich daher als root an oder verwenden Sie su oder sudo, um die notwendigen Rechte zu erlangen.

Für das Upgrade gibt es ein paar Voraussetzungen; Sie sollten diese überprüfen, bevor Sie das Upgrade durchführen.

Es empfiehlt sich, alle Nutzer vor dem geplanten Upgrade zu informieren, auch wenn Benutzer, die über ssh auf Ihr System zugreifen, wenig von dem Upgrade mitbekommen sollten und es ihnen möglich sein sollte, weiterzuarbeiten.

Falls Sie zusätzliche Vorsichtsmaßnahmen ergreifen wollen, sichern Sie die Partition /home vor dem Upgrade oder hängen Sie diese mit umount aus.

Wahrscheinlich müssen Sie beim Upgrade auf Lenny auch ein Kernel-Upgrade durchführen, daher wird normalerweise ein Systemneustart notwendig. Normalerweise erfolgt dieser, nachdem das Upgrade beendet wurde.

Aufgrund der vielen Änderungen im Kernel zwischen Etch und Lenny im Hinblick auf Treiber, Hardware-Erkennung und der Benennung und Sortierung von Gerätedateien besteht ein reales Risiko, dass beim Systemneustart nach dem Upgrade Probleme auftauchen. Eine ganze Reihe von bekannten, möglichen Problemen sind in diesem und den nächsten Kapiteln dieser Veröffentlichungshinweise dokumentiert.

Aus diesem Grund ist es sinnvoll, sicherzustellen, dass Sie die Möglichkeit haben, Ihr System wieder zum Laufen zu bringen, falls der Start fehlschlagen sollte oder (bei fernverwalteten Systemen) der Aufbau der Netzwerkverbindung nicht erfolgreich sein sollte.

Falls Sie das Upgrade aus der Ferne über eine ssh-Verbindung durchführen, wird dringend empfohlen, dass Sie die nötigen Vorkehrungen treffen, um den Server über eine serielle Terminalverbindung aus der Ferne erreichen zu können. Es besteht die Möglichkeit, dass nach dem Kernel-Upgrade und anschließendem Neustart einige Geräte andere Namen bekommen (wie in Abschnitt 4.6.2, „Neusortierung der Gerätenummerierung“ beschrieben) und Sie die Systemkonfiguration über eine lokale Konsole korrigieren müssen. Auch könnte es sein, dass Sie das System über eine lokale Konsole wiederherstellen müssen, wenn es in der Mitte des Upgrade-Prozesses versehentlich neu gebootet wird.

Am naheliegendsten ist es in einem solchen Fall, zu versuchen, das System mit Ihrem alten Kernel zu starten. Aus verschiedenen Gründen, die an anderer Stelle in diesem Dokument beschrieben sind, kann allerdings nicht garantiert werden, dass dies funktioniert.

Falls dies fehlschlägt, benötigen Sie eine alternative Möglichkeit, Ihr System zu starten und zu reparieren. Eine Möglichkeit ist, ein spezielles Rettungs-Image oder eine Linux-Live-CD zu verwenden. Nachdem Sie davon gebootet haben, sollten Sie die Wurzel Ihres Dateisystems (/) einhängen und ein chroot darauf ausführen, um das Problem zu untersuchen und zu beheben.

Eine andere von uns empfohlene Option ist die Verwendung des Rettungsmodus des Lenny-Debian-Installers. Der Vorteil der Verwendung des Installers besteht darin, dass Sie aus den vielen Installationsmethoden diejenige aussuchen können, die am besten für Sie passt. Für weitere Informationen lesen Sie bitte den Abschnitt „Ein kaputtes System reparieren“ in Kapitel 8 des Installationsleitfadens und die FAQ des Debian-Installers.

Das Distributions-Upgrade sollte entweder lokal von einer virtuellen Konsole im Textmodus (oder von einem direkt angebundenen seriellen Terminal) oder aus der Ferne über eine ssh-Verbindung erfolgen.

Für zusätzliche Sicherheit sollten Sie beim Upgrade aus der Ferne den Upgrade-Prozess in einer virtuellen Konsole des Programms screen durchführen, da damit bei möglichen Verbindungsabbrüchen die Verbindung wieder sicher hergestellt werden kann und der Upgrade-Prozess somit nicht fehlschlägt.

	Wichtig
	Sie sollten das Upgrade nicht mit telnet, rlogin, rsh oder bei lokalen Upgrades unter von xdm, gdm oder kdm verwalteten X-Sitzungen durchführen. Da diese Dienste während des Upgrades beendet werden könnten, könnte dies dazu führen, dass auf das System kein Zugriff mehr möglich ist und somit das Upgrade nicht fertiggestellt werden kann.

Benutzer, die den Boot-Loader LILO verwenden, sollten beachten, dass die initramfs-tools jetzt in den Standardeinstellungen ein so großes Initramfs erzeugen, dass LILO es nicht mehr laden kann. Diese Benutzer sollten entweder auf grub umstellen oder die Datei /etc/initramfs-tools/initramfs.conf bearbeiten und die Zeile

MODULES=most

ändern, so dass sie wie folgt lautet:

MODULES=dep

Beachten Sie, dass damit initramfs-tools nur die Module in die Initramfs installiert, die für diese spezielle Hardware benötigt werden, auf der es momentan läuft. Möchten Sie ein Boot-Medium erstellen, das auch auf anderer Hardware läuft, belassen Sie die Zeile als

MODULES=most

und stellen Sie sicher, dass Sie LILO nicht mehr verwenden.

Manchmal führt die Verwendung von apt-get statt aptitude für die Paketinstallation dazu, dass aptitude ein Paket für „unbenutzt“ hält und es zur Entfernung einplant. Grundsätzlich sollten Sie sicherstellen, dass Ihr System vollständig aktuell und „sauber“ ist, bevor Sie mit dem Upgrade fortfahren.

Deshalb sollten Sie kontrollieren, ob noch ausstehende Aktionen im Paketmanager aptitude vorhanden sind. Falls ein Paket im Paketmanager zum Entfernen oder Aktualisieren vorgemerkt ist, könnte dies den Upgrade-Prozess negativ beeinflussen. Beachten Sie, dass Sie eine solche Situation nur korrigieren können, falls Ihre sources.list noch auf etch und nicht auf stable oder lenny verweist; siehe dazu Abschnitt A.2, „Überprüfen Ihrer Paketquellen“.

Dann sollten Sie aptitude im „visuellen Modus“ starten und g drücken, um diese Begutachtung zu beginnen. Falls irgendwelche Aktionen angezeigt werden, sollten Sie diese kontrollieren und entweder rückgängig machen/beheben oder die empfohlenen Vorgänge ausführen. Sind keine Aktionen vorgesehen, wird folgende Nachricht angezeigt: „Es wurden keine Pakete zum Installieren, Entfernen oder Aktualisieren ausgewählt.“.

Falls Sie APT so konfiguriert haben, dass bestimmte Pakete aus einer anderen Debian-Suite als Stable (z.B. aus Testing) installiert werden (Pinning), müssen Sie unter Umständen Ihre APT-Pinning-Konfiguration (in /etc/apt/preferences gespeichert) ändern, um das Upgrade der Pakete aus der neuen Stable-Veröffentlichung zu erlauben. Weitere Informationen zu APT Pinning finden Sie in apt_preferences(5).

Unabhängig von der Methode zum Upgrade wird empfohlen, dass Sie zuerst überprüfen, ob alle Pakete in einem Status sind, der zum Upgrade geeignet ist. Der folgende Befehl wird Ihnen alle Pakete anzeigen, die im Status halb-installiert oder Konfiguration-fehlgeschlagen sind, und solche mit Fehler-Status.

# dpkg --audit

Sie sollten auch den Status aller Pakete Ihres Systems mittels dselect, aptitude oder Befehlen der folgenden Form überprüfen:

# dpkg -l | pager

oder

# dpkg --get-selections "*" > ~/aktuelle-Pakete.txt

Es ist erstrebenswert, alle hold-Markierungen („halten“; Markierung, dass ein Paket in dem Zustand belassen werden soll, in dem es ist; es würde nicht aktualisiert) vor dem Upgrade zu entfernen. Wenn irgendein Paket, das für das Upgrade unverzichtbar ist, auf hold steht, schlägt das Upgrade fehl.

Beachten Sie, dass aptitude verglichen mit apt-get oder dselect eine andere Methode verwendet, um Pakete, die auf hold gesetzt sind, zu registrieren. Sie können Pakete, für die die hold-Markierung gesetzt ist, mit aptitude identifizieren, indem Sie diesen Befehl verwenden:

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

Um Pakete, die für apt-get auf hold gesetzt worden waren, zu identifizieren, sollten Sie dies verwenden:

# dpkg --get-selections | grep hold

Falls Sie ein Paket lokal verändert und neu kompiliert haben und ihm nicht einen anderen Namen gegeben haben oder eine Epoche in die Versionsnummer eingefügt haben, müssen Sie es auf hold setzen, um zu verhindern, dass davon ein Upgrade durchgeführt und es damit überschrieben wird.

Der „hold“-Paketstatus für aptitude kann mit folgendem Befehl geändert werden:

# aptitude hold paketname

Ersetzen Sie hold durch unhold, um die hold-Markierung zu löschen.

Falls etwas korrigiert werden muss, sorgen Sie am besten dafür, dass sources.list noch auf etch verweist, wie dies in Abschnitt A.2, „Überprüfen Ihrer Paketquellen“ erklärt wird.

Wenn Sie proposed-updates in Ihrer /etc/apt/sources.list-Datei aufgeführt haben, sollten Sie das entfernen, bevor Sie versuchen, ein Upgrade Ihres Systems durchzuführen. Dies ist eine Vorsichtsmaßnahme, um die Zahl möglicher Konflikte zu reduzieren.

Falls auf Ihrem System Debian-fremde Pakete installiert sind, sollten Sie wissen, dass diese während des Upgrades aufgrund von Konflikten in den Abhängigkeiten entfernt werden könnten. Falls diese Pakete installiert wurden, indem ein zusätzliches Paketarchiv in Ihrer /etc/apt/sources.list hinzugefügt wurde, sollten Sie überprüfen, ob das Archiv auch für Lenny übersetzte Pakete anbietet und die Quellzeile gleichzeitig mit der Quellzeile für die Debian-Pakete ändern.

Einige Benutzer haben inoffizielle rückportierte „neuere“ Versionen von Paketen aus Debian auf ihrem Etch-System installiert. Diese Pakete werden wahrscheinlich während des Upgrades zu Problemen führen, da Dateikonflikte auftreten können^[3]. Abschnitt 4.5.8, „Mögliche Probleme während des Upgrades“ enthält Informationen, wie mit Dateikonflikten, falls diese auftreten, umgegangen werden kann.

Die Konfiguration ist standardmäßig so eingerichtet, dass Sie von den Haupt-Internetservern von Debian installieren, aber Sie können /etc/apt/sources.list bearbeiten, um andere Spiegel zu verwenden, bevorzugt solche, die netztopologisch nahe bei Ihnen liegen.

Adressen von HTTP- und FTP-Spiegeln können unter http://www.debian.org/distrib/ftplist gefunden werden (suchen Sie nach dem Abschnitt „Liste von Debian-Spiegeln“). HTTP-Spiegel sind im Allgemeinen schneller als FTP-Spiegel.

Im Beispiel nehmen wir an, dass der für Sie am nächsten liegende Spiegel http://mirrors.kernel.org sei. Wenn Sie sich den Spiegel mit einem Web-Browser oder einem FTP-Programm anschauen, werden Sie bemerken, dass die Hauptverzeichnisse wie folgt organisiert sind:

http://mirrors.kernel.org/debian/dists/lenny/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...

Um diesen Spiegel mit apt zu verwenden, müssen Sie die folgende Zeile zu Ihrer Datei sources.list hinzufügen:

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

Beachten Sie, dass das „dists“ implizit hinzugefügt wird und dass Argumente nach dem Namen der Veröffentlichung zur Expansion des Pfades in mehrere Verzeichnisse verwandt werden.

Nachdem Sie neue Quellen hinzugefügt haben, deaktivieren Sie die bisher existierenden „deb“-Zeilen in der Datei sources.list, indem Sie eine Raute (#) am Zeilenanfang einfügen.

Statt HTTP- oder FTP-Paketspiegel zu verwenden, können Sie auch Ihre /etc/apt/sources.list anpassen, um einen Spiegel auf einer lokalen Platte zu verwenden (die möglicherweise über NFS eingehängt ist).

Beispielsweise könnte Ihr Paketspiegel unter /var/ftp/debian/ liegen und über die folgenden Hauptverzeichnisse verfügen:

/var/ftp/debian/dists/lenny/main/binary-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

Um dies mit apt zu verwenden, fügen Sie die folgende Zeile zu Ihrer Datei sources.list hinzu:

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

Beachten Sie, dass das „dists“ implizit hinzugefügt wird und dass Argumente nach dem Namen der Veröffentlichung zur Expansion des Pfades in mehrere Verzeichnisse verwandt werden.

Nachdem Sie neue Quellen hinzugefügt haben, deaktivieren Sie die bisher existierenden „deb“-Zeilen in der Datei sources.list, indem Sie eine Raute (#) am Zeilenanfang einfügen.

Falls Sie ausschließlich die CDs verwenden möchten, kommentieren Sie die existierenden „deb“-Zeilen in der /etc/apt/sources.list aus, indem Sie am Zeilenanfang eine Raute (#) einfügen.

Stellen Sie sicher, dass es eine Zeile in /etc/fstab gibt, die das Einhängen Ihres CD-ROM-Laufwerks unter /cdrom ermöglicht (der Einhängepunkt muss für apt-cdrom exakt /cdrom sein). Falls Ihr CD-ROM-Laufwerk beispielsweise /dev/hdc ist, sollte /etc/fstab eine Zeile der folgenden Art enthalten:

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

Beachten Sie, dass es keine Leerzeichen zwischen den Wörtern defaults,noauto,ro im vierten Feld geben darf.

Um zu überprüfen, ob dies funktioniert, legen Sie eine CD ein und versuchen Sie, Folgendes auszuführen:

# mount /cdrom    # dies wird die CD am Einhängepunkt einhängen
# ls -alF /cdrom  # dies sollte Ihnen das Wurzelverzeichnis der CD anzeigen
# umount /cdrom   # dies wird die Einhängung der CD wieder aufheben

Führen Sie als nächstes für jede Binär-CD, die Sie von Debian haben, den Befehl

# apt-cdrom add

aus, um die Daten der CD zu der APT-Datenbank hinzuzufügen.

Es wird nachdrücklich empfohlen, dass Sie das Programm /usr/bin/script verwenden, um einen Mitschnitt der Upgrade-Sitzung zu erstellen. Falls dann ein Problem auftritt, haben Sie ein exaktes Protokoll der Ereignisse und können - falls notwendig - genaue Informationen in einem Fehlerbericht angeben. Um die Aufzeichnung zu beginnen, geben Sie

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

oder Ähnliches ein. Legen Sie die Mitschnittdatei nicht in einem temporären Verzeichnis wie /tmp oder /var/tmp an (Dateien in diesen Verzeichnissen könnten während des Upgrades oder eines Systemstarts gelöscht werden).

Der Mitschnitt erlaubt es Ihnen auch, die Informationen durchzuschauen, die bereits aus dem Bildschirm herausgelaufen sind. Schalten Sie auf VT2 um (mit Alt+F2) und verwenden Sie nach dem Anmelden less -R ~root/upgrade-lenny.script, um die Datei durchzuschauen.

Nach Beendigung des Upgrades können Sie script beenden, indem Sie exit an der Eingabeaufforderung eingeben.

Falls Sie den Schalter -t für script verwendet haben, können Sie das Programm scriptreplay zum Abspielen der gesamten Sitzung verwenden:

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

Zuerst muss die Liste der verfügbaren Pakete für die neue Veröffentlichung abgerufen werden. Dies erledigen Sie mit dem folgenden Befehl:

# aptitude update

Wird dies beim ersten Mal zur Aktualisierung von neuen Quellen ausgeführt, werden einige Warnungen in Bezug auf die Verfügbarkeit der Quellen ausgegeben. Diese Warnungen sind harmlos und werden nicht auftreten, falls Sie den Befehl erneut ausführen.

Sie müssen vor dem Upgrade sicherstellen, dass Sie genügend Platz auf Ihrer Festplatte verfügbar haben, wenn Sie wie in Abschnitt 4.5.7, „Upgrade des restlichen Systems“ beschrieben ein Upgrade des kompletten Systems starten. Als erstes wird jedes Paket, das zur Installation benötigt wird und über Netz heruntergeladen werden muss, in /var/cache/apt/archives gespeichert (bzw. während des Downloads im Unterverzeichnis partial/). Sie müssen also sicherstellen, dass Sie auf der Partition, die /var/ beinhaltet, genügend Platz haben, um temporär alle Pakete, die installiert werden sollen, herunterladen zu können. Nach dem Download benötigen Sie möglicherweise mehr Platz in anderen Partitionen, sowohl um die zu aktualisierenden Pakete zu installieren (diese könnten größere Binärdateien oder zusätzliche Daten enthalten) als auch um Pakete zu installieren, die neu hinzukommen. Falls Sie nicht genügend freien Speicherplatz bereithalten, bleibt vielleicht ein System mit einem unvollständigen Upgrade zurück, das unter Umständen nur schwer wiederbelebt werden kann.

Sowohl aptitude wie auch apt zeigen Ihnen detaillierte Informationen über den Festplattenplatz an, der für die Installation benötigt wird. Bevor Sie das Upgrade ausführen, können Sie sich die ungefähren Werte durch folgenden Befehl anschauen:

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX 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.
Würde Pakete herunterladen/installieren/entfernen.

Anmerkung

Das Ausführen dieses Befehls zu Beginn des Upgrade-Prozesses könnte einen Fehler ausgeben (die Gründe sind in den folgenden Abschnitten beschrieben). In diesem Fall müssen Sie mit der Ausführung des Befehls warten, bis Sie das minimale System-Upgrade (wie in Abschnitt 4.5.6, „Minimales System-Upgrade“ beschrieben) und einen Upgrade Ihres Kernels durchgeführt haben, bevor Sie diesen Befehl ausführen, um den Platzbedarf abzuschätzen.

Falls Sie nicht genügend Platz für das Upgrade haben, müssen Sie vorher manuell Platz schaffen. Sie können:

Beachten Sie, dass es ratsam ist, die sources.list zurück auf Etch zu ändern (wie in Abschnitt A.2, „Überprüfen Ihrer Paketquellen“ beschrieben), um Pakete sicher zu entfernen.

Etliche Fehlerberichte haben gezeigt, dass die Pakete aptitude und apt in den Versionen aus Etch oft Probleme haben, das Upgrade nach Lenny durchzuführen. Die apt-Version aus Lenny kann besser mit komplexen Ketten von Paketen umgehen, die eine sofortige Konfiguration erfordern. Außerdem ist aptitude aus Lenny bei der Suche nach Lösungen von Abhängigkeitsproblemen geschickter. Diese beiden Funktionalitäten sind beim Distributions-Upgrade auf Lenny in erheblichem Umfang beteiligt, daher ist es notwendig, ein Upgrade dieser beiden Pakete durchzuführen, bevor das eigentliche Upgrade gestartet wird. Für ein Upgrade von apt führen Sie Folgendes aus:

# apt-get install apt

und für aptitude (falls Sie es installiert haben):

# aptitude install aptitude

Dieser Schritt wird automatisch libc6 und locales aktualisieren und SELinux-Support-Bibliotheken nachziehen (libselinux1). An dieser Stelle werden einige laufende Dienste neu gestartet, darunter xdm, gdm und kdm. Als Konsequenz daraus könnten lokal laufende X-Sitzungen die Verbindung verlieren.

aptitude verwaltet eine Liste von Paketen, die automatisch installiert worden sind (zum Beispiel aufgrund einer Abhängigkeit von einem anderen Paket). In Lenny hat nun auch apt diese Funktion.

Wenn die Lenny-Version von aptitude das erste Mal gestartet wird, liest sie die Liste von automatisch installierten Paketen ein und konvertiert sie für die Verwendung durch die Lenny-Version von apt. Falls Sie aptitude installiert haben, sollten Sie zumindest einen aptitude-Befehl ausführen, um die Konvertierung durchzuführen. Eine Möglichkeit, dies zu tun, wäre die Suche nach einem nicht-vorhandenen Paket:

# aptitude search "?false"

Weil bei bestimmten benötigten Paketen Konflikte zwischen der Etch- und der Lenny-Version bestehen, wird das direkte Ausführen von aptitude dist-upgrade oft eine große Anzahl von Paketen entfernen, die Sie eigentlich behalten möchten. Wir empfehlen deshalb einen zweiteiligen Upgrade-Prozess; als erstes ein minimales Upgrade, um diese Konflikte zu umgehen und anschließend ein vollständiges dist-upgrade.

Führen Sie als erstes aus:

# aptitude safe-upgrade

Dies hat den Effekt, dass für diejenigen Pakete ein Upgrade durchgeführt wird, für die dies möglich ist, ohne dass irgendwelche anderen Pakete entfernt oder installiert werden müssen.

Der nächste Schritt unterscheidet sich abhängig davon, welche Pakete Sie installiert haben. Diese Veröffentlichungshinweise geben grundsätzliche Hinweise darüber, welche Methode benutzt werden sollte, aber falls Sie Zweifel haben, wird empfohlen, dass Sie die zu entfernenden Pakete, die von den einzelnen Methoden vorgeschlagen werden, kontrollieren, bevor Sie fortfahren.

Einige gebräuchliche Pakete, von denen erwartet wird, dass Sie entfernt werden, sind base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common und xserver-common. Eine vollständigere Liste von veralteten Paketen in Lenny finden Sie in Abschnitt 4.10, „Veraltete Pakete“.

Sie sind jetzt bereit für den eigentlichen Hauptteil des Upgrades. Führen Sie aus:

# aptitude dist-upgrade

Dadurch wird ein vollständiges Upgrade des Systems durchgeführt, also die Installation der neuesten verfügbaren Versionen aller Pakete und die Auflösung aller möglichen Änderungen bei den Abhängigkeiten zwischen Paketen der verschiedenen Veröffentlichungen. Falls nötig werden einige neue Pakete installiert (üblicherweise neue Bibliotheksversionen oder umbenannte Pakete) sowie veraltete Pakete entfernt, die Konflikte verursachen.

Falls Sie ein Upgrade von einem Satz CD-ROMs (oder DVDs) durchführen, werden Sie an verschiedenen Stellen des Upgrade-Prozesses aufgefordert, bestimmte CDs einzulegen. Sie müssen eventuell ein und dieselbe CD mehrmals einlegen; dies liegt daran, dass einige Pakete mit gegenseitiger Wechselbeziehung zueinander über verschiedene CDs verteilt sind.

Neue Versionen von bereits installierten Paketen, die nicht aktualisiert werden können, ohne den Installationsstatus eines anderen Pakets zu ändern, werden in ihrer derzeitigen Version belassen (sie werden als „zurückgehalten“ angezeigt). Dies kann aufgelöst werden, indem Sie entweder aptitude verwenden, um diese Pakete zur Installation vorzumerken, oder indem Sie aptitude -f install paketname verwenden.

Falls eine Operation von aptitude, apt-get oder dpkg mit der Meldung

E: Dynamic MMap ran out of room

fehlschlägt, dann ist der Standardwert für den Cache nicht ausreichend groß. Sie können dies Problem lösen, indem Sie entweder Zeilen in Ihrer /etc/apt/sources.list entfernen bzw. mit einem Rautezeichen am Anfang auskommentieren oder Sie die Größe des Caches erhöhen. Dies erledigen Sie mit der Einstellung APT::Cache-Limit in /etc/apt/apt.conf. Der folgende Befehl setzt den Cache auf einen Wert, der für dieses Upgrade passend sein sollte:

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

Dabei wird davon ausgegangen, dass diese Variable in der betreffenden Datei noch nicht gesetzt war.

Manchmal ist es nötig, die Option APT::Force-LoopBreak in APT zu aktivieren, um die Möglichkeit zu haben, ein zwingend nötiges Paket vorübergehend entfernen zu können, falls das Problem einer Konflikt- oder Pre-Depends-Schleife besteht. aptitude wird Sie über so etwas in Kenntnis setzen und das Upgrade abbrechen. Sie setzen diese Option, indem Sie -o APT::Force-LoopBreak=1 im aptitude-Befehl angeben.

Es ist möglich, dass die Abhängigkeitsstruktur eines Systems so beschädigt ist, dass ein manuelles Eingreifen nötig ist. Dies erfordert üblicherweise die Verwendung von aptitude oder

# dpkg --remove paketname

um einige der beschädigten Pakete zu eliminieren, oder

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

In extremen Fällen müssen Sie eventuell die Neuinstallation eines Pakets erzwingen; verwenden Sie dazu einen Befehl wie

# dpkg --install /pfad/zum/paketname.deb

Dateikonflikte sollten nicht auftauchen, wenn Sie ein Upgrade auf einem „reinen“ Etch-System durchführen, können aber vorkommen, wenn Sie inoffizielle Backports installiert haben. Ein Dateikonflikt resultiert in einem Fehler wie:

Entpacke <package-foo> (aus <package-foo-file>) ...
dpkg: Fehler beim Bearbeiten von <package-foo> (--install):
 Versuche, `<some-file-name>' zu überschreiben,
 welches auch in Paket <package-bar> ist
dpkg-deb: Unterprozess paste mit Signal (Broken pipe) getötet
 Fehler traten auf beim Bearbeiten von:
 <package-foo>

Sie können versuchen, einen Dateikonflikt zu lösen, indem Sie zwangsweise das Paket entfernen, das in der letzten Zeile der Fehlermeldung genannt wird:

# dpkg -r --force-depends paketname

Nachdem Sie die Probleme behoben haben, sollte es möglich sein, das Upgrade fortzusetzen, indem Sie die oben beschriebenen aptitude-Befehle nochmals ausführen.

Während des Upgrades werden Ihnen Fragen gestellt, die die Konfiguration oder Neukonfiguration von verschiedenen Paketen betreffen. Wenn Sie gefragt werden, ob Dateien in den Verzeichnissen /etc/init.d und /etc/terminfo oder die Datei /etc/manpath.config durch die Version des Paketbetreuers ersetzt werden sollen, ist die Antwort „yes“ (ja) für gewöhnlich die richtige, um die Konsistenz des Systems sicherzustellen. Sie können immer noch zu der alten Version zurückkehren, da diese mit der Erweiterung .dpkg-old abgespeichert werden.

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 die Mitschnittdatei durchsuchen, um die Informationen erneut zu betrachten, die zum Zeitpunkt des Upgrades auf dem Bildschirm angezeigt wurden.

Wenn Sie ein Distributions-Upgrade von Etch auf Lenny durchführen, wird dringend empfohlen, dass Sie eines der neuen linux-image-2.6-Metapakete installieren. Dieses Paket könnte auch automatisch durch den Upgrade-Prozess installiert werden. Sie können dies verifizieren mit:

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

Falls nichts angezeigt wird, müssen Sie ein neues linux-image-Paket von Hand installieren. Eine Liste verfügbarer linux-image-2.6-Metapakete bekommen Sie mit:

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

Falls Sie sich bei der Entscheidung, welches Paket Sie wählen sollen, unsicher sind, führen Sie uname -r aus und suchen Sie nach einem Paket mit einem ähnlichen Namen. Falls die Anzeige zum Beispiel 2.6.18-6-686 ist, wird empfohlen, dass Sie linux-image-2.6-686 installieren. (Beachten Sie, dass die k7-Variante nicht mehr existiert; falls Sie derzeit eine k7-Kernelvariante verwenden, sollten Sie stattdessen jetzt die 686-Variante installieren.) Sie können auch apt-cache benutzen, um eine ausführliche Beschreibung jedes Pakets zu bekommen, was Ihnen bei der Auswahl des besten Paketes helfen kann. Zum Beispiel:

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

Sie sollten dann aptitude install verwenden, um es zu installieren. Sobald dieser neue Kernel installiert ist, sollten Sie sobald wie möglich einen Neustart durchführen, um von der neuen Kernel-Version zu profitieren.

Für die Experimentierfreudigen gibt es einen einfachen Weg, einen eigenen Kernel unter Debian GNU/Linux zu erstellen. Installieren Sie das kernel-package-Werkzeug und lesen Sie die Dokumentation in /usr/share/doc/kernel-package.

Falls möglich, wäre es ein Vorteil, wenn Sie das Kernel-Paket separat vom Rest des Systems aktualisieren, um die Wahrscheinlichkeit eines nicht-bootfähigen Systems zu reduzieren. Beachten Sie, dass Sie dies nur nach dem minimalen System-Upgrade (siehe Abschnitt 4.5.6, „Minimales System-Upgrade“) durchführen sollten.

Lenny enthält einen robusteren Mechanismus für die Hardware-Erkennung als frühere Veröffentlichungen. Allerdings könnte dies dazu führen, dass die Reihenfolge, in der Geräte auf Ihrem System erkannt werden, sich ändert, was sich auf die Vergabe der Gerätenamen auswirken kann. Falls Sie zum Beispiel zwei Netzwerk-Adapter in Ihrem System haben, die von verschiedenen Treibern bedient werden, könnten die Bezeichnungen eth0 und eth1 vertauscht werden. Bitte beachten Sie, dass die Änderung des Mechanismus auch bedeutet, dass ein Adapter, der in einem laufenden Lenny-System ausgetauscht wird, auch einen neuen Schnittstellen-Namen bekommt.

Bei Netzwerkkarten können Sie diese Neunummerierung vermeiden, indem Sie udev-Regeln verwenden, genauer gesagt durch die Definitionen in /etc/udev/rules.d/70-persistent-net.rules^[4]. Alternativ können Sie das ifrename-Werkzeug benutzen, um physische Geräte beim Systemstart an spezielle Namen zu binden. Siehe ifrename(8) und iftab(5) für weitere Informationen. Diese beiden Alternativen (udev und ifrename) sollten nicht zur gleichen Zeit verwendet werden.

Bei Speichergeräten können Sie diese Neunummerierung vermeiden, indem Sie initramfs-tools benutzen und so konfigurieren, dass die Treibermodule für Speichergeräte in der gleichen Reihenfolge wie bisher geladen werden. Identifizieren Sie dazu auf Basis der Ausgabe von lsmod die Reihenfolge, in der die Module geladen wurden. lsmod listet die Module in der umgekehrten Reihenfolge auf, in der sie geladen wurden, zum Beispiel wurde das erste Modul in der Liste als letztes geladen. Beachten Sie, dass dieses Prinzip nur für Geräte funktioniert, die vom Kernel in einer stabilen Reihenfolge durchnummeriert werden (wie PCI-Geräte).

Allerdings wird das Entfernen und Neuladen von Modulen nach dem eigentlichen Systemstart diese Reihenfolge beeinflussen. Auch könnte der Kernel bestimmte Treiber statisch gelinkt haben, so dass diese Namen nicht in der Ausgabe von lsmod erscheinen. Sie können diese Treibernamen und die Reihenfolge des Ladens herausfinden, indem Sie in /var/log/kern.log oder in der Ausgabe von dmesg nachschauen.

Fügen Sie diese Modulnamen in der Reihenfolge zu /etc/initramfs-tools/modules hinzu, in der Sie bei Systemstart geladen werden sollen. Einige Modulnamen könnten zwischen Etch und Lenny geändert worden sein. Zum Beispiel heißt das Modul sym53c8xx_2 jetzt sym53c8xx.

Sie müssen dann Ihr Initramfs-Image neu erzeugen, indem Sie update-initramfs -u -k all ausführen.

Sobald ein Lenny-Kernel sowie das Paket udev laufen, sollten Sie überlegen, Ihr System neu zu konfigurieren, sodass auf Festplatten über einen Alias zugegriffen wird, der unabhängig von der Reihenfolge des Ladens der Treiber ist. Diese Aliase liegen unterhalb von /dev/disk/.

Falls eine durch initramfs-tools erstellte Initrd benutzt wird, um das System zu starten, könnte die Erzeugung von Gerätedateien durch udev zu spät stattfinden, sodass die Boot-Skripte nicht mehr darauf reagieren können.

Häufige Symptome sind, dass der Systemstart fehlschlägt, weil das Wurzel-Dateisystem (/) nicht eingehängt werden kann. Sie werden dann auf eine Shell zur Fehlersuche (Debug-Shell) umgeleitet. Wenn Sie dann aber alles kontrollieren, sind alle benötigten Gerätedateien in /dev vorhanden. Dies ist in Fällen beobachtet worden, bei denen das Wurzel-Dateisystem (/) auf einer USB-Festplatte oder auf einem RAID lag, speziell wenn LILO genutzt wurde.

Das Problem kann umgangen werden, indem der Boot-Parameter rootdelay=9 verwendet wird. Der Wert für die Zeitüberschreitung (in Sekunden) muss eventuell noch angepasst werden.

Falls Sie lilo als Bootloader verwenden (bei einigen Installationen von Etch ist Lilo der Standard-Bootloader), wird dringendst empfohlen, dass Sie lilo nach dem Upgrade erneut ausführen:

# /sbin/lilo

Beachten Sie, dass dies auch nötig ist, falls Sie Ihren System-Kernel nicht aktualisiert haben, da sich lilos zweite Stufe aufgrund des Upgrades ändert.

Kontrollieren Sie auch den Inhalt der Datei /etc/kernel-img.conf und stellen Sie sicher, dass do_bootloader = Yes enthalten ist. Auf diese Art wird der Bootloader jedes Mal nach einem Kernel-Upgrade erneut ausgeführt.

Sollten Sie irgendwelche Probleme feststellen, wenn Sie lilo ausführen, kontrollieren Sie in / die symbolischen Links auf vmlinuz und initrd sowie den Inhalt von /etc/lilo.conf auf eventuelle Unstimmigkeiten.

Falls Sie vor dem Neustart vergessen haben, lilo erneut auszuführen oder das System versehentlich neu gestartet wurde bevor Sie dies erledigen konnten, schlägt der Start des Systems eventuell fehl. Statt des Lilo-Prompts sehen Sie dann nur LI, wenn das System bootet^[5]. In Abschnitt 4.1.3, „Systemwiederherstellung vorbereiten“ finden Sie Informationen, wie Sie dieses Problem beheben können.

Sie können dieses Problem vollständig vermeiden, indem Sie eine Kennung (Identifier) für das Wurzel-Dateisystem verwenden, die sich nicht von einem Systemstart zum nächsten verändert. Es gibt zwei mögliche Methoden dazu: dem Dateisystem ein Label zuzuordnen oder den Universal Unique Identifier (UUID) des Dateisystems zu verwenden. Diese beiden Methoden werden von Debian seit der Veröffentlichung von „Etch“ unterstützt.

Beide Ansätze haben Vor- und Nachteile. Der Ansatz der Vergabe eines Labels ist einfacher verständlich, aber es können Probleme auftreten, falls ein anderes Dateisystem auf Ihrem System das gleiche Label hat. Der Ansatz der Verwendung der UUID ist ein wenig hässlicher, allerdings sind sich überschneidende UUIDs höchst unwahrscheinlich.

Bei dem Beispiel unten nehmen wir an, dass das Wurzel-Dateisystem auf /dev/hda6 liegt. Außerdem gehen wir davon aus, dass auf Ihrem System eine funktionierende udev-Installation vorhanden ist und die Dateisysteme vom Typ ext2 oder ext3 sind.

Den Label-Ansatz implementieren:

Den UUID-Ansatz implementieren:

Einige Pakete aus Etch sind für Lenny in mehrere Pakete aufgeteilt worden, oft um die System-Wartungsfähigkeit zu erhöhen. Um in solchen Fällen den Upgrade-Prozess zu erleichtern, bietet Lenny oft so-genannte „Dummy“-Pakete an: leere Pakete, die den gleichen Namen haben wie das alte Paket in Etch und mit entsprechenden Abhängigkeiten, die dazu führen, dass die neuen Pakete installiert werden. Diese „Dummy“-Pakete werden nach dem Upgrade-Prozess als veraltet angesehen und können problemlos entfernt werden.

Die Paketbeschreibungen der meisten (aber nicht aller) Dummy-Pakete enthalten einen Hinweis auf ihren Zweck. Die Paketbeschreibungen für Dummy-Pakete sind jedoch nicht standardisiert, daher werden Sie vielleicht deborphan mit den --guess-Optionen sinnvoll finden, um diese Pakete auf Ihrem System zu finden. Beachten Sie, dass einige Dummy-Pakete nicht dazu gedacht sind, nach einem Upgrade entfernt zu werden, sondern stattdessen dazu dienen, die gerade verfügbare Version eines Programms über längere Zeit zu verfolgen.