hätte ich es nur gelassen! Ich habe ein wirklich einfaches UCS-System. Installation mit 4.1, DHCP, DNS, ADS … fertig. Keine zusätzlichen Apps etc. Da sollte man meinen ein Update sollte problemlos durch laufen.
Habe heute zunächst die Pakete aktualisiert, Neustart und habe dann auf dem Server:
univention-upgrade
aufgerufen. Irgendwann brich das Update dann ab und teilt mir mit ich soll in:
/var/log/univention/updater.log
Da habe ich mal nachgeschaut. Ist ja rießig die Datei aber Fehler finde ich da lediglich am Ende die mir aber nichts sagen …updater.log (1.9 MB)
First things first: Ich möchte dich bitten die FAQs/Posting Guidelines zu lesen und deinen Beitrag entsprechend zu überarbeiten. Wichtig wäre:
Verwendung der richtigen Kategorie (bspw. Univention Corporate Server)
Verwendung von passenden Tags (bspw. ucs-4-2 und german)
Beim nächsten Mal Verwendung von Englisch als bevorzugte Sprache, wenn möglich
Vollständige Auflistung der Version und der installierten Apps über den Befehl univention-app info
Die updater.log ist recht groß, weil die Debian-Version von 7 auf 8 angehoben wird. Entsprechend viel wird da angefasst und protokolliert, auch weil das Upgrade ja mehrfach gestartet wurde.
Also was passiert nun in der updater.log?
Zunächst werden unter UCS 4.1-4 die letzten Errata installiert
Dann wird nach App Updates gesucht. Da ist relativ viel DEBUG-Output dabei - wurde da evtl. mal das Loglevel angepasst?
Dann startet das Upgrade auf 4.2. Das bricht im ersten Anlauf mit folgendem Hinweis vorher ab:
Checking for space on /var/cache/apt/archives: failed
ERROR: Not enough space in /var/cache/apt/archives, need at least 4000 MB.
This may interrupt the update and result in an inconsistent system!
If necessary you can skip this check by setting the value of the
config registry variable update42/checkfilesystems to "no".
But be aware that this is not recommended!
Das wurde offenbar behoben, denn rund 10 Minuten später startet der zweite Upgrade-Versuch. Der kommt bis:
[....] Starting Docker: engine...
[....] Docker: did not start properly ... failed!
invoke-rc.d: initscript docker, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes docker.io (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Alles andere sind Folgefehler, soweit ich das sehe. D.h. man müsste nun herausfinden, warum der Docker daemon nicht startet.
Das Upgrade wurde dann noch mehrere Male angeworfen, bricht aber immer ab, weil einige Pakete nicht fertig konfiguriert sind und sich auch nicht konfigurieren lassen (docker.io, univention-docker, univention-app-center).
Ist das das gleiche System wie hier? →
Da wird btrfs verwendet. Das wäre dann schon der Grund.
Kleine Anmerkung am Rande: Ich kann absolut nachvollziehen, dass ein fehlgeschlagenes Upgrade frustriert und man dann entsprechende Laune hat. Aber bei dem Ton in deinem ersten Absatz ist die Motivation für andere hier zu helfen nicht so wahnsinnig groß.
Viel Spaß weiterhin auf Univention Help :slight_smile:
war schon eine Weile nicht mehr im Forum und beim letzten mal sah dies noch ganz anders aus. War dann ziemlich frustriert wegen dem Update und habe deshalb schnell und nicht gearde mit der perfekten Einleitung gepostet. Sorry!
Ja, es ist das gleiche System wie im genannten Beitrag. Das mit dem Speicherplatz lag an der Zeile:
in der /etc/fstab die ich dann temporär deaktiviert habe.
Ja, das FS ist btrfs. Habe ich den verlinkten Beitrag richtig verstanden dass es damit überhaupt nicht funktioniert? … Da wäre ein Hinwei in der Releas-Note schon sinvoll.
Frage. Kann ich dass bisher gemachte irgendwie rückgängig machen, Ich kann im Moment nicht abschätzen was funktioniert und was nicht.
Das Update wieder rückgängig machen, oder das System an sich wieder gerade rücken? Das Update lässt sich vermutlich nur durch ein vorheriges Backup wieder rückgängig machen. Gegebenenfalls kann man das System aber wieder fixen. Wurde schon ein
dpkg --audit
dpkg --configure -a
durchgeführt? Diese Befehle müssten aufzeigen welche Paketprobleme es gibt und zu reparieren versuchen. Docker auf BTRFS wird jedoch auch damit leider nicht zu fixen sein.
Da ich ja das BTRFS nicht einfach in ext4 verwandeln kann eine Frage: Wir Docker dies in absehbarer Zeit unterstützen und ich kann das Upgrade dann abschließen?
