expertenaustausch > linux.debian.user.german

Martin Steigerwald (12.01.2018, 18: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, 21: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, 22: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, 22: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 (12.01.2018, 23: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 (12.01.2018, 23: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 (12.01.2018, 23: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 (12.01.2018, 23: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 (12.01.2018, 23: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, 00: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, 11: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,
Paul Muster (24.01.2018, 22:10)
On 13.01.2018 11:22, Martin Steigerwald wrote:

> 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,was ja
> auch mit dem 32-Bit-Apt-Zeug geht? Damit gehe ich erst mal noch kein Risiko
> ein.


Berechtigte Fragen.

Hast du mittlerweile evtl. weiter getestet und neue Erkenntnisse? Ich
habe bisher auch nur den Kernel gewechselt, würde aber durchaus gerne -
wenn es positive Erfahrungen gibt - auch das Userland crossgraden.

mfG Paul
Spiro Trikaliotis (25.01.2018, 22:30)
Hallo,

* On Wed, Jan 24, 2018 at 09:56:48PM +0100 Paul Muster wrote:
> On 13.01.2018 11:22, Martin Steigerwald wrote:
> Berechtigte Fragen.


Vermutung: apt/apt-get/aptitude/... aus der richtigen Version wissen am
besten, wie man mit den Abhängigkeiten gerade aus dieser Version umgeht.
Daher macht es wohl Sinn, apt(*) als erstes umzustellen, um nicht
vielleicht wegen Fehlern oder anderen Dingen, die in späteren Versionen
umgestellt wurden, auf einem nicht benutzbaren System zu hängen.

Ausserdem passt es zu dem Grundsatz "fail early". ;)

Viele Grüße,
Spiro.
Martin Steigerwald (25.01.2018, 23:00)
Spiro Trikaliotis - 25.01.18, 22:10:
> Hallo,
> * On Wed, Jan 24, 2018 at 09:56:48PM +0100 Paul Muster wrote:
> Vermutung: apt/apt-get/aptitude/... aus der richtigen Version wissen am
> besten, wie man mit den Abhängigkeiten gerade aus dieser Version umgeht.
> Daher macht es wohl Sinn, apt(*) als erstes umzustellen, um nicht
> vielleicht wegen Fehlern oder anderen Dingen, die in späteren Versionen
> umgestellt wurden, auf einem nicht benutzbaren System zu hängen.
> Ausserdem passt es zu dem Grundsatz "fail early". ;)


Hmmm, das bröselt wahrscheinlich aber die Update-Fähigkeit in Stücke, da
es standardmäßig amd64-Pakete installieren würde, oder würde ein amd64
apt dann i386-Pakete beim Aktualisieren weiterhin auf i386 belassen?
hmm, an sich ja schon, macht es ja auf einem "normalen" Multiarch-System
auch nicht anders? Ich glaube auch nicht, dass sich die Abhängigkeiten-
Auflösung innerhalb von apt selbst architektur-spezifisch ist. Ich denke, es
beachtet einfach nur die Abhängigkeiten zwischen den Paketen und eben
die zumindest teilweise die Multiarch-Besonderheiten.

So oder so kommt apt dann schon mal mit der Warnung, dass ich im
Begriff sei, was potentiell Schädliches zu tun.

mondschein:~> apt install apt:amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
libregexp-assemble-perl python3-apt python3-chardet python3-debian python3-debianbts python3-httplib2 python3-pkg-resources python3-pycurl python3-pysimplesoap
python3-requests python3-six python3-urllib3 ruby-soap4r ruby-unicode
Verwenden Sie »apt autoremove«, um sie zu entfernen.
The following additional packages will be installed:
libapt-pkg5.0:amd64 libbz2-1.0:amd64 libstdc++6:amd64
Vorgeschlagene Pakete:
apt-doc:amd64 powermgmt-base:amd64 python-apt:amd64
Die folgenden Pakete werden ENTFERNT:
apt apt-file apt-listbugs apt-listchanges apt-show-versions apt-utils apticron python-reportbug python3-reportbug reportbug
Die folgenden NEUEN Pakete werden installiert:
apt:amd64 libapt-pkg5.0:amd64 libbz2-1.0:amd64 libstdc++6:amd64
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
apt
0 aktualisiert, 4 neu installiert, 10 zu entfernen und 0 nicht aktualisiert.
Es müssen 2.588 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 2.054 kB Plattenplatz zusätzlich benutzt.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
?]

Ich glaube zwar, dass das nur kommt, weil ein essentielles Paket betroffen
ist und apt das nicht rafft, dass ich es ja gleich als amd64-Fassung wieder
drauf haben möchte? aber dennoch.

Meine Idee war eigentlich gerade anders herum: Mich von den harmloseren
Dingen zu den gefährlicheren vorarbeiten und währenddessen die
Betriebsfähigkeit des Systems zu erhalten. Zum Beispiel erst mal diverse
Rettungsanker an den Start bringen, wie dieses hier:

mondschein:~#1> apt install bash-static:amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Vorgeschlagene Pakete:
bash-doc:amd64
Die folgenden NEUEN Pakete werden installiert:
bash-static:amd64
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 1.033 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 2.268 kB Plattenplatz zusätzlich benutzt.
Holen:1 stretch/main amd64 bash-static amd64 4.4-5 [1.033 kB]
Es wurden 1.033 kB in 1 s geholt (833 kB/s).
Laden der Fehlerberichte ? Erledigt
»Found/Fixed«-Informationen werden ausgewertet ? Erledigt
Vormals nicht ausgewähltes Paket bash-static:amd64 wird gewählt.
(Lese Datenbank ... 92071 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../bash-static_4.4-5_amd64.deb ...
Entpacken von bash-static:amd64 (4.4-5) ...
bash-static:amd64 (4.4-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.

mondschein:~> bash-static
mondschein:~#

Dito geht das mit zsh-static und sogar mit zsh, die ja ansonsten meine
Standard-Shell ist. Ich kann mich danach auch noch via SSH anmelden,
soweit so gut. Das Schöne ist, dass jetzt schon ein paar mehr Bibliotheks-
Pakete in amd64-Fassung drauf sind. Z.B. ncurses.

Und genau das war ja meine Idee? ihm so viele amd64-Pakete wie möglich
unter zu schieben, dass dann der kritische Schritt vielleicht gar nicht mehr
kritisch ist.

Ich denke jedoch, dass es mit bash:amd64 Ärger gibt. Mal
sehen:

mondschein:~> apt install bash:amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
The following additional packages will be installed:
dash:amd64
Vorgeschlagene Pakete:
bash-doc:amd64
Die folgenden Pakete werden ENTFERNT:
bash dash
Die folgenden NEUEN Pakete werden installiert:
bash:amd64 dash:amd64
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
bash dash (wegen bash)
0 aktualisiert, 2 neu installiert, 2 zu entfernen und 0 nicht aktualisiert.
Es müssen 1.536 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 162 kB Plattenplatz freigegeben.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
?]

Naja, gut, das ist wegen essentiellen Paket. Wie auch beim apt?, das ja
ansonsten auch gut durchlaufen dürfte. So oder so? das traue ich mich
erst mit Snapshot der VM :). Hoffentlich :)

Hehe? ich komme mir gerade vor wie jemand, der Yenga spielt. Ich ziehe
klötze aus dem Turm raus und schaue, wann der Turm in sich zusammen
fällt.

Beim Aktualisieren von Diensten wie cron sind bereits Abhängigkeiten zu
beachten, denn sonst würde ich meinen MTA los:

mondschein:~> apt install cron:amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
guile-2.0-libs libkyotocabinet16v5 liblmdb0 libmailutils5 python-dnspython
Verwenden Sie »apt autoremove«, um sie zu entfernen.
The following additional packages will be installed:
anacron bsd-mailx exim4-base exim4-config exim4-daemon-light libaudit1:amd64 liblockfile1 libpam0g:amd64
Vorgeschlagene Pakete:
powermgmt-base anacron:amd64 logrotate:amd64 checksecurity:amd64 eximon4 exim4-doc-html | exim4-doc-info spf-tools-perl swaks libpam-doc:amd64
Empfohlene Pakete:
cron | cron-daemon exim4:amd64 | postfix:amd64 | mail-transport-agent:amd64
Die folgenden Pakete werden ENTFERNT:
apticron cron mailman mailutils pmailq postfix postfix-lmdb postfix-pcre postfix-sqlite
Die folgenden NEUEN Pakete werden installiert:
anacron bsd-mailx cron:amd64 exim4-base exim4-config exim4-daemon-light libaudit1:amd64 liblockfile1 libpam0g:amd64
0 aktualisiert, 9 neu installiert, 9 zu entfernen und 0 nicht aktualisiert.
Es müssen 2.445 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 40,6 MB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]

Das geht schon, wenn ich postfix:amd64 noch dazu nehme, aber spätestens
wenn ich mailman:amd64 dazu nehme, gibt es wieder Ärger, wahrscheinlich
wegen Python. Aber das ginge vielleicht schrittweise, also erstmal entfernen
lassen und dann wieder drauf.

Aber gut, genug davon jetzt.

Ciao,
Martin Steigerwald (25.01.2018, 23:20)
Martin Steigerwald - 25.01.18, 22:53:
> Dito geht das mit zsh-static und sogar mit zsh, die ja ansonsten meine
> Standard-Shell ist. Ich kann mich danach auch noch via SSH anmelden,
> soweit so gut. Das Schöne ist, dass jetzt schon ein paar mehr Bibliotheks-
> Pakete in amd64-Fassung drauf sind. Z.B. ncurses.
> Und genau das war ja meine Idee? ihm so viele amd64-Pakete wie möglich
> unter zu schieben, dass dann der kritische Schritt vielleicht gar nicht mehr
> kritisch ist.


Hmmm, irgendwo ist wahrscheinlich ein kritischer Schritt, den ich nicht
wirklich umgehen kann.

Möglicherweise genau beim Austausch von apt, dpkg & co bzw. anderen kritischen
System-Komponenten. Ich frage mich gerade, wie dpkg Pakete auspackt? Was ist,
wenn ich ihm da unten drunter gerade wegziehe, was zum Paket installieren
gerade braucht. Z.B. beim Aktualisieren von coreutils (bei dem im Übrigen auch
die potentiell-schädlich Warnung kommt), das ja ggf. diverse Maintainer-
Skripte verwenden.

busybox-static:amd64 ist jetzt auch drauf.

Ähnliche Themen