[Erledigt] Verständnisprobleme zu upgrade, dist-upgrade und full-upgrade

[oamaru]

Verständnisprobleme zu upgrade, dist-upgrade und full-upgrade

1) soweit ich verstanden habe, ist dist-upgrade umfassender als upgrade. Es werden zusätzlich noch paket-Abhängigkeiten berücksichtigt und in Ordnung gebracht. dist-upgrade und full-upgrade seien fast gleich. Was aber ist dieser kleine Unterschied fast?

2)Jemand hat mir gesagt, es sei klug zuerst upgrade durchzuführen und danach dist-upgrade. Das Risiko von Kompilkationen sei dann kleiner. Kennt jemand einen Grund dafür?

3) WER soll die updates und upgrades anstossen? a) Ich als user penguin mit sudo? Dann würden, wenn ich das richtig verstehe Dateien und logs im Zusammenhang mit Update bei /home/pinguin landen? Wenn ich sudo -l dist-upgrade eingebe, dann wäre das present working directory /root, genau wie wenn ich su -l zum einloggen verwende? Wenn ich su eingebe, werde ich root und das pwd ist. wie es als user pinguin war.

4) Kann man etwas durcheinanderbringen, wenn man es einmal so und ein anderes Mal anders macht?

Oder denke ich hier zu viel nach und die Pfade sind absolut?

[isabena]

schau mal in

Code: Alles auswählen

man apt 

und

Code: Alles auswählen

man apt-get

das erklärt so einiges deiner Fragen

[tobo]

1) soweit ich verstanden habe, ist dist-upgrade umfassender als upgrade. Es werden zusätzlich noch paket-Abhängigkeiten berücksichtigt und in Ordnung gebracht.

Das ist richtig so.

dist-upgrade und full-upgrade seien fast gleich. Was aber ist dieser kleine Unterschied fast?

Es gibt kein fast - full-upgrade ist ein Synonym für dist-upgrade. Die sind identisch und in apt, apt-get und aptitude funktionieren beide (wegen Kompatiblität) nebeneinander. Irgendwann funktioniert vielleicht nur noch full-upgrade.

2)Jemand hat mir gesagt, es sei klug zuerst upgrade durchzuführen und danach dist-upgrade. Das Risiko von Kompilkationen sei dann kleiner. Kennt jemand einen Grund dafür?

Für den täglichen Gebrauch stimmt das nicht, beim Releasewechsel ist es aber seit einigen Versionen die von Debian empfohlene Vorgehensweise. Auf den meisten Maschinen dürfte das jedoch nur einen theoretischen Unterschied machen.

3) WER soll die updates und upgrades anstossen? a) Ich als user penguin mit sudo? Dann würden, wenn ich das richtig verstehe Dateien und logs im Zusammenhang mit Update bei /home/pinguin landen? Wenn ich sudo -l dist-upgrade eingebe, dann wäre das present working directory /root, genau wie wenn ich su -l zum einloggen verwende? Wenn ich su eingebe, werde ich root und das pwd ist. wie es als user pinguin war.

Die Logs landen unter /var/log/apt/, egal wer das anstößt. Der normale Weg ist mit su oder `su -' Root zu werden und dann die Aktualisierung zu machen. In welchem Arbeitsverzeichnis du landest und welchen PATH du dann hast, spielt für die Paket-Tools keine Rolle - `su' und `su -' sind hier also gleichwertig. Sudo verwendet man in Debian um sich Sachen zu erleichtern, nicht für das normale administrieren.

4) Kann man etwas durcheinanderbringen, wenn man es einmal so und ein anderes Mal anders macht?

Nö, du kannst das Root-Anmeldeverfahren und das benutzte Paket-Tool wild mischen, das hat keinen Einfluss auf das Ergebnis.

Oder denke ich hier zu viel nach und die Pfade sind absolut?

Zuviel nachdenken geht nicht...

[Blue]

Vorneweg: Die Antworten von tobo finde ich erste Sahne!

@oamaru:

WER soll die updates und upgrades anstossen?

Es gibt mehrere Möglichkeiten:

