Linux

WWAN / Mobile Broadband sorgt für Segfault in NetworkManager

Der Titel sagt schon alles: Heute mit dem Laptop draußen gewesen und auf einmal geht die SIM Karte im Laptop nichtmehr. Dmesg spuckte Folgendes aus:

[   58.654350] NetworkManager[327]: segfault at 8 ip 00000000004a0b52 sp 00007fff6271b5c0 error 4 in NetworkManager[400000+23e000]
[   60.537051] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready

Die Lösung war nach längerer Suche tatsächlich sehr einfach: Nachdem man IPv6 für diese Verbindung deaktiviert, sollte alles wie gehabt funktionieren. Es gibt wohl schon einen Fix ab NetworkManager 1.8.1 aber der ist im Arch Repo wohl noch nicht drin.

Quelle / Bugreport

Chrome und 2560×1440 WQHD unter Linux

Irgendwie sah bei mir unter Chrome die Schrift bei meinem neuen Monitor mit WQHD Auflösung (2560×1440) sehr verwaschen aus. Das Problem trat allerdings nur unter Linux auf und evtl. auch nur im Multimonitorbetrieb. Eventuell liegt das am proprietären Nvidia Treiber den ich nutze, habe ich jetzt aber alles nicht ausgiebig getestet. In jedem Fall hier die Lösung:

Bei mir schaut der Befehl um Chrome zu starten wie folgt aus:

chromium --force-device-scale-factor=0.75

Um das richtige Verhältnis rauszufinden muss man ein wenig rechnen. Die erste Zeile ist die aktuelle Pixelbreite des Monitors geteilt durch die FullHD Pixelbreite. Diese Teilen wir durch eins und haben das Verhältnis, welches wir an den Chrome Startbefehl anhängen.

2560 / 1920 = 1,3333333....
1 / 1.3333 = 0,75...

Anschließend Chrome mit dem obigen Befehl starten, und die Schriften sollten wieder knackig scharf und korrekt skaliert sein mit 2560×1440 WQHD. Warum hier Chrome so rumzickt weiß ich nicht, allerdings hat mir das Archlinux Wiki auf die Sprünge geholfen. Ich vermute, dass Chrome irgendwie von FullHD ausgeht und die WQHD Auflösung nicht korrekt erkennt. Eigentlich sollte der Device Scale Factor ja immer 1 sein aber nunja.

Hier aber noch 2 Bilder zum vorher / nachher Vergleich.

Den Monitor, einen Dell U2515H, kann ich übrigens uneingeschränkt empfehlen! Da mir 4K im Alltag noch zu unpraktisch ist und 27″ zu groß, waren 25″ und 2560×1440 WQHD ideal. Farbwiedergabe, Schwarzwert, etc. sind auch top und mit ca. 300€ ist er sogar günstiger als ich es bei der Leistung erwartet hätte.

php.ini Einstellungen für Uploads bei WordPress

Da mich häufiger bei frischen Installationen von Ubuntu Servern oder auch diversen Hostern schon häufiger diese Fehlermeldung:

„Are you sure you want to do this? Please try again“

Oder auch diverse Timeouts begrüßt haben, hier für mich zur Erinnerung und für alle anderen vielleicht auch PHP Settings, die für jede Standardinstallation bei WordPress gut funktionieren sollten. Ausahmen gibts natürlich, aber so macht WordPress in Zeiten immer größerer Template Files oder Plugins zumindest keine Probleme.

Einfach folgende Einstellungen in eurer php.ini überschreiben:

max_execution_time = 180
max_input_time = 600
post_max_size = 128M
upload_max_filesize = 256M

Damit sollten Timeouts beim Theme hochladen erstmal der Vergangenheit angehören.

Grund für die immer größeren Theme Dateien, sind gerade bei Premiumtemplates wie z.B. bei Themeforest, gebundelte Pluginfiles. Da kommen schnell mal 10-20mb zusammen, auch wenn das eigentliche Theme nur 2mb hat.

