staging.inyokaproject.org

Moin!

Meine letzte Linuxerfahrung ist schon etwas her, da gab es noch keine Snap- und Flatpakete, sonder PPA's oder Fremdquellen direkt in der sources.list. Diese sollte man damals vor einem Release Upgrade vorher deaktivieren bzw. auskommentieren.

Muss ich irgendwas mit den installierten Snap Paketen machen?

Eigentlich liefern doch, wenn ich es richtig verstanden habe, die Snap-Pakete alle benötigten Dateien selbst mit aus, oder? Das würde ja bedeutet, dass man da nichts vorbereiten muss.

Im Wiki hatte ich darüber nichts gefunden, ob bei einem Release-Upgrade irgendwas beachtet werden muss.

Oder kümmert sich der Befehl

1

do-release-upgrade 

auch um die Snap-Pakete?

Da die Snaps für alle Ubuntu-Versionen gleich sind (ist ja einer der "Vorteile", dass die alle ihre Abhängigkeiten unabhängig vom installierten System nochmal mitbringen) wüsste ich nicht, was da ein Problem darstellen sollte.

Man muss auch für .deb-Pakete vor einem Upgrade nichts "vorbereiten".

Fremdquellen gehören übrigens nicht direkt in die sources.list.

(Im Übrigen stellt der Großteil der Snaps Fremdquellen dar, wenn du da schon nach fragst, aber auch ohne Unterschiede für die verschiedenen Ubuntu-Versionen.)

tomtomtom schrieb:

...(ist ja einer der "Vorteile", dass die alle ihre Abhängigkeiten unabhängig vom installierten System nochmal mitbringen) wüsste ich nicht, was da ein Problem darstellen sollte.

Genau so habe ich das auch verstanden. Vielen Dank für die Aufklärung

tomtomtom schrieb:

Man muss auch für .deb-Pakete vor einem Upgrade nichts "vorbereiten".

Das stimmt. Unter Debian hatte ich damals immer den Codenamen in der sources.list verändert und dann die Paketeliste aktualisiert und ein Upgrade durchgeführt. Da wird es ja dann direkt durch "apt" durchgeführt, der .deb Pakete beherrscht. Was der Befehl

1

sudo do-release-upgrade

genau macht, weiß ich gar nicht. Wird dann die /etc/apt/sources.list.d/ubuntu.sources ensprechend geändert und anschließend auch apt-Befehle durchgeführt?

tomtomtom schrieb:

Fremdquellen gehören übrigens nicht direkt in die sources.list.

Hat jedoch, in meinem Fall, nie Probleme bereitet. Da ging es aber nur um den originalen Firefox, der damals innerhalb von Debian noch Iceweasel hieß, und um Spotify.

Hallo, ab Ubuntu 24.04 ist die sources.list nicht mehr die zentrale Datei. Aus dem Wiki → sources.list:

Ubuntu verwendet ab Ubuntu 24.04 Noble Numbat standardmäßig nicht mehr die Datei /etc/apt/sources.list.

Die snaps würde ich nach dem Upgrade bearbeiten. Dazu hilfreich → snap

Dr_Schmoker schrieb:

Hallo, ab Ubuntu 24.04 ist die sources.list nicht mehr die zentrale Datei.

Genau. Das hatte ich schon gesehen. Es wird jetzt /etc/apt/sources.list.d/ubuntu.sources verwendet.

Dr_Schmoker schrieb:

Die snaps würde ich nach dem Upgrade bearbeiten. Dazu hilfreich → snap

Ok, danke.

Abschließend würde ich gerne noch klären, was der Befehl

1

do-release-upgrade

genau macht. Wird im Hintergrund auch apt bei diesem Befehl verwendet?

Oder kann man das Upgrade auch manuell ohne diesen Befehl machen?

Patsche schrieb:

Abschließend würde ich gerne noch klären, was der Befehl

1	do-release-upgrade

genau macht.

Schau mal hier → Upgrade (Abschnitt „Durchfuehrung“)

Du hast oben die Version 24.10 angegeben. Willst du auf die 25.04 upgraden?

Dr_Schmoker schrieb:

Schau mal hier → Upgrade (Abschnitt „Durchfuehrung“)

Habe ich gelesen, aber daraus geht auch nicht hervor, was genau dieser Befehl tut. Dr_Schmoker schrieb:

Du hast oben die Version 24.10 angegeben. Willst du auf die 25.04 upgraden?

