VPS G11 mit "altem" Debian 64 Bit

Zitat von voip2gsm

Unsere letzten Server sind bei HE und auf eigener Hardware virtualisiert - das muss ein Ende haben, denn bei denen ...naja...

Jetzt bin ich aber gespannt.

Zitat von voip2gsm

wir haben ja schon darauf gewartet, bis die ersten typisch deutschen Foreneinträge kommen, von Leuten, die nicht aufmerksam lesen.

Wir, sind das du und dein Ego?
Die Nachfrage, ob das Problem vor dem Rechner sitzt, führt in 99,9% der Fälle zu einem positiven Resultat.
Alleine die Tatsache, dass "Ihr" bei Problemen mit dem 64'er Image das 32'er versucht - obwohl dieses nicht für euch in Frage kommt berechtigt ja wohl die Nachfrage.

In diesem Sinne wünsche ich einen sonnigen Tag.

Zitat von voip2gsm

Unsere letzten Server sind bei HE und auf eigener Hardware virtualisiert - das muss ein Ende haben, denn bei denen ...naja...

Das habe ich jetzt nicht wirklich verstanden. Könntest du bitte dies nochmal genauer beschreiben?

Denn ich betreibe auch bei einem Provider meiner Wahl echte Hardware mit installiertem Hypervisor mit eigenen VM´s in Frankfurt und kann mir von daher nicht wirklich vorstellen, dass man davon weg möchte.

Ziemlich sicher, dass es das ist:

https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01220.html

(Der Kernel macht einen Fehler auf einer bestimmten Hardwarekonstellation, in dem Fall eine Google Compute VM, weil wegen der unterschiedlichen Behandlung verschiedener CPUs in dem Fall die Invalidierung eines Translation Lookaside Buffer Eintrags fehlt. Das führt zu einem fehlerhaften Speicherzugriff. Mit anderen Worten: Alte fehlerhafte Software kommt nicht mit bestimmter neuerer "Hardware" klar. Ich vermute, dass für die VMs, wo der Fehler des Linuxkernels zum Tragen kommt, die virtuellen CPUs anders konfiguriert sind.)

Zitat von voip2gsm

Echt?

Ja, jetzt habe ich es auch verstanden.

Zitat von voip2gsm

Zugegeben, die Server machen nicht ganz so viel Ärger, wie die StorageBoxen ..

Die Dedicated Server (echtes Blech) machen von daher im Gegensatz zu vServer oder anderen Dienstleistungen keinen Ärger, weil du diese, solange kein Hardwareschaden vorhanden ist, warten kannst, wann du willst.

Zitat von voip2gsm

.. aber ein Unternehmen, aus der MEZ, welches nur (!) tagsüber Updates und Wartungen durchführt und jetzt auf den StorageBoxen nun das zweite Mal in 10 Tagen, passt nicht in eine stabile Umgebung.

Sobald du Dienstleistung in dieser Art einkaufst, muss man sich nach dem Wartungfenster des Providers richten.

Aber durch zubuchen von Storage-Servern (echtes Blech) aus dessen Serverbörse kannst du dieses Problem problemlos beseitigen. Denn auch hier kannst du das System zu jeder Zeit ungestört warten, da hier der Provider nicht dazwischenfunkt.

Zitat von NaN

die virtuellen CPUs anders konfiguriert sind.

Kann man das als Kunde selbst feststellen, z.b. via dmidecode etc.?

Zitat von Olivetti

Kann man das als Kunde selbst feststellen, z.b. via dmidecode etc.?

Ich würde mir /proc/cpuinfo anschauen, aber dmidecode liefert vielleicht auch Hinweise, wenn man VPS vergleichen kann, wo's geht und wo nicht. Am Ende ist das aber nur Neugier, weil es auch dann nicht laufen wird, wenn man weiß, warum nicht. Da ich keinen VPS in der IP-Range habe, bin ich raus.

Was ist denn die Erwartung an der Stelle? Wenn du einen neuen Computer kaufst und das alte Betriebssystem lässt sich nicht installieren, weil es die Hardware nicht unterstützt, beschwerst du dich dann auch über den Computerhersteller?

Persönlich finde ich es etwas komisch 2025 von het zner weg zu gehen weil es 2018 ein Problem gab.

Ich wollte dich noch warnen, dass Netcup die einzelnen vServer auf andere nodes verschieben kann.

Nur dass du nicht eines morgens aufwachst und dein Server nicht mehr läuft weil er auf einen neuen Node migrieren worden ist.

In dem oben verlinkten Thread wird in einem späteren Kommentar beschrieben, dass der Kernelparameter pci=on das Problem umgeht, weil dann der fehlerhafte Codepfad im Kernel nicht genutzt wird. Vielleicht kann das mal jemand mit einem solchen System ausprobieren.

(Workaround in https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01883.html, Ausführliche Fehleranalyse in https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01919.html)

Die Kernel Panic ist exakt identisch mit der in deinem Screenshot und sie wird in dem Thread für Debian 9 auf einer VM bei Google beschrieben. Auch Installer kann man mit Kerneloptionen booten. Wenn das installierte System läuft, verwendet es wahrscheinlich einen anderen Kernel als der Installer. Aber ich nehme an, es ist einfacher, auf alle anderen zu schimpfen, als tatsächlich zu debuggen.

Hallo zusammen,

wir haben inzwischen eine neue "Optimierung für Betriebssystem" im SCP veröffentlicht, welche unter "Einstellungen" beim Server gewählt werden kann. Diese heißt "Linux legacy" und erlaubt die Nutzung älterer Kernel-Versionen innerhalb des Servers. Damit sollte das hier beschriebene Problem gelöst werden können.

Ich wünsche euch einen schönen Abend.

Zitat von voip2gsm

LEGACY aktiviert - Installation gestartet

Du hast das virtuelle System nach der Konfigurationsänderung abgeschaltet, nicht nur neugestartet, ja?

Zitat von voip2gsm

EOL ELTS

Das vom "Hersteller" bereits seit 2022 nicht mehr unterstützte Betriebssystem wird von einem kommerziellen Anbieter mit Sicherheitspatches versorgt, aber das garantiert nicht, dass das System in jeder modernen Umgebung installierbar ist. Die Software, die du einsetzen möchtest, ist fehlerhaft, nicht die Umgebung, in der du sie laufen lassen möchtest. Was das Problem ist, habe ich schon ausführlich aufgezeigt. Der Fehler ist in neueren Versionen des Kernels behoben, aber nicht in der Version, die der uralte Installer verwendet. Es gibt einen Workaround, den du mal probieren könntest.

Zitat von NaN

Es gibt einen Workaround, den du mal probieren könntest.

Womöglich den Kernel im Image updaten, die Images sind ja auch EndOf Life.. Bietet Freexian fertige gepatchte Images an?