Youtube mit HTML5 unter FC22 + Firefox

Kürzlich hatte ich Flash von meinem System komplett heruntergeschmissen, um zu sehen ob es nicht auch ohne geht. Mit Youtube gab es allerdings kleine Probleme, so funktionierte die Video-Wiedergabe mit HTML5 nicht sofort, da der H.264 nicht mitgeliefert wurde.
Mit dnf install gstreamer1-libav gstreamer1-vaapi gstreamer1-plugins-{good,good-extras,ugly} und einem Neustart von Firefox wurde die H.264-Unterstützung unter https://www.youtube.com/html5 angezeigt und Videos liefen wieder wie gewohnt.

via http://martin.preisler.me/2014/08/h264-html5-video-in-firefox-on-fedora-20/

OpenStack schnell und einfach auf einem Host installieren

OpenStack auf einem einzigen Host aufzusetzen kann viel Handarbeit bedeuten, muss aber nicht. Über packstack des RDO-Projekts lässt sich OpenStack schnell und einfach installieren und konfigurieren. Zwar bringt Ferdora 22 Packstack von Haus aus mit sich, das Skript scheint aber noch nicht angepasst zu sein. Auf CentOS 7 lief die Installation ohne Probleme durch – nach 30 Minuten war OpenStack installiert und einsatzbereit.

dnf und alte Metadaten