OpenELEC auf Raspberry Pi 2: Anleitung & Test

Nach langem Warten gab es endlich den Raspberry Pi 2 zu kaufen. Ich habe ihn direkt am Erscheinungstag bestellt und am Tag der Anlieferung gab es bereits eine lauffähige Version von OpenELEC.

Wer OpenElec noch nicht kennt, der kann sich genauere Infos zum MediaCenter auf deren Seite ansehen. Kurzgesagt ist es eine MediaCenter Distribution, die auf dem Pi (und anderen Systemen) lauffähig ist und auf Kodi (ehemals XBMC) basiert. Durch starke Optimierung lief OpenElec schon auf dem Pi erster Generation erstaunlich flüssig. Ab und an gab es im Menu zwar mal kleine Ruckler und die Indexierung der Medien bei der Datenbankerstellung dauerte auch etwas, aber das Wichtigste funktionierte einwandfrei und ohne Hakler: Videos in FullHD schauen.

Deshalb war ich insbesondere gespannt wie sich der neue Raspberry Pi 2 mit OpenElec schlägt. Kaufen könnt ihr den neuen PI beispielsweise hier.

Installation

Die Installation war gewohnt einfach. Einfach das richtige Image (ARMv7) von der Downloadseite runterladen und unter Linux per DD auf die SD Karte ziehen (detaillierte Anleitung).

Es funktioniert übrigens NICHT, einfach die alte SD Karte auf eine microSD zu klonen! Die Images für den Raspberry 1 und Raspberry 2 sind unterschiedlich und deshalb nicht direkt kompatibel.

OpenElec Einstellungen exportieren & importieren

Sämtliche Daten die ich über OpenElec wiedergebe liegen bei mir auf meinem kleinen Homeserver. Da die Einrichtung aller Einstellungen und Dienste doch recht nervig ist, habe ich bei der Gelegenheit auch direkt mal den Export ausprobieren. Dabei werden sämtliche Einstellungen, Datenbank, etc. in eine Datei exportiert. Diese kann man anschließend auf die neue SD Karte kopieren. Man geht einfach in die OpenElec Systemeinstellungen und erstellt zunächst ein Backup. Dieses zieht man anschließend auf die neue microSD Karte und zwar idealerweise in den gleichen Ordner, in dem es sich auf der alten SD Karte befand. Dann einfach die neue microSD im RaspPi2 booten, in den Optionen auf wiederherstellen gehen und das passende Backup auswählen.

Das Wiederherstellen dauert ein paar Minuten und ist erst nach einem Reboot vollständig. OpenElec meldet sich aber wenn es neugestartet werden will, also einfach den Anweisungen folgen. Beim Neustart sollten dann nach ein wenige Wartezeit alle Einstellungen, Themes, Datenbank etc. wieder da sein.

Performance von OpenElec auf dem RasPi2

Nun aber zum Wichtigsten: Der Performance. Diese ist im Vergleich zum Pi 1 auf dem Papier enorm gewachsen und OpenElec läuft nun wie geschmiert. Absolut keine Ruckler mehr im Menu und man kann nun problemlos auch aufwendigere Themes verwenden. Auch das Starten von Videos oder Suchen von Untertiteln geht nun eine ganze Spur flotter vonstatten.

Insgesamt lohnt sich das Update meiner Meinung nach enorm. Der Preis ist quasi gleich geblieben und man bekommt dafür eine extrem gesteigerte Leistung, sowohl auf dem Papier als auch in der Praxis.

Falls ihr den Pi 2 kaufen wollt, könnt ihr ihn hier bestellen.

NFS Update verhindert Suspend / Hibernate

Seit einigen Tagen funktionierte Suspend2Ram auf meiner Workstation nichtmehr. Da ich dummerweise zum gleichen Zeitpunkt eine neue Grafikkarte eingebaut habe, dachte ich hier liegt der Fehler.

