openSuse MicroOS getestet
Ich hab zu MicroOS schon einige Worte verloren aber kann nun auf eine längere Teststrecke zurückblicken. Hier könnt ihr lesen wie sich MicroOS nach etwa drei Monaten als mein Produktivsystem gemacht hat, was mich genervt hat und warum es geil ist.
Immutable in aller Kürze
Ich werde jetzt nicht nochmal groß und breit erklären was ein immutable System ist, nur soviel: Bei openSuse MicroOS handelt es sich wie auch bei Fedora Silverblue und dem SteamOS auf dem Steamdeck um ein sog. immutable OS oder gern auch Containersystem genannt, was im weitesten Sinne bedeutet, dass das Kern-Betriebssystem in sich geschlossen läuft, und nicht vom Benutzer geändert werden kann. Programme können vom Endnutzer als Flatpak installiert, gelöscht und genutzt werden. Flatpaks laufen ebenfalls für sich, in sich geschlossen und haben kaum Berührungspunkte mit dem Kernsystem - Schnittstellen die Flatpaks verwenden dürfen wie z.B. den Netzwerkzugriff lassen sich durch das Tool Flatseal bequem einstellen.
 |
| Flatseal |
Das Kernsystem aktualisiert sich dabei selbstständig im Hintergrund über transaktionale Updates. Aktualisierungen werden _im weitesten Sinne_ als eine Art Wiederherstellungspunkt angewendet und sind erst nach einem erfolgreichen Neustart des Computers wirksam. Sollte dabei ein Update mal daneben gehen, wird automatisch auf den letzten laufenden Wiederherstellungspunkt zurückgegriffen wodurch man immer ein funktionierendes System vorfindet - Mit ein Grund warum openSuse auch mit dem Stabilen Zweig Leap, ab Version 16 ebenfalls auf eine Containerlösung setzen will.
Installieren und haben
Mit diesem Wissen im Hinterkopf hab ich das Angebot angenommen und die Desktop Variante von MicroOS installiert. MicroOS Desktop ist kein separat zu beschaffendes Iso Image sondern lässt sich während der Installation nebst Minimal, Server oder noch irgendwas was ich vergessen hab, auswählen. Als Desktop werden entweder Gnome oder KDE angeboten, dabei wird nochmal drauf hingewiesen dass es sich aktuell bei Gnome schon um den Release Candidate handelt, und bei KDE noch um eine Alpha. In meinem Fall hab ich mich mutigerweise für KDE entschieden und schnell wird klar dass man das 'Micro' in MicroOS wörtlich nehmen kann. Dort ist nämlich außer der Oberfläche mit seinen Einstellungen, einem Dateimanager und Discover nämlich nichts an Software dabei - Ist auch nicht gewollt denn Anwender sollen ausschließlich Software als Flatpaks auf dem vorgegebenen bzw im Anwendungsfall vom Administrator- oder IT Heini vorkonfiguriertem Kernsystem installiert werden.
Gesagt getan, bzw tun lassen, sofort nach dem ersten Neustart wird ein firstboot script ausgeführt was die Flatpakquellen in den KDE eigenen Softwarestore 'Discover' einpflegt, Firefox installiert und als Bonus auch noch den Taschenrechner installiert.
Im Grunde war das schon alles. Und ohne irgendein Tamtam wurde mir auch schon das System übergeben. Ich installiere also meine sieben Sachen, teste sie auf Funktion und zu meiner Verwunderung liefen selbst alle Multimediellen Anwendungen auf Anhieb. Kein Gemecker über fehlende Codecs oder Plugins. Dabei war ich immer davon überzeugt, dass Codec Bibliotheken sehr global und recht nah am System arbeiten müssen, aber diese Form der Modularität ist bei Immuatablen Systemen weitesgehend vorbei, denn die Flatpaks bringen alles was sie brauchen, auch alle Codecs selber mit und sind damit auch nicht auf die Codecs des Systems angewiesen.
Nie wieder Nvidia
Nun aber zur ersten Feuerprobe denn ich brauche Grafikkartentreiber. Ich hab leider noch nicht den Absprung von NVIDIA geschafft und muss deshalb proprietäre Treiber einsetzen, on top hab ich auch noch so eine super krasse Optimus Karte die mir in der Vergangenheit schon den letzten Nerv geraubt hat. Das Treiber installieren scheint auf einem System mit read only Dateisystem ziemlich schwierig, denn Treiber unter Linux haben immer irgendwas mit dem Kernel zu tun - und da muss ich nun irgendwie dran. Zum Glück kann man selbst so ein transaktionales Update durchführen und dabei neben Programmen auch beispielsweise NVIDIA Treiber installieren. Das Procedere ist dabei nicht anders als es sonst bei openSuse ist, nur dass man hier eben mit transactional-update arbeitet statt direkt mit zypper - das sieht dann ungefähr so aus:
sudo zypper addrepo -f https://download.nvidia.com/opensuse/tumbleweed NVIDIA
sudo transactional-update shell
(oder)
sudo tukit --continue execute bash
# zypper inr
Sollte den NVIDIA Treiber und Zubehör installieren, ansonsten:
# zypper install x11-video-nvidiaG06 nvidia-glG06 nvidia-computeG06 nvidia-gfxG06-kmp-default inxi nvidia-utils-G06 kernel-source
Auf jeden Fall dann hiermit abschließen und neu starten
# exit
sudo reboot
Schon ist der Treiber einsatzbereit.
//edit:
Kleiner Nachtrag, auf einer anderen NVIDIA Maschine klappte die Installation mit transactional-update nicht, augenscheinlich war alles in Ordnung aber irgendwie lud der Treiber nicht. Das selbe Verfahren mit tukit funktioniert hingegen ohne Probleme was seltsam ist da beides mit tukit arbeitet... . Also, oben das Orange oder ist für den Ablauf mittels tukit.
Optimus
In meinem Fall war mach dem Reboot aber irgendwie garnix einsatzbereit und die Nvidia Treiber liefen nicht. Ich hab die Treiberinstallation einige male Wiederholt, immer mit dem selben Ergebnis, nix geht. Da fiel mir irgendwann ein dass ich ja so eine tolle Optimus Karte habe genau und das muss ich selbst unter Suse ziemlich explizit mitteilen, denn sonst schafft der Rechner es nicht bis zum Anmeldeschirm - Ist irgend so ein Nvidia Bug.
MicroOS hat tatsächlich mitbekommen dass mit den Treibern keine Grafische Oberfläche gestartet werden kann und hat, so wie muss, den letzten Funktionierenden Schnappschuss gestartet, ohne Nvidia Treiber.
Nach der Eingabe von:
sudo transactional-update shell
# prime-select boot nvidia
# exit
sudo reboot
war simsalabim alles erledigt und letzten Endes hat sich MicroOS hier richtig verhalten und mich nicht vor einem schwarzen Bildschirm sitzen lassen. Ich hab das nochmal wiederholt und den Treiber mit Absicht wieder kaputt gemacht um zu schauen ob MicroOS an irgendeiner Stelle mitteilt dass es einen früheren Schnappschuss läd - was ich finde eine nützliche Info ist. Eine Info gibt es tatsächlich allerdings nur im Bootloader. Während des startens, kann man in Grub sehen dass MicroOS grad einen früheren Schnappschuss booten will, weil das mit dem aktuellsten nicht geklappt hat, mehr Hinweise gibt es aber nicht.
SELinux blockiert Steam
Damit war ich dann auch erstmal eine ganze Weile zufrieden und konnte tun was ich so mit einem Computer tue. - Bis zu dem Tag als ich zocken wollte.
Steam lief zwar grundsätzlich, allerdings stellte ich schnell fest dass so ziemlich kein einziges Spiel starten wollte und ich nicht so richtig nachvollziehen konnte warum das so war. Kurz bevor ich den Stecker ziehen wollte und mein Void Image schon auf dem Stick geladen war, stolperte ich über SELinux. (Hätte ich die Dokumentation von MicroOS vorher gelesen wäre das nicht passiert) Das ist eine super spezielle Spezialsoftware die durch Programm-spezifische Spezialrechteverwaltung für sehr spezielle Spezialsicherheit sorgen soll, leider hat SELinux meinem lieben Steam verboten irgendetwas auf der Festplatte zu machen, weshalb nix ging. Zum Glück ist SELinux aber einstellbar und kann vom Standartmodus: "Hier darf niemand irgendetwas bis der Besitzer was anderes sagt", auf den Modus: "Hier darf jeder alles bis der Besitzer was anderes sagt", gestellt werden. Klingt brutal und fahrlässig, tut aber nicht weh. SELinux ist für Immutable Server Systeme durchaus legitim, aber für die Desktopvariante hätte man sich das auch schenken können. - Während der Installation kann man SELinux übrigens im Vorfeld so eistellen wie man es möchte, oder gleich ganz weglassen.
Wie dem auch sein, SELinux wird im Nachhinein gezähmt indem man etwas in der Grub config ändert:
sudo nano (oder vim, oder wie auch immer) /etc/default/grub
Hier folgende Zeile ändern:
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent swapaccount=1 mitigations=auto quiet security=selinux selinux=1 enforcing=1"
in:
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent swapaccount=1 mitigations=auto quiet security=selinux selinux=1 enforcing=0"
Anschließend darf man nicht vergessen dass man auf einem Containersystem wohnt und deshalb:
sudo transactional-update grub.cfg
Und neu starten.
Aber
Soweit jene Dinge die noch recht gut gelaufen sind, ich muss aber betonen dass MicroOS noch nicht fertig ist - und das merkt man auch. So habe ich zu beginn meiner Testzeit viele Male alles kaputt gemacht weil der Installationsprozess mit Fehlern behaftet, und es im Moment einer recht klaren Reihenfolge bedarf die man einhalten sollte. Wird man beispielsweise während der Installation aufgefordert seine Netzwerkhardware per Hand einzurichten, sollte man tunlichst darauf verzichten und lieber eine Offlineinstallation durchführen. Andernfalls kann es dazu kommen, dass das System Snapper nicht einrichtet und man somit keinerlei transaktionale updates durchführen kann. Was wiederum ziemlich blöd ist weil es außer der transaktionalen Updates keine andere Möglichkeit gibt das System auf Stand zu halten bzw das Kernsystem überhaupt zu konfigurieren.
Auch sollte man vor einer Treiberinstallation unbedingt zuerst ein vollständiges Update durchführen um schonmal einen Schnappschuss sicher zu haben, ich hab es hinbekommen noch vor dem ersten Snapshot den Kernel derart zu stören dass es nichts mehr gab was ich hätte booten können (Das wurde meines Wissens zwischenzeitlich behoben und es gibt vom ersten boot an einen Snapshot).
Ich schiebe das erstmal auf das sehr junge Alter von MicroOS und dem Umstand dass es schon fast aus einer Laune heraus von einem Entwickler ins Leben gerufen wurde um dem zukünftigen ALP auf Tumbleweed Ebene zu begegnen. Schlechte Nachrichten gibt es auch für KDE Liebhaber, denn im Moment sieht es so aus als würde der Alpha Status längerfristig nicht verschwinden da der Plasma Desktop noch viele Probleme auf diversen Hardwarekonfigurationen aufweist. Dazu gibt es einen sehr schönen Beitrag vom Entwickler selbst (unten verlinkt).
Fazit
Nundenn, so lief bisher meine Reise mit MicroOS und alles in allem hab ich, bis auf den Umstand das man die frühe Entwicklungsphase noch spürt, nicht allzuviel zu meckern. MicroOS gibt einen ganz guten Ausblick auf das was aus Leap mal werden soll. Stabile Systeme unzerstörbar und bedingungslos Verfügbar machen - und das ganze für Jedermann - ohne groß kompliziert sein zu müssen. In meiner bisherigen Zeit mit MicroOS gab es keinen Zeitpunkt an dem ich mich am read only System gestört habe und mir ist bis auf die oben ausgeführten Schwierigkeiten nichts über den Weg gelaufen was mich von einer Weiternutzung abgehalten hätte. Was getan werden muss kann mit transactional-update gemacht werden, die Apps von Flatpak arbeiten zuverlässig und durch das schlanke Grundsystem hab ich _spürbar_ noch nichts an Performance eingebüßt.
Einzig die beachtliche Größe der ganzen Flatpaks kann ziemlich stören, denn man darf nicht vergessen dass ein Containersystem darauf angewiesen ist dass die Container auch alles selbst mitbringen was sie brauchen - Entsprechend groß fallen sie dann auch aus. Ich habe beispielsweise 18 Apps installiert und die nehmen mal eben 31,4GB Festplattenplatz in Anspruch.
Und warum ist das jetzt geil?
Es ist schlicht und einfach bequem. Es ist in etwa vergleichbar mit der Einführung von Face ID oder Fingerabdrucksensoren im Smartphone, so wirklich hat man sich nie um sowas gerissen, aber gewöhnt hat man sich sehr schnell an den neuen Komfort - jeder der schonmal FaceID hatte und dann zurück auf Fingerabdruck gehen musste wird das nachfühlen können.
Ich hab lange überlegt und bin mir sicher dass ich kein anderes Betriebssystem kenne an dem ich nicht früher oder später Hand anlegen muss. Sei es ein Upgrade oder es neu aufsetzen, oder im schlimmsten Fall irgendwas reparieren müssen. Theoretisch entfällt das bei MicroOS denn hier muss man überhaupt gar nichts machen. Denn Micro hält sich von ganz allein auf dem laufenden ohne damit zu stören. Getreu dem slogan: "[...]openSUSE MicroOS is an operating system you don't have to worry about." Wenn es ein Systemupdate durchgeführt hat, wird dies mit einer kleinen Popup Meldung mitgeteilt und das wars auch schon.
So sieht ein Systemupdate bei MicroOS aus, nur eine Mitteilung
Ich hab auch sonst bisher keinen Grund mich von MicroOS zu lösen, aber vielleicht begegne ich noch dem fatal flaw, und wenn es soweit ist, steht es genau hier.
//Edit:
Und hier stehts. Ein Systemupdate hat einen ziemlich wilden Fehler mitgebracht welcher dafür sorgt dass flatpaks nicht mehr installiert, gelöscht oder aktualisiert werden können. Ich konnte keinen Bugreport finden oder andere Nutzer die ein ähnliches Problem damit haben was bei der Behebung schonmal schwierig ist. Geduld hab ich bei mir gedacht und wartete einige Wochen ob sich das Problem durch zukünftige Aktualisierungen vielleicht von selbst behebt, zum Glück kann ich ja einfach einen alten Snapshot booten und alles lief wieder wie gecremt.
Nun sind allerdings 4 Wochen seit auftauchen ins Land gezogen und wenn ich richtig gerechnet habe wurde das System in der Zwischenzeit drei mal komplett aktualisiert, also seitens Tumbleweed wurde ein neuer snapshot ausgerollt. Das Problem bestand weiterhin und das auswählen von früheren Versionen meines Systems macht mich langsam mürbe. No hate an dieser Stelle, MicroOS, bzw Aeon, bzw Kalpa sind noch nicht fertig deshalb schiebe ich das mal darauf, scheine aber wie so oft der einzige Mensch zu sein der so ein Problem hat. ...
//Edit2:
Nur damit ich das nicht vergesse, das Problem scheint nun auch ein paar anderen auf die Füße gefallen zu sein. Offenbar änderten sich bei einem Update aus Gründen die Ausführungsrechte von fusermount
# chmod +x /usr/bin/fusermount
In manchen fällen ist fusermount komplett verloren -warum auch immer- und man muss "fuse" per transactional-update nachinstallieren.
Aber dann ist alles wieder schick.
Wisster bescheid
https://microos.opensuse.org/
https://en.opensuse.org/Portal:MicroOS/SELinux
https://en.opensuse.org/Portal:MicroOS/Downloads
https://linuxnews.de/2022/09/27/suse-alp-prototyp-steht-vor-der-auslieferung/ Schon älter, aber da geht Leap mal hin.
https://microos.opensuse.org/blog/2023-04-02-state-of-microOS-Desktop-Plasma/
Kommentare