(1) Wie oben von tobo schon gesagt, sich im Terminal mit "su -" als Root anmelden und dann gebe ich z.B. immer "apt update && apt full-upgrade" ein. Dabei stoße ich sowohl ein "normales" Upgrade als auch die Möglichkeit zu einem Dist-Upgrade an.
Erleichtern tue ich mir das Ganze mit dem alias s='su -' im ~/.bashrc, um Root zu werden und dem alias u='apt update && apt full-upgrade im /root/.bashrc, um das Upgrade einzuleiten. Nach dem Upgrade nicht mehr benötigte Programmpakete werden danach auch zum Löschen vorgeschlagen.

(2) Viele Systeme melden von sich aus ein anstehendes Update per Benachrichtigung an und nehmen dieses auch nach Bestätigung durch den User vor. So zum Beispiel das Programm "Gnome-Software" bei Gnome3 oder der "package-update-indicator" zusammen mit "gnome-packagekit-common" bei XFCE.

(3) Sehr komfortabel und übersichtlich ist es auch, ein Update über die graphische Oberfläche des Paketmanagers "synaptic" vorzunehmen. Synaptic zeigt nach einem Upgrade oder der Deinstallation von Programmen auch nicht mehr benötigte Programmpakete an, sodass man sich entscheiden kann, diese zu löschen.

[dasebastian]

Ich habe hier ein kleines Updateskript, dass ich als # per Alias "up" aufrufe:

Code: Alles auswählen

#!/bin/bash
# up - Updateskript

clear

echo
echo "  █ █ █▀▄"
echo "  ▀▄█ █▀ "
echo

echo "  -> Suche verfügbare Updates (update):"
apt update &&

echo
echo "  -> Führe Upgrades aus (full-upgrade):"
apt full-upgrade &&

echo
read -p "  ... weiter mit ENTER sonst STRG-c ..."

echo
echo "  -> Räume das System auf (autopurge & clean):"
apt autopurge && apt clean &&

echo
echo "  -> Updates abgeschlossen, fertig."
echo

# EOF

Ist die gleiche Verkettung wie oben schon genannt mit zusätzlichem Hinterherausputzen. Das führe ich aber nur im "regulären" Betrieb aus, also kein Heben auf neuen Release damit.

[Livingston]

@seb: Wozu denn die "&&" am Ende der Befehle?

[dasebastian]

Wozu denn ...

Um das ganze abzubrechen, sollte ein voriger Befehl nicht funktionieren. Falschdenke?

EDIT: Zitat

[isabena]

Ich habe hier ein kleines Updateskript, dass ich als # per Alias "up" aufrufe:
...
Ist die gleiche Verkettung wie oben schon genannt mit zusätzlichem Hinterherausputzen. Das führe ich aber nur im "regulären" Betrieb aus, also kein Heben auf neuen Release damit.

ein ähnliches Skript verwende ich auch, nur mit 'apt-get' und 'dist-upgrade'

allerdings habe ich dafür einen Starter angelegt in der dash und muß nicht erst ins Terminal.

Wie immer gibt es mehrere Möglichkeiten zum Ziel zu kommen

[tobo]

Wozu denn ...

Um das ganze abzubrechen, sollte ein voriger Befehl nicht funktionieren. Falschdenke?

Ja.

Code: Alles auswählen

apt update &&

echo

Die && bewirken, dass das echo nur dann ausgeführt wird, falls das Update erfolgreich durchlaufen wird. Die Leerzeile dazwischen hat dabei keine Bewandtnis. Anders als bei & und ; können && und || nicht am Ende einer Kommandoliste stehen.
Wenn du einen Abbruch willst, dann eher so was:

Code: Alles auswählen

apt update || exit
## oder
apt update || { echo "Fehler" >&2; exit; }

[oamaru]

Herzlichen Dank an alle für ihre konstruktiven Antworten.

Ganz besonders Dir, Tobo. Ich bin jetzt sehr beruhigt. Ich hatte wirklich Angst, ich könnte unbeabsichtigt etwas beschädigen.

Vielen Dank, manchmal ist eine Antwort, die exakt auf das Problem eingeht viel wertvoller als ein Schrank voll Bücher. (Oder eine HD voller e-Books )

[dasebastian]

