Wenn das WLAN mal nicht läuft – das richtige Kernelmodul finden

Kürzlich erschien die zweite Betaversion von Ubuntu 11.04 “Natty Narwal”. Also USB-Stick gepackt, Image draufgespielt und ausprobiert. Es kam nur der Standard-Desktop, also kein Unity, weil kein 3D. Das war zu erwarten, denn der vorinstallierte freie Nvidia-Treiber kann für meine Karte kein 3D. Was mich aber verwunderte war, dass mein D-Link DWA 140 WLAN Stick (Ralink-Chipsatz) nicht ging, der Network Manager zeigte nur ein “firmware missing” an. Ich installierte den Natty-Kernel 2.6.38 vom Mainline-PPA unter Maverick und stellte fest, dass das Problem dort auch auftrat. Ein Kernel-Problem also. Ich googelte und stellte fest, dass ich nicht allein war. Da fiel mir ein Artikel aus dem Ubuntu-User-Magazin ein, indem verschiedene WLAN-Sticks auf Linux-Tauglichkeit geprüft wurden. Bei einem stand der Autor vor demselben Problem; es wurden falsche Kernelmodule geladen.

Normalerweise lädt Ubuntu beim Booten oder beim Anschluss des Geräts das dafür passende Kernelmodul. Danach kann man mit dem Gerät schon loslegen. In diesem Fall aber (und offenbar in vielen anderen Fällen auch) lud Ubuntu zusätzlich zum richtigen Modul noch einige falsche Module für ähnliche Chipsätze. Dies sorgt allerdings dafür, dass das System nun nicht weiß, welches Modul die Kontrolle über den WLAN-Stick haben soll und deswegen kam keine Verbindung zustande.

Um das Problem zu lösen, sollte man sich ersteinmal alle geladenen WLAN-Module anzeigen lassen. Da mein Stick einen Ralink-Chipsatz benutzt, lautet der Befehl

$ lsmod | grep rt

Der Hersteller des Sticks bzw. der WLAN-Karte ist unwichtig, wichtig ist nur der Chipsatz (z.B Atheros, Broadcom oder eben Ralink). Wer einen anderen Chipsatz als ich hat, muss in Erfahrung bringen, welches Präfix die entsprechenden Module haben (das ubuntuusers-Wiki ist eine gute Anlaufstelle). Die Ausgabe schaut bei mir folgendermaßen aus:

parport_pc 36959 0
parport 46458 3 parport_pc,ppdev,lp
rt2870sta 450556 0
rt2800usb 18235 0
rt2800lib 45181 1 rt2800usb
crc_ccitt 12667 2 rt2870sta,rt2800lib
rt2x00usb 20330 1 rt2800usb
rt2x00lib 49235 3 rt2800usb,rt2800lib,rt2x00usb
mac80211 294370 3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211 178528 2 rt2x00lib,mac80211

Hier sind nur die Module interessant, die mit “rt” anfangen. Diese werden jetzt allesamt entladen:

$ sudo modprobe -rf rt2870sta rt2800usb rt2800lib rt2x00usb rt2x00lib

Jetzt kommt das Ausprobieren. Man muss jetzt probieren, welches Modul das richtige ist. Also mit

$ sudo modprobe <modulname>

das Modul laden, ausprobieren, ob das WLAN läuft und wenn nicht, das Modul mit

$ sudo modprobe -rf <modulname>

wieder entladen. Glücklicherweise wusste ich schon von meiner Maverick-Installation, dass das Modul rt2870sta das richtige ist. Nach dem Laden dieses Moduls funktionierte auch das WLAN wieder.

Eine Kleinigkeit wäre da noch: Damit man das Prozedere nicht bei jedem Neustart wiederholen muss, sollte man die falschen Module blacklisten. In meinen Fall reicht es, folgende Zeilen zur Datei /etc/modprobe.d/blacklist.conf hinzuzufügen:

blacklist rt2800usb
blacklist rt2800lib
blacklist rt2x00usb
blacklist rt2x00lib

Es freut mich zwar, dass das Problem so einfach zu lösen war, aber Anfänger werden dadurch abgeschreckt. Wegen der neuen Unity-Oberfläche wird Natty sowieso ein heikles Release werden. Hoffen wir, dass es nicht das Vista der Ubuntu-Versionen wird

Update 2.Juni 2011:

