OpenSuse: Tumbleweed Rolling Release nutzen

Deutsch (German) Installation/Administration
1

Hallo,

ich finde die Idee eines Rolling Releases sehr interessant, weil man dann nie mehr gezwungen ist ein neues System aufzusetzen und im Grunde auf immer und ewig up-to-date bleiben kann. Daher interessiert mich Tumbleweed für OpenSuse.

Ich habe allerdings noch keinerlei Erfahrung im Umgang mit einem Rolling Release.

Was meint Ihr dazu?
Benutzt jemand Tumbleweed?
Was gilt es dabei zu beachten und wie gut oder schlecht funktioniert das ganze?

Ich habe Bedenken das z.B. nach einer Kernel-Aktualisierung o.ä. plötzlich meine Virtuelle Maschine unter KVM nicht mehr funktioniert oder der Drucker nicht mehr druckt, der Scanner nicht mehr scannt, keine Internetverbindung mehr da ist usw… oder gar das System nicht mehr durch Grub gebootet werden kann (hatte ich schon mal nach Veränderungen des Kernels durch VMWare-Player-Installation…

Auf was muss man da alles gefasst sein?
Oder wird das Updating so präzise organisiert und geplant das man da kaum Befürchtungen dergleichen haben braucht?
Soweit ich weis werden ja nur stabile Updates durch Tumbleweed durchgeführt.

2

Hi,

ich benutze Tumbleweed seit Jahren und bin soweit zufrieden damit.
Noch ein paar Anmerkungen:

  • TW ist keine Rolling Release Distro, sondern ein Addon-Repository zur jeweils aktuellen openSUSE-Version (derzeit 13.1), d.h., bei jedem Release-Wechsel wird es leer gemacht und dann nach und nach wieder neu gefüllt. Wenn man seine openSUSE-Standard-Repositories auf “current” statt “13.1” konfiguriert, kann man diesen Wechsel vollautomatisch mitmachen - sofern man das möchte.
  • Es gibt sehr oft neue Kernel-Versionen. Wenn Du also Software hast, die nach jedem Kernel-Update neu kompiliert werden muss, und dabei Gefahr läuft, dass das nicht klappt, weil die Software erst auf die neuen Kernel-Header angepasst werden muss, lass die Finger davon. Gute Bespiele dafür sind proprietäre Grafiktreiber und Virtualisierungssoftware, die nicht aus den openSUSE-Repositories stammt.
  • Wenn Du weitere Repositories außer den openSUSE-Standard-Repositories (z.B. Packman) einbinden willst, musst Du selbst sehen, wie Du mit Konflikten umgehst. Die Tumbleweed-Maintainer unterstützen das nicht (ich habe Packman drin, schließlich will ich auch gelegentlich Videos gucken).
  • Updates sind ausschließlich(!) per “zypper dup” auszuführen.

Gruß,
Hendrik

3

Hallo Hendrik,

TW ist keine Rolling Release Distro, sondern ein Addon-Repository zur jeweils aktuellen openSUSE-Version (derzeit 13.1), d.h., bei jedem Release-Wechsel wird es leer gemacht und dann nach und nach wieder neu gefüllt.

Siehe dazu:
“Das Ziel des Projekts Tumbleweed ist es, eine Rolling Release-Version von openSUSE mit den neuesten stabilen Paketversionen anzubieten, als Alternative zum normalen Releasezyklus. Das Projekt macht das für Anwender, die die neuste, aber stabile Software wollen.”(aus: Portal:Tumbleweed – openSUSE Wiki)

Was Du da sagst ist das nicht eigentlich das Selbe? Addon oder Rolling Release, ich meine es geht doch darum das es immer weiter vorwärts geht von Version zu Version.
Die klassischen Rolling Release Distris (z.B: Arch) bringen doch auch von Zeit zu Zeit eine offizielle Version als Live-CD heraus.

Es gibt sehr oft neue Kernel-Versionen. Wenn Du also Software hast, die nach jedem Kernel-Update neu kompiliert werden muss, und dabei Gefahr läuft, dass das nicht klappt, weil die Software erst auf die neuen Kernel-Header angepasst werden muss, lass die Finger davon. Gute Bespiele dafür sind proprietäre Grafiktreiber und Virtualisierungssoftware, die nicht aus den openSUSE-Repositories stammt.

Also bis auf meinen proprietären NVIDIA Grafiktreiber nutze ich eigentlich nur Software aus den offiziellen Paketquellen einschl. Packman.
Wenn ich mich an meine Linux-Installation auf meinem alten PC erinnere denke ich an die Probleme die ich hatte den proprietären Grafiktreiber zu installieren, da dieser nicht mit der x-org Version funktioniert hat. Es musste ein Downgrade von x-org durchgeführt werden um diesen zum Laufen zu bringen. Aber ich vermute das dieses Problem wohl eher ältere Hardware betrifft. Wenn ich aktuelle Hardware nutze dürften Schwierigkeiten mit Kernel-Updates doch eher unwahrscheinlich sein, oder?

Virtualisieren tue ich mit KVM/QEMU… das KVM Modul ist in jedem aktuellen Kernel enthalten. Behütet mich das vor Problemen mit KVM/QEMU bei Kernel-Updates?

Des weiteren habe ich einen Samba-Server eingerichtet um mit meiner Windows-VM unter KVM/QEMU Dateien zu tauschen. Sind hier Probleme zu erwarten bei Samba Updates…?

Updates sind ausschließlich(!) per “zypper dup” auszuführen.

Siehe hierzu:
“Tumbleweed Repositorys können mit Hilfe von YaST oder per Zypper zugefügt und verwaltet werden.”
(aus: Portal:Tumbleweed – openSUSE Wiki)

Verstehe ich nicht. Wieso sollte ich nicht per Yast meine Tumbleweed-Updates durchführen können wenn ich dort die entsprechenden Repositorys eingerichtet habe?

4

Na ja, das ist wohl Ansichtssache. Du bekommst auf jeden Fall von bestimmten Softwarepaketen neuere Versionen als in den Standard-Repositorries. Bei einem Release-Wechsel ist aber eine große Update-Orgie fällig (je nach Installation > 1500 Pakete). Das passiert bei einer “richtigen” Rolling-Release-Distro nicht.

Also bis auf meinen proprietären NVIDIA Grafiktreiber nutze ich eigentlich nur Software aus den offiziellen Paketquellen einschl. Packman.
Wenn ich mich an meine Linux-Installation auf meinem alten PC erinnere denke ich an die Probleme die ich hatte den proprietären Grafiktreiber zu installieren, da dieser nicht mit der x-org Version funktioniert hat. Es musste ein Downgrade von x-org durchgeführt werden um diesen zum Laufen zu bringen. Aber ich vermute das dieses Problem wohl eher ältere Hardware betrifft. Wenn ich aktuelle Hardware nutze dürften Schwierigkeiten mit Kernel-Updates doch eher unwahrscheinlich sein, oder?

Nach jedem ernsthaften Kernel-Update, wo nicht nur die 5. Stelle nach dem Komma hochgezählt wird, findest Du in den Foren einen Eintrag unter dem Motto: “Der NVIDIA-Treiber geht nicht unter Kernel x.y.z”

Virtualisieren tue ich mit KVM/QEMU… das KVM Modul ist in jedem aktuellen Kernel enthalten. Behütet mich das vor Problemen mit KVM/QEMU bei Kernel-Updates?

Ja.

Des weiteren habe ich einen Samba-Server eingerichtet um mit meiner Windows-VM unter KVM/QEMU Dateien zu tauschen. Sind hier Probleme zu erwarten bei Samba Updates…?

Eher nicht; aber damit habe ich nicht soviel Erfahrung.

Siehe hierzu:
“Tumbleweed Repositorys können mit Hilfe von YaST oder per Zypper zugefügt und verwaltet werden.”
(aus: Portal:Tumbleweed – openSUSE Wiki)

Verstehe ich nicht. Wieso sollte ich nicht per Yast meine Tumbleweed-Updates durchführen können wenn ich dort die entsprechenden Repositorys eingerichtet habe?

Repositories hinzuzufügen ist ein relativ einfacher Vorgang. Bei der richtigen Ermittlung aller Abhängigkeiten beim eigentlichen Update zeigt sich schnell, wie unterschiedlich “intelligent” die verschiedenen Werkzeuge sind. zypper ist hier einfach umschlagbar. Du wirst auch in allen Anleitungen zu Tumbleweed nur die Empfehlung “sudo zypper dup” finden. Und ganz ehrlich, so kompliziert oder umständlich finde ich die Eingabe dieses kurzen Befehls nun auch wieder nicht. Aber auch das ist Geschmackssache…

5

Nach jedem ernsthaften Kernel-Update, wo nicht nur die 5. Stelle nach dem Komma hochgezählt wird, findest Du in den Foren einen Eintrag unter dem Motto: “Der NVIDIA-Treiber geht nicht unter Kernel x.y.z”

Ich weiss. Aber ich vermute und hoffe das dies vorrangig Nicht-Aktuelle Grafikkartentreiber betrifft und aktuelle Hardware da eher unproblematisch ist… oder ist diese Annahme falsch?

Repositories hinzuzufügen ist ein relativ einfacher Vorgang. Bei der richtigen Ermittlung aller Abhängigkeiten beim eigentlichen Update zeigt sich schnell, wie unterschiedlich “intelligent” die verschiedenen Werkzeuge sind. zypper ist hier einfach umschlagbar.

Das wusste ich noch nicht.
Zypper löst Abhängigkeiten besser auf als Yast? Interessant!

Und ganz ehrlich, so kompliziert oder umständlich finde ich die Eingabe dieses kurzen Befehls nun auch wieder nicht. Aber auch das ist Geschmackssache…

Ist auch völligst simpel!
Irgendwie hab ichs halt mit GUI… , aber wenns schlechter funktioniert (wie z.B. zypper) werd ich das nochmal überdenken!

6

NVidia braucht öfter mal etwas länger um den aktuellsten Kernel zu unterstützen. Du musst dir dann vorübergehend mit inoffiziellen Patches behelfen.

Außerdem musst du nach jedem Kernel-Update (und die gibts bei Tumbleweed zahlreich) den Treiber von der nvidia-Homepage (“the hard way”) neu installieren, die Pakete aus dem Repo funktionieren dort nicht bzw. es gibt keine für Tumbleweed.

Von den Tumbleweed-Maintainern wird ausdrücklich davon abgeraten, den nvidia Treiber zu verwenden.

Das wusste ich noch nicht.
Zypper löst Abhängigkeiten besser auf als Yast? Interessant!

Nein. zypper und YaST nutzen sowieso die selbe Bibliothek dafür, nämlich libzypp.
Aber “zypper dup” ist dafür entwickelt worden ein DistributionsUPgrade durchzuführen, während “zypper up” dazu gedacht ist normale UPdates zu installieren. Bei einem DistributionsUPgrade kann es auch passieren dass Pakete umbenannt/gelöscht werden und neue dazukommen z.B., damit kommt “zypper up” nicht klar. Und “zypper patch” (das Äquivalent zu YaST->Online Updates) installiert sowieso nur “Patches” aus dem Update-Repo.

Außerdem wechselt “zypper up” Pakete nicht zu Versionen aus anderen Repos, das ist aber zwingend notwendig für Tumbleweed.

Natürlich kannst du auch YaST verwenden, du solltest aber wissen was du tust und bist auf dich allein gestellt.
Jedenfalls solltest du vermutlich unbedingt die Option “Herstellerwechsel erlauben” einschalten. Global geht das in /etc/zypp/zypp.conf (Option “solver.allowVendorChange”).

7

Hallo ThomasKR,

Das ist zumindest das Ziel von Tumbleweed.
Aber auch auf meinem Desktop-Rechner habe ich seit Jahren mein /home nicht mehr erneuern müssen.
Zu beachten sind eigentlich nur die Dinge die auf der Projektseite geschrieben sind.

Auf meinem Netbook habe ich Tumbleweed installiert und bislang keine Probleme damit gehabt.
Das mag zum einen daran liegen das auf diesem Gerät keine proprietären Treiber installiert sind und auch keine “händisch” installierten Programme vorhanden sind und daran das ich dieses aktuell fast nicht gebrauche.

Ist das wirklich so? Keine Ahnung, aber auf meinem Produktivsystem bleibe ich doch lieber auf der “normalen” Release

Lieben Gruß aus Hessen

8

[QUOTE]Zitat von ThomasKR
Soweit ich weis werden ja nur stabile Updates durch Tumbleweed durchgeführt.

Ist das wirklich so? Keine Ahnung, aber auf meinem Produktivsystem bleibe ich doch lieber auf der “normalen” Release[/QUOTE]

@ThomasKR
So lange Menschen daran arbeiten wird es auch Fehler geben.
Dann wird sich zeigen, ob Du die beheben kannst.

Man siehe die Probleme mit dem Nvidia-Treiber, die kürzlich auftraten.

Tumbleweed läuft bei mir nur in einer VBox, wenn es nicht mehr geht wird dran herum geschraubt, wenn gar nichts mehr geht wird es gelöscht.

Ansonsten wird jede openSUSE Version neu installiert unter Beibehaltung des alten /home (hat seit SuSE 10.0 funktioniert).

Es muss nicht immer das Neueste vom Neuen sein.

9

Hallo zusammen,

also ich denke ich werde dann wohl lieber die Finger von Tumbleweed lassen!

@Sauerland: Auch ich habe mir überlegt das ganze - wenn überhaupt - lieber in einer VM laufen zu lassen.

Die Vorstellung immer wieder wegen Kernel-Updates mit Problemen konfrontiert zu werden gefällt mir nicht.

Kürzlich habe ich auf einer Homepage gelesen das Suse darüber nachdenkt evtl. zukünftig nur noch auf Rolling-Release als Veröffentlichungsvariante zu setzen (Ich weiss leider nicht mehr aus welcher Quelle). Hinsichtlich dessen was Ihr so schreibt halte ich das für keine so prickelnde Idee!

10

Tja, an sich sollten die Kernel-Updates ja kein Problem machen. Und du kannst natürlich auch immer einen älteren Kernel booten (“Erweiterte Einstellungen”/“Advanced Options” im Boot Menü), falls es doch mal Probleme gibt.

Nachteilig ist das (die vielen Kernel-Updates) halt eben hauptsächlich, wenn du Kernel-Module von Dritt-Anbietern verwendest (vor allem proprietäre wie z.B. nvidia/fglrx und broadcom-wl z.B.).

Aber der Sinn und Zweck von Tumbleweed (oder einer Rolling Release allgemein) ist ja eben immer die neuesten Versionen von allem zu haben, inklusive dem Kernel.

Eine Möglichkeit wäre aber dkms zu benutzen (ein Paket gibts auf Packman). Das würde die Kernel-Module nach einem Kernel-Update automatisch neu kompilieren. Vor allem bei einem größeren Update, also z.B. 3.15.x auf 3.16.0, kanns da aber natürlich trotzdem Probleme geben, weil das entsprechende Modul z.B. den neuen Kernel noch nicht unterstützt und deshalb nicht gebaut werden kann. Deswegen wird so ein Szenario von den Tumbleweed-Maintainern eben nicht empfohlen oder gar unterstützt.

Kürzlich habe ich auf einer Homepage gelesen das Suse darüber nachdenkt evtl. zukünftig nur noch auf Rolling-Release als Veröffentlichungsvariante zu setzen (Ich weiss leider nicht mehr aus welcher Quelle).

Das wär mir aber neu.

Momentan wird hauptsächlich daran gearbeitet, Factory durch Änderungen in der Infrastruktur stabiler zu machen. Das ist auch der Grund, warum sich die Veröffentlichung von 13.2 verzögern wird (momentaner Stand ist November).
Vermutlich wird Factory dann auch irgendwann mal Tumbleweed als “stabile” Rolling Release ablösen.

Aber davon dass keine “normalen” openSUSE Versionen mehr veröffentlicht werden würden, ist derzeit absolut keine Rede.
Natürlich weiß man nie, was in ein paar Jahren sein wird… Aber geplant ist das nicht, soweit ich weiß.

Wenn Factory stabil ist, ists ja auch viel leichter eine neue openSUSE Version rauszubringen. Man bräuchte ja im einfachsten Fall einfach nur einen Factory-Snapshot erstellen, und den dann halt openSUSE 14.1 taufen, oder so… :wink:
Obwohl, komplett anders zur jetzigen Situation wäre das ja auch nicht. Derzeit ist ja auch Factory die Entwicklungsversion für die nächste openSUSE Version. Zu einem bestimmten Zeitpunkt wird dann openSUSE-Next (um das jetzt mal so zu bezeichnen, das ist kein “offizieller” Name) von Factory abgespalten und erhält nur mehr Bugfixes, vor dem Release direkt im Repo, danach über das Update-Repo.

Ein Grund für das Missverständnis ist vielleicht, dass ein gewisser SUSE Mitarbeiter vor ein paar Monaten bei der Ankündigung, dass SUSE sich vorläufig vermehrt um das OBS kümmern wird (um Factory stabiler zu machen), etwas (teilweise komplett…) mit seinen Aussagen danebengregriffen hat. Z.B. dass SUSE sich nicht an der Veröffentlichung von 13.2 beteiligen sondern das allein der Community überlassen werden wird, oder dass von SUSE vermutlich keine offiziellen Updates für 13.2 erscheinen werden. Das ist aber alles inzwischen (seit längerem) klargestellt.