Upgrade auf Fedora 18 mit FedUp: Ein Erfahrungsbericht

Es gibt verschiedene Methoden auf die kommende Fedora zu upgraden: über yum, über das DVD-Image und über FedUp. Was FedUp ist und wo PreUpgrade geblieben ist? Nun, um es kurz zu machen: FedUp ersetzt mit dem Erscheinen von Fedora 18 das vielen Benutzern bekannte PreUpgrade. Und laut Wiki-Eintrag ersetzt es damit auch die bisher empfohlenen Upgrade-Methoden via DVD und PreUpgrade.

Ich versuche hier kurz zu beschreiben wie das Upgrade verläuft.

Zuerst gibt es eine gute und eine schlechte Nachricht. Die Schlechte zuerst: Ein Upgrade von Fedora 16 auf die Version 18 ist nicht möglich.

Nun die Gute: FedUp bedient sich im Großen und Ganzen wie PreUpgrade und verlief bei mir ähnlich schmerzfrei, d.h.: Abgesehen von ein paar Schönheitsfehlern lief es durch und ich erfreue mich nun an „Spherical Cow“ inkl. Gnome 3.6.

Als erstes empfiehlt es sich ein Backup zu machen. Sowohl FedUp also auch Fedora 18 sind noch in der Entwicklung und so kann da noch einiges schief gehen. Außerdem ist es nie verkehrt ein Backup zu haben.

Wer außer rpmfusion noch weitere Fremdrepositories eingebunden hat, dem empfiehlt es sich diese zu deaktivieren, da viele noch keine Pakete für Fedora 18 bereitstellen. Und die daraus installierten Pakete sollten ebenfalls deinstalliert werden, um eventuell auftretende Abhängigkeitsprobleme zu vermeiden.

Nun bringt man sein System auf den aktuellen Stand, falls noch nicht geschehen. Sollte ein Kernel-Update dabei sein, muss man natürlich rebooten. Anschließend installiert man FedUp mit folgenden Befehl:

yum install fedup --enablerepo=updates-testing

Der Zusatz ’–enablerepo=updates-testing’ sorgt dafür, dass man die neueste Version von FedUp bekommt.

Dann kommt man endlich zu spannenden Teil: Der Start von FedUp. Dazu benötigt man noch die URL der Fedora-Version, auf die man upgraden möchte. Zur Zeit ist das:

http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/$arch/os

Wobei $arch für die eingesetzte Architektur steht, also für 32bit i686 und für 64bit x86_64, und dementsprechend ersetzt werden muss.

Hat man die URL, führt man folgenden Befehl als root aus:

fedup-cli --network 18 --debuglog fedupdebug.log --instrepo $URL

Nun fängt FedUp an, die Aktualisierungen für die installierten Pakete herunter zu laden. Je nach Umfang und Internetanbindung kann das einen Weile dauern. Man kann also schon mal einen Kaffee trinken gehen oder den Weihnachtsurlaub auf den Bahamas planen und ausführen. Wenn FedUp dann damit fertig ist, wird versucht aus den Paketen ein Upgrade-Images zu erstellen.

Sollten es während des gesamten Vorgangs Fehler auftauchen, so muss man selbst entscheiden, ob man weiter macht. Hilfreich für die Entscheidungsfindung sollte die angelegte Log-Datei fedupdebug.log sein. Grobe Faustregel: Wenn die große Mehrheit an Aktualisierungen heruntergeladen wurden und das Upgrade-Image erfolgreich erstellt werden konnte, dann kann man weiter machen.

Anschließend erfolgt ein Neustart des System. Im Grub Menü befindet sich nun in der 1. Zeile ein Eintrag namens „System Upgrade“. Wählt man diesen aus, so startet der Upgrade-Prozess.

Achtung: Der eigentliche Upgrade-Prozess dauert recht lange, deutlich länger als mit dem alten PreUpgrade. Und bei mir schien sich meine Maschine phasenweise aufgehangen zu haben, so dass minutenlang keine Änderung zu sehen war, aber es ging trotzdem weiter. Also habt Geduld. Das gesamte Upgrade dauerte bei mir ca. 45 Minuten. Also bringt viel Geduld mit.

Sofern nichts schief geht, startet das System nach dem ganzen Prozedere neu und man kann in Grub Fedora 18 auswählen und starten. Nutzer eines UEFI-Systems sollten vorher unbedingt die Anleitung zur Aktualisierung von grub2-efi lesen und durchführen. Da ich kein UEFI System habe, kann die Anleitung nicht weiter kommentieren.

Das war das Pflichtprogramm zum Upgrade. Nun folgt die Kür:
Nachdem man sich, hoffentlich erfolgreich, in den Desktop seiner Wahl eingeloggt hat, aktualisiert man nochmals das System:

sudo yum distro-sync

Der Grund ist einfach: Während der Beta sind die updates-testing Repositories aktiviert und liefern nochmals einen ganzen Stapel an Updates. Danach ist man endlich fertig.
Herzlichen Glückwunsch und frohes testen!

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

Razor-qt unter Fedora 17

