Starto VServer Plesk Dist-Upgrade Ubuntu 16.04

[daralla]

Hallo,

ich habe vorgestern versucht meinen VServer Ubuntu 14.04 / Plesk 12.5 auf Ubuntu 16.04 zu upgraden. Als erstes Plesk auf Onyx aktualisiert, das ging ohne Probleme. Danach das von Plesk estra für den Zweck bereitgestellte Script benutzt um Ubuntu von 14.04 auf 16.04 zu aktualisieren, auch das hat funktioniert - mit einer entscheidenden Ausnahme, nämlich MySQL. Das sollte eigentlich auf 5.7 aktualisiert werden, bricht aber mit Fehler ab. Passiert wohl häufiger beim Ubuntu 14.04 -> 16.04 Upgrade, ich hab auch versch. Fixes ausprobiert hauptsächlich wie hier und hier beschrieben, alles ohne Erfolg. Inzwischen bin ich mittels Strato Backup wieder zurück auf Stand Ubuntu 14.04 und Plesk Onyx 17.5.

Nun die Frage: gibt es irgendeinen sicheren Weg, Ubuntu auf 16.04 zu aktualisieren ohne das es MySQL zerschießt? Vor dem Upgrade MySQL Datenbunken dumpen und komplett deinstallieren ist auch nicht ideal, denn dann kann ich ja auch das Plesk Upgrade Script nicht mehr nutzen.

Hat jemand schon Erfahrungen mit demselben oder einem ähnlichen Szenario?

Danke!

 

[ThomasChr]

Ist Strato nicht mit Virtuozzo virtualisiert? Gibts denn die Datei /proc/user_beancounters bei dir? Was gibt ‚uname -a‘ aus?

Sollte es Virtuozzo sein dann kannst du -imho- garkeinen Kernel auf normalem Weg updaten.

 

[daralla]

Das sagt uname:

Linux xxxxxxxx.stratoserver.net 3.13.0-042stab124.2 #1 SMP Fri Sep 1 20:42:18 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux

Woran kann ich sehen ob es virtuozzo ist? Tatsächlich lief das Upgrade ja durch, ich konnte mich auch problemlos per SSH verbinden und es war 16.04 xenia installiert, konnte ich auch sehen per apt-get update das die Quellen für 16.04 verwendet wurden.

Nur mysql lief eben nicht, demzufolge auch kein Plesk und keine (Wordpress) websites.

PS: Bei meiner Suche nach einer Lösung stieß ich auch auf identische MySQL Probleme bei Usern, die das Ubuntu Upgrade auf eigenen, nicht virtuellen Servern gemacht hatten, ich denke also das Problem hat nicht ursächlich mit der Virtualisierung zu tun.

 

[ThomasChr]

Gibts die /proc/user_beancounters ? Kannste mal mit cat auslesen, was kommt da?

 

[daralla]

/proc/user_beancounters sieht so aus:

Version: 2.5
uid resource held maxheld barrier limit failcnt
1206913: kmemsize 60673552 80961536 9223372036854775807 9223372036854775807 0
lockedpages 0 16 2097152 2097152 0
privvmpages 500940 751108 9223372036854775807 9223372036854775807 0
shmpages 83704 197745 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 170 222 700 700 0
physpages 255106 391883 2097152 2097152 0
vmguarpages 0 0 2097152 2097152 0
oomguarpages 114883 188039 2097152 2097152 0
numtcpsock 73 89 750 750 0
numflock 11 19 9223372036854775807 9223372036854775807 0
numpty 3 23 9223372036854775807 9223372036854775807 0
numsiginfo 0 51 9223372036854775807 9223372036854775807 0
tcpsndbuf 1327784 2311200 9223372036854775807 9223372036854775807 0
tcprcvbuf 1196032 2338016 9223372036854775807 9223372036854775807 0
othersockbuf 418224 951184 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 10768 9223372036854775807 9223372036854775807 0
numothersock 281 314 950 950 0
dcachesize 32509660 51657429 9223372036854775807 9223372036854775807 0
numfile 3727 4815 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numiptent 27 27 9223372036854775807 9223372036854775807 0

Sorry, Tab Formatierung geht scheinbar flöten.

 

[danton]

