Debian-Squeeze-Migration 32- nach 64-Bit

Das Debian-Paketsystem kennt bis maximal Version 6 (Squeeze) keinen Weg zu einer sauberen Architekturmigration einer bestehenden Installation. Nichts anderes ist ist eine Umstellung von i386 auf amd64. Ab Debian 7 (Wheezy) kennt das Paketsystem die Möglichkeit verschiedener Architekturen auf einem System zu beherbergen. Beizeiten gibt es dann auch eine entsprechende Aktualisierung dieses Artikels. Deutlich: Nicht mit Debian 7 oder neuer versuchen, dort sind die Vorgehensweisen anders!

Das hier vorgestellte Prinzip ist einfach, aber nicht unbedingt schön:

• Installation eines 64-Bit-Kernels,
• Erstellen eines minimalen 64-Bit-chroot-Systems,
• Überschreiben der zentralen Binärdateien mittels dieses Minisystems,
• Reinstallation aller installierten Pakete mit der zugehörigen 64-Bit-Variante.

Eine Neuinstallation ist andererseits recht aufwendig, wenn diese umfangreiche Konfigurationsanpassungen, Benutzer, usw. durchlebt hat.

Dieses Upgrade setzt Kenntnisse mit apt-get, dpkg und allgemeinen systemadministrativen Aufgaben voraus. Im Laufe des Vorganges ergeben sich sehr individuelle Konstellationen von Abhängigkeiten, die im Rahmen dieser Kurzanleitung nicht abgedeckt werden können.

Dieses Update benötigt Zugang zur Maschinenkonsole. Eine Ferninstallation über ssh oder telnet ist nicht durchführbar. Die beschriebenen Schritte wurden mit Debian Lenny und Squeeze getestet.

Vorbereitungen

Benötigtes Prozessorfeature prüfen

grep -q '^flags.* lm ' /proc/cpuinfo && echo "Can 64-Bit"

Wenn diese Ausgabe erfolgt, kann das System auf 64-Bit aktualisiert werden. Ansonsten nicht.

Dokumentation der Plattenpartitionen

Zu einem späteren Zeitpunkt wäre wichtig zu wissen, auf welcher Partition welches Dateisystem ruht.

df -h

gibt eine Liste der Partitionen und ihrer Mountpoints, sowie der Platzbelegung aus. Diese sollten wir in einer Datei auf einem anderen System zugänglich aufbewahren oder ausgedruckt auf einem Blatt Papier zur Hand haben.

Installation eines passenden 64-Bit-Kernels

In der Regel genügt es, das zugehörige Kernel-Metapaket zu installieren:

apt-get install linux-image-2.6-amd64

Nach der Installation und dem obligatorischen Reboot ist darauf zu achten, dass der Kernel auch wirklich gestartet wird. In der Standardkonfiguration von Grub werden die Kernelvarianten alphabetisch aufgelistet, sodass amd64 immer vor ix86 liegt.

Nach dem Reboot läuft aller Kernelcode bereits im 64-Bit-Modus. Nun müssen noch die Programme ausgetauscht werden, damit diese ebenfalls in diesem Modus laufen.

Erstellen eines 64-Bit-Minisystems

In diesem Beispiel wird das System in /chroot64 installiert. Jeder andere Platz ist ebenfalls möglich, muss im Laufe dieser Anleitung allerdings entsprechend berücksichtigt werden.

mkdir /chroot64
apt-get install debootstrap
debootstrap --arch amd64 squeeze /chroot64 http://ftp.de.debian.org/debian

Dieses Minisystem besteht ausschließlich aus 64-Bit-Komponenten. Statt Squeeze sollte die bereits installierte Distribution benutzt werden.

In diesem Minisystem müssen nun noch ein paar weitere Pakete installiert werden:

chroot /chroot64
apt-get install file bzip2 openssh-client tnftp
<CTRL-D>

Anlegen einer Liste der Binärprogramme des Minisystems

