expertenaustausch > linux.debian.user.german

Martin Steigerwald (12.01.2018, 19:10)
Hallo.

Angesichts der Meltdown/Spectre-Geschichten habe ich mal wieder daran gedacht,
meinen letzten 32-bittigen Debian Stretch-Server auf 64-Bit zu migrieren.

Was ist denn da der letzte Stand zu? Offiziell unterstützt ist das
wahrscheinlich immer noch nicht. Aber was ist die beste,
erfolgsversprechendste Anleitung dazu?

Ich kann natürlich abwarten, inwiefern es für 32-Bit-Fixes gibt. Mir ist auch
nicht klar, inwieweit der Hypervisor, in diesem Fall ein VMware ESX das
vielleicht auf Host-Ebene für alle VMs abfangen kann. Wahrscheinlich sind
dessen Möglichkeiten begrenzt.

Danke,
Sven Hartge (12.01.2018, 22:50)
Martin Steigerwald <martin> wrote:

> Angesichts der Meltdown/Spectre-Geschichten habe ich mal wieder daran
> gedacht, meinen letzten 32-bittigen Debian Stretch-Server auf 64-Bit
> zu migrieren.


> Was ist denn da der letzte Stand zu? Offiziell unterstützt ist das
> wahrscheinlich immer noch nicht. Aber was ist die beste,
> erfolgsversprechendste Anleitung dazu?


Backup, Reinstall mit 64bit, Restore.

Manuell habe ich vor 8 Wochen das letzte gemacht, allerdings mit einem
meiner Sid-Systeme. Dort habe ich knapp über 3 Stunden gebraucht, die
meiste Zeit dabei manuell Abhänigkeiten aufgelöst, Ring-Abhängigkeiten
umgangen und in zwei Fällen Daten gedumpt und danach neu eingespielt,
weil die Programme eine bitbreitenabhängige Datenstruktur genutzt haben.

Spassig ist anders.

> Ich kann natürlich abwarten, inwiefern es für 32-Bit-Fixes gibt. Mir
> ist auch nicht klar, inwieweit der Hypervisor, in diesem Fall ein
> VMware ESX das vielleicht auf Host-Ebene für alle VMs abfangen kann.


Warte nicht darauf.

> Wahrscheinlich sind dessen Möglichkeiten begrenzt.


Wenn man brauchbare Performance haben will: ja.

Stefan Baur (12.01.2018, 23:00)
Am 12.01.2018 um 18:00 schrieb Martin Steigerwald:

> Angesichts der Meltdown/Spectre-Geschichten habe ich mal wieder daran
> gedacht, meinen letzten 32-bittigen Debian Stretch-Server auf 64-Bit zu
> migrieren.


> Was ist denn da der letzte Stand zu? Offiziell unterstützt ist das
> wahrscheinlich immer noch nicht. Aber was ist die beste,
> erfolgsversprechendste Anleitung dazu?


Grundsätzlich diese Seite aus dem Debian-Wiki:
<https://wiki.debian.org/CrossGrading>
(<https://wiki.debian.org/Migrate32To64Bit> ist veraltet, weist aber
auch im Header auf die neuere Seite hin)

Ich habe das neulich in einer VM durchgezogen, die bislang nur 32-Bit
war. Natürlich vorher einen Snapshot gemacht.
Es war ziemlich haarig und hätte jederzeit schiefgehen können. Deswegen
wirklich nur machen, wenn VM+Snapshot, oder komplettes, getestetes
Offline-Backup vorhanden.

Anfangs lief es wie in der Anleitung beschrieben, irgendwann verhakte
sich dann aber apt-get.

Es artete dann dahingehend aus, dass ich mir per dpkg -l eine Liste
aller Pakete ausgeben ließ, diese auf "^ii" und "i386" filterte, und die
Pakete dann einzeln bzw. in zusammenhängenden Gruppen durch ihr
amd64-Paket ersetzen ließ (mit "apt-get install paketname:amd64").
Dabei kam es des öfteren zu Warnungen, die nur mit "Yes, do as I say!"
zu umgehen waren - aber es ging.
Scheinbar erkennt apt-get nicht, dass man ein essentielles Paket zwar
deinstallieren, aber umgehend durch sein 64-Bit-Pendant ersetzen will,
und gibt daher die Warnungen aus.

> Ich kann natürlich abwarten, inwiefern es für 32-Bit-Fixes gibt. Mir ist
> auch nicht klar, inwieweit der Hypervisor, in diesem Fall ein VMware ESX
> das vielleicht auf Host-Ebene für alle VMs abfangen kann. Wahrscheinlich
> sind dessen Möglichkeiten begrenzt.


