SDB Talk:Distribution-Upgrade

$releasever

https://www.opensuse-forum.de/thread/63541-%C3%A4nderung-der-repo-url-bei-ver%C3%B6ffentlichung-leap-15-2/

Wie ihr schon bemerkt habt ist die Wiki Anleitung nicht mehr aktuell, bitte ersetzt nicht einfach die Variable mit der Versionsnummer, stattdessen ergänzt die Variable in den Repos in denen noch die feste Versionsnummer steht und nutzt die folgenden Schritte zum upgrade:

zypper --releasever 15.5 refresh

Um den Repocache für die neue Version zu bauen

zypper --releasever 15.5 dist-upgrade

Um das Upgrade auf die neue Version durchzuführen

=> Wichtig: Repository für CD-/DVD-Laufwerk deaktivieren! Ansonsten können Versionskonflikte auftreten.

--felbre (Diskussion) 04:44, 05. Feb. 2022 (UTC)

Ich denke der Vorteil sich bei zukünftigen neuen Versionen das editieren der Repos sparen zu können ist offensichtlichIst das aufwändige Verschieben von /var/cache wirklich nötig?

Ich bin jetzt schon auf mehreren Systemen bei der Aktualisierung auf Leap 15.2 erfolgreich einfach so vorgegangen:

1. Altes System über die Softwareaktualisierung (zypper refresh / zypper update) auf den letzten Stand gebracht
2. Die Links der Repositorys manuell aktualisiert in yast (auch Packman & Co.)
3. Auf der Konsole (STRG+ALT+F2) sudo zypper dup
4. Systemneustart mit init 6

Fertig!?

(User felbre)

Es kommt drauf an ;-)

Hintergrund der Verschiebeaktion ist, dass /var/cache/ viele sich ständig ändernde Daten enthält (z. B. den zypper-Paketcache). Wenn /var/cache/ kein eigenes btrfs-Subvolume ist, werden dadurch die Snapshots (für einen möglichen Rollback) deutlich größer als nötig und verschwenden Plattenplatz.

Wenn die Basisinstallation neu genug ist, um /var/ oder /var/cache/ als eigenes Subvolume zu haben (zur Überprüfung: mount | grep /var ), musst Du nichts mehr verschieben. Und wenn Du kein btrfs benutzt, auch nicht. --Cboltz (Diskussion) 12:30, 19. Jul. 2020 (UTC)

Was sagt uns das:

/dev/sda3 on /var type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/var)

Auf einem anderen System bekomme ich folgendes:

/dev/sda6 on /var/log type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/var/log)
/dev/sda6 on /var/crash type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/var/crash)
/dev/sda6 on /var/tmp type btrfs (rw,relatime,space_cache,subvolid=270,subvol=/var/tmp)
/dev/sda6 on /var/opt type btrfs (rw,relatime,space_cache,subvolid=268,subvol=/var/opt)
/dev/sda6 on /var/lib/named type btrfs (rw,relatime,space_cache,subvolid=265,subvol=/var/lib/named)
/dev/sda6 on /var/spool type btrfs (rw,relatime,space_cache,subvolid=269,subvol=/var/spool)
/dev/sda6 on /var/lib/mailman type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/var/lib/mailman)
/dev/sda6 on /var/lib/pgsql type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/var/lib/pgsql)

Besteht hier Handlungsbedarf?

--Felbre (Diskussion) 13:34, 26. Jul. 2020 (UTC)

Auf dem System mit /dev/sda3 on /var type btrfs hast Du schon das aktuelle Layout, da musst Du nichts ändern.

Beim anderen System mit mehreren mounts für /var/irgendwas würde ich empfehlen, entweder ein Subvolume für /var/cache anzulegen oder, größere Lösung, ein Subvolume für /var anzulegen. Die vorhandenen Subvolumes sollten sich problemlos darin mounten lassen (leere Verzeichnisse als Mountpoint anlegen!) - oder Du verschiebst den Inhalt der /var/irgendwas-Subvolumes ins /var-Subvolume. --Cboltz (Diskussion) 14:06, 26. Jul. 2020 (UTC)