Damit das eigentliche Hauptsystem (auf schmutzige Weise) von 32- auf 64-Bit hochgezogen werden kann, brauchen wir eine Liste der ausführbaren Binärdateien des Minisystems. Nur diese Programme und Libraries sind relevant und müssen ausgetauscht werden:

cd /chroot64
find . -depth |while read f; do
 if file -L "$f" |fgrep -q ELF; then
  echo "$f" >> /tmp/binaries.txt
 fi
done
echo "./etc/ld.so.cache" >> /tmp/binaries.txt

Das Hinzufügen des ld.so.cache ist unabdingbar! Der Cache ist zwar kein ausführbares Programm, wird aber vom dynamischen Linker (ld.so) benötigt.

Angleichen des 32-Bit-Systems an das Minisystem

Damit das alte System aus Sicht der Konfiguration dem Minisystem so ähnlich wie möglich wird, sollten nun alle Pakete im Minisystem auch im alten 32-Bit-System vorhanden sein. Diese werden also nun nachinstalliert:

chroot /chroot64
dpkg --get-selections |awk '{print $1}' > /tmp/minipackages.txt
<CTRL-D>
apt-get update
apt-get install `cat /chroot64/tmp/minipackages.txt`

Starten von externem Linux-Medium

Hierbei ist es ziemlich egal, auf welche Weise das System gestartet wird (CD, USB-Stick, PXE-Boot, …). Wichtig ist nur, dass

• das derzeit installierte System nicht läuft, da im Folgeschritt zentrale Dateien ausgetauscht werden müssen,
• das zu startende Linux eine 64-Bit-Installation ist.

Das Debian-Projekt bietet zu diesem Zweck Liveimages an. Das Rescue-Image reicht für unsere Zwecke aus.

Die Partitionen des installierten Systems müssen nach dem Startvorgang zugänglich gemacht werden. Dabei ist die weiter oben angelegte Partitionsliste eine große Hilfe und vermeidet unnötiges Raten, welche Partition nun gleich wieder was war.

mount /dev/sda3 /mnt
mount /dev/sda1 /mnt/boot
…

Alle Partitionen mit Binärprogrammen müssen gemountet werden. Also zum Beispiel ein separates /usr-Dateisystem, aber nicht unbedingt /home. Falls Unsicherheit herrscht, besser alle mounten.

Überschreiben des 32-Bit-Basissystems

Damit das System später per Paketinstallation auf 64-Bit umgestellt werden kann, müssen vorher die zentralen Binärdateien ausgetauscht werden. Dies geschieht anhand der weiter oben angelegten Liste-der-Binärdateien:

cd /mnt/chroot64
cpio -pVdu /mnt < /mnt/tmp/binaries.txt

Da 32- und 64-Bit-Libraries koexistieren können, gibt es zwei Pfade, die wir an dieser Stelle auf einen zeigen lassen, damit das System auch starten kann:

cd ..
ln -s /lib lib64

Nun räumen wir auf und starten neu:

cd ..
umount /mnt/boot /mnt
reboot

Start des neu gebauten 64-Bit-Systems

Nun kann das bereits vorher installierte, nun minimal auf 64-Bit gezogene System gestartet werden. Der Großteil des Systems besteht noch aus 32-Bit-Komponenten. Das sorgt bei einem Standardstartvorgang für eine erhebliche Menge an Fehlermeldungen. Diese können ignoriert werden. Alternativ kann in Grub auch der Punkt "(rescue)" ausgewählt werden, was den Startvorgang etwas beschleunigt als auch die Menge der Fehlermeldungen reduziert.

Letztendlich können wir uns einloggen und an dieser Stelle weitermachen.

Reinstallation aller Pakete

Damit das komplette System aus 64-Bit-Komponenten besteht, müssen alle Pakete neu installiert werden. Dieser Vorgang ist wie oben gesagt sehr individuell. An dieser Stelle können wir nur auf die häufigsten Fehler und ihre Behebung eingehen.

Laut der Apt-Datenbank ist das System derzeit in einem nicht validen Zustand: Apt sieht anhand uname -m, dass das System 64-bittig ist, aber alle vorhandenen Pakete in ihrer 32-Bit-Variante installiert sind (i386). Diesen Zustand müssen wir nun auf möglichst saubere Weise ändern.

