Von außen betrachtet wirkt der Linux-Kernel wie ein riesiger Code-Klumpen, in dessen Schlund unzählige Treiber verborgen sind, die dafür sorgen, dass Linux die diversen Geräte und Komponenten, die an die Hauptplatine eines Computers angeschlossen sind, ansprechen kann. Eben alles vom Grafikchip oder Festplatten-Controller bis hin zu Tastatur oder Webcam. Da der Linux-Kernel monolithisch konzipiert ist, besteht das Interesse der Kernel-Entwickler um Linux-Erfinder Linus Torvalds darin, dass alle Hersteller ihren Treiber-Code in den Kernel einfließen lassen. Auf diese Weise kann ein frisch aufgesetztes Linux-System „out of the box“ sämtliche Hardware nutzen, auf der es installiert ist.
In der Praxis ist das zwar immer öfter, aber leider nicht immer so. Manche Hersteller haben kein Interesse, neben dem obligatorischen Windows-Treiber auch noch einen für Linux zu programmieren und zu pflegen. Ein Grund dafür ist, dass sie dafür ihren Code offenlegen müssten („Open source“), dies aber nicht wollen. Andere Hersteller bringen zwar Linux-Treiber heraus, scheitern aber an der Qualitätskontrolle von Torvalds und Kollegen oder reichen sie erst gar nicht dort ein.
Wie identifiziert man ein PCI- oder USB-Gerät unter Linux?
Eins von diesen Sorgenkindern ist die taiwanische Firma Realtek, vor allem als Hersteller von Netzwerkkarten und Audio-Codecs bekannt. Weil Geräte mit Realtek-Chips weniger kosten als etwa ihre Intel-Pendants, sind sie oft anzutreffen, vor allem im Consumer-Segment. Als Linux-Anwender hat man dann das Problem, diese Teile zum Laufen zu bringen. Bei meinem nur ein paar Euro teuren 1200AC-WLAN-Adapter lag zwar eine betagte Treiber-CD mit einem Linux-Treiber bei – aber wie installieren? Und sollte man sich nicht besser einen aktuellen Treiber aus dem Netz ziehen?
An dieser Stelle gilt es erst einmal herauszufinden, welchen Chip man vor sich hat, denn häufig haben diese Teile keine oder eine nichtssagende Hersteller-Bezeichnung. Bei einem USB-Gerät setzt man (als Superuser oder mit vorangestelltem sudo) das Kommando
lsusb
und bei einem PCI-Gerät
lspci
in einem Terminal ab, um sich die angeschlossenen Geräte anzuschauen. Wer einen USB-Adapter hat, kann ihn auch anstecken und dann sofort das Kommando
dmesg
absetzen. Es protokolliert die Einträge aus dem Kernel-Puffer in der Reihenfolge ihres Auftretens – die letzten Einträge sollten also Aufschluss über den soeben angeschlossenen Adapter geben.
Im Fall meines WLAN-Adapters offenbarten die letzten Zeilen von dmesg nach dem Anschließen folgendes:
[ 3142.084385] usb 1-3: new high-speed USB device number 5 using xhci_hcd [ 3142.211198] usb 1-3: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 2.10 [ 3142.211210] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumbe r=3 [ 3142.211216] usb 1-3: Product: USB3.0 802.11ac 1200M Adapter [ 3142.211220] usb 1-3: Manufacturer: Realtek [ 3142.211223] usb 1-3: SerialNumber: 123456
Und unter lsusb fand sich u.a. folgende Zeile:
Bus 001 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC120 0 Techkey]
Wir haben es also mit einem Realtek-WLAN-Adapter zu tun, und zwar dem RTL88x2bu, der nach dem 802.11ac-Standard funkt und über USB 3.0 angebunden ist.
Wie man einen Treiber für Linux findet
Mit der gefundenen Chip-Bezeichnung gilt es nun, mit der Suchmaschine der Wahl nach einem Treiber für diesen Chipsatz zu suchen. Da ich Ubuntu nutze, habe ich direkt nach „Ubuntu RTL88x2bu“ gesucht. Das meiste, was in diesem Posting geschildert wird, trifft aber nicht nur auf Ubuntu, sondern auf alle Betriebssysteme mit Linux-Kernel zu. Auch die Suche nach der ID – hier „0bda:b812“ – führt oft zum Erfolg.
Zurück zu meiner Suche: In den Ergebnissen fand sich ein Github-Repository, das – wie die Zeitstempel der enthaltenen Dateien zeigten – aktuell gepflegt wird, also auch frische Treiber verspricht. Darauf sollte man immer achten. Natürlich birgt solch ein Fremd-Repository immer auch ein Risiko – man muss dem Autor der Software vertrauen. Dass auf dieses Repository aber auf anderen Websites verwiesen wird, darunter auch auf AskUbuntu, reduziert das Wagnis.
Um Software aus einem Git-Repository auf den eigenen Computer zu bringen, installiert man sich Git – falls noch nicht geschehen – und klont sich den Inhalt vom gefundenen Repository:
sudo apt install git git clone https://github.com/cilynx/rtl88x2bu
Aus den heruntergeladenen Dateien, die im Verzeichnis rtl88x2bu landen, lässt sich nun ein Kernel-Modul „bauen“, also kompilieren. Dieses Modul soll künftig geladen werden, wenn Linux startet – eben gerade so, als wäre es schon im Kernel drin.
Automatischer Neubau für Kernel-Module dank DKMS
So weit, so gut. Die Sache hat aber noch einen Haken. Was, wenn der Kernel aktualisiert wird? Dann startet beim nächsten Mal ein neuer Kernel, für den das Modul erneut gebaut werden müsste, und so weiter bei jedem neuen Kernel. Um sich diese ewige Wiederkehr des Gleichen zu ersparen, wurde DKMS erfunden, der Dynamic Kernel Module Support. DKMS sorgt dafür, dass ein einmal registriertes Kernel-Modul automatisch neu gebaut wird, sobald ein neuer Kernel installiert wird.
Falls DKMS noch nicht installiert ist, holt man dieses unter Debian, Ubuntu und Derivaten wie folgt nach:
sudo apt install dkms
Dann passiert folgendes: Man betritt das Verzeichnis mit den heruntergeladenen Dateien, liest die Treiber-Version aus der beiliegenden Datei dkms.conf aus und speichert sie zur späteren Verwendung in einer Shell-Variablen, verschiebt den Treiber in ein nach Namen und Version benanntes Verzeichnis unterhalb von /usr/src/ und „füttert“ DKMS damit. Praktischerweise beherrscht das dkms-Kommando auch gleich Kompilierung und Installation, was je nach Potenz der verwendeten CPU ein paar Minuten dauern kann:
cd rtl88x2bu/ VER=$(sed -n 's/\PACKAGE_VERSION="\(.*\)"/\1/p' dkms.conf) echo $VER sudo rsync -rvhP ./ /usr/src/rtl88x2bu-${VER} sudo dkms add -m rtl88x2bu -v ${VER} sudo dkms build -m rtl88x2bu -v ${VER} sudo dkms install -m rtl88x2bu -v ${VER} sudo modprobe 88x2bu
Zum Schluss sorgt modprobe dafür, dass der Treiber ohne Reboot sofort zur Verfügung steht. Mein WLAN-Adapter war danach in den Netzwerk-Einstellungen auswählbar und bot mir die verfügbaren Netzwerke zur Auswahl an.
Kernelmodule verwalten und deinstallieren
Wer DKMS weiter administrieren will, dem zeigt
sudo dkms status
die von DKMS verwalteten Kernelmodule und ihre Versionen an. Der Zusatz „installed“ zeigt, dass alles korrekt installiert wurde. Um ein Kernelmodul wieder zu deinstallieren, genügt folgender Befehl:
sudo dkms remove -m rtl88x2bu -v 5.8.7.1 --all
Dies entfernte den Realtek-Treiber mit der Versionsnummer 5.8.7.1 für alle auf meinem System installierten Kernel. Da der Treiber nicht über das Paketmanagement der Distribution installiert wurde, muss man sich selbstredend um Aktualisierungen selbst kümmern. Findet sich ein Update, klont man zuerst die neue Version aus dem Git-Repository, deinstalliert dann den alten Treiber und installiert den neuen in derselben Manier wie zuvor beschrieben.
DKMS baut auch für nvidia oder VirtualBox
Die Chancen stehen übrigens nicht schlecht, dass Sie DKMS bereits nutzen, vielleicht sogar ohne es zu wissen. Das ist beispielsweise dann der Fall, wenn Ihr Rechner eine Nvidia-Grafikkarte hat und Sie den proprietären nvidia-Treiber verwenden. Oder wenn Sie Virtualbox einsetzen. In beiden Fällen werden die zusätzlichen Module jedoch automatisch hinter den Kulissen gebaut und auch aktualisiert – ohne dass man das selbst in die Hand nehmen müsste.
….nach stundenlangem Probieren, trotz InstallationsCD und Internet über Handy… endlich Deine Seite gefunden!!!! DANKE!!!
ich war schon am verzweifeln, da alles nichts gebracht hat. Ich bin nicht doof aber auch nicht gerade die Leuchte bei Linux.
DANKE, DANKE, Danke!!! Super das es so Menschen gibt wie Dich.
Hallo,
danke Dirk für die ausführliche Anleitung! Im Github-Projekt https://github.com/aircrack-ng/rtl8812au/
enthält die Datei Makefile so einen Abschnitt:
DRIVER_VERSION = $(shell grep „\#define DRIVERVERSION“ include/rtw_version.h | awk ‚{print $$3}‘ | tr -d v\“)
dkms_install:
@mkdir -vp /usr/src/8812au-$(DRIVER_VERSION)
cp -r * /usr/src/8812au-$(DRIVER_VERSION)
dkms add -m 8812au -v $(DRIVER_VERSION)
+ dkms build -m 8812au -v $(DRIVER_VERSION)
dkms install -m 8812au -v $(DRIVER_VERSION)
dkms status -m 8812au
Zitiert von hier https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/Makefile
Und nach dem Herunterladen mit
git clone https://github.com/aircrack-ng/rtl8812au.git
werden die Befehle im „dkms_install:“-Abschnitt mit
sudo make dkms_install
gestartet. Ich verstehe es so, dass die Befehle unter dem Abschnitt „Dann passiert folgendes:“ hier in diesem Artikel zum gleichen Ergebnis führen. Mit dem Unterschied, dass rsync in einer Zeile erledigt, was mit „@mkdir“ und „cp“ im zitierten Abschnitt beschrieben ist und statt $VER eine $DRIVER_VERSION -Variable verwendet wird.
Meine Frage ist, verstehe ich es richtig, dass ich die die Befehle aus dem Abschnitt „Dann passiert folgendes:“ hier in diesem Artikel in ein „rtl88x2bu/Makefile“ bspw. in ein Abschnitt „dann_passiert:“ speichern und dann mit
> sudo dkms dann_passiert
ausführen kann?
Du kannst das Target in einem Makefile so nennen wie Du willst, ob nun „dkms_install:“ oder „dann_passiert:“. Der Aufruf wäre dann allerdings nicht „sudo dkms dann_passiert“, sondern „sudo make dann_passiert“
Ich habe deswegen gefragt, weil aus der Beshreibung im Abschnitt „Dann passiert folgendes:“ hier in diesem Artikel mMn unklar ist, ob die Befehle nur bei einer zeileneweisen Eingabe im Terminal zum gewünschten Ergebnis führen. Oder mit der Speicherung des Targets „dann_passiert:“ im Makefile und einem
sudo make dann_passiert
Start im Terminal eine zeitsparende Kompilierung und sofotige Bereistellung des Treibers möglich ist.