Wie aus den von mir gemeldeten Launchpad-Bug hervorgeht, hatte ich mit meiner Einschätzung nicht ganz recht. Alle Module, die beim Hochfahren/Einstecken des DWA 140 geladen werden, sind richtige Treiber, die für den Stick geeignet sind. rt2870sta ist ein alter Staging-Treiber, der nicht offiziell zum Kernel gehört, nicht wirklich gepflegt wird und der irgendwann mal verschwinden wird. Der neue Treiber der ihn ersetzen soll ist dieser rt2800usb, welcher auch von den Wifi-Schnittstellen des Kernels besser Gebrauch macht. Die in Natty enthaltene Version dieses Treibers funktioniert aber mit meinem Stick noch nicht, weil linux-firmware zu alt ist. rt2800usb wird also geladen, kann aber nicht arbeiten, daraufhin wird rt2870sta geladen, welcher aber auch nicht arbeiten kann, weil rt2800usb nicht entladen wurde.

Eine bessere Alternative zu dem oben vorgestellten Lösungsvorschlag ist die Benutzung von rt2800usb mit aktueller Firmware, weil dieser Treiber besser gepflegt wird. Zuerst muss rt2870sta geblacklistet werden:

 
$ echo 'blacklist rt2870sta' | sudo tee -a /etc/modprobe.d/blacklist.conf

Das Blacklisting der anderen rt-Module muss natürlich rückgängig gemacht werden. Anschließend lädt man sich die neueste Version von linux-firmware herunter und entpackt das Archiv. Einzig die Datei rt2870.bin ist interessant. Nun wird die alte Firmware umbenannt und die neue installiert:

$ cd <entpackter Ordner>
$ sudo mv /lib/firmware/rt2870.bin /lib/firmware/rt2870.bin.old
$ sudo cp rt2870.bin /lib/firmware/rt2870.bin

Nach einem Neustart sollte das drahtlose Netzwerk wieder funktionieren. Am besten, man testet beide Treiber und nutzt dann den, welcher besser läuft.

Über die Balance von Stabilität und Aktualität in Ubuntu

Die Frage, ob stabile, aber ältere oder neuere, aber instabilere Pakete ausgeliefert werden sollen, beantwortet jede Distribution unterschiedlich. Bei Debian Stable kommt die Distribution raus, wenn sie fertig ist, und dann werden nur noch Bugfixes eingespielt, und das jahrelang. Bei Arch Linux hingegen wird auf einen Rolling-Release-Zyklus gesetzt, die Pakete werden ständig auf die jeweils aktuellste Version gehoben.

Ubuntu hingegen hat bisher einen Mittelweg praktiziert: Alle sechs Monate kommt eine neue Version raus, die zugehörigen Paketquellen werden eingefroren und wie bei Debian nur noch mit Bugfixes und Sicherheitsupdates versorgt, neuere Major-Releases der Programme gibt es erst in der nächsten Version. Bisher hat dies meiner Meinung nach recht gut funktioniert, wer tortzdem aktuellere Pakete wollte, der konnte Fremquellen benutzen.

Aber mittlerweile läuft da einiges schief. Beim aktuellen Release (das auch noch eine LTS ist) wurde etwa das Videoschnittprogramm PiTiVi integriert, dass sich immernoch in Entwicklung befindet und einige notwendige Features nicht beherrscht, teilweise noch viele Bugs hat. Hier gäbe es mit OpenShot eine ausgereiftere und stabilere Alternative. Dann wird KMS sowie Nouveau verwendet, ersteres führt bei mir zu einer langsamen Performace bei 3D, nach der Deaktivierung funzt die Performance wieder, dafür funktioniert GDM nicht mehr richtig (Blackscreen). Korrekterweise kommt Kernel 2.6.32 zum Einsatz, dafür werden Treiber und Features aus 2.6.33 zurückportiert. GIMP, ein erprobtes und zuverlässiges Programm, wird einfach entfernt (aus der Standardinstallation). Seit Lucid befindet sich auch Chromium in den Quellen, ein durchaus guter und vernünftiger Browser, leider im Beta-Status, die Version in den Paketquellen wird auch nicht geupdatet.

Jetzt lese ich hier bei OMG! Ubuntu!, dass F-Spot in 10.10 entfernt und stattdessen Shotwell eingesetzt werden soll. Über Shotwell habe ich schon einmal geschrieben, mir persönlich hat die Software gefallen. Allerdings ist die Software in einem noch frühen Stadium, so werden z.B keine PNGs unterstützt und es nicht möglich, Tags in die Metadaten zu schreiben, wodurch ein Wechsel zu einem anderen Programm mehr als schwierig wird. Gegen F-Spot spricht eigentlich nur die langsame Performance, was aber in Lucid bei mir besser geworden ist – könnte eine Nebenwirkung des Grafikkarten-Problems sein.