Aussage von den QEMU-Entwicklern hierzu war, ist der Host gefixt, können
Gäste nicht mehr Amok laufen und Daten aus dem Host/aus anderen Gästen
lesen. Innerhalb eines Gastes kann natürlich immer noch Mist passieren
(wenn dort z.B. ein Browser läuft und ein JavaScript mit Exploit-Code
startet, kann das zwar keinen anderen Hast und auch nicht den Host
auslesen, wenn der Host gepatcht ist, aber andere Prozesse des
Gastsystems, in dem es läuft, inklusive dessen Kernel-Memory).
Ich würde vermuten, dass das für ESX(i) genauso gilt.

Gruß
Stefan
Stefan Baur (12.01.2018, 23:10)
Am 12.01.2018 um 21:56 schrieb Stefan Baur:
[..]
> Scheinbar erkennt apt-get nicht, dass man ein essentielles Paket zwar
> deinstallieren, aber umgehend durch sein 64-Bit-Pendant ersetzen will,
> und gibt daher die Warnungen aus.


Nachtrag dazu: Wenn man die amd64-Pakete alle installiert hat, kann man
sich daran machen, die i386er-Pakete, die nicht automatisch rausgeflogen
sind, per apt-get remove oder per apt-get purge zu löschen.
Sinnvollerweise macht man das erst nach einem Reboot mit dem
amd64-Kernel, weil man sonst den aktuell laufenden i386-Kernel nicht
restlos los wird.

Gruß
Stefan
Martin Steigerwald (13.01.2018, 00:00)
Sven Hartge - 12.01.18, 21:42:
> Martin Steigerwald <martin> wrote:
> Backup, Reinstall mit 64bit, Restore.
> Manuell habe ich vor 8 Wochen das letzte gemacht, allerdings mit einem
> meiner Sid-Systeme. Dort habe ich knapp über 3 Stunden gebraucht, die
> meiste Zeit dabei manuell Abhänigkeiten aufgelöst, Ring-Abhängigkeiten
> umgangen und in zwei Fällen Daten gedumpt und danach neu eingespielt,
> weil die Programme eine bitbreitenabhängige Datenstruktur genutzt haben.
> Spassig ist anders.


Hmmmmm? ich hatte gehofft, dass das mittlerweile einfacher geht.

Auf dem Server laufen auch so einige Dienste? d.h. ich müsste mir an sich ne
zweite VM geben lassen? diese komplett neu installieren und dann die Dienste
installieren und anhand der Konfiguration aus der alten VM einrichten, um dann
via DNS umzuschalten. Genug IPv4-Adressen hätte ich dafür. Und IPv6 sowieso.

Da brauche ich wahrscheinlich länger als 3 Stunden zu. Aber? es wäre wohl das
sicherste Vorgehen.

Naja, vielleicht lasse ich mir die VM dennoch mal snapshotten und probier die
Crossgrade-Geschichte. Falls das schief geht, kann ich immer noch den anderen
Weg gehen.

Bezüglich Meltdown überlege ich, zumindest bereits mal einen 64-Bit-Kernel zu
installieren, der dann eben erst mal mit 32-Bit-Userspace läuft. Das dürfte
zumindest für Meltdown helfen.

Ciao,
Sven Hartge (13.01.2018, 00:00)
Stefan Baur <newsgroups.mail2> wrote:

> Nachtrag dazu: Wenn man die amd64-Pakete alle installiert hat, kann
> man sich daran machen, die i386er-Pakete, die nicht automatisch
> rausgeflogen sind, per apt-get remove oder per apt-get purge zu
> löschen. Sinnvollerweise macht man das erst nach einem Reboot mit dem
> amd64-Kernel, weil man sonst den aktuell laufenden i386-Kernel nicht
> restlos los wird.


Man muss ja ohnehin *zuerst* in den AMD64-Kernel booten, um überhaupt
Cross-Graden zu können, sonst ist spätestens beim Ersetzen des ersten
essentiellen Programmes durch die 64bit-Fassung schluss, weil nichts
mehr läuft.

Martin Steigerwald (13.01.2018, 00:00)
Stefan Baur - 12.01.18, 21:56:
[..]
> Scheinbar erkennt apt-get nicht, dass man ein essentielles Paket zwar
> deinstallieren, aber umgehend durch sein 64-Bit-Pendant ersetzen will,
> und gibt daher die Warnungen aus.


Danke, Stefan.

Das sieht ja so aus, als ob das gehen könnte, und es wäre nicht das erste Mal,
dass ich in die Untiefen des Paketmanagement-Systems hinab gestiegen bin?
dennoch hoffte ich, dass das mittlerweile verlässlicher funktioniert.

Na mal sehen, wie ich mich da entscheide.