apt-get update
apt-get install -f

Nun werden alle Pakete zum Austausch in ihrer amd64-Variante heruntergeladen und installiert. Dabei können wiederum Fehlermeldungen auftreten, zum Beispiel von Postinstall-Scripten, welche versuchen, Programme aufzurufen, die derzeit noch in der 32-Bit-Variante installiert sind.

Hier ist nun systemadministrative Kreativität gefragt. Einige der häufiger auftretenden Fehler wären:

Libc6 wird nicht automatisch aktualisiert

Internal Error, Could not perform immediate configuration (2) on libc6
E: Could not perform immediate configuration on 'libc6'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.

Das Libc6-Paket wurde zwar heruntergeladen, aber nicht ausgepackt, weil das Original eine andere Architektur aufweist. Hier müssen wir diese Apt-Vorsichtsmaßnahme (durch manuelle Installation) umgehen:

dpkg -i /var/cache/apt/archives/libc6*deb

Alternativ:

apt-get dist-upgrade -o APT::Immediate-Configure=0

Weiter mit erneutem Aufruf von

apt-get install -f

Librarykollisionen

Die derzeit eingesetzte Version des dynamischen Loaders (ld.so) unterstützt keine 32- und 64-Bit Libraries im gleichen Verzeichnis. Warnungen ähnlich wie wie:

ldconfig: libraries libz.so.1.2.3.0 and libz.so.1.2.3.3 in directory /usr/lib have same soname but different type.

bedeuten, dass geprüft werden muss, welches die 32-Bit-Variante ist, die üblicherweise gelöscht werden kann (da wir ja auf 64-Bit aktualisieren).

cd /usr/lib
ls -l libz.so*
lrwxrwxrwx 1 root root    15 Dec 30 21:25 libz.so -> libz.so.1.2.3.4
lrwxrwxrwx 1 root root    15 Dec 30 21:25 libz.so.1 -> libz.so.1.2.3.4
-rw-r--r-- 1 root root 93936 Dec 28 20:10 libz.so.1.2.3.4
-rw-r--r-- 1 root root 93936 Jun 18 11:14 libz.so.1.2.3.0
file libz.so.1.2.*
libz.so.1.2.3.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
libz.so.1.2.3.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
rm libz.so.1.2.3.0
ldconfig
apt-get -f install

Dieser Fehler tritt dann auf, wenn sich die Versionen des alten 32-Bit-Systems und des neuen 64-Bit-Systems unterscheiden, quasi gleichzeitig ein dist-upgrade auf eine neue Debian-Version durchgeführt wird. Das ist nicht empfohlen.

Installation von libperl schlägt fehl

Die Installation von perl-base schlägt fehl, weil die libperl.so.5.10.1 ebenfalls im Paket libc5.10 enthalten ist. Wir können diese aber getrost überschreiben:

dpkg --force-overwrite -i /var/cache/apt/archives/perl-base_*
apt-get -f install

Debsums schlägt fehl

Falls Fehler auftreten, weil das md5-Modul von Perl nicht funktioniert (weil es tatsächlich ein Binärmodul ist), dann kann auch dieses manuell und forciert installiert werden. Je nach dem kann dies zu Konflikten wegen bereits aus anderen (älteren) Paketen vorhandenen Dateien führen. Daher empfiehlt es sich, ein Überschreiben zuzulassen:

dpkg -i --force-overwrite /var/cache/apt/archives/perl*
apt-get -f install

Reinstallation von doc-base schlägt fehl

Dieses Paket benutzt ndbm Datenbankdateien (files.db und status.db), welche aber achitekturspezifisch sind. Die Austauschprozedur 32→64-Bit kann mit dieser Situation nicht umgehen. Das ist aber nicht weiter schlimm, ein simples Löschen dieser Dateien forciert ein Neuanlegen.