Als Linux-User hat man ja das Glück sich seinen Desktop aussuchen zu können. Und so gibt es von den Dingern auch eine recht ansehnliche Zahl. Dazu kommen noch die diversen Fenstermanager. Wenn man allerdings als Qt als GUI-Toolkit haben möchte, so blieb dem User bisher nur der Einsatz von KDE Plasma. Okay, theoretisch gäbe es noch den KDE3-Fork Trinity. Der ist aber ein „Desktop ohne Zukunft“ (O-Ton M. Gräßlin, KWin-Entwickler, im freienMagazin 09/2011).

Der Razor-qt desktop
Razor-qt mit, KWin und Arora (Browser)

Seit einiger Zeit gibt es eine Alternative zu KDE Plasma für diejenigen, denen KDE Plasma zu groß und zu umfangreich ist: Razor-qt.

Die Entwickler beschreiben Razor-qt als „toolbox-like desktop-enviroment“, was ich sinngemäß mit „baukastenartige Desktop-Umgebung“ übersetze. Das beschreibt die Geschichte schon ganz gut. Neben dem konsequenten Einsatz von Qt wird bei Razor vor allem Wert auf Modularität gelegt. Jede einzelne Komponente, vom Powermanagment über das Panel bis hin zum Fenstermanager, liegt als einzelnes Paket vor. Und bei weiterführenden Programmen wie Dateimanager, Browser, Mail-Client, etc. werden nur passende Programme empfohlen, so dass sich jeder Benutzer nehmen kann, was ihm am besten gefällt. So bleibt der Desktop schlank und verhältnismäßig Ressourcen schonend. Und der Desktop sieht dabei, dank Qt, richtig schick aus und nicht als hätte man den Quellcode Ende der 90er vergraben und irgendein Idiot hätte ihn heute wieder aus gebuddelt.

Desktop-Menü von Razor
Das Kontextmenü von Razor

Richtig Pepp kommt meiner Meinung nach erst rein, wenn man statt des Standardfenstermanager OpenBox KWin einsetzt. KWin mag nicht ganz so viele Einstellungsmöglichkeiten haben wie OpenBox, dafür macht er optisch deutlich mehr her.

Bei den Programmen macht es natürlich Sinn nach Möglichkeit auf Qt-Programme zu setzen. Für diejenigen, die nicht wissen, was sie nehmen sollen, haben die Entwickler von Razor eine Liste der empfohlenen Anwendungen in ihrem Wiki erstellt.

Leider fällt einem schnell auf, dass es verhältnismäßig wenig Qt-Software außerhalb des KDE SC Universums gibt: So bin ich immer noch auf der Suche nach einem Mail-Client, der nicht Kmail heißt. Und damit wären wir bei den Nachteilen diese noch jungen Desktop-Projektes.

Konfigurationsdialog des Razor Desktops
Razor Desktop Config

Angefangen mit der Dokumentation: Das Wiki ist, vorsichtig ausgedrückt, sehr rudimentär. Auch fehlen verschiedene Einstellungsmöglichkeiten, wie z.B. Die Anzahl der Arbeitsflächen. Oder andere lassen sich nur über die entsprechende config Datei erreichen (Schnellstarter-Leiste). Und natürlich die schon angesprochene Softwareauswahl. Wenn man sich nicht KDE Plasma durch die Hintertür installieren will, ist man doch recht stark eingeschränkt.

Bei all diesen Problemen und Problemchen muss man jedoch bedenken, dass der Desktop noch sehr jung in der Entwicklung ist. Aktuell ist die Version 0.4.1. Wer dennoch einen Versuch wagen will, kann sich entweder via git etwas backen oder man bindet das X11 QtDesktop Repo mit

su -c 'wget http://download.opensuse.org/repositories/X11:/QtDesktop/\
Fedora_17/X11:QtDesktop.repo -O /etc/yum.repos.d/QtDesktop.repo'

ein.(Edit, 29.08.: Typo korrigiert) Wer Fedora 16 einsetzt, muss hier natürlich Fedora_17 gegen Fedora_16 austauschen. Anschließend installiert man die neueste Version via

su -c 'yum install razorqt'

Das hat den Vorteil, dass man Zugriff auf ein paar Qt-Anwendungen hat, die nicht in den offiziellen Repositories sind, z.B. den Dateimanager Andromeda.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

Fedora 17 & Gnome: Neues Mountverhalten bei USB-Sticks und -Platten

Eine der vielen Neuerungen von Fedora 17 ist udisks2. Selbiges kommt zum Einsatz, wenn man Gnome 3.4 einsetzt. Daraus ergibt sich aber ein nennen wir es ungewohntes Verhalten beim mounten von USB-Medien.

Diese werden nicht mehr, wie gewohnt, unter /media/$stick gemountet, sondern unter /run/media/$user/$stick. Für die Desktop-Benutzung hat das erst mal keine Auswirkung. Nautilus zeigt den Stick ganz normal in der rechten Spalte und dort lässt er sich ein- und aushängen.

Problematisch wird es erst, wenn man den Datenträger über die Konsole sucht. Dementsprechend müssen selbst erstellte Scripte angepasst werden.