Jetzt noch nicht. Weiß auch gar nicht, ob das überhaupt schon ginge, aber ich bin gerne vorbereitet.

Kann man ein Release Upgrade auch manuell vornehmen? In dem man beispielsweise den Codenamen in der /etc/apt/sources.list.d/ubuntu.sources ändert? Von:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Types: deb
URIs: http://de.archive.ubuntu.com/ubuntu/
Suites: oracular oracular-updates oracular-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: oracular-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

zu:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Types: deb
URIs: http://de.archive.ubuntu.com/ubuntu/
Suites: pluckypuffin pluckypuffin-updates oracular-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: pluckypuffin-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

ändert und danach ein

1

apt update && apt full-upgrade

ausführt?

Das ist nur ein Beispiel und eine theoretische Frage. Wie der Codename nach genau geschrieben wird, weiß ich nicht.

Patsche schrieb:

Abschließend würde ich gerne noch klären, was der Befehl

1	do-release-upgrade

genau macht.

Gannst du guggn: /usr/bin/do-release-upgrade usw. sind eine Sammlung von Python-Skripten, die man im Editor öffnen kann. Es wird u. a.

• geprüft, ob für das bisherige System alle Aktualisierungen installiert sind. Dass Kernel, apt, dpkg & Co. aktuell sein sollten, leuchtet wohl ein; aber warum muss bspw. das Office aktualisiert sein? (Weil das Programm sonst zu komplex wird.)

• Die offiziellen Paketquellen werden auf die neue Version umgeschrieben

• Die Fremdquellen werden deaktiviert, damit möglichst alles von einem Server kommt.

• geprüft, ob das Metapaket der Desktop-Umgebung noch installiert ist und falls nicht, wird geraten, welches es gewesen sein könnte (Kann gut gehend oder auch nicht).

• Für jedes einzelne Paket wird nach einer aktuellen Entsprechung gesucht. Auf jedem Rechner einzeln! Warum das nicht einmal zentral erfolgt und man eine „Datenbank“/Liste abarbeitet, ist mir ein Rätsel. Jedenfalls kann an diesem Punkt das Upgrade scheitern, weil das Programm nicht mehr weiter weiß. In dem Fall wird ein Backup der bisherigen Paketquellen wiederhergestellt.

• Sollte erst es im weiteren Verlauf zu Fehlern kommen, wird versucht diese zu behandeln.

Alles in allem viel Aufwand, da man für alle möglichen Eventualitäten (Verbastelungen) gerüstet sein muss.

Oder kann man das Upgrade auch manuell ohne diesen Befehl machen?

Die debian-Methode kann man durchführen, wenn man sich seine Sache sicher ist und evtl. Probleme selbst lösen kann. Empfohlen wird das offiziell nicht.

PS: Ubuntu Versionen haben einen vollständigen Namen und einen Codenamen. Wenn du da unsicher bist, wie was heißt, dann schau in der Datei /usr/share/distro-info/ubuntu.csv nach. Jedenfalls ist es falsch „oracular“ (für Oracular Oriole) durch „pluckypuffin“ zu ersetzen. 🙄

Ah okay. Vielen dank! 👍

Ruth-Wies schrieb:

PS: Ubuntu Versionen haben einen vollständigen Namen und einen Codenamen. Wenn du da unsicher bist, wie was heißt, dann schau in der Datei /usr/share/distro-info/ubuntu.csv nach. Jedenfalls ist es falsch „oracular“ (für Oracular Oriole) durch „pluckypuffin“ zu ersetzen. 🙄

War wie gesagt theoretischer Natur und habe da jetzt nicht drauf geachtet. Dann wird "plucky" der nächste Codename sein. Hätte nicht erwartet, dass der kurze Codename schon irgendwo hinterlegt wäre.

Ging mir ja auch eher um die Sache. Du wusstest ja, was ich meine. Vielen Dank für die Aufklärung. Damit ist das Thema dann auch endgültig gelöst.

Patsche schrieb:

zu:

Types: deb
URIs: http://de.archive.ubuntu.com/ubuntu/
Suites: pluckypuffin pluckypuffin-updates oracular-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: pluckypuffin-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Theoretisch hätteste da (markiert) eine Änderung vergessen. 😀

schwarzheit schrieb:

Theoretisch hätteste da (markiert) eine Änderung vergessen. 😀

Tatsache....stimmt. Ja, so schnell kann es gehen ☺