Veröffentlicht am

Grub2 unter Fedora 15 installieren

Obwohl es eine gewisse Überschneidung mit der Anleitung für Fedora 16 gibt, wollen wir Fedora 15 Anwendern nicht vorenthalten, wie sie grub2 auf ihrem System installieren können.

Zuerst muss grub2 sowie os-prober via

su -c'yum install grub2 os-prober'

installiert werden.

Als nächstes installieren wir grub2 als Bootloader und ersetzen somit grub. Dies geschieht mittels folgendem Kommando1 :

su -c'grub2-install /dev/sda'

Im Anschluss daran muss die Datei /etc/default/grub angepasst werden, damit uns der Bug 678453 nicht die Tour vermasselt. Dies geschieht mittels

su -c'nano /etc/default/grub'

hier fügen wir nun folgende Zeile als Workaround ein

GRUB_DISTRIBUTOR=$(sed "s/.*(\(.*\))/\1/" /etc/system-release)

Im letzten Schritt erzeugen2 wir nun noch eine neue grub2.conf mittels

su -c'grub2-mkconfig -o /boot/grub2/grub.cfg'

Ab dem nächsten (Neu)Start des Systems wird jetzt grub2 anstelle von grub verwendet.

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!

  1. Falls die erste Festplatte eine andere Bezeichnung hat, muss der Befehl entsprechend angepasst werden! [↩]
  2. Dieser Schritt muss nach jeder Änderung von /etc/default/grub wiederholt werden, damit die Änderungen wirksam werden. [↩]
Veröffentlicht am

Fedora 16: grub2 aktivieren

Für Fedora 16 wird seit heute ein Update für grub2 ausgerollt, welches grub als Bootloader ersetzt. Um grub2 auch nutzen zu können, sind jedoch noch ein paar manuelle Handgriffe notwendig.

Zuerst muss grub2 als Bootloader installiert werden. Dies geschieht mittels folgendem Kommando1 :

su -c'grub2-install /dev/sda'

Im nächsten Schritt muss die Datei /etc/default/grub angepasst werden, damit uns der Bug 678453 nicht die Tour vermasselt. Dies geschieht mittels

su -c'nano /etc/default/grub'

hier fügen wir nun folgende Zeile als Workaround ein

GRUB_DISTRIBUTOR=$(sed "s/.*(\(.*\))/\1/" /etc/system-release)

Im letzten Schritt erzeugen2 wir nun noch eine neue grub2.conf mittels

su -c'grub2-mkconfig -o /boot/grub2/grub.cfg'

Ab dem nächsten (Neu)Start des Systems wird jetzt grub2 anstelle von grub verwendet.

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!

  1. Falls die erste Festplatte eine andere Bezeichnung hat, muss der Befehl entsprechend angepasst werden! [↩]
  2. Dieser Schritt muss nach jeder Änderung von /etc/default/grub wiederholt werden, damit die Änderungen wirksam werden. [↩]
Veröffentlicht am

Fedora 16: Grub-Einstellungen werden nach dem Upgrade nicht aktualisiert

Momentan scheint es so, als ob Preupgrade bzw. der Installer für das Upgrade die Grub-Einstellungen nicht aktualisiert (Bugreport).

Wer ebenfalls von diesem Problem betroffen ist, hat nur die Möglichkeit, den noch vorhandenen Fedora 15 Kernel zu booten und entweder einen aktuelleren Fedora 16 Kernel zu installieren oder die Grub-Einstellungen von Hand zu aktualisieren.

Veröffentlicht am

Chatzilla wieder zum Leben erwecken

Anscheinend wurde bei den letzten Firefox Updates vergessen, Chatzilla entsprechend zu patchen. Wer versucht, Chatzilla zu starten, wird feststellen müssen, das nichts passiert. Versucht man, Chatzilla im Terminal zu starten, erhält man zumindest folgende Fehlermeldung:

Error: Platform version '6.0' is not compatible with
minVersion >= 1.8
maxVersion <= 2.0.*

Da es zwar einen entsprechenden Bug gibt, der zuständige Entwickler bislang jedoch nicht reagiert hat, behelfen wir uns, indem wir Chatzilla selber patchen. Dazu führen wir folgenden Befehl im Terminal aus:

su -c'sed -i 's/2.0.*/6.0.*/g' /usr/share/chatzilla-0.9.86/application.ini'

Mit diesem Kommando ersetzen wir mit Hilfe von sed die Zeichenfolge „2.0.*“ in der application.ini von Chatzilla durch „6.0.*“ und reanimieren somit Chatzilla wieder zum Leben.

Update: Inzwischen befindet sich ein aktuelles chatzilla Paket in updates-testing, welches das Problem behebt.

Veröffentlicht am

Xfce: gnome-sound-applet deaktivieren

Wer seinen Desktop von Gnome auf Xfce migriert, der hat zunächst unter Xfce auch das Gnome-Sound-Applet, dessen schwarzes Icon unter Xfce wie ein Fremdkörper wirkt. Sofern das Paket control-center nicht entfernt werden kann, da z.B. gnome-bluetooth noch benötigt wird, hilft folgende Anleitung, das Applet los zu werden.

Um das gnome-sound-applet zu deaktivieren, muss zuerst der entsprechende Eintrag in den gnome-session-properties deaktiviert werden. Anschließend muss noch folgendes Kommando in einer Shell ausgeführt werden, um zukünftig den Start des Applets zu unterbinden:

echo "Hidden=true" >> ~/.config/autostart/gnome-sound-applet.desktop

Ab dem nächsten Neustart des Systems sollte das Applet nicht mehr gestartet werden. Wer nicht so lange warten möchte, kann das Applet mittels

killall gnome-sound-applet

beenden und hat fortan Ruhe.

Veröffentlicht am

gnome-python2 Paket ist fehlerhaft

Das momentan von Fedora ausgelieferte gnome-python2 Paket ist anscheinend fehlerhaft, da sich beispielsweise nach eine Neuinstallation von Fedora 15 der Passwort-Manager revelation nicht mehr starten lässt.

Bis der Fehler behoben und ein fehlerfreies Paket bereit steht, ist der einzig mögliche Workaround, das gnome-python2 Paket selber mit geänderter Versionsnummer neu zu bauen und zu installieren.

Nachtrag: Das Problem scheint nur Personen zu betreffen, die Fedora 15 neu installiert haben. Wer hingegen das Upgrade von Fedora 14 gemacht hat, ist von diesem Problem nicht betroffen, da das gnome-python2 Paket von Fedora 14 fehlerfrei zu sein scheint.

Nachtrag 2: Das gnome-python2 Paket ist vollständig. Ursache des Problems von revelation sind unvollständige Angaben über die Abhängigkeiten. So fehlen mindestens gnome-python2-gnome und gnome-python2-bonobo in den Abhängigkeiten von revelation.

Veröffentlicht am

Frust mit Bugzilla

Das Melden von Bugs im Bugzilla von Red Hat/Fedora macht teilweise keinen Spaß mehr, wenn man miterlebt, das eigene Bugreports, die man z.T. für Pakete aus Fedora 13 angelegt hat, jetzt automatisch geschlossen werden, ohne das es seit dem Anlegen des Bugreports irgendeine Reaktion der Verwalter des betroffenen Paketes gab. Einige der Bugreports wurden mit Fedoras abrt1 erstellt, was sie aber auch nicht davor bewahrt hat, komplett ignoriert zu werden.

Bin ich der einzige oder geht das auch anderen Lesern so?

  1. automatic bug reporting tool [↩]