Ein Upgrade einer Stable-Distribution ist nicht so einfach. Am Beispiel meiner Raspberries zeige ich, wie es geht. Dabei stellt sich die Frage, ob Stable-Modelle wirklich besser sind, als Rolling-Releases.
Im vergangenen Herbst habe ich meinen Raspi3 von Bullseye über Bookworm auf Trixie hochgezogen. Wobei "hochgezogen" zu viel gesagt ist, weil ich bei dieser full-upgrade Geschichte grandios gescheitert bin. Zum Schluss lief genau gar nichts mehr, weshalb ich die SD-Karte mit RasbianOS neu beschreiben musste. Das war nicht so schlimm, weil auf meinem Raspi3 nur das Badezimmer-Radio läuft. Dennoch war die Prozedur ärgerlich:
- Den Raspi aus dem Spielschrank raus klauben
- Das Gerät an einen externen Bildschirm und an eine Tastatur anschliessen
- SD-Karte neu flashen
- Diverse Einstellungen vornehmen
- Badezimmer-Radio einrichten
- Testen
Danach lief der Raspi3 mit Debian-Trixie und lässt mich hoffentlich bis zum 30. Juni 2030 in Ruhe (LTS).
Nach dieser Erfahrung war das Trixie-Upgrade für meinen Raspi4 ein Angst-Projekt. Im Gegensatz zum kleinen Raspi, laufen auf dem 4er wesentliche Dienste, auf die ich im Alltag nicht verzichten kann:
- Mein Fileserver, auf dem alle zentralen Daten liegen.
- Der Music Player Daemon (MPD), den ich für den täglichen Musikgenuss brauche.
- Eine Bildersammlung, die ich auf dem TV betrachten möchte.
- Raspotify, um Musik von Spotify vom Raspi auf die Stereoanlage zu streamen.
In beiden Fällen (Raspi3 und Raspi4) habe ich diese Anleitung zum Upgrade von Debian Bookworm auf Trixie verwendet: https://forums.raspberrypi.com/viewtopic.php?t=392376
Bemerkenswert sind die Informationen zu Beginn dieses Blogposts (übersetzt):
Wie immer bei größeren Debian-Versions-Upgrades empfehlen wir, ein bestehendes Bookworm-Image nicht zu aktualisieren, und bieten keinen Support für Probleme, die dabei auftreten können. Wir empfehlen immer, mit einem sauberen Trixie-Image (entweder von Raspberry Pi Imager oder der Software-Seite auf der Website) zu beginnen und alle Programme und Daten, die Sie benötigen, aus Ihrem vorherigen Bookworm-Image zu installieren.
Wir tun zwar unser Möglichstes, um sicherzustellen, dass ein Upgrade eines Bookworm-Images theoretisch möglich ist, können jedoch nur saubere Images testen. Wir können nicht jede Kombination von Software und Konfiguration testen, die ein Benutzer möglicherweise angewendet hat, und solche Änderungen können dazu führen, dass das Update auf eine Weise fehlschlägt, die wir nicht vorhersagen können, was zu einem beschädigten und nicht wiederherstellbaren System führen kann.
Sie sollten nicht versuchen, ein System zu aktualisieren, auf das Sie angewiesen sind, und Sie sollten nicht versuchen, ein System zu aktualisieren, ohne zuvor eine vollständige Sicherung durchzuführen. Wir übernehmen keine Verantwortung, wenn dieser Vorgang zu einem beschädigten Image führt – wir können lediglich sagen, dass der hier beschriebene Aktualisierungsvorgang getestet wurde und auf dem neuesten sauberen Bookworm-Image funktioniert. Wenn Sie dies dennoch tun, geschieht dies auf eigene Gefahr.
Das erinnert mich an meine Ubuntu-Zeiten. Jedes halbe Jahr hatte ich den kalten Schweiss im Gesicht. Läuft das System noch, oder muss ich alles neu einrichten? Zum Glück habe ich mich vor 5 Jahren von den "stabilen" Distributions-Modellen verabschiedet und bin auf eine kuratierte Rolling-Distro (Manjaro) umgestiegen. Seitdem herrscht "peace of mind".
Doch was für den Desktop sinnvoll ist, gilt noch lange nicht für einen Server, auch wenn es nur ein Raspberry Pi ist. Die Migration von Bookworm zu Trixie auf meinem Raspi4 hat ca. 3 Stunden meiner Aufmerksamkeit beansprucht und ein paar Posts in unserem HELP-Raum benötigt. Nachdem ich der Anleitung streng gefolgt bin, kam es beim zeitaufwendigen vorletzten Schritt zu einer Unterbrechung der SSH-Verbindung mit dem Raspi. Ob es an einem Timeout der SSH-Session oder einer Unterbrechung der Netzwerkverbindung lag, weiss ich nicht. Tatsache war, dass ich nicht mehr wusste, wie weit der langwierige Upgrade-Prozess durchgelaufen war.
Tipp: Ein Blick in tail /var/log/apt/history.log schafft Klarheit. Ausserdem sollte man sich exakt an die Anleitung halten.
Nachdem ich eine Stunde gewartet hatte, um noch laufenden Prozessen genügend Zeit zu geben, habe ich den letzten Schritt wiederholt und bin danach gemäss der Anleitung fortgefahren. Zum Schluss folgte ein sudo reboot und die Hoffnung, mich wieder mit dem Raspi verbinden zu können. Das gelang, sodass ich die Services testen konnte (siehe oben). Alle Dienste funktionierten einwandfrei, womit ich einen Haken hinter die Aufgabe "Raspi4-Upgrade" setzen konnte. Na ja, eine Funktion läuft noch nicht (sie lief auch vorher nicht), nämlich der Alias "play":
play='_y(){ mpv --ytdl-format=bestaudio ytdl://ytsearch:"$*";}; _y'
Da jammert der Audio-Stack auf dem Raspi. Wer es bisher nicht weiss: Dieser Alias spielt ein beliebiges Musikstück von YouTube ab. Geht z.B. so: play "abba mama mia". Egal, dieses Problem bekomme ich noch in den Griff. Die Hauptsache ist, dass das Upgrade auf Trixie überhaupt funktioniert hat. Ich hätte es bedauert, in tagelanger Arbeit, alles wieder neu einrichten zu müssen.
Fazit
Nun frage ich mich, ob ein Stable-Release tatsächlich die beste Wahl für einen Server ist. Wegen der Sicherheitsupdates muss man auch einen Server, der mit einem Stable-Release läuft, ständig im Auge behalten. Wie wäre es, einen Server mit einem Rolling-Release zu betreiben? Wer auf Container-Formate setzt, hat sich ohnehin schon für Rolling entschieden. Die vermeintliche Stabilität der Dienste/Anwendungen steht in Konkurrenz zu den nicht behobenen Sicherheitslücken, die man sich ohne regelmässige Updates einhandelt. Nach meiner Meinung, erspart man sich mit einem semi-rolling Release-Modell den jährlichen Angstschweiss.
Welche semi-rolling Distros gibt es?
Ja, bei der Auflistung der semi-rolling Distros habe ich schnell aufgegeben, weil sich die renommierten Seiten nicht einig sind. Die Begriffe "semi-rolling" oder "curated-rolling" sind nicht klar definiert. Ich definiere "semi-rolling" so: Semi-rolling Releases basieren auf rolling Releases, wie z.B. Arch Linux oder openSUSE Tumbleweed. Massgeblich für den Status "semi-rolling" ist, dass die Pakete eine zusätzliche Testrunde, im Vergleich zu den neuesten Paketen durchlaufen haben. Dadurch erscheinen sie etwas später, als die "rolling Pakete" und sind ein wenig besser vor frühen Fehlern geschützt.
Wofür entscheidet ihr euch auf euren Servern: gelegentlich etwas flicken, oder alle paar Jahre die grosse Krise?
Titelbild: https://pixabay.com/photos/tart-raspberries-whipped-cream-1283822/
Quelle: https://forums.raspberrypi.com/viewtopic.php?t=392376
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.