Ich bin der Meinung, dass man diese Strategie überdenken sollte: Ein Rolling-Release-Zyklus wäre wohl nicht so ideal, da Ubuntu ja halbwegs stabil und für den Endanwender geeignet sein will, und eine Debian-ähnliche Strategie würde die Distribution nicht interessant genug machen. Grundsätzlich finde ich die 6-Monate-Strategie gut, aber dann sollte man auch wirklich stabile Versionen in die Paketquellen legen und innerhalb der Support-Zeitraums aktualisieren, Aber Beta-Versionen in eine LTS zu integrieren und dann 3 Jahre lang diese Beta zu benutzen, ist quatsch. Die Entwickler des Programms werden wohl kaum diese Beta mit Sicherheitsupdates versorgen, wenn es schon eine neue Beta, RC oder vielleicht schon eine Final gibt.

Warum nicht die Backports besser ausnutzen? In die normalen Quellen kommt die jeweils aktuelle finale Version, während in den Backports die neuesten Versionen von beliebten Programmen bereitgehalten werden (so wollen viele Nutzer eine neue Firefox-Version benutzen, aber nicht aufs nächste Release warten). So könnte der Nutzer das Stabilitäts-Aktualitäts-Mischungsverhältnis ein wenig selbst justieren.

Performance der ATI X1650 unter Lucid auf Karmic-Niveau bringen

Im letzten Artikel schrieb ich ja schon, dass ich aktuell – wieder – Probleme mit meiner ATI Grafikkarte, einer Radeon X1650, unter Lucid habe. Grund dafür, so habe ich herausgefunden, ist offenbar KMS, also Kernel Mode Setting. Dadurch kann die Grafikkarte schon beim Booten eingestellt werden, was auch diesen schönen Plymouth-Screen in hoher Auflösung ermöglicht. Leider sorgt dies für eine niedrigere Performance bei meiner Grafik.

Wer wie ich mit Problemen zu kämpfen hat, der sollte KMS vielleicht auch mal probeweise abschalten. Wenn ihr den radeon-Treiber benutzt, dann müsst ihr einfach die Datei /etc/modprobe.d/radeon-kms.conf bearbeiten.

$ gksudo gedit /etc/modprobe.d/radeon-kms.conf

Dort die Zeile

options radeon modeset=1

durch

options radeon modeset=0

ersetzen. Dann muss noch das Initial Ram Filesystem neu erstellt werden:

$ sudo update-initramfs -u

Jetzt einfach mal rebooten und dann am besten gleich ein 3D-Spiel, z.B einen Shooter, starten, um die Performance zu testen. Bei mir läuft nun alles auf Karmic-Niveau. Leider gibt es einen Haken bei der Sache: GDM startet mit einem Blackscreen, man muss den Bildschirm ein- und wieder ausschalten, um ein Bild zu kriegen. Weiterhin läuft nun Plymouth in niedriger Auflösung, was natürlich weniger schön aussieht. So hat man die Wahl zwischem schicken Bootscreen und schneller 3D-Grafik…

Edit: Der Trick mit dem Bildschirm funktioniert nur sporadisch, daher hab ich KMS wieder aktiviert. Dann halt kein 3D, lieber stabiles einloggen.

Würgaround: Panel-Schatten mit Metacity auch nach Neustart anzeigen

Momentan habe ich – schon wieder – Probleme mit meinem ATI-Grafikkartentreiber unter Lucid, was nach sich zieht, dass Compiz ziemlich träge und langsam ist. Deswegen habe ich ihn vorerst abgeschaltet. Da ich aber nicht ganz ohne Compositing dastehen möchte, u.a deshalb, weil ich weiterhin Docky nutzen möchte, habe ich die Compositing Funktion von Metacity aktiviert. Kann eigentlich nicht mehr als Schatten unter den Fenstern anzeigen. Aber genau hier gibt es einen Bug.

Schaltet man die Funktion über GConf ein, so werden die Schatten unter Fenster und unter dem Panel angezeigt. Rebootet man nun (oder meldet sich neu an), so haben die Fenster weiterhin Schatten, das Panel jedoch nicht. Jemanden wie mich, der immer einen schönen Desktop braucht, stört sowas natürlich. Die einzige Möglichkeit, das zu fixen, wäre, das Compositing nach jedem Neustart aus- und wieder anzuschalten. Daher ein kleines Skript, quick&dirty:

#!/bin/sh
sleep 10
gconftool-2 -s --type bool /apps/metacity/general/compositing_manager false
gconftool-2 -s --type bool /apps/metacity/general/compositing_manager true