Inwieweit ist die Anleitung hierfür auf diesen Seiten ausreichend? Kann es sein, dass ich dafür noch händisch die fstab editieren muss? Welches Vorgehen würdest Du empfehlen, wenn man nicht so fit ist mit solchen Dingen (möglichst eine Schritt-für-Schritt-Anleitung, falls die Anleitung hier wie gesagt nicht ausreichend ist)? Grundsätzlich würde ich die Lösung mit dem /var-Subvolume bevorzugen. Vielen Dank! --Felbre (Diskussion) 14:19, 26. Jul. 2020 (UTC)

Ferndiagnostisch ;-) ist eine 100% verlässliche Anleitung schwierig, aber prinzipiell müsste die Anleitung auch passen (und sieht korrekt aus), wenn Du ein Subvolume für /var erstellst. Du musst "nur" die Pfade entsprechend anpassen, z. B. /mnt/var.old statt /mnt/var/cache.old. Und wie schon erwähnt leere Verzeichnisse für die Mountpoints der bestehenden Subvolumes anlegen: mkdir /mnt/var/log /mnt/var/tmp usw.. (Alternativ: den Inhalt dieser Subvolumes ins /var-Subvolume verschieben und die /var/irgendwas-Subvolumes (erstmal nur aus der fstab, später wirklich löschen) - aber das macht nochmal mehr Arbeit.) Und ja, Du brauchst einen fstab-Eintrag für das neue Subvolume - dieser Punkt fehlt in der Anleitung tatsächlich.

Wie immer bei solchen Operationen gilt: wer kein Backup hat, ist selbst schuld ;-) --Cboltz (Diskussion) 16:23, 26. Jul. 2020 (UTC)

Danke für die Hilfe! Ich tendiere momentan dazu, nur ein separates Subvolume /var/cache wie beschrieben neu anzulegen.

Wäre für mich noch die Frage, ob es evtl. hilfreich sein könnte, ein Update über die DVD zu fahren (statt zypper dup) oder vielleicht sogar das System komplett neu aufzusetzen (möglichst unter Beibehaltung des Home-Directories, was ja meine eigentlichen Daten enthält)? --Felbre (Diskussion) 21:38, 27. Jul. 2020 (UTC)

OK, das Erzeugen des Subvolumens /var/cache scheint geklappt zu haben. War an sich gar nicht so schwierig...

Zwei Fragen noch:

1. Es gibt auch Subvolumes "Snapshot" in meinem System. War das nicht der eigentliche Grund für die Migration von /var/cache, weil die Snapshots angeblich so anschwellen können?

2. Auf meinen anderen Systemen steht der Wert "noCoW" für @var als einziges Subvolume auf "Yes". Wäre das auch für mein /var/cache erforderlich gewesen? (Nebenbei bemerkt: ist das vielleicht auch der Grund für die Fehlermeldung "Failed to unmount /var" beim Herunterfahren auf den anderen Systemen?)

Besten Dank für die Aufmerksamkeit,

Felix --Felbre (Diskussion) 15:25, 28. Jul. 2020 (UTC)

zu 1 - Die Snapshots werden standardmäßig nur vom /-Volume gemacht - alles, was auf einem eigenen Subvolume liegt, landet nicht im Snapshot

zu 2 - "noCoW" heißt nicht, dass /var keine Kühe mag, sondern "kein Copy on Write". Das will man z. B. für Datenbanken aus Performance-Gründen. Copy on Write ist zwar sicherer, um das Dateisystem z. B. bei Stromausfall konsistent zu halten, aber im Gegenzug auch vergleichsweise unperformant.

Für /var/cache/ ist noCoW IMHO weniger sinnvoll - da landen z. B. immer ganze Pakete im zypper-Cache und werden später wieder gelöscht, aber selten bis gar nicht geändert.

Zu "Failed to unmount /var" - vermutlich läuft da noch ein Prozess, der eine Datei unterhalb von /var/ offen hat. Mit "noCoW" hat das aber nichts zu tun. --Cboltz (Diskussion) 21:05, 28. Jul. 2020 (UTC)