Die && bewirken, dass das echo nur dann ausgeführt wird, falls das Update erfolgreich durchlaufen wird. Die Leerzeile dazwischen ...

Das mit der Leerzeile ist klar, meinem (bisherigen) Verständnis nach, würde einfach das gesamte Skript nach dem ersten Fehler abgebrochen. So dachte ich...

[JTH]

Das mit der Leerzeile ist klar, meinem (bisherigen) Verständnis nach, würde einfach das gesamte Skript nach dem ersten Fehler abgebrochen. So dachte ich...

Nee, das ist nicht der Fall. && bezieht sich nur auf das davor- und dahinterstehende Kommando:

Code: Alles auswählen

wenn_ich_erfolgreich_bin && werde_auch_ich_ausgefuehrt
mir_ist_das_egal_was_oben_passiert_ist

Beispiel zum Ausführen:

Code: Alles auswählen

#!/bin/sh
( echo 'Ich scheitere'; exit 1 ) && echo 'Schade'
echo 'Mir doch egal :-P'

Wenn das ganze Skript abbrechen soll, wenn ein einzelnes Kommando fehlschlägt, kann man das an allen notwendigen Stellen (die echos werden normalerweise nicht scheitern) explizit machen, so wie tobo es gezeigt hat.

Eine Alternative ist, der umgebenden Shell zu sagen, dass sie sich in dem Fall beenden soll. Das geht mit set -e, meist so benutzt:

Code: Alles auswählen

#!/bin/bash
set -e

…

[dasebastian]

OK, danke euch beiden, wieder was gelernt!

Das "set -e", da hätte ich auch selber dran denken können, das kenne ich schon aus einem Cronjob-Skript.

[Livingston]

set -e kann aber auch nach hinten losgehen, wenn z.B. ein grep nichts findet. Muss ja nicht immer der Fall sein, dass dann abgebrochen wird. Sowas kann zu unglaublichen Debug-Orgien führen, wenn man selbst nach 100x Überprüfen dieses kleine set -e am Anfang des Scriptes übersieht. (Funktioniert am "Besten", wenn der Arbeitstag zu lang ist, zu wenig/zu viel Kaffee getrunken wurde oder die Kollegen nerven.)

[dasebastian]

... kann aber auch nach hinten losgehen, wenn z.B. ... der Arbeitstag zu lang ist, zu wenig/zu viel Kaffee getrunken wurde oder die Kollegen nerven.

Das kann ich mir gut vorstellen...

[Tula]

Ich mag es einfach und kontrolliert, gebe jeden Befehl einzeln ein und betrachte die jeweiligen Ergebnisse.

[oamaru]

Danke auch für die Zusatzdiskussion mit Skripten und so, man kann dabei viel lernen. Manchmal sogar, ohne Lehrgeld zu zahlen

[QT]

2)Jemand hat mir gesagt, es sei klug zuerst upgrade durchzuführen und danach dist-upgrade. Das Risiko von Kompilkationen sei dann kleiner. Kennt jemand einen Grund dafür?

Die Empfehlung ist per se keine schlechte, hängt aber mMn davon ab, welches Debian System man da gerade kontrolliert. Bei einem STABLE dürfte diese Empfehlung eher unwichtiger sein, bei einem UNSTABLE dagegen kann die Empfehlung das System retten.

Man muss halt wissen, dass dist-upgrade im Zweifel auch Pakete entfernt, nur um 1 Upgrade eines anderen Paketes durchführen zu können!

Ein Beispiel: Du nutzt GNOME oder KDE als Desktop und es gibt in UNSTABLE gerade in dem Moment, wo Du "update" machst 1 neuere Version einer Library XYZ, welche von Deinem GNOME oder KDE auch benutzt wird, aber auf dem Feed sind die neuen GNOME/KDE Paketversionen, die mit dieser XYZ Version gebaut sind noch nicht hochgeladen und damit verfügbar. Bei einem dist-upgrade wird dann versucht, alles zu unternehmen, um die neue XYZ Version zu installieren und wenn es da Konflikte mit GNOME oder KDE Pakete gibt, so werden diese halt entfernt, was dazu führt, dass man danach keinen Desktop mehr hat.