Nun muss man das Skript nur noch ausführbar machen, irgendwo hinschmeisen, wo es nicht stört, und mithilfe von System->Einstellungen->Startprogramme festlegen, dass es bei jedem Login starten soll.

Jetzt frage ich mich: Gibt es eine saubere Methode, als das Skript einfach 10 Sekunden schlafen zu lassen? Oder gibt es sogar einen “echten” Fix für Metacity, der das Problem behebt?

Performance von ATI-Karten unter Ubuntu erhöhen

Linux, ATI und Treiber. Diese drei Worte reichen. um mich mit den Zähnen knirschen zu lassen. Wer ebenfalls Besitzer einer ATI-Grafikkarte und zugleich Linux-Benutzer ist weiß, warum.

Warum? Nun, der Grund liegt darin, dass ATI nunmal keine gescheiten Treiber für Linux anbietet. Es gibt zwar eine Linux-Version des Catalyst-Treibers (fglrx), doch die läuft nur mit neueren Karten, während sich Besitzer älterer Modelle mit den freien Treibern (radeon und RadeonHD) begnügen müssen. Die hinken den Original-Treiben natürlich deutlich hinterher. Wer auf die Idee kommt, damit Spiele spielen zu wollen: Vergisst es!

Glücklicherweise schreitet die Entwicklung relativ schnell voran und deshalb lohnt es sich, mal einen Blick auf den Unstable-Zweig der freien Treiber zu werfen und ihn auszuprobieren, denn die Treiber laufen deutlich besser, als die stabilen Versionen aus den Ubuntu-Paketquellen.

Um auf den Unstable-Zweig zu aktualisieren fügt man sich ein PPA in seine sources.list hinzu:

deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu jaunty main

Dann wird noch der passende GnuPG-Key benötigt:

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8844C542

Nach einem

$ sudo apt-get update && sudo apt-get upgrade

werden die neuen Treiber installiert, u.a wird aber auch X.org ansich aktualisiert. Man sollte sich gut überlegen ob man dies möchte, da, abgesehen von irgendwelche Bugs der instabilen Treiber,  man sich so auch das Update auf Karmic verbauen kann.

Wie oben angesprochen, gibt es zwei freie Treiber für aktuelle ATI-Karten der Radeon-Serie: einmal radeon sowie RadeonHD welche sich in dem Paket xserver-xorg-radeon bzw xserver-xorg-radeonhd befinden. Der Unterschied besteht darin, dass sich RadeonHD auf Karten ab der X1550 konzentriert, während radeon auch Unterstützung für ältere Karten bietet. Am besten, man probiert beide Treiber aus und nimmt den, der besser funktioniert. RadeonHD schleudert mich kommentarlos auf die Konsole, radeon allerdings ermöglicht mir zumindest Compiz und mit der Unstable-Version endlich auch das Spielen (!) von Warsow, UrbanTerror und Sauerbraten auf mittleren Einstellungen. Unter Windows ist die Performance zwar wesentlich besser, aber immerhin sind die Unstable-Treiber schonmal ein Fortschritt.

Icy installiert ältere Paketversionen als Cydia

Da hab ich mich im letzten Post noch gefreut, wie toll, hübsch, schnell, benutzerfreundlich usw Icy ist, da begegnet mir schon der erste Bug. Man schaue sich diese beiden Screenshots an:

Na, was fällt auf? Die Versionsnummer vom Paket MobileTerminal ist anders. Bei Icy lautet sie 316s-7, bei Cydia 364-9, letztere ist also neuer. Blöd nur, dass 316s-7 nicht unter iPhone OS 3.0 funktioniert – installiert man MobileTerminal also über Icy, stürzt es kommentarlos ab. Öffnet man danach Cydia, bietet es Version 364-9 als Update an. Nach dem Update funktioniert auch MobileTerminal wieder. Blöd nur für Leute, die ausschließlich Icy nutzen und Cydia nicht installiert haben, denn Cydia lässt sich nicht nach einer Installation über Icy starten – anscheinend installiert Icy auch hier eine ältere Version, die nicht unter iPhone OS 3.0 läuft. Bei anderen Paketen, wie dem Five Icon Dock, welches es erlaubt fünf statt vier Icons im Dock unterzubringen, ist es diesselbe Leier..

Das ganze wundert mich ein wenig. Entweder liest Icy die Paketquellen nicht richtig aus und installiert so alte Versionen, oder einer von beiden dreht irgendwie ein eigenes Ding und nutzt nicht die von APT vorgegebene sources.list. Deshalb hab ich Icy vorerst von meinem iPod touch verbannt und nutze jetzt wieder Cydia – auch wenn es langsam ist – es funktioniert nämlich. Und das ist bei einem Paketmanager das wichtigste.

