PoC: /* Installation von Apache2/kbd schlägt fehl */ Typo

2022-11-12T23:09:40Z

Installation von Apache2/kbd schlägt fehl: Typo

← Nächstältere Version		Version vom 13. November 2022, 01:09 Uhr
Zeile 157:		Zeile 157:
	=== Installation von Apache2/kbd schlägt fehl ===		=== Installation von Apache2/kbd schlägt fehl ===
	Die sehr unübersichtliche Ausgabe zeigt gleich zwei Fehler:		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,		* ''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:		* 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 install apache2-mpm-prefork console-tools libconsole

PoC: PoC verschob die Seite Debian-Migration 32- nach 64-Bit nach Debian-Squeeze-Migration 32- nach 64-Bit: Bald kommt neuer Artikel für Jessie

2015-08-09T19:39:48Z

PoC verschob die Seite Debian-Migration 32- nach 64-Bit nach Debian-Squeeze-Migration 32- nach 64-Bit: Bald kommt neuer Artikel für Jessie

Neue Seite

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 <nowiki>http://ftp.de.debian.org/debian</nowiki>

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 [http://cdimage.debian.org/cdimage/release/current-live/amd64/ 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 <code>apt-get install -f </code> 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 <code>/var/lib/news/history cant dbminit SERVER Numerical argument out of domain</code>. 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 ==
* [http://wiki.debian.org/Migrate32To64Bit Debian-Wiki, Migrate32To64Bit]
* [http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html Unüberprüfte Vorgehensweise für Wheezy]

[[Kategorie:Linux]]

Debian-Squeeze-Migration 32- nach 64-Bit - Versionsgeschichte

PoC: /* Installation von Apache2/kbd schlägt fehl */ Typo

PoC: PoC verschob die Seite Debian-Migration 32- nach 64-Bit nach Debian-Squeeze-Migration 32- nach 64-Bit: Bald kommt neuer Artikel für Jessie