Bei Nutzung von UNSTABLE oder auch TESTING sollte man immer schauen, ob irgendwas ENTFERNT werden soll bei einem dist-upgrade und dann sollte man sofort aufpassen, dass einem sowas nicht passiert. Wenn Pakete entfernt werden sollen, dann lieber nur upgrade der problemlosen Pakete und mal ein paar Stunden oder manchmal auch Tage warten, bis die Nachzüglerpakete auf dem Feed aufschlagen und das XYZ Upgrade samt aller Abhängigkeiten nun auch auf dem Feed vorliegt. Dann wird auch nix mehr entfernt.

Situation hatte ich mit UNSTABLE in den letzte 20+ Jahren nun schon so oft, dass es Gewohnheit ist, immer zu schauen, was entfernt werden soll und dann nochmal zu überlegen, ob man wirklich das dist-upgrade abnickt.

[QT]

Bei Nutzung von UNSTABLE oder auch TESTING sollte man immer schauen, ob irgendwas ENTFERNT werden soll bei einem dist-upgrade

Kaum geschrieben, schon abe ich heute den Fall bei meinem UNSTABLE Desktop. Es soll mit dist-upgrade der network-manager ENTFERNT werden, diese nutze ich aber, daher kann ich in diesem Moment das dist-upgrade nicht abnicken, sondern werde abbrechen, danach erstmal ein upgrade, um die unproblematischen Pakete zu aktualisieren und dann warte ich mal paar Stunden oder im Zweifel Tage bis der Rest auch ohne entfernen des network-manager ablaufen wird. Ich denke, da fehlen einfach noch paar neue Paketversionen auf dem Feed aktuell.

Code: Alles auswählen

Die folgenden Pakete werden ENTFERNT:
  network-manager network-manager-openvpn network-manager-vpnc plasma-nm
Die folgenden Pakete werden aktualisiert (Upgrade):
  libaom3 libmysofa1 libnm0 libnss-systemd libpam-systemd libsystemd-shared libsystemd0 libudev1
  libudisks2-0 libupower-glib3 systemd systemd-coredump systemd-dev systemd-sysv systemd-timesyncd udev
  udisks2 upower
18 aktualisiert, 0 neu installiert, 4 zu entfernen und 0 nicht aktualisiert.

Beim folgenden Upgrade sieht man dann auch dass das libnm0 Update ebenso zurückgehalten wird und dann weiß ich, dass dessen Upgrade vorher der Grund war, dass network-manager entfernt werden soll. Ich habe ja aber keine Eile mit dem libnm0 Update. Also mache ich erstmal für ne Weile kein dist-upgrade mehr bis das Problem behoben ist.

Hier der Output beim upgrade:

Code: Alles auswählen

Die folgenden Pakete sind zurückgehalten worden:
  libnm0 network-manager
Die folgenden Pakete werden aktualisiert (Upgrade):
  libaom3 libmysofa1 libnss-systemd libpam-systemd libsystemd-shared libsystemd0 libudev1 libudisks2-0
  libupower-glib3 systemd systemd-coredump systemd-dev systemd-sysv systemd-timesyncd udev udisks2 upower
17 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.

Lieber aktualisiere ich für den Moment die 2 Pakete mal nicht, als dass es mir vorher 4 von mir genutzte Pakete entfernt. In Meinem Fall (da ich Netzwerk per network-manager konfiguriere) stünde ich danach ohne Netzwerk erstmal da.

EDIT: Nun habe ich noch getestet, was passiert wenn ich libnm0 Installation anfrage und er will mir den dhcp-client entfernen. Das verunsichert mich auch und ich lasse es erstmal dabei, dass ich das aussetze, bis hoffentlich auf dem Feed die richtigen Pakete liegen:

Code: Alles auswählen

Die folgenden Pakete werden ENTFERNT:
  isc-dhcp-client
Die folgenden Pakete werden aktualisiert (Upgrade):
  libnm0 network-manager
2 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.

[Livingston]

Man munkelt, dass isc-dhcp-client über kurz oder lang komplett rausfliegt, weil ISC diesen Client nicht mehr weiterentwickelt. Es kann nicht schaden, schon mal nach Ersatz Ausschau zu halten, z.B. dhcpcd-base.