Ciao,
Sven Hartge (13.01.2018, 00:10)
Martin Steigerwald <martin> wrote:
> Sven Hartge - 12.01.18, 21:42:



> Hmmmmm? ich hatte gehofft, dass das mittlerweile einfacher geht.


Der Grund ist, dass noch bei weitem nicht alle Pakete die korrekten
Multi-Arch-Markierungen haben, so dass technisch eigentlich funktionierende
Cross-Architektur-Abhängigkeiten vom Paketmanagement nicht erkannt
werden und das Cross-Grade an der Stelle dann hängt und man manuell
eingreifen muss, manchmal auch mit --force.

> Bezüglich Meltdown überlege ich, zumindest bereits mal einen
> 64-Bit-Kernel zu installieren, der dann eben erst mal mit
> 32-Bit-Userspace läuft. Das dürfte zumindest für Meltdown helfen.


Das funktioniert auch, ja.

Martin Steigerwald (13.01.2018, 00:30)
Hi Sven.

Sven Hartge - 12.01.18, 23:00:
> > Bezüglich Meltdown überlege ich, zumindest bereits mal einen
> > 64-Bit-Kernel zu installieren, der dann eben erst mal mit
> > 32-Bit-Userspace läuft. Das dürfte zumindest für Meltdown helfen.

> Das funktioniert auch, ja.


Nagut, das hat zumindest mal funktioniert und auch schon lustig ein paar
weitere amd64-Pakete installiert:

% apt install linux-image-amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
The following additional packages will be installed:
gcc-6-base:amd64 irqbalance:amd64 libblkid1:amd64 libc6:amd64 libcap-
ng0:amd64 libffi6:amd64 libgcc1:amd64 libgcrypt20:amd64 libglib2.0-0:amd64
libglib2.0-data libgpg-error0:amd64 liblz4-1:amd64 liblzma5:amd64
libmount1:amd64 libnuma1:amd64 libpcre3:amd64 libselinux1:amd64
libsystemd0:amd64 libuuid1:amd64 linux-image-4.9.0-5-amd64:amd64 uuid-runtime
xdg-user-dirs zlib1g:amd64
Vorgeschlagene Pakete:
glibc-doc:amd64 locales:amd64 rng-tools:amd64 linux-doc-4.9:amd64 debian-
kernel-handbook:amd64
Die folgenden Pakete werden ENTFERNT:
irqbalance
Die folgenden NEUEN Pakete werden installiert:
gcc-6-base:amd64 irqbalance:amd64 libblkid1:amd64 libc6:amd64 libcap-
ng0:amd64 libffi6:amd64 libgcc1:amd64 libgcrypt20:amd64 libglib2.0-0:amd64
libglib2.0-data libgpg-error0:amd64 liblz4-1:amd64 liblzma5:amd64
libmount1:amd64 libnuma1:amd64 libpcre3:amd64 libselinux1:amd64
libsystemd0:amd64 libuuid1:amd64 linux-image-4.9.0-5-amd64:amd64 linux-image-
amd64:amd64 uuid-runtime xdg-user-dirs zlib1g:amd64
0 aktualisiert, 24 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0 B von 49,3 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 222 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Laden der Fehlerberichte ? Erledigt
»Found/Fixed«-Informationen werden ausgewertet ? Erledigt
critical Fehler von libc6:amd64 (? 2.24-11+deb9u1) <In einigen Versionen
gelöst>
b1 - #882272 - libc6:amd64: upgrade of libc6:amd64 + libc6:i386 + libc6-i686
breaks system (Gelöst: glibc/2.24-11+deb9u2 glibc/2.25-2)
serious Fehler von libgpg-error0:amd64 (? 1.26-2) <In einigen Versionen
gelöst>
b2 - #863659 - debian/copyright puts LGPL-2.1+ text in GPL-2.1+ license block
(Gelöst: libgpg-error/1.27-3)
Zusammenfassung:
libc6:amd64(1 Fehler), libgpg-error0:amd64(1 Fehler)
Sind Sie sicher, dass Sie die oben genannten Pakete installieren bzw. ein
Upgrade von ihnen durchführen wollen? [Y/n/?/...]

Ja, ich hab geschaut, ob diese optimierte libc6-i686 installiert war, bevor
ich apt das Update durchführen lassen ? war sie nicht.