[Fixed!] Winzige Schaltflächen im IE8 RC1 bei aktiviertem Visual Style (XP)

Im IE8 RC1 werden mit aktivierten Visual Styles bei jeder Webseite die Schaltflächen so verkleinert, dass man den Text nicht mehr entziffern kann. Schalte ich die Visual Styles aus(Windows Classic Theme), werden die Schaltflächen wieder normal angezeigt. Im IE selbst existiert zwar eine Option, visuelle Stile für Schaltflächen nicht zu verwenden, aber das ist mehr ein Workaround. Ich will meinen Visual Style auch auf Schaltflächen in Webseiten anwenden können(mir ist Design halt wichtig). Weiß da jemand eine Lösung? Oder ist das halt nur ein Bug der in der Final Version gefixt wird?

Visual Styles verwende ich übrigends im Zusammenhang mit dem UltraUXThemeMultiPatcher, damit Visual Styles angewandt werden können. Wenn ich eine VM aufsetze, dort den Patch und einen Style installiere, tritt der Bug im IE8 RC1 komischerweise nicht auf. Also muss es an einer Software liegen, die in meinen Hostsystem, nicht aber in meinen Gastsystem eingesetzt wird(das Gastsystem war frisch aufgesetzt). Ich habe QtTabBar im Verdacht, irgendwas Explorernahes. Das deaktivieren aller Addons im IE bringt jedoch auch nichts

Update:

Auch im IETester tritt der Fehler auf…

Fixed: Alles eine Frage des Styles

Ich hab eine Lösung für mein Problem gefunden . Es war alles eine Frage des verwendeten Visual Styles. Der Witz ist der, das bei einigen Styles das Problem auftritt und bei manchen nicht. Mit meinem Visual Style (WE Black) hab ich anscheinend einen erwischt, den der IE nicht mag. Razor2 mag er anscheinend auch nicht. Doch bei einem Leopard-Style, den ich noch irgendwo auf meiner Festplatte ausgegraben habe, trat das Problem nicht auf. Also schnell mal zu DeviantArt hin gesurft und mal ein paar Styles durchprobiert. Und siehe da: Auch mit dem Skin Nion 2 funktioniert es:

Mittlerweile ist der IE8 ja in der Final-Version erschienen. Also mach ich mich mal ans surfen.

Unlocker – Gesperrte Dateien freigeben

Unter Windows können Programme Dateien sperren, auf die sie gerade zugreifen. Dies ist auch sinnvoll, damit andere Programme oder man selbst die Dateien nicht löschen oder verschieben können und dadurch die Systemstabilität gefährdet wird oder Datenverlust entsteht. Manchmal kommt es vor, dass eine Datei gesperrt ist, obwohl sie es eigentlich gar nicht sein sollte. In einigen Fällen hilft nicht mal ein Neustart. Ich verwende hier immer das Tool Unlocker, dass sich in das Explorer-Kontextmenü integriert und mit dem man so Dateien freigeben kann.

Bitte verwendet das Tool mit Vorsicht und löscht/verschiebt nicht kopflos Dateien, dies kann böse enden, insbesondere wenn ihr Workarounds/Hacks durchführt.

[Download]

Den Drucker an den Drucker anschließen

Habe neulich mein Windows neu aufgesetzt und wollte meinen Canon Druckertreiber installieren. Dabei kam mir folgender Screen unter:

Den Drucker an den Drucker anschließen. Geht klar Boss.

No Keyboard detected. Press F1 to resume

Vor ein paar Stunden ist mir meine Tastatur kaputt gegangen. Ein paar Tasten wie D, Q, Shift und F3 gingen nicht. Ich hab dann natürlich gleich mit einer Ubuntu-Live-CD gebootet um das Problem einzukreisen, doch da hatte ich dieselben Probleme(Ja, Kabel steckt auch fest drin). Schließlich bin ich mir zu 100% sicher, dass meine mittlerweile 5 Jahre alte Tastatur einfach in Rente gehen will. Hol ich mir halt ne neue, kostet ja nicht viel und wahrscheinlich hab ich noch eine rumliegen. Also zieh ich die Tastatur raus und reboote. Mein BIOS präsentiert mir folgende Meldung:

Ihr kennt doch solche Witze, wo genau diese Fehlermeldung genannt wird? Ich hatte immer geglaubt niemand wäre zu doof so eine Fehlermeldung zu formulieren, aber mir ist es tatsächlich passiert. Ich habe ein ASUS-Mainboard mit Ami-BIOS.

Edit: Mittlerweile habe ich natürlich eine neue Tastatur und kann wieder normal tippen.