Weit gefehlt, der Übeltäter war das Paket nfs-utils-1.3.2. Unten der dmesg Output der mich auf die richtige Spur brachte. Es gibt auch schon mehrere Bugreports bei diversen Distributionen. Auch Debian ist betroffen. Da ich persönlich kein Hibernate benutze, kann ich hier nur vom kaputten Suspend berichten. Die Lösung dürfte aber in beiden Fällen funktionieren und lautet: NFS Downgrade.

Die Lösung: NFS Downgrade

Da NFS der Übeltäter ist und Suspend bei mir bisher einwandfrei funktionierte, war ein Downgrade die einfachste Lösung. Dummerweise habe ich meinen Package Cache vor einigen Tagen erst geleert. Die Lösung unter Archlinux lautet Arch Rollback Machine. Dort finden sich Mirrors, die eine Spiegelung älterer Builds vorhalten. Ich hab einfach die Version nfs-utils-1.3.1 genommen und Suspend funktioniert wieder einwandfrei.

Pro-Tipp: Bis zum nächsten NFS Update mit einem Fix sollte man an der Stelle noch das Paket nfs-utils in der pacman.conf unter „Ignored Packages“ eintragen.

nfs4.1-svc hangs and breaks suspend:
[ 242.963957] PM: Syncing filesystems ... done.
[ 243.535088] PM: Preparing system for mem sleep
[ 243.730776] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 243.733034] Freezing remaining freezable tasks ... 
[ 263.736906] Freezing of tasks failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 263.737154] nfsv4.1-svc D ffff8800a0fd7d78 0 951 2 0x00000000
[ 263.737165] ffff8800a0fd7d78 ffff8800a0f66d50 0000000000013f00 ffff8800a0fd7fd8
[ 263.737174] 0000000000013f00 ffff88012af86d50 ffff8800a0f66d50 ffffffffa0298aa0
[ 263.737181] ffff8800a0d70000 ffffffffa0298aa0 0000000000000000 ffff8800a0fd7cd8
[ 263.737188] Call Trace:
[ 263.737239] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
[ 263.737262] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
[ 263.737282] [] ? rpc_release_resources_task+0x34/0x40 [sunrpc]
[ 263.737301] [] ? __rpc_execute+0x2c8/0x4a0 [sunrpc]
[ 263.737313] [] ? lock_timer_base.isra.37+0x2b/0x50
[ 263.737323] [] schedule+0x29/0x70
[ 263.737332] [] schedule_timeout+0x11b/0x250
[ 263.737340] [] ? migrate_timer_list+0xd0/0xd0
[ 263.737362] [] nfs41_callback_svc+0x1aa/0x1e0 [nfsv4]
[ 263.737369] [] ? wait_woken+0x90/0x90
[ 263.737387] [] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
[ 263.737396] [] kthread+0xd8/0xf0
[ 263.737404] [] ? kthread_create_on_node+0x1c0/0x1c0
[ 263.737412] [] ret_from_fork+0x58/0x90
[ 263.737419] [] ? kthread_create_on_node+0x1c0/0x1c0

Bilder verlustfrei komprimieren unter Linux

Viele Webworker dürften das Problem mit Bildern kennen. Irgendwie dauert die wenn möglich verlustfreie Komprimierung und das entfernen der Exif Daten dann doch länger oder kommt zu kurz. Ich habe mir jetzt vorgenommen künftig noch mehr darauf zu achten und bin auf die idiotensichere Lösung Trimage gestoßen.

Das Tool ist Open Source, für allerlei Plattformen verfügbar und kann genau eine Sache: Bilder im Format JPG oder PNG lossless zu komprimieren und auf Wunsch von sämtlichen Metadaten befreien.

Die Oberfläche ist bewusst simpel gehalten um ideal in den persönlichen Workflow eingebaut werden zu können. Außerdem kann das Tool auch prima übers Terminal angesteuert werden. Unterstützt werden JPGs und PNGs. Mehr brauche ich in 95% der Fälle nicht, insofern finde ich den KISS ansatz perfekt!

