Auf Mastodon ansehen
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
Ich verwende Dietpi auf meinen Raspis und habe nun über 20 Pi's hochgezogen. Teilweise laufen die seit Debian 10 Buster und wurden immer wieder hoch gezogen. Dietpi bietet dazu ein Update-Script an, welches immer wieder aktualisiert wird und so gut wie möglich auf mögliche Probleme reagiert. Natürlich gab es auch ab und zu Probleme beim update, aber im grossen und ganzen läuft es recht gut. Ich muss jedoch dazu sagen das auf den meisten meiner Pi's keine grossen Dinge laufen, viele dienen schlicht dazu Sensoren zu überwachen (Magnetschalter, Bewegungssensoren, Temperatur etc.).
Auf meinen Servern verwende ich Debian Stable. Und ja, da graust es mich jedes mal wenn ich zur nächsten Stable updaten muss.
Meine Strategie: Ich erstelle einen FS-Dump bevor ich starte und ich beginne mit den "einfachsten" und "unwichtigsten" Installationen. Dann schaue ich was für Probleme auftreten, suche Lösungen dafür und irgendwie geht es dann immer. Gerade fällt mir auf das ich Systeme habe die ich seit Debian 6 Squeeze so immer wieder hochgezogen habe (aktuell läuft 13 Trixie drauf). 😯
Ob eine Rolling für einen Server besser ist weiss ich nicht. Die meisten Probleme gab es z.B. damals von Python2 auf Python3 oder mit den verschiedenen PHP-Versionen. Ob das mit einer Rolling besser klappt wage ich zu bezweifeln. Weil irgendwann muss man ja den wechsel machen und dann seine Scripte oder Config-Dateien entsprechend anpassen. Problematisch sind natürlich auch Fremdquellen. Aber oft hat man gar keine andere Wahl weil man z.B. für Nextcloud eine neuere PHP-Version zwingend braucht.
Ich bleibe vorerst bei Debian Stable. Vermutlich brauche ich einfach den "kick" beim updaten. 😜
DietPi ist wirklich sehr gut! Hatte ich lange Zeit übersehen, da ich dachte: Ist nur so was wie Raspberry Pi Lite. Funktioniert aber auf allen Architekturen, wird sehr gut gepflegt - kann ich nur empfehlen. Auch für Update-Vorgänge!
ich nehme an im Help channel ists eh auch schon erwähnt worden: beim upgraden einen Multiplexer wie tmux/screen/... zu verwenden hilft gegen trennungen oder ssh prozessabstürzen. Damit kann man einfach neu verbinden und die Session wieder betreten.
Hoi,
das ist ein interessantes Thema, welches einen Admin sein/ihr Leben lang beschäftigt. Meine Lösung, jetzt nach über 25 Jahren Erfahrung privat und beruflich sieht folgendermassen aus. Ich nutze immer eine Distribution aus einem LTS Zweig. Da ich aus der Debian Richtung komme dann meistens Debian oder auch mal ein Ubuntu LTS. Oder auch gerne eine RedHat based Distro, je nach Einsatzzweck. Diese Distro wird auf Autoupdate und Autoneustart konfiguriert, aber nur in Ihrer Major Version. Wenn die LTS älter wird kann man unter Debian die Backports einsetzen um an neuere Kernel zu kommen, wenn benötigt. Dies ist, meiner Erfahrung nach, heutzutage nicht mehr nötig. Dies für die Distribution.
Für die darauf laufende Software verfahre ich ähnlich. So lange die Major Version der Software in den Quellen der Distribution enthalten ist und ich diese nutzen möchte, keine Änderungen und Autoupdate. Wenn ich eine andere Major Version der Software benötige, dann binde ich hier direkt die Quellen des Herstellers ein und Installiere von diesen. Als Beispiel wäre hier Ondrej PHP, MariaDB, Zabbix und weitere zu nennen.
Wenn dann die LTS Distri ausläuft mache ich einen Plan für ein Update bzw. eine Migration, je nach Verfügbarkeit. Zwischen den Jahren habe ich erst meine privaten Server gemacht. Dabei war ein Debian 11, Asche auf mein Haupt. Aber auch dieses konnte ich ohne Probleme von 11 auf 12 auf 13 updaten indem ich die Quellen ausgetauscht habe.
Diesen Ablauf nutze ich jetzt erfolgreich seit guten 10 bis 15 Jahren an den meisten Systemen. Bis heute ohne nennenswerte Zwischenfälle. Dabei muss man aber auch immer sagen, ich arbeite hier hauptsächlich mit virtuellen Maschinen und einem vollständigen Backup. Damit habe ich aber auch die Möglichkeit bei Problemen direkt zurück rollen zu können und im Vorfeld eine Test VM zu haben, in welcher ich das Update durchspielen kann.
Kleine Anekdote noch vom privaten Update, mein Virtualisierungshost steht in einem Rechenzentrum eines großen europäischen Anbieters. Auch dieses habe ich von Debian 12 auf Debian 13 gehoben, oder besser gesagt von PVE 8 auf PVE 9. Im Anschluss war der Server mittels SSH nicht mehr erreichbar. Ich konnte dann über eine KVM Konsole direkt auf die Hardware zugreifen und mich anmelden. Problem war, dass sich der Pfad/Name der Netzwerkkarte geändert hatte. Das kannte ich noch von früher, daher bin ich nach 15 Minuten bereits auf die Lösung gekommen. Noch kurz udev Rules angepasst und läuft wieder.
Abschluss, es ist nicht so sehr eine Frage wie man das Update durchführt, als vielmehr die Frage nach Backup und notwendige Verfügbarkeit der Maschinen die mich zu der aufgezeigten Lösung geführt hat.
Beste Grüße,
Alexander Meckelein
Ich habe dein Alias Problem gelöst, statt ein
alias play='...'direkt zu schreiben. Mache einfach eine Funktion in dieser Datei, wie im Bild:Ich habe einen Heimserver mit OMV, also letztendlich Debian, aktuell noch Bookworm, aber das Upgrade auf Trixie ist schon möglich. Mein virtueller Server läuft mit Arch Linux. Da ich Arch Linux möglichst minimal betreibe, sollten problematische Upgrades eigentlich nicht vorkommen können. Die betriebenen Dienste laufen alle in Containern (systemd-nspawn). Anfallende Neustarts beim Upgrade motivieren mich sehr stark dazu, mein System rebootsicher zu machen. Das hilft dann auch bei der Administration meines Rootservers, der zwar mit Ubuntu läuft, ansonsten aber sehr ähnlich verwendet wird: System möglichst schlank, Dienste in systemd-nspawn-Container oder KVM-VMs.
Upgrades von Debian oder Ubuntu bereiten mir deutlich mehr Sorgen als das von Arch Linux.
Meine Server laufen alle auf Debian Stable. Im Gegensatz zu dir haben bei mir die rolling Releases immer Sorgen bereitet - die hatte ich eine Zeitlang auf meinem Desktop, und den hab ich mir damit zu oft zerschossen. Seither bin ich überall auf Debian Stable - und alle Major Release Upgrades waren bei mir bisher problemlos. Dazu kommt dass ich Updates dann machen möchte wenn ich Zeit und Nerven habe, potentielle Probleme auch zu lösen. "Gelegentlich etwas flicken" interessiert mich im Alltag nicht.
Den Nebensatz "Container-Formate sind ohnehin rolling" finde ich spannend. Könntest du ausführen, was du damit meinst?
Vor ein paar Wochen wurde auch mir das Vergnügen zuteil, einen Rock 4A auf Armbian Trixie zu aktualisieren. Dies führte dazu, dass das eMMC-Modul nicht mehr erkannt wurde und ich jetzt ein aktuelles Armbian Community auf einer SD Karte nutzen muss. Wenigstens funktioniert der Rock wieder. Die wichtigen Konfig-Dateien (nftables.conf, fstab etc.) hab ich mir gesichert, damit eine zukünftige Neuinstallation schneller gelingt.
Ich bastle auch an einem eigenen Server mit HBA und mehreren Enterprise-HDDs. Hierfür setze ich auf Alpinebox: https://github.com/psy0rz/alpinebox Es handelt sich um ein schlankes, sicheres Alpine Linux mit ZFS Boot Menu und ZFS als Rootdateisystem (für Snapshots). Das Upgrade auf die neue Alpine-Version verlief absolut problemlos.
Die verwendete Anleitung aus dem Forum habe ich ebenfalls erfolgreich verwenden können (Raspi4). Allerdings bin ich mir nicht sicher, ob ich die getroffene Einschätzung zu den "semi-rolling" Release-Modellen vs. den "stable" Releases teile.
Die hier geschilderten "gesonderten" Klimmzüge werden ja insbesondere nur deswegen erforderlich, weil das "RasbianOS" an der Debian Distribution herumfummelt, und zwar über und unter der Haube. Eventuell werden da also "Karotten" mit "Weintrauben" verglichen.
Auch "Debian testing" hatte ich mal im Einsatz, weil ich das damalige "stable" auf einem neuen Gerät nicht hatte installieren können. Unter Sicherheitsaspekten empfohlen wird das aber nicht.
PS: Eine "Ubuntu-Phase" hatte ich übrigens auch, und "semi-rolling" sah bei mir so aus, daß ich zwei Geräte im Einsatz hatte, von denen jeweils eines neu installiert wurde, und das andere nur "distri-geupdated". – OK, wirklich "rolling" war das nicht, eher ..."rocking" :D
Ich bin bei meinem Homeserver auf Void Linux mit LTS Kernel umgestiegen. Ist Rolling Release und läuft schon lange vollkommen problemlos.
Ich hab mich für alle meine privaten Servern vor vielen Jahren für volles Rolling-Linux entschieden und hatte noch keine Probleme damit, im vergleich zum vorherigen Ubuntu deutlich weniger Arbeit.
Ich verstehe das Problem nicht? du brauchst doch eh ein sinvolles Backupkonzept - auch aus anderen Gründen! Grob gesagt kann man da 3 Teilbereiche unerscheiden (oder zumindest ich mache das so):
Palyoad würd ich persönlich jetzt eher nicht auf einem Raspy haben wollen, da ist nur ein SD Kartenslot, eine Spiegelung der Daten (die viel speicher brauchen wenn wir über bilder sprechen) ist frickelig und Mühsam. Payload kommt übers Netzwerk (CIFS) vom NAS und da ist es in einer Raid und dieses wiederum wird auf ein zweites Raid gebackupt. Gibt natürlich auch noch andere Ansatze aber das ist meiner. Da kann mit dem Raspi passieren was will, es kann von der Wand herunterfallen (ja das ist mir schon passiert) oder staub ansaugen oder ... Main Payload ist safe.
Für Programme habe ich ein install.sh da sind einfach die apt install befehle aufgelistet, das führ ich einmal aus und dann sind die Programme wieder da.
Konfiguration lös ich über einen USB stick da ist dann ein backup.sh welches congesteuert die configdaten rausschreibt (und ja es gibt natürlich auch ein restore.sh
Ich installiere meine Raspy images regelmässig neu (Ja ich muss ständig was ausprobieren, oder hab neue Ideen :D ) und der Restore prozess dauert etwa 2 Stunden, dann ist alles wieder ready to go. Ein Update dauert fast gleich lange. Meiner Meinung ist so ein Ansatz auch bei einem Rolling system empfehlenswert, das kann dir ja dann... also ... jederzeit ..ausfallen.... ;)
Das Aliases Problem ist nun gelöst. Schreibe einfach eine Funktion in dieser Datei "
~\.bash_aliases".Dann einfach mit
play "abba money money"oderplay "abba mama mia"testen. Bei mir hat es funktioniert. Meine erste Version hatte ein dreher drin mit dem Single-Qoute und Double-Qoute. Aber jetzt ist es richtig - Viel Spaß damit.Wahrscheinlich wäre openSUSE Slowroll (basiert auf Tumblweed) ideal für diesen Anwendungszweck:
https://en.opensuse.org/Portal:Slowroll
Durch die Kombination openQA Tests + (automatisch erstellte) Btrfs Snapshots gehört Tumbleweed an sich schon zu den stabilsten Rolling Release Distros. Slowroll setzt dem ganzen noch die Krone auf, wenn "Bleeding Edge" keine große Rolle spielt.
Aber für Aarch64/ARM64 scheint es noch nichts Vorgefertigtes zu geben...
Ich nutze Debian seit mehr wie 20 Jahren auf allem was rechnet. Mein letzter Arbeitsrechner lief gut 9 Jahre mit einer Installation und dann immer Upgrades. Der Rechner wurde dann in HW Ruhestand geschickt, sonst würde er heute noch mit der Installation laufen. Mein OMV NAS werde ich sehr wahrscheinlich gegen eine Debian Server Installation austauschen. Ihr dürft ersten warum 😉. Ein Raspian mit einem original Debian zu vergleichen, halte ich nicht für richtig. Da wird dem Original etwas angelastet, wofür es möglicherweise nichts kann. Im übrigen würdest du solche Warnungen von Debian nicht zu einem Upgrade bekommen. Rolling Releases und stable, alte Diskussion!
Ich nutzte seit Jahren Debian Stable als OS für meinen Homeserver, alles was ich dort hoste läuft aber in einem Docker Container. Daher sind so gut wie keine zusätzlichen Pakete installiert und das Update lief bisher immer Problemlos.
Auf dem Desktop hatte mich das Release-Konzept von Ubuntu genervt. Anfangs hatte ich mich immer für LTS-Versionen entschieden, dann aber mit der Zeit immer PPAs eingebunden. Diese Kombination kann gut gehen, tut es aber ab einem bestimmten Punkt nicht mehr, irgendwann passen die Abhängigkeiten nicht mehr zusammen, wenn du bestimmte Apps aktuell haben willst. Snap oder Flatpak kam für mich nicht in Frage, dafür ist mir Speicherplatz dann doch auch etwas zu schade, und ich empfinde das Konzept als Notlösung, nichts für den Alltag.
Mein Server läuft noch unter Ubuntu Server, auch immer LTS, aber es ist immer ein riesen Akt, diese Upgrades zu fahren. Deswegen schiebe ich das oft immer vor mir her.
Auf dem Desktop bin ich deswegen auch zu Manjaro gewechselt und konnte mich nie beschweren. Da ich schon immer manuell aktualisiere, darf ich das bei Manjaro auch nicht zu lange schleifen lassen.
Auf meinem zweiten Server (Raspi 5) läuft ein Ubuntu Server mit Incus. Aktuell will ich alles von meinem erster Server in Incus-Container umziehen. Aber auch bei den Containern muss ich mich für eine "Distro" entscheiden und habe hier aus Gewohnheit auch Ubuntu Server LTS gewählt.
Der Hinweis auf Void Linux ist interessant, das möchte ich gerne mal ausprobieren.
Disclaimer: Ich bin weiter lernwilliger Neuling mit zu wenig Zeit.
Auf meinen Servern läuft überall eine Form von Debian, also "Stable". Hintergrund ist, dass ich eher Anfänger und eher Anwender bin und damit zwei OMV-Server und einen Pi-Hole auf einem Raspi betreibe. Die Idee eines Rolling Releases finde ich sehr spannend und muss mich da mal umschauen. Auf einem Laptop läuft mit CachyOS eine Rolling-Distribution, auf dem anderen ein LMDE, das aber beim Update von 6 auf 7 keinerlei Probleme gemacht hat.
Viele Grüße und vielen Dank für den Artikel!
Hi Ralf!
Ich habe ähnliche Überlegungen, wenn auch nicht auf einem Pi oder Server, sondern auf meinem Rechner, mit dem ich mich im Netz bewege. Sämtliche Upgrade-Versuche endeten mit einem kaputten System, so dass ich stets neu installiere. Ich vermute sehr stark, dass ein Distupgrade nur bei bei per Standard-Installation durchgeführten Distros wirklich sauber durchläuft (Linux Mint?).
Zu den genannten rollenden Distros will ich noch Rhino als rollendes Ubuntu ergänzen - zu dem ich keine qualifizierte Aussage tätigen kann, da ich seit vielen Jahren glücklich von Ubuntu geschieden bin.
Meine erste Überlegung, ein Debian bzw. Devuan (weil ich SystemD ablehne) Unstable zu installieren, habe ich nach verschiedenen gelesenen Artikeln verworfen. Und was da so aus dem Arch-Umfeld kommt, scheint mir auch immer wieder ziemlich kaputt zu sein, weshalb ich davon ebenfalls Abstand nehme.
Nach einigen Versuchen habe ich ein vollverschlüsseltes Void Linux (welches mit runit ebenfalls SystemD-frei ist) auf die Platte bekommen (welches den Ruf hat, ein ziemlich stabiles Rolling zu sein), welches aber nicht bootfähig ist (die Initrd macht scheinbar Probleme - selbst der Versuch, diese neu zu generieren half nicht weiter).
Demnach hänge ich in einem Zwischenstadium fest, werde aber neue Installationsversuche starten, um die Kiste mit Void endlich hoch zu kriegen, denn als ein apt-Jünger finde ich dieses xbps auch ganz sympatisch.
Falls man Debian oder Ubuntu versucht auf die nächste Version zu bringen, sollte man Fremdquellen Anwendungen deinstallieren und aus dem
/etc/apt/sources.list.d/*.listnehmen indem man es verschieb oder in dieser Datei ein#setzt am Anfang, dann noch einapt updateum es neu einzulesen - Jetzt kann man damit anfangen das System auf zu Leveln zur nächsten Version. Weil ich habe noch nie Probleme gehabt, da ich ja weiß das Fremdquellen immer andere Versionen benötigen als das System, somit sollte man diese erst einmal ablegen. Und wie es schon oft erwähnt wurde, bevor man ein Running System anfasst macht man ein All umfassendes Backup 3-2-1 Regel! Noch als Tipp folgendes im Terminal eingebenLC_ALL=c, dann die ganze Sachen umbenennen von ein Debian-Namen zum anderen/etc/apt/sources.listund update/upgrade/dist-upgrade machen.Ansonsten weiterhin Spaß beim ausprobieren neuer Linux Distros.
Ich für mein Teil bleibe bei Ubuntu 22.04.5 LTS, da meine Hardware nicht mehr die neuste ist. In meiner Alltäglichen VM nutze ich Arch Linux hatte im laufe der Zeit mal Probleme mit Audio wireplumber hatte, aber nach endlich den einen Update ist das nun auch Geschichte. Nicht mehr am Host Ubuntu folgenden Befehl machen, damit ich in der VM wieder Sound hatte
pulseaudio -k && pulseaudio --start, diesen Befehl habe ich als alias eingetragen mit FixSound, damit man schneller ist:alias FixSound='pulseaudio -k && pulseaudio --start && echo "Sound neu gestartet!"'.Dann noch einen schönen Abend.
Ich hab mein ganzes Homelab auf Nixos umgestellt, das macht fasnremote management incl. update super einfach. Damit hab ich Konfiguration als code, zusätzlich läuft nächtlich ein Backup job (restic), der mir alle wichtigen Daten auf Backblaze speichert.