Probleme nach Upgrade auf Debian 10

[CaoCao]

Hallo zusammen,

ehe ich auf aktiv laufenden Servern den Schritt von Debian 9 auf 10 vollziehe wollte ich das auf einem Testsystem vorab durchspielen. Damals, von 8 auf 9 ging das weitestgehend ohne Schwierigkeiten.
Also testweise einen kleinen vServer bei Server4You für paar Euronen geordert, Debian 8 Minimal drauf geklatscht und losgelegt. Alles aktualisiert, dann die sources.list angepasst -> update, dist-upgrade.

Schon während dem Dist-Upgrade wird eine weitere SSH-Verbindung direkt gecancelt, ist das Upgrade durch zeigen sich mehrere Fehler - z.B. bei Verwendung von sudo:

Code: Alles auswählen

sudo: getrlimit: Function not implemented
sudo: setrlimit: Function not implemented
sudo: setrlimit: Function not implemented
sudo: getrlimit: Function not implemented
sudo: setrlimit: Function not implemented
sudo: setrlimit: Function not implemented

Das Upgrade selbst (ob von 8 auf 10 oder von 9 auf 10) wird jeweils beendet mit:

Code: Alles auswählen

Errors were encountered while processing:
 udev
 initramfs-tools-core
 initramfs-tools

Irgendwas am neuen Kernel passt da nicht... will ich mir entsprechende Details über z.B. journalctl -xe ansehen, wird das aber quittiert mit:

Code: Alles auswählen

Failed to lower RLIMIT_NOFILE's soft limit to 1K: Function not implemented

So... ehe ich da nun weitere Stunden in alle Richtungen google: Hat hier jemand spontan/direkt nen konkreten Anhaltspunkt, wo ich dazu ansetzen kann oder was ich falsch gemacht habe?
Wenn ich die SSH-Session schließe, komme ich natürlich nicht mehr drauf - und muss wieder auf Debian 8 Minimal restoren.


Grüße

[DeletedUserReAsG]

Du weißt, dass du bei billigen vServern je nach Virtualisierung keinen Zugriff auf den Kernel hast? Das wäre das erste, was ich prüfen würde.

[CaoCao]

Also auf /boot/ habe ich Zugriff... !?

Ein Wechsel von 8 auf 9 funktioniert außerdem reibungslos; weshalb nicht auch auf 10?

[DeletedUserReAsG]

Also auf /boot/ habe ich Zugriff... !?

Die interessante Frage ist, was uname -a ausgibt.

Ein Wechsel von 8 auf 9 funktioniert außerdem reibungslos; weshalb nicht auch auf 10?

Möglicherweise, weil unter 10 Funktionalität benötigt wird, die vom vorliegenden Kernel einfach nicht zur Verfügung gestellt wird? Das wäre jedenfalls rauszufinden.

OT: als Testszenario für Server (ohne ›v‹) würde ich immer lokal ’ne VM aufsetzen. Dadurch baut man sich keine künstlichen Problemstellen rein, die man sonst nicht hätte, und muss sich auch keine Sorgen um Zugriffsmöglichkeiten machen.

[CaoCao]

Also auf /boot/ habe ich Zugriff... !?

Die interessante Frage ist, was uname -a ausgibt.

Folgendes:

Code: Alles auswählen

root@euve266432:/boot# uname -a
Linux euve266432 3.16.0-042stab138.1 #1 SMP Wed May 15 09:33:10 MSK 2019 x86_64 GNU/Linux

[DeletedUserReAsG]

Dieser Kernel ist uralt, und stammt von Jessie/Debian 8. Bedeutet: dass dein Stretch/Debian9 damit problemlos funktioniert hat, war auch eher Zufall.

Edit:

Das Upgrade selbst (ob von 8 auf 10 oder von 9 auf 10) wird jeweils beendet mit: […]

Die Gründe dafür, der eigentlich interessante Teil der Ausgabe, stehen weiter oben.

[CaoCao]

Hmm... okay... verdammt...
Aber danke.

[CaoCao]

Dieser Kernel ist uralt, und stammt von Jessie/Debian 8. Bedeutet: dass dein Stretch/Debian9 damit problemlos funktioniert hat, war auch eher Zufall.

Edit:

Das Upgrade selbst (ob von 8 auf 10 oder von 9 auf 10) wird jeweils beendet mit: […]

Die Gründe dafür, der eigentlich interessante Teil der Ausgabe, stehen weiter oben.

Weiter oben steht viel, schließlich läuft da ja das Update durch ^^ - so wie ich das verfolge haut bis dahin auch alles hin:

Code: Alles auswählen

Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/resolved.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/timesyncd.conf ...
Job for systemd-journald.service failed because the control process exited with error code.
See "systemctl status systemd-journald.service" and "journalctl -xe" for details.
Job for systemd-resolved.service failed.
See "systemctl status systemd-resolved.service" and "journalctl -xe" for details.
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 241-5); however:
  Package systemd is not configured yet.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of systemd-sysv:
 systemd-sysv depends on systemd; however:
  Package systemd is not configured yet.

dpkg: dependency problems prevent configuration of libnss-systemd:amd64:
 libnss-systemd:amd64 depends on systemd (= 241-5); however:
  Package systemd is not configured yet.

dpkg: error processing package libnss-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for dbus (1.12.16-1) ...
Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
Processing triggers for mime-support (3.62) ...
Processing triggers for libc-bin (2.28-10) ...
Processing triggers for ca-certificates (20190110) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for initramfs-tools (0.133) ...
Errors were encountered while processing:

[DeletedUserReAsG]

Ja, hängt damit zusammen. Der laufende 3.16er-Kernel ist auch keiner direkt von Debian, nur halt einer aus der Generation von Jessie. Somit wäre die erste Antwort zielführend: es läuft also eine Virtualisierung, bei der du keinen Zugriff auf den Kernel hast. Du könntest den Support des Anbieters kontaktieren und fragen, ob du nicht ’ne Maschine mit aktuellem Kern bekommen könntest. Oder halt, wenn’s eh zu Testzwecken sein soll, lokal ’ne VM aufsetzen und gut – wie schon geschrieben. Ist ja auch schnell gemacht.

[CaoCao]

Ja, hängt damit zusammen. Der laufende 3.16er-Kernel ist auch keiner direkt von Debian, nur halt einer aus der Generation von Jessie. Somit wäre die erste Antwort zielführend: es läuft also eine Virtualisierung, bei der du keinen Zugriff auf den Kernel hast. Du könntest den Support des Anbieters kontaktieren und fragen, ob du nicht ’ne Maschine mit aktuellem Kern bekommen könntest. Oder halt, wenn’s eh zu Testzwecken sein soll, lokal ’ne VM aufsetzen und gut – wie schon geschrieben. Ist ja auch schnell gemacht.

Installation in ner VM bei mir lokal läuft gerade; mach ich nun auch so...
Auf den dedizierten Roots gibts diese Hürde ja ebenfalls nicht, daher ist dein Weg ohnehin der effektivste.