Webbasiert JPGs/PNGs verlustfrei komprimieren

Alternativ gibt es einige webbasierte Tool, wenn man keine Lust hat etwas zu installieren oder an fremden Rechnern sitzt. Mir am besten gefallen hat dabei https://compressor.io/.

Ist auch total fancy mit hipper .io URL…

Terminfo & rxvt-unicode-256colors Probleme

In letzter Zeit hatte ich ab und an Probleme mit der Term Variable und Verbindungen per SSH auf diverse Systeme. Die Fehlermeldung lautet immer: 

terminal open failed: missing or unsuitable terminal: rxvt-unicode-256color

Scheint also ein Problem mit rxvt-unicode-256color zu sein. Merkwürdigerweise trat es nicht bei allen Distributionen auf. Von Archlinux zu Archlinux gab es in der Regel keine Probleme. Nur mein Homeserver wollte irgendwie nicht. Dort war das Problem allerdings einfach zu lösen. Einfach per Pacman das Paket rxvt-unicode-terminfo installieren und fertig.

Unter CentOS und Ubuntu gibt es dieses Paket leider nicht. Dort ist die Lösung aber auch einfach: Man kopiert sich einfach die Terminfo Datei rüber.

Also von einem System mit vorhandener (passender) Terminfo Datei per SCP rüber auf den Server (bzw. Rechner mit auftretendem Problem):

scp /usr/share/terminfo/r/rxvt-unicode-256color host:/home/user

Und anschließend an die richtige Stelle kopieren. Bei CentOS und Archlinux ist es der gleiche Pfad unter /usr/share also einfach dahin. Bei Ubuntu schaut man da aktuell ins Leere. Ein kurzes Find hat es dann aber aufgelöst: Die Terminfo Dateien befinden sich unter /lib/terminfo/

Bei einer frischen Installation von Ubuntu Server 14.01-LTS trat das Problem übrigens nicht auf. Aber falls die oben genannte Fehlermeldung bei euren Systemen auftreten sollte, wisst ihr nun Bescheid.

Urxvt öffnet keine URLs nach Update auf Fedora 18

Nachdem ich das Update von Fedora 17 auf 18 gefahren hab, ging der URL Opener von urxvt (rxvt-unicode) bei mir plötzlich nichtmehr. Kurzes googlen hat mich nicht wirklich weitergebracht und wegen Zeitmangel hab ich mich irgendwann auch nicht weiter darum gekümmert.

Eben hab ich mich aber nochmal kurz drangesetzt und eine kurze Nachfrage in meinem Lieblings IRC Channel #woot brachte dank andi folgendes aus dem Urxvt Changelog ans Licht:

- INCOMPATIBLE CHANGE: renamed urlLauncher resource to url-launcher.

Das Problem ist also leicht und schnell gelöst, einmal in der .Xresources urlLauncher durch url-launcher ersetzen und fertig. Meine .Xresources sieht damit jetzt so aus: Click

Steam & Counter Strike:Source auf Fedora 18

Vor einiger Zeit hatte ich mal den nativen Beta Client von Steam für Linux auf meiner Fedora Workstation ausprobiert. Man hat leider gemerkt, dass er noch sehr Beta war. Häufige Abstürze, viele Glitches und Spiele hab ich mir deshalb gar nicht installiert (damals gab es auch noch keine wirklich große Auswahl).

Nun wurde vor kurzem der finale Steam Client für Linux veröffentlicht und auch ein paar Spiele aus meiner Library waren auch schon verfügbar. Insbesondere Counter Strike: Source nativ unter Linux war für mich interessant. Außerdem hatte ich mir im letzten Sale aus Spaß Serious Sam 3 gekauft für ein paar Euro gekauft, da es nativ unterstützt wird. Hab es allerdings noch nie gespielt.

Die Steam Installation unter Fedora 18