Dnf wird demnächst in FC22 den Paketmanager yum ersetzen. Dnf kann man jetzt schon im Parallelbetrieb testen. Dabei fiel mir auf, dass yum und dnf Updates ganz unterschiedlich finden:
Nicht selten hatte yum schon eine ganze Stange Aktualisierungen parat, während dnf noch meinte, alles sei aktuell. Der Grund liegt in den Metadaten, die bei yum öfters aktualisiert bzw schneller als veraltet angesehen werden.
dnf -refresh upgrade umgeht dieses Problem zwar, allerdings werden dann immer wieder die neusten Metadaten der Repos heruntergeladen, was u.U. etwas dauern kann.
Um dnf das Verhalten von yum beizubringen, reicht es das Timeout, wann die Metadaten als veraltet gelten, zu ändern. Bei yum sind die Daten nach 6 Stunden veraltet, bei dnf nach 48 Stunden! (Siehe https://www.mankier.com/8/dnf.conf und http://linux.die.net/man/5/yum.conf, jeweils unter “metadata_expire”)
Mit metadata_expire=21600 unter /etc/dnf/dnf.conf verhält sich dnf wieder genau wie von yum gewohnt.

Fedora und der Realtek RTS5139 Kartenleser…

Fedora bringt standardmäßig keinen Treiber für den Realtek RTS5139 Kartenleser mit, welcher in vielen Laptops verbaut ist.
Die Installation von kmod-staging löst dieses Problem, aber nur bis ein neuer Kernel veröffentlicht wird. Da es mir zu doof war, ein paar Tage ohne Kartenleser da zu stehen, habe ich einen anderen Weg gesucht. Dies führte dazu, dass ich mir den Kernel selbst kompiliere – MIT Treiber. Im Prinzip ist es auch gar nicht schwierig, die Fedora Docs bieten eine ganz gute Anleitung: https://fedoraproject.org/wiki/Building_a_custom_kernel?rd=Docs/CustomKernel

Da ich keine Lust hatte, die Befehle immer wieder manuell einzugeben sind die folgenden Scripte entstanden (die in oben verlinkter Anleitung genannten Tools müssen noch installiert werden):

1_prepare.sh

#!/bin/sh
cd ~
rpmdev-setuptree
yumdownloader --source kernel
rpm -Uvh kernel-*
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ~/rpmbuild/BUILD/

2_configure_kernel.sh

#!/bin/sh
#copy to BUILD/kernel-$ver.$subver.$fedver/linux-$ver.$arch/
make oldconfig
make xconfig
cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic

3_make_kernel.sh

#!/bin/sh
rpmbuild -bb --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec

cleanup.sh

#!/bin/sh
rm -rf BU* S* ~/kernel-*.rpm

Zuerst habe ich in meinem Homeverzeichnis einen Ordner “rpmbuild” erstellt und alle Scripte dort hinein kopiert. Anschließend wird das erste Script ausgeführt. Es lädt den Quellcode des Kernels herunter und entpackt diesen. Danach wir das 2. Script in den Ordner BUILD/kernel-*/linux-*/ kopiert und darin ausgeführt. In dem sich anschließend öffnenden Dialog kann der Kernel konfiguriert werden. Hier sucht man über die Suchfunktion den entsprechenden Treiber, aktiviert das Häkchen und speichert die Konfiguration ab. Dann startet man den Kompiliervorgang mit dem 3. Script. Dies dauert je nach Rechner eine Weile. Ist der Kernel kompiliert finden sich die installierbaren rpms im Ordern RPMS.

Update 18.9.2014: Die neuen Treiber sind jetzt unter rtxs* (siehe https://bbs.archlinux.org/viewtopic.php?pid=1448633) zu finden.

Update 15.12.2014: Wie es scheint sind die Treiber unter Fedora 21 und Kernel 3.17 schon von Haus aus in den Kernel integriert. Zumindest funktionierte der Kartenleser ohne erneute Kompilierung.

Fedora: Opera unter KDE als Standardbrowser

Opera unter KDE als Standardbrowser einrichten ist auf den zweiten Blick doch irgendwie schwieriger. Der erste Schritt bei mir war in den Einstellungen die folgende Option anzupassen:opera_default_browser
Dadurch wurden zumindest schon mal die meisten Links in Opera geöffnet. Aber nicht alle. Ein paar Anwendungen (wie z.B: der Twitterclient Polly) haben immer noch den vorher eingestellten Browser geöffnet.

Erst die Datei /usr/local/share/applications/defaults.list hat mich auf die richtige Spur gebracht. Hier war immer noch die alte Konfiguration hinterlegt, welche auf /usr/share/applications/firefox.desktop als Standardbrowser für HTTP-Links gezeigt hat. Da Opera solch eine Datei scheinbar nicht erstellt/mitliefert habe ich die von Firefox gegebene als Grundlage genommen. Die entscheidende Änderung war die Zeile

Exec=firefox %u

welche zu

Exec=opera %u

wurde.

Letztendlich sah die Datei dann so aus:

[root@daedalus ~]# cat /usr/share/applications/firefox.desktop
[Desktop Entry]
Version=1.0
Name=Firefox
GenericName=Web Browser
GenericName[ca]=Navegador web
GenericName[cs]=Webový prohlížeč
GenericName[es]=Navegador web
GenericName[fa]=مرورگر اینترنتی
GenericName[fi]=WWW-selain
GenericName[fr]=Navigateur Web
GenericName[hu]=Webböngésző
GenericName[it]=Browser Web
GenericName[ja]=ウェブ・ブラウザ
GenericName[ko]=웹 브라우저
GenericName[nb]=Nettleser
GenericName[nl]=Webbrowser
GenericName[nn]=Nettlesar
GenericName[no]=Nettleser
GenericName[pl]=Przeglądarka WWW
GenericName[pt]=Navegador Web
GenericName[pt_BR]=Navegador Web
GenericName[sk]=Internetový prehliadač
GenericName[sv]=Webbläsare
Comment=Browse the Web
Comment[ca]=Navegueu per el web
Comment[cs]=Prohlížení stránek World Wide Webu
Comment[de]=Im Internet surfen
Comment[es]=Navegue por la web
Comment[fa]=صفحات شبکه جهانی اینترنت را مرور نمایید
Comment[fi]=Selaa Internetin WWW-sivuja
Comment[fr]=Navigue sur Internet
Comment[hu]=A világháló böngészése
Comment[it]=Esplora il web
Comment[ja]=ウェブを閲覧します
Comment[ko]=웹을 돌아 다닙니다
Comment[nb]=Surf på nettet
Comment[nl]=Verken het internet
Comment[nn]=Surf på nettet
Comment[no]=Surf på nettet
Comment[pl]=Przeglądanie stron WWW
Comment[pt]=Navegue na Internet
Comment[pt_BR]=Navegue na Internet
Comment[sk]=Prehliadanie internetu
Comment[sv]=Surfa på webben
Exec=opera %u
Icon=firefox
Terminal=false
Type=Application
MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;
StartupNotify=true
Categories=Network;WebBrowser;
Keywords=web;browser;internet;
X-Desktop-File-Install-Version=0.21

In wie weit der Rest relevant ist/gebraucht wird habe ich nicht ausprobiert ;-)

Fedora 20: KDE + Bluetooth-Kopfhörer = segmentation fault

Die Kombination aus Fedora 20 Beta, KDE und Bluetooth Kopfhörer funktioniert zum jetzigen Zeitpunkt eher schlecht als recht. Versucht man, einen Kopfhörer zu verbinden, stürzt bluedevil-audio mit einem segmentation fault reproduzierbar ab. Der Bug ist bekannt, aber noch nicht gelöst. Ein Workaround: bluetoothctl über die Kommandozeile. Es ist zwar etwas umständlicher, funktioniert aber.

bluetoothctl
devices
//Bluetooth MAC des Kopfhörers/Headsets suchen
connect $Bluetooth-MAC

Die Verbindung trennt man dann mit “disconnect”. Logisch irgendwie ;-)
Update 21.12.13: Das Problem ist behoben, eine gepatchte Version von bluedevil ist in den fedora-updates-testing repos.