rm -f /var/lib/doc-base/info/*.db
apt-get -f install

Installation von Apache2/kbd schlägt fehl

Die sehr unübersichtliche Ausgabe zeigt gleich zwei Fehler:

• Apache2' kann nicht installiert werden, weil Apt sich nicht klar ist, ob nun mpm-worker oder mpm-prefork benutzt werden soll,
• Die Konsole-Tools können nicht installiert werden, weil Apt sich nicht klar ist, ob nun kbd oder die console-tools installiert werden sollen. Letzteres kann Apt nicht auflösen, weil keine libconsole installiert werden soll. Abhilfe mit:

apt-get install apache2-mpm-prefork console-tools libconsole
apt-get -f install

Konfiguration von Qmail schlägt fehl

Die Konfiguration von Qmail bricht mit dem Fehler 127 ab. Ursache ist, dass das Programm svc von den Daemontools nicht im Suchpfad gefunden werden kann. Abhilfe mit:

export PATH=/usr/local/bin:$PATH
apt-get -f install

Hilfspakete

Manche Postinstall-Scripte benötigen menu and pyhon. Wenn im Rahmen des Prozesses Nachrichten über update-menus failed auftreten, dann ist das hierauf zurückzuführen.

Manuell forcierte Installation dieser Pakete hilft auch hier:

dpkg -i /var/cache/apt/archives/menu* /var/cache/apt/archives/python*
apt-get -f install

Die gleiche Problematik (nur für Python) trifft auch bei Fehlermeldungen über python-apt und python-xapian zu.

apt-get install python2.5 python2.5-minimal
apt-get -f install

Manuelle Reinstallation verbleibender 32-Bit Pakete

Wenn ein apt-get install -f keine weiteren Aufgaben ausführt, ist das System soweit migriert. Trotzdem bleiben manchmal einige Pakete als 32-Bit-Variante erhalten. Falls Apt in der Statistik sagt, es würde noch ein Paket nicht aktualisiert worden, muss noch ein

apt-get dist-upgrade

Eine Auflistung der verbleibenden Pakete erhalten wir mit diesem Befehl:

dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'

Ein schöner Nebeneffekt dieser Methode ist, dass hierbei auch Leichen zutage gefördert werden. Also Pakete, die vor langer Zeit installiert wurden, einige Upgrades überlebt haben, aber inzwischen nicht mehr im Apt zu finden sind und deswegen nicht aktualisiert werden konnten. Diese können jetzt deinstalliert werden, bzw. durch ein funktional äquivalentes Paket ersetzt werden (wie z. B. pine → alpine).

Ein automatisches Upgrade aller restlichen 32-Bit-Pakete ergibt sich aus dem obigen Kommando zur Listenerzeugung:

apt-get install `dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'`

Alternativ kann die Liste Paket für Paket abgearbeitet werden. Dieser Vorgang ist langsamer, aber weniger fehleranfällig: Abhängigkeiten werden pro Paket separat behandelt.

for p in `dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'`; do
  apt-get -y install $p
done

Wenn hierbei nichts mehr passiert, werden keine 32-Bit-Pakete mehr gefunden. Als letzter Schritt sollte sicherheitshalber nochmal die initrd neu gebaut werden:

update-initramfs -u

Ein finaler Reboot startet dann das System in seiner 64-Bit-Variante.

Nacharbeiten

Da sich die Prozessorarchitektur geändert hat, haben sich teilweise auch (binäre) Datenformate geändert.

• INN startet nicht mehr mit der Logmeldung /var/lib/news/history cant dbminit SERVER Numerical argument out of domain. Die Binärdatenbank mit folgendem Kommando neu erzeugen (als User news):

/usr/lib/news/bin/makehistory -oir

• MTA prüfen (Aliasdatei, usw.).
• Netatalk prüfen (hat bei Squeeze keinen Ärger gemacht).
• RRD-Dateien prüfen (mailgraph, o. Ä.)

Ebenso müssen nachträglich hinzugefügte Kernelmodule neu erzeugt werden, wie z. B. Open-vm-tools, AFS, dahdi, Iscsitarget, usw.

Weblinks

• Debian-Wiki, Migrate32To64Bit
• Unüberprüfte Vorgehensweise für Wheezy