Ein weiteres Problem ist/war, dass USB-Medien nicht mehr gemountet werden, wenn sie eingesteckt sind, bevor das System (re)bootet bzw. udisks2 bereit ist. Dies war zumindest während der Beta so. Nun sind hier bei mir auf Grund von Abhängigkeiten beide Varianten (udisks und udisks2) installiert sind. Und nun werden Sticks/Festplatten/DVDs/whatever während des Bootvorgangs eingehangen.

Zum Schluss noch 2 Vermutungen:

  1. Eine Lösung scheint zu sein udisks oder irgendein Paket, das udisks als Abhängigkeit mit sich bringt, zu installieren.
  2. Dieses „Problem“ scheint erst mal nur Gnome zu betreffen, da meines Wissens nach die anderen Desktop-Umgebungen noch udisks einsetzen.

Fedora 17 „Beefy Miracle“ – Ein Zwischenbericht

Das ist also mein erster Gast-Beitrag für Fedora-Blog.de. Worum soll’s gehen? Eigentlich sollte es ein kurzer Statusbericht zu Fedora 17 „Beefy Miracle“ werden. Aber was schreibt man, wenn es im Großen und Ganzen gut läuft?

Okay, das Wichtigste zuerst: So sieht Fedora 17 (mit Gnome) bei Neuinstallation aus:

Screenshot von Fedora 17 "Beefy Miracle"
Screenshot von Fedora 17 "Beefy Miracle"

Der/die/das Wallpaper ist mal richtig schick geworden.

Ich kann in Sachen Problemen eigentlich nur von ein paar kleineren Macken berichten. Das soll nicht heißen, dass es keine gibt, sondern nur, das ich keine größeren Probleme habe: ymmv.

Ein Punkt ist das von Gnome eingeführte Application-Menü: Das Ding ist vielleicht nervig! Auf einem Monitor vielleicht ja noch ganz nett, aber auf 2 sieht das dann so aus:

Das "Application Menu" ist nicht immer hilfreich

Okay, das ist jetzt kein echter Bug. Aber ist nervig ist es trotzdem!
Das 2. Problem ist schon ein echtes: Ich kann bei einigen Anwendungen (Evolution & Gwibber) nicht richtig scrollen, bei anderen (z.B.: Gnome Terminal) hingegen schon. Wenn ich wüsste gegen welches Paket ich einen Bug filen soll, dann würd ich das tun. Gegen Gtk3? Das Terminal funktioniert tadellos. Gegen die einzelnen Programme? Es ist 3mal derselbe Effekt, da ist es doch unwahrscheinlich, dass es 3 verschiedene Bugs sind.

Eine gewisse Zeit lang war die Gnome-Shell etwas wackelig, d.h.: Sie startete unregelmäßig neu. Mittlerweile hat sich aber auch das erledigt.

Soweit zu den „Problemen“, wenn man das so nennen möchte. Ich bin von einer de facto Beta anderes gewohnt. Insgesamt läuft es hier schon richtig rund und Gnome 3.4 ist eine schöne Verbesserung gegenüber 3.2. Wobei sich nur schwer erklären lässt warum. Es ist an vielen Kleinigkeiten geschraubt worden, so dass es im Gesamteindruck einfach etwas runder, glatter und schöner wirkt. Eine Liste der Änderungen gibt es hier. Und langsam füllt sich auch die Extensions Homepage. Während ich das hier schreibe, haben wir 7 Seiten mit kompatiblen Extensions. Das ist doch schon mal was!

Benutzer anderer Desktop dürften nicht so viele offensichtliche Änderungen auffallen, zumindest bei Xfce sollte in den aktuellen Fedora Releases die Version die gleiche sein.
Das Verschieben aller Binaries nach /usr/bin bzw. /usr/lib hat wohl die meiste Aufmerksamkeit in den entsprechenden Online-Medien bekommen. In der Praxis merke ich keinen Unterschied. Wie auch? Für mich als User ist es völlig egal, ob die Binaries in /bin, /usr/bin oder in /mordor liegen. Hauptsache mein System weiß, wo die Dinger sind und findet sie, wenn ich sie brauche.

In der Praxis sieht das jedenfalls so aus:
$ ls -l /
insgesamt 64
lrwxrwxrwx. 1 root root 7 21. Feb 20:52 bin -> usr/bin
(...)
lrwxrwxrwx. 1 root root 7 21. Feb 20:52 lib -> usr/lib
(...)
lrwxrwxrwx. 1 root root 8 21. Feb 20:52 sbin -> usr/sbin

Letztlich, wie erwartet, etwas unspektakulär.

Wer eine freie Partition über hat oder VirtualBox (oder Qemu-KVM, …) installiert hat, sollte auf jeden Fall einen Blick riskieren.

Wenn ihr upgraden wollt: Nutzt preupgrade. Ehrlich! Ein Upgrade via yum ist zum Scheitern verurteilt. Besser ihr führt das Upgrade nur aus, wenn ihr auch wisst, was ihr tut. Alle anderen sollten warten, bis „Beefy Miracle“ erschienen ist.