Fedora: Freeze beim kopieren von größeren Dateien per USB

Warum auch immer, aber beim kopieren von größeren Dateien auf USB-Geräte wurde jeder Rechner unter Fedora 19 langsamer bis unbenutzbar. Die Lösung war die dirty_ratio mit

echo 1 > /proc/sys/vm/dirty_ratio && echo "echo 1 > /proc/sys/vm/dirty_ratio" >> /etc/rc.local

anzupassen. Ohne versucht Fedora wohl aus irgendeinem Grund erstmal den Cache bis 40% (der Standardwert) vollzuschaufeln und dann irgendwann auf den Datenträger zu schreiben. Naja, mit dem geänderten Kernelparameter traten zumindest bei mir keine Lags mehr auf.

via https://bbs.archlinux.org/viewtopic.php?pid=998740#p998740

Von einer Festplatte auf eine SSD umziehen…

Von einer normalen Festplatte auf eine SSD umzuziehen – das hört sich erstmal simpel an. Der Plan war: Image erstellen der ursprünglichen HDDD, Image auf die SSD wiederherstellen.
Solange beide Platten gleichgroß sind mag das auch kein Problem darstellen. In meinem Fall war die SSD jedoch deutlich kleiner (256 GB) als die normale Festplatte (1 TB). Vom belegten Platz hätte die Kopieraktion auch ohne Probleme funktionieren können, jedoch monierte Clonezilla die Größe der Partitionen. Die Nutzdatenpartition war mit mehr als 900GB deutlich zu groß. Im Prinzip hätte hier eine einfache Verkleingerung gereicht, aber die sieht CloneZilla wohl nicht vor.
Der Workaround: Verkleinerung der Partition mit GParted, bis diese auf die SSD passt. Anschließend konnte Clonezilla ein Vollimage der Platte erstellen. Für die Wiederherstelllung auf die SSD habe ich dann statt “restoredisk” “restoreparts” gewählt, da man so die zu wiederherstellenden Partitionen auswählen kann. So umgeht man das Problem, dass CloneZilla meckert, die Zielplatte wäre zu klein um das Image der 1TB Platte zurückzuspielen.
Anschließend weigerte sich Fedora 19 zu starten: Der Bootvorgang stoppte bei Reached target basic system. Die Lösung war die Neuerstellung des initramfs mit dracut -f /boot/initramfs-3.10.10-200.fc19.x86_64.img.
Das nächste Problem war die SWAP-Partition. Aus irgendeinem Grund hatte sie eine neue UUID bekommen, wodurch die Patition nicht beim Start nicht eingebunden wurde. Die neue UUID muss dazu nur in der /etc/fstab geändert werden – und schon funktioniert auch das.
Als nächstes habe ich Verzeichnisse, welche oft beschrieben werden auf die normale Platte ausgelagert (Die normale Festplatte hat seinen neuen Platz an Stelle des DVD-Laufwerkes gefunden), um den Verschleis der SSD zu minimieren. Zum einen war das das komplette /home Verzeichnis (hier liegen fast nur Nutzdaten, welche ruhig auf einem langsameren Laufwerk liegen können) und zum anderen /tmp und /var. Damit das System die Verzeichnisse auch wiederfindet, müssen diese per Symlink zur neuen Position verlinkt werden. Wenn man /tmp verschoben hat, empfiehlt es sich die Initialisierung mit systemctl mask tmp.mount< zu deaktivieren. Ein weiterer Stolperstein sind die Symlinks unter /var. Hier sind einige Verzeichnisse untereinander verlinkt - diese Links sollte man hinterher auf Gültigkeit überprüfen.