Fedora 17/18 & gnome-shell: Probleme mit Hyper-V

Wer Fedora 17/18 als virtueller Gast unter xem/vmware/hyperV/kvm verwendet, läuft wahrscheinlich in den Fehler, dass bereits vor der Anmeldung die Gnome Shell eine Fehlermeldung zeigt und die Anmeldung so unmöglich wird – so bleibt nur noch der Neustart. In der Konsole könnte man ja noch etwas ausrichten, aber Ctrl+Alt+F2 in einer virtuellen Maschine zu drücken ist gar nicht so einfach.

In die markierte Zeile ganz zum Schluss eine 3 schreibenAm einfachsten ist es, die virtuelle Maschine neu zu starten und dann in den Runlevel 3 zu starten. Sobald man gestartet hat, in der Kommandozeile

sudo yum remove fprintd fprintd-pam

ausführen, da sich in den Diskussionen dazu dieser als Fehlerquelle herausgestellt hat. Anscheinend hängt es mit der USB-Emulation der Virtualisierer zusammen – wenn das nicht hinhaut, reißt fprintd das ganze Ding in den Abgrund.

Neustarten und schon hat man sein virtuelles Fedora.

Fedora 17: Beefly Miracle plymouth theme aktivieren

Die Fedora Designer haben für das aktuelle Release ein eigenes Plymouth theme erstellt, das dem Bootvorgang ein gewisses Etwas verleiht.

Um das Theme zu aktivieren, muss es zuerst via

su -c'yum install plymouth-theme-hot-dog'

aus dem Fedora-Repository nachinstalliert werden.

Anschließend kann man das Theme über das Kommando

su -c'plymouth-set-default-theme hot-dog -R'

aktivieren. Der Parameter „-R“ sorgt dafür, dass das initrd neu erstellt wird, was notwendig ist, um das geänderte Theme verwenden zu können und einige Momente dauern kann.

Ab dem nächsten (Neu)Start des System begrüßt einen anstatt des Fedora-Logos das Fedora 17 Maskottchen „beefly miracle“.

(via)

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: dkms reparieren

Durch einen Bug im dkms Paket ist selbiges momentan zumindest in Fedora 17 als unbrauchbar zu bezeichnen.

Insbesondere Nutzer der proprietären Version von VirtualBox dürften unter diesem Bug leiden, da diese VirtualBox Variante dkms nutzt, um die benötigten Kernelmodule automatisch zu aktualisieren.

Als Workaround sollte es reichen, das dkms Binary via

su -c'mv /usr/sbin/dkms.old /usr/sbin/dkms'

umzubenennen.

Nutzer der proprietären Version von VirtualBox müssen anschließend noch die Kernelmodule via

su -c'/etc/init.d/vboxdrv setup'

neu zu compilieren und im dkms zu registrieren.

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: Samba trotz Abhängigkeitsproblemen aktualisieren

Das aktuelle Update für Samba4 kann zur Zeit nicht installiert werden, da das Paket libsmbclient Abhängigkeitsprobleme verursacht. Ursache des Problems ist anscheinend, das die Pakete libsmbclient und libwbclient in die übrigen Samba4-Pakete integriert wurden, jedoch in keinem der übrigen Sama4-Paketen die entsprechende Information, das es libsmbclient und libwbclient ersetzt, hinterlegt wurde. Es gibt nun zwei Optionen, wie man mit dem Problem umgeht: Warten, bis korrigierte Pakete bereitgestellt werden oder das Update manuell durchführen.

Wer sich für Option Nr. 2 entscheidet, sollte folgende Schritte befolgen:

Zuerst finden wir heraus, welche Pakete manuell aktualisiert werden müssen, in dem wir libsmbclient und libwbclient manuell deinstallieren:

su -c'yum erase libsmbclient libwbclient'

Bevor wir die Deinstallation starten, notieren wir uns die Pakete, die zusätzlich zu libsmbclient und libwbclient deinstalliert werden, um sie im nächsten Schritt manuell wieder zu installieren.

Nachdem yum die Pakete libsmbclient und libwbclient aus dem System entfernt hat, installieren wir die übrigen von yum deinstallierten Pakete wie gewohnt neu und haben somit das Abhängigkeitsproblem mehr oder weniger elegant aus der Welt geschafft.

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: Xfce auf Version 4.10 updaten

Da es sich bei Xfce 4.10 momentan noch um eine Vorabversion handelt, kann es noch zu schweren Fehlern oder Instabilitäten kommen! Das Update sollte deshalb nur von erfahrenen Anwendern durchgeführt werden!

Kevin Fenzi, einer der Xfce Maintainer bei Fedora, stellt in einem privaten Repository Pakete für Xfce 4.10 zur Installation bereit.

Um ein vorhandenes Xfce 4.08 auf die Version 4.10 zu aktualisieren, muss zuerst das notwendige Repository mittels

su-
cd /etc/yum.repos.d
wget http://repos.fedorapeople.org/repos/kevin/xfce-4.10/fedora-xfce-4.10.repo

eingerichtet werden.

Falls xfburn oder xfce4-time-out-plugin installiert sind, müssen diese zuerst mittels

su -c'yum erase xfburn xfce4-time-out-plugin'

deinstalliert werden, damit das Update erfolgreich durchgeführt werden kann.

Um Xfce zu aktualisieren, wird folgender Befehlt ausgeführt

su -c'yum update – nogpgcheck'

Der Parameter nogpgcheck ist notwendig, da yum ansonsten die Aktualisierung aufgrund der fehlenden GPG-Signatur der Pakete abbricht. Nun noch das System neu starten und fertig ist das Update auf Xfce 4.10.

Edit 22.04.2012: Angepasst für Xfce 4.10pre2
Edit 23.04.2012: Absatz bzgl. des RDP-Plugins für remmina entfernt

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 „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.

DropBox Client unter Fedora 17 „reanimieren“

Wer sein System auf die Beta von Fedora 17 aktualisiert hat, wird feststellen, das sich der DropBox Client nicht mehr startet und eine SELinux Fehlermeldung erscheint.

Um den Client zu „reanimieren“, muss lediglich die allow_execstack Option von SELinux (re)aktiviert werden. Dies geschieht am einfachsten über folgendes Kommando

su -c'setsebool -P allow_execstack 1'

Nachdem man das root Kennwort eingegeben hat, wird die Option (re)aktiviert, was jedoch einen kurzen Moment dauern kann. Anschließend lässt sich der DropBox Client wie gewohnt starten.