Die Installation verlief soweit komplett problemlos. Ein Fedora Dev hat ein Repository und fertige RPMs erstellt und oflegt dieses. Ich halte es für empfehlenswert direkt das Repo einzubinden, damit zukünftige Updates direkt über YUM eingespielt werden. Also einfach die steam.repo hier runterladen und nach /etc/yum.repos.d/ kopieren.

Für die Faulen unter euch tuts auch dieser Befehl als root (oder sudo vorne dranhängen):

$ cd /etc/yum.repos.d/ && wget http://spot.fedorapeople.org/steam/steam.repo

nun könnt ihr mit folgendem Befehl Steam per YUM installieren und die passenden Abhängigkeiten werden gleich mit draufgebügelt:

yum install steam

Beim ersten Start werden dann nochmal ca 200mb runtergeladen und der Client auf den neusten Stand gebracht. Anschließend solltet ihr euch einloggen können. Unter Library sollten nun alle Spiele angezeigt werden, die nativ unter Linux installiert werden können.

Ich habe erstmal direkt Counter-Strike: Source installiert. Je nach Schnelligkeit eurer Leitung dauert dies ein wenig länger. Auch wenn CS:S seit Jahren nichtmehr gespielt habe, früher war ich recht aktiv und extrem genervt, immer Windows booten zu müssen. Eigentlich war CS:S jahrelang der Hauptgrund einer Windows Installation für mich. Deshalb war ich doch sehr gespannt.

Der erste Start spuckte mir dann auch direkt folgende Fehlermeldung aus:

Es fehlt also augenscheinlich die S3TC Unterstützung auf meinem System.

Fehlende S3TC Unterstützung bei CS:S

Steam Linux - s3tc FehlerNach kurzem googlen fand ich heraus welche Pakete diese enthalten. Mit folgendem Befehl kann man sie installieren:

yum install libtxc_dxtn.i686 libtxc_dxtn.x86_64

Anschließend sollte Counter-Strike Source problemlos laufen.

Performance: freier Treiber vs. Catalyst

Ich hatte allerdings aus diversen Gründen den freien Treiber drauf. Primär brauche ich die Power vom Catalyst nicht. Hier hat man dann allerdings direkt gesehen, dass die freien Treiber noch einiges na Arbeiten im Performancebereich benötigen. Counter-Strike Source lief mit ziemlich grandiosen 8-10 Fps, auch mit komplett nach unten geschraubten Details. Also doch den proprietären Catalyst Treiber mal installiert mit:

yum install akmod-catalyst xorg-x11-drv-catalyst

Eine ausführlichere Anleitung zur Catalyst Installation hab ich vor einiger Zeit mal verfasst. Bei mir gings nun aber unter Fedora 18 problemlos nur mit oberem Befehl. Auch Probleme mit Suspend to RAM gab es keine mehr.

Fehlermeldung: veralteter Grafikkartentreiber

Nun wieder CS:S gestartet und siehe da: eine Fehlermeldung bzgl. veraltetem Grafikkartentreiber:

Allerdings auch halb so wild, folgende Pakete zum Catalyst dazuinstallieren und alles sollte gehen:

yum install xorg-x11-drv-catalyst-devel.i686 xorg-x11-drv-catalyst-libs.i686

Und nun siehe da: flotte 300 Fps. Ich habe dann auch mal ein paar Ründchen gespielt und es war absolut kein Unterschied zur Windows Version erkennbar. Alles funktionierte einwandfrei, nur die Schriften waren teilweise schlechter lesbar.

Fazit zu Steam bzw. Counter Strike: Source auf Fedora 18

Ich finds super, läuft bis auf die kleineren Fehler doch erstaunlich gut und problemlos. Leider zocke ich quasi gar nicht mehr aber nunja, sobald Half Life 2 (hoffentlich recht bald) nativ für Linux veröffentlicht wird, werde ich das wohl auf jeden Fall mal wieder durchspielen :-)

Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that’s *your* issue.

Link

— Linus Torvalds zu Secure Boot Unterstützern

1 2  Scroll to top