Ubuntu Offline-Update

[Mickey Cohen]

Hallo,

bitte erst lesen: es geht nicht um online/offline im sinne von "es besteht eine internetverbindung".

ich möcht meinen ubuntu server 23.04 x64 so einstellen, dass updates nicht im laufenden normalen betrieb durchgeführt werden, sondern dazu extra ein reboot in einen "update-modus" durchgeführt wird, in dem dann geupdatet wird und anschließend wieder in den normalen modus gerebootet wird. man verspricht sich davon erhöhte stabilität.

bei dnf unter fedora ist das mit einem dnf-addon möglich, dort ist dieses vorgehen/addon als "offline-update" bekannt.

wie ihr euch denken könnt, liefern alle meine suchergebnisse natürlich nur lösungen, wie man ubuntu ohne internetverbindung updatet. das ist jedoch nicht mein problem, eine internetverbindung besteht.

kann mir hier wer weiterhelfen?

vielen dank!

 

[r.fx]

Was soll dieser Update-Modus denn können oder anders machen, was im "normalen Betrieb" hinderlich ist?

 

[Alexander2]

"früher" gabs mal bootziele, die man ansteuern kann, wo dann nur gewisse sachen geladen/gestartet werden. gibts sicher heutzutage auch noch mit systemd

wennsde da halt in einen konsolenmodus bootest und da das update machst sollte das sehr stabil sein.

Was die bei fedora da machen weiß ich aber nicht.

 

[frabron]

Wenn man in bestimmte Runlevel bootet, braucht man aber wahrscheinlich auch physischen Zugang zum Server, denn SSH geht dann wohl auch nicht mehr ...

Unter Gnome und anderen DE macht das Updaten / installieren per Reboot ja packagekit und nicht dnf/apt. Keine Ahnung, ob man packagekit auf nem Server haben will, wenn das X dependencies nach sich zieht, hier ist aber ein Link, der beschreibt, wie das mit Packagekit gehen würde: https://unix.stackexchange.com/ques...ine-updates-with-packagekit-from-command-line

apt-get upgrade lädt herunter und installiert gleich, das zu trennen wird bestimmt schwierig, weil das ja in so ein geschlossenes Konzept gegossen ist.

Ich verstehe aber auch nicht, warum ihr nicht die Updates installiert und dann den Server neustartet, wenn das "mehr Stabilität" bringen soll - was ich ehrlich gesagt für Aberglauben halte. Wenn man nicht grade den Kernel updatet, reicht es doch, die betroffenen Services neuzustarten.

 

[Alexander2]

apt-get upgrade lädt herunter und installiert gleich, das zu trennen wird bestimmt schwierig, weil das ja in so ein geschlossenes Konzept gegossen ist.

ich meine da gibts "-d" um was geupdatet würde erstmal nur herunterzuladen.

Ergänzung (17. August 2023)

Wenn man nicht grade den Kernel updatet, reicht es doch, die betroffenen Services neuzustarten.

Unter Suse, auch Tumbleweed kannst du dir anzeigen Lassen welche Programme/dienste exakt veränderte DAten hat/geupdatet wurden. Kannste dann theoretisch auch automatisieren mit der Liste das entsprechende neuzustarten.(wenns da nicht sowieso was gibt)

 

[frabron]

Für Ubuntu gibt es needrestart, das zeigt dir auch an, welche Dienste neu gestartet werden müssen

 

[Mickey Cohen]

https://fedoramagazine.org/offline-updates-and-fedora-35/

habe auf meinem Fedora Laptop damit jetzt eben seit 2 Jahren sehr gute Erfahrungen gemacht (kann natürlich auch sein, dass die fedora-qualität in den letzten 2 Jahren nochmals gestiegen ist und das gar nichts mit den offline-updates zu tun hat, mir fehlt der persönliche Vergleich).

habe es jetzt bei @fethomm doch noch gefunden (https://linuxnews.de/kde-neon-erhaelt-offline-updates/):

sudo pkcon update --only-download
sudo pkcon offline-trigger
sudo systemctl reboot

pkcon ist ohnehin @Default installiert bei Ubuntu server 23.04

 

[Alexander2]

Alles was schon läuft und nichts von der Platte anchladen muss kann sowieso ungestört weiter laufen, auf der Festplatte sind sogar noch die alte dateien gespeichert, die gerade aktive genutzt werden und somit die betroffenen Programme einen verweis der Nutzung darauf haben. Wenn die Programme eben noch solche zugriffe haben ist dadurch auch immernoch im Inhaltsverzeichnis genau zu dem zweck die Datei eingetragen und selbst wenn durch ein update der datei oder dateien die betroffen sind dann der Eintrag für das vorhanden sein im festplatteninhaltsverzeichnis gelöscht wird bleibt wegen dem temporären zugriffsmarker die alte datei und das update wird seperat geschrieben. erst wenn das programm gekillt wird hat die alte datei dann auch keinen eintrag/marker mehr im inhaltsverzeichnis und wird bei hdd "vergessen" und bei ssd für trim zur löschung vorgemerkt (es werden beim Daten löschen bei hdd ja nur inhaltsverzeichniseinträge entfernt. die eigentlichen Inhalte werden da nichtmal angefasst, die dürfen dann nur wieder überschrieben werden für neues.)

So jedenfalls mein versuch das zu erklären mit dem laienhaften wissen.

Wenn jetzt also laufende programme updates bekommen kommt es sobald sie bisher nicht angefasste dateien brauchen und diese jetzt abweichen zu problemen (wenn die neue version nicht mehr mit dem altem programm kompatibel ist) dann gäbe es abstürze/fehler/etc.

Man kann die kiste einfach weiter laufen lassen, ggf ohne Probleme, ggf. mit oder einfach neustarten um solchen Problemen vorzubeugen.

Das gute daran ist, das man mitten im update die kiste noch weiter nutzen kann (für nicht kritische aufgaben wie browsen oder so, bis es eben Fehler gibt). Nachteil sehe ich keinen nennenswerten, wenn man sich dem bewusst ist.

Wenns um Professionelle /wichtige Daten und Programme gibt, will man evtl. auch einfach sicherstellen, das durch solche Programmverwirrungen und abstürze keine DAten korrumpiert werden die dann weiter geschrieben würden oder so - jedenfalls würde im professionellen umfeld da keine beim update einfach alles weiterlaufen lassen, es sei denn es ist eine mechanik eingebaut, die das weiter absichert.
Daher wohl auch die ganze Geschichte mit dem offline update. Für mich selber bevorzuge ich das die Kiste beim update einfach weitermach bis ich den restart anschmeisse.

Ne andere Art von stabilität wird ein offline update aber wohl auch nicht verbessern.

 

[drake23]

Also vermutlich müsstest du einfach einen reboot ohne graphical target machen. Ka, ob man das systemd so mitgeben kann, würde ich aber von ausgehen. Das wäre dann das Äquivalent dazu, wie man früher nur in einen bestimmten runlevel gebooted hat