Ciao,
Martin Steigerwald (13.01.2018, 01:10)
Stefan Baur - 12.01.18, 21:56:
> Es artete dann dahingehend aus, dass ich mir per dpkg -l eine Liste
> aller Pakete ausgeben ließ, diese auf "^ii" und "i386" filterte, unddie
> Pakete dann einzeln bzw. in zusammenhängenden Gruppen durch ihr
> amd64-Paket ersetzen ließ (mit "apt-get install paketname:amd64").
> Dabei kam es des öfteren zu Warnungen, die nur mit "Yes, do as I say!"
> zu umgehen waren - aber es ging.
> Scheinbar erkennt apt-get nicht, dass man ein essentielles Paket zwar
> deinstallieren, aber umgehend durch sein 64-Bit-Pendant ersetzen will,
> und gibt daher die Warnungen aus.


Hmmm, auf der CrossGrade-Seite im Debian-Wiki ist



verlinkt.

Das nutzt --allow-remove-essential, um apt davon zu überzeugen, die 32-Bit-
Pakete zu entsorgen. Das sieht krass aus? ist aber vielleicht genaudas, was
die von Dir geschilderten Probleme umgeht. Allerdings besteht dann ein höheres
Risiko, essentielle Pakete zu entsorgen, die vielleicht noch gebraucht werden?

Nun, ohne VM-Snapshot wage ich mich da nicht ran. Daher bleibt es fürsErste
beim 64-Bit-Kernel.

Ciao,
Martin Steigerwald (13.01.2018, 12:30)
Martin Steigerwald - 13.01.18, 00:02:
[..]
> gebraucht werden?
> Nun, ohne VM-Snapshot wage ich mich da nicht ran. Daher bleibt es fürs Erste
> beim 64-Bit-Kernel.


Ich frage mich gerade, inwiefern die Reihenfolge:

1. apt/dpkg/tar ersetzen.

2. Bibliotheken ersetzen.

3. Restliche Pakete ersetzen.

wirklich Sinn macht.

Warum apt/dpkg/tar bereits am Anfang umbauen? Warum einen der riskanteren
Schritte gleich am Anfang?

Warum installiere ich nicht erst alle Bibliotheken in 64-Bit-Versionen, wasja
auch mit dem 32-Bit-Apt-Zeug geht? Damit gehe ich erst mal noch kein Risiko
ein.

Und dann kann ich das ganze auch erst mal testen, indem ich ein Paket mit
einem für mich eher unwichtigen Befehl (z.B. tree) als 64-Bit-Version
installiere. Funktioniert der Befehl, dann kann ich mich schrittweise zu den
kritischeren Komponenten vorarbeiten.

Interessanterweise würde das für den tree-Befehl auch einfach so durchlaufen
auf meinem Server:

% apt install tree:amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
tree
Die folgenden NEUEN Pakete werden installiert:
tree:amd64
0 aktualisiert, 1 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Es müssen 46,1 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 7.168 B Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]
Holen:1 stretch/main amd64 tree amd64 1.7.0-5
[46,1 kB]
Es wurden 46,1 kB in 0 s geholt (410 kB/s).
Laden der Fehlerberichte ? Erledigt
»Found/Fixed«-Informationen werden ausgewertet ? Erledigt
Vormals nicht ausgewähltes Paket tree:amd64 wird gewählt.
(Lese Datenbank ... 92071 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../tree_1.7.0-5_amd64.deb ...
Entpacken von tree:amd64 (1.7.0-5) über (1.7.0-5) ...
tree:amd64 (1.7.0-5) wird eingerichtet ...
Trigger für man-db (2.7.6.1-2) werden verarbeitet ...
Prüfe Prozesse...
Prüfe Linux-Kernel...
Der laufende Kernel ist aktuell.
Es müssen keine Dienste neugestartet werden.
Es müssen keine Container neu gestartet werden.
Es gibt keine Nutzer-Sitzungen mit veralteten Prozessen.

Und der Befehl tut danach auch:

mondschein:~> file /usr/bin/tree
/usr/bin/tree: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
2.6.32, BuildID[sha1]=82bcf4eab00b4f71a0a87b92c489dd6585cb6ed9, stripped

(jaja, ich wollte da ohne Snapshot nix mehr dran rum basteln :)

Der Befehl "tree" funktioniert auch in der 64-Bit-Version.

Übersehe ich da etwas?

Warum apt/dpkg/tar und andere kritischere Komponenten wie coreutils, util-
linux, systemd (die libsystemd hat apt ja bereits als 64-Bit-Version drauf
installiert) nicht eher zum Schluss des Crossgrades? Warum das ganze nicht
inkrementeller angehen, mit der Option, zwischen drin auch mal zu pausieren
und Fehlerberichte zu schreiben, falls es Probleme gibt?

Das hätte auch den Vorteil, das die Bibliotheken dann bereits alle oder fast
alle zusätzlich als 64-Bit installiert sind, bevor ich die kritischeren Sachen
umbaue.

Danke,
Ähnliche Themen