[QT]

Gute Info - Danke. Das erklärt vermutlich den Vorgang. Ich bin leider nicht mehr irgendwo in den Debian Welten tiefer informiert und daher fehlt mir diese Info. Nun bin ich gewarnt. Ich beobachte die Situation jetzt mal und schaue dann, was ich machen muss/kann.

Generell war der Fall aber 1 gutes Beispiel zum Thema hier, dass ein dist-upgrade im Zweifel auch benötigte Pakete ENTFERNT nur um 1 anderes Upgrade machen zu können. Das sollte man wissen und mit Vorsicht agieren - besonders bei UNSTABLE und TESTING. Im STABLE Bereich sollte der Feed eigentlich selten bis nie nicht im Sync sein und sowas nicht passieren. Aber wer blind dist-upgrade durchwinkt, hat im Zweifel den Ärger danach...

[michaa7]

... sondern werde abbrechen, danach erstmal ein upgrade, um die unproblematischen Pakete zu aktualisieren und dann warte ich mal paar Stunden oder im Zweifel Tage bis der Rest auch ohne entfernen des network-manager ablaufen wird. ...

Alternativ, und so mache ich das mit Debian/sid(uction), setzt du den network-manager mit "apt-mark hold network-manager" auf "hold" und schaust was ein d-u dann anstellt. Auf diese Weise hättest du immer noch eine installationsweite Abhängigkeitsprüfung, die bei einem "upgrade" fehlt. Natürlich solltest auf hold gesetze Pakete nicht vergessen. Allerdings siehst du diese beim "apt update" unter "zurückgehaltene Pakete".

... my 2 cts

[QT]

Auf diese Weise hättest du immer noch eine installationsweite Abhängigkeitsprüfung, die bei einem "upgrade" fehlt.

Hi Michaa7, ich verstehe das mit der HOLD Nutzung, mir ist nicht klar, wieso ein "upgrade" keine Abhängigkeitsprüfung machen sollte? In den letzten 20+ Jahren bin ich mit meiner Methode immer gut klar gekommen (wobei das nicht heißt, dass es nix besseres gibt), aber weiß nicht, wozu ich den extra Aufwand mit HOLD und INSTALL Status nehmen soll, wenn das Problem vermutlich in kurzer Zeit eh von selbst erledigt ist. Zumindest war es so immer in Vergangenheit, wenn sich aufm Feed wieder ein konsistentes "System" vorfand.

Aber ich finds gut, dass wir drüber schreiben. Man muss ja immer was neues lernen. Also erkläre nochmal bitte

EDIT: Bin nun der Empfehlung von Livingston gefolgt und habe dhcpcd-base installiert und den isc client gelöscht. Danach konnte ich libnm0 und network-manager aktualisieren und habe nun keine offenstehenden oder zurückgehaltenen Pakete mehr.

[michaa7]

...mir ist nicht klar, wieso ein "upgrade" keine Abhängigkeitsprüfung machen sollte? ...

Es macht keine. Full. Stop.

dist-upgrade
dist-upgrade enthält zusätzlich zu der Funktion von upgrade einen
intelligenten Mechanismus zur Auflösung von geänderten
Paketabhängigkeiten in den neuen Paketversionen.

Aber vermutlich ist meine Vorgehensweise einfach siduction old school

[dasebastian]

Aus der Man für apt:

Code: Alles auswählen

       upgrade (apt-get(8))
           upgrade wird verwendet, um verfügbare Upgrades für alle derzeit auf
           dem System installierten Pakete von den in der sources.list(5)
           konfigurierten Quellen zu installieren. Neue Pakete werden
           installiert, falls dies nötig ist, um Abhängigkeiten zu erfüllen,
           existierende werden jedoch nie entfernt. Falls das Upgrade für ein
           Paket verlangt, dass ein installiertes Paket entfernt wird, wird
           dieses Upgrade nicht durchgeführt.

       full-upgrade (apt-get(8))
           full-upgrade verrichtet die Funktion von »upgrade«, wird aber auch
           installierte Pakete entfernen, falls dies erforderlich ist, um ein
           Upgrade des Systems als Ganzes durchzuführen.