PS: Bei meiner Suche nach einer Lösung stieß ich auch auf identische MySQL Probleme bei Usern, die das Ubuntu Upgrade auf eigenen, nicht virtuellen Servern gemacht hatten, ich denke also das Problem hat nicht ursächlich mit der Virtualisierung zu tun.

Interessanter wären die Fehlermeldungen, die bei dem MySQL-Update kommen bzw. beim anschließenden Starten von MySQL. Alles andere ist nur Stochern im Nebel...

 

[ThomasChr]

Wenns die bean_counters gibt ist das auf jeden Fall Virtuozzo. Ich dachte da kann man den Kernel nicht austauschen und somit geht der normale Upgradeweg nicht!

 

[daralla]

Interessanter wären die Fehlermeldungen, die bei dem MySQL-Update kommen bzw. beim anschließenden Starten von MySQL. Alles andere ist nur Stochern im Nebel...

Steht alles in den beiden Links im ersten Post, wie auch versch. Lösungsansätze, die aber alle nicht funktioniert haben bei mir.

Speziell in meinem Fall:

Letzte Zeilen des Plesk Update Scripts:

Errors were encountered while processing:
mysql-server-5.7
mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
Some error during dist-upgrade middle stage have occurred.

Nach Reboot und "apt-get update && apt-get dist-upgrade && apt-get autoremove":

mysql-server-5.7 (5.7.20-0ubuntu0.16.04.1) wird eingerichtet ...
Renaming removed key_buffer and myisam-recover options (if present)
ERROR: Unable to start MySQL server:
2017-10-30T11:55:27.723924Z 0 [ERROR] unknown variable 'innodb_additional_mem_pool_size=500K'
2017-10-30T11:55:27.727101Z 0 [ERROR] Aborting
Please take a look at https://wiki.debian.org/Teams/MySQL/FAQ for tips on fixing common upgrade issues.
Once the problem is resolved, run apt-get --fix-broken install to retry.
dpkg: Fehler beim Bearbeiten des Paketes mysql-server-5.7 (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
mysql-server hängt ab von mysql-server-5.7; aber:
Paket mysql-server-5.7 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes mysql-server (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
mysql-server-5.7
mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Die "unknown variable" hab ich aus my.cnf auskommentiert, aber letztlich hat das auch nicht geholfen.

Ich hatte hier auch nicht auf weitere Basteltips gehofft, die gibts schon zuhauf, sondern eher auf jemanden, der dasselbe oder ein Update Ubuntu 14.04 -> 16.04 unter ähnlichen Bedingungen erfolgeich gemeistert hat?!

 

[daralla]

Wenns die bean_counters gibt ist das auf jeden Fall Virtuozzo. Ich dachte da kann man den Kernel nicht austauschen und somit geht der normale Upgradeweg nicht!

Danke für die Info, ist dann aber komisch, daß es eben grundsätzlich doch ging bei mir, bis auf mysql. Ich hatte definitiv ein 16.04 System laufen auf dem ich mich per SSH und auch mit WinSCP einloggen und normale shell Befehle ausführen konnte.

Wie auch immer, die Websites müssen laufen also bleib ich jetzt erstmal bei 14.04. Entweder stolpere ich irgendwann über einen gangbaren Weg oder muß halt irgendwann bei 0 starten mit einem neu aufgesetzten 16.04, grusel...

 

[andreas0]

... Entweder stolpere ich irgendwann über einen gangbaren Weg oder muß halt irgendwann bei 0 starten mit einem neu aufgesetzten 16.04, grusel...

Schau mal im Kundenbereich, ob es überhaupt möglich ist, Ubuntu 16.04 LTS auf deinem vServer zu installieren.

Wenn ja, so würde ich an deiner Stelle folgende Schritte mal ausprobieren:

1. Server in Rettungsmodus hochfahren und den kompletten Inhalt der eingehängten Festplatte per tar sichern.
   
2. Danach das Betriebssystem Ubuntu 16.04 LTS auf den Server neu drauf installieren und nach dem Neustart des Servers die Kernelversion abfragen. Denn nach der Neuinstallation sollte dann die Kernelversion 4.X angezeigt werden.
   
3. Server erneut in Rettungsmodus hochfahren und den kompletten Inhalt auf der eingehängten Festplatte auf dem Server löschen.
   
4. Den zuvor erstellten Tar-Ball auf dieser Festplatte wieder auspacken und den Server neu starten. Die Kernelversion erneut abfragen. Auch hier sollte dann wieder die Version 4.X angezeigt werden.
   
5. Server komplett im Kundenbereich erneut sichern.
   
6. Zum Abschluß die im Anfangsbeitrag von dir beschriebenen Schritte wiederholen und schauen ob es dann fehlerfrei durchläuft.

Warum diese Klimmzüge? Nach der Neuinstallation auf Ubuntu 16.4 LTS erkennt das System Virtuozzo selber, dass zum stabilen ausführen des Betriebssystems Ubuntu 16.4 und weitere Anwendungen zwingend auch die Kernelversion ab Version 4.X benötigt wird.

 

[daralla]

Schau mal im Kundenbereich, ob es überhaupt möglich ist, Ubuntu 16.04 LTS auf deinem vServer zu installieren.

Ja, 16.04 LTS + Plesk Onyx wird angeboten für Neuinstallation.

Wenn ja, so würde ich an deiner Stelle folgende Schritte mal ausprobieren:
....

Das trau ich mir so nicht wirklich zu, zumal mir einige Schritte riskant erscheinen... an einem Punkt soll dann also das System mit Kernel 4.x aber immer noch Ubuntu 14.04 starten, das klappt? Und das Plesk Script 14.04 -> 16.04 wird auch nicht über diese Inkonsistenz stolpern?

Und dann ist ja abschließend noch die Frage, ob ich nicht wieder an genau demselben Punkt hängenbleibe. Bzgl. MySQL (was ja das Problem war) ist doch dein Vorschlag und das was ich schon probiert hatte ohne Unterschiede, oder übersehe ich da was?

Trotzdem danke. Jedenfalls wieder was über einen Upgrade-Weg gelernt, auf den ich selbst nie gekommen wäre...

 

[ThomasChr]

Das Problem mit Virtuozzo ist doch dass die VMs den Kernel des Hosts nutzen. Somit kommt es drauf an ob der Host überhaupt den entsprechenden Kernel unterstützt. Was sagt denn der *grusel* Strato „Support“ dazu?

 

[andreas0]

Das trau ich mir so nicht wirklich zu, zumal mir einige Schritte riskant erscheinen...

Bei meinem Vorschlag sollte man tatsächlich schon wissen, was man tut. Aber wenn du dein System zu Anfang, bevor du mit dieser Prozedur anfängst, im Kundenbereich sicherst und zudem noch dein Tar-Ball auch nochmal extern auslagerst, ist dieser Weg recht sicher. Denn nach der Neuinstallation mit der Version 16.04 LTS ohne Plesk und dem Auspacken des Tar-Balls mit der noch alten Ubuntu-Version wieder mit Plesk wird deinem alten Ubuntu 14.04 nach dem Neustart des vServers ein Kernel mit der Versionsnummer 4.x nur vorgegaukelt, da dein vServer mit dem Kernel des Hostssystems, der noch die Versionsnummer 3.x tragen dürfte, betrieben wird.

Nimm dir aber für dieses Aktion sehr viel Zeit. Denn diese Aktion kann unter Umständen Stunden dauern.

Und dann ist ja abschließend noch die Frage, ob ich nicht wieder an genau demselben Punkt hängenbleibe.

Das kann ich dir auch nicht sagen.
Aber wie eventuell schon @ThomasChr vermutet haben dürfte, könnte dein Problem in Zusammenhang mit der alten Ubuntu- und der Kernelversion < 4.x zusammenhängen.

 

[daralla]

Das Problem mit Virtuozzo ist doch dass die VMs den Kernel des Hosts nutzen. Somit kommt es drauf an ob der Host überhaupt den entsprechenden Kernel unterstützt. Was sagt denn der *grusel* Strato „Support“ dazu?

So weit bin ich noch nicht gegangen.

Aber wie schon gesagt, ich hatte definitiv schon ein 16.04 am Laufen mit der im ersten Post beschriebenen Methode, nur eben ohne mySQL und damit ohne Plesk. Also gehe ich 99-prozentig davon aus daß das Upgrade kerneltechnisch kein Problem ist.

 

[daralla]

Aber wie eventuell schon @ThomasChr vermutet haben dürfte, könnte dein Problem in Zusammenhang mit der alten Ubuntu- und der Kernelversion < 4.x zusammenhängen.

Das glaub ich un auch wieder nicht, da ich eben im Netz zahlreiche ähnliche "Upgrade 14.04 -> 16.04 mysql Probleme" mit völlig anderen Konfigurationen, u.a auch auf echten, nicht virtuellen Servern gefunden habe, wie hier als Bugreport beschrieben. Nur leider haben die enstprechenden Fixes bei mir nicht funktioniert. Oder ich hab sie nicht korrekt angewandt, was auch möglich ist.

 

[phibo]

Die Kernelversion vom Hostsystem wird nicht das Problem sein. Da daralla im Uname einen 3.13.0-042stab124.2 angezeigt bekommt, gehe ich davon aus, dass auf dem Hostsystem ein Virtuozzo 6 mit 2.6.32er Kernel läuft, was (mehr oder weniger, da EOM) in Ordnung ist. Virtuozzo faked hier basierend auf der ihm bekannten installierten Distribution eine passende Kernelversion. Abhängig davon, was die Komponenten der Distribution voraussetzen. Wenn jetzt ein Distributions Upgrade durchgeführt wird, wird hier weiterhin der alte Kernel angezeigt. Wenn die Version die Anforderungen nicht erfüllt, gibt das wieder Probleme.

Die einzig saubere (und vom Hoster supportbare) Option ist im Falle einer Container-Virtualisierung, die saubere Neuinstallation mit dem gewünschten OS-Template. Die Durchführung eines dist-upgrades kann funktionieren (und tut dies häufig auch), muss aber nicht. Durch die Durchführung eines Distributions Upgrades ändern sich auch gerne mal Dinge wie das Init-System. Wenn jetzt bspw ein SysVinit erwartet wird, aber ein systemd vorhanden ist, kommt der Container auch nicht mehr hoch.

Da hier Plesk zum Einsatz kommt, sollte es relativ einfach sein, einen FTP-Backupspace einzubinden, auf diesen zu backupen und nach einer sauberen Neuinstallation mit 16.04 ein entsprechendes Restore der Daten durchzuführen. Alles andere ist unnötiges Gefrickel, was zu einem späteren Zeitpunkt durchaus weitere Probleme verursachen könnte.

 

[daralla]

Die einzig saubere (und vom Hoster supportbare) Option ist im Falle einer Container-Virtualisierung, die saubere Neuinstallation mit dem gewünschten OS-Template.

Ist mir schon klar, daß das die sauberste Lösung ist.

Da hier Plesk zum Einsatz kommt, sollte es relativ einfach sein, einen FTP-Backupspace einzubinden, auf diesen zu backupen und nach einer sauberen Neuinstallation mit 16.04 ein entsprechendes Restore der Daten durchzuführen.

Aber was genau sichere ich und spiele es dann aus dem Backup zurück? Doch nicht das ganze System, dann wäre ich ja wieder an dem Punkt wo ich ein Dist-Upgrade machen muß um auf 16.04 zu kommen (und u.U. wieder bei exakt dem mysql Problem mit dem alles begann). Ansonsten könnte ich wohl die Datenbanken, 2 Wordpress Sites und 'ne Menge Mail-Adressen samt der Mails irgendwie selektiv wieder einspielen, eine Seafile und eine Owncloud Instanz könnte ich auch neu aufsetzen, Domains natürlich als erstes alle wieder anlegen... Am Ende werde ich es wohl so machen müssen.

Ich habe nun seit ungefähr 12 Jahren den einen VServer, bis jetzt auch alle Klippen umschifft, aber de facto verdiene ich meine Brötchen in einem anderen IT Bereich und muß mich gezwungenermaßen nur im Detail mit dem Unterbau meines Servers beschäftigen, wenn mal wieder ein größeres Update ansteht. da hoffe ich dann alle zwei Jahre daß das inzwischen simpler geht als beim letzten Mal, aber offensichtlich wieder umsonst...

 

[Superadmin]

Ich mache es einfach, neuen Server holen, Migrationstool von Plesk, dann alles umziehen, klappt prima mit dem Migrationstool.
Fertig, neues Ubuntu, neuer Server.
Nachteil, es gibt jetzt nur noch eine IPV 4 dazu, nicht mehr zwei.Hast 4 Wochen 2 vServer, genug Zeit um alles zu schaffen.