Hallo Gemeinde

Ich betreibe an meinem Arch-Rechner eine USB-WLan-Stick Edimax EW-7811UAC mit dem Treiberpaket rtl88xxau-aircrack-dkms-git aus dem AUR.
Der Stick läuft auch fast tadellos. Immer wieder mal funktioniert der Stick nach einem Systemupdate nicht mehr.
Gerade eben wieder.
Scheinbar wird der Treiber dann nicht mehr geladen.
Nachdem ich dann eine Lan-Verbindung herstelle und den Treiber neu installiere, funktioniert der Stick wieder.
Bei den Systemupdates wird der AUR-Treiber nicht aktualisiert weil er aktuell ist.
Ich update meinen Rechner mindestens wöchentlich.
Aber die Sache mit dem WLan-Stick passiert nur alle zwei oder drei Monate.
Das Treiberpaket rtl88xxau-aircrack-dkms-git wurde zuletzt am 10.11.2020 aktualisiert.

Kann mir jemand einen Tipp geben, wo ich da mit der Fehlersuche ansetzen kann?
Vielleicht jedes Mal, wenn der Kernel gewechselt wird?!?
Wäre möglich. Beobachte ich mal.
Allerdings gab es allein im Dezember drei Kernelupdates:

linux-5.9.12.arch
linux-5.9.13.arch
linux-5.9.14.arch

Jedesmal ohne Problem.
Vielleicht finde ich im Pacman-Log was.

Dort ist folgendes zu finden: 
[2021-01-06T15:31:27+0100] [ALPM-SCRIPTLET] ==> dkms install --no-depmod -m rtl88xxau -v r1123.e9fbf5c -k 5.10.4-arch2-1
[2021-01-06T15:31:54+0100] [ALPM-SCRIPTLET] Error! Bad return status for module build on kernel: 5.10.4-arch2-1 (x86_64)
[2021-01-06T15:31:54+0100] [ALPM-SCRIPTLET] Consult /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/make.log for more information.
In der /var/lib/..../make.log steht dann folgendes: 
DKMS make.log for rtl88xxau-r1123.e9fbf5c for kernel 5.10.4-arch2-1 (x86_64)
Mi 6. Jan 15:31:28 CET 2021
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.10.4-arch2-1/build M=/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build  modules
make[1]: Verzeichnis „/usr/lib/modules/5.10.4-arch2-1/build“ wird betreten
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_cmd.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_debug.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_security.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_io.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_ioctl_query.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_ioctl_set.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_ieee80211.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_mlme.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_mlme_ext.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_mi.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_wlan_util.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_vht.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_pwrctrl.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_rf.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_chplan.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_recv.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_sta_mgt.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_ap.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/mesh/rtw_mesh.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/mesh/rtw_mesh_pathtbl.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/mesh/rtw_mesh_hwmp.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_xmit.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_p2p.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_rson.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_tdls.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_br_ext.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_iol.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_sreset.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_btcoex_wifionly.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_btcoex.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_beamforming.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_odm.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_rm.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/rtw_rm_fsm.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/core/efuse/rtw_efuse.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/linux/os_intfs.o
  CC [M]  /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/linux/usb_intf.o
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c: In Funktion »isFileReadable«:
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2201:11: Fehler: Implizite Deklaration der Funktion »get_fs«; meinten Sie »get_sa«? [-Werror=implicit-function-declaration]
 2201 |   oldfs = get_fs();
      |           ^~~~~~
      |           get_sa
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2201:11: Fehler: unverträgliche Typen bei Zuweisung an Typ »mm_segment_t« von Typ »int«
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2203:3: Fehler: Implizite Deklaration der Funktion »set_fs«; meinten Sie »sget_fc«? [-Werror=implicit-function-declaration]
 2203 |   set_fs(KERNEL_DS);
      |   ^~~~~~
      |   sget_fc
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2203:10: Fehler: »KERNEL_DS« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »KERNFS_NS«?
 2203 |   set_fs(KERNEL_DS);
      |          ^~~~~~~~~
      |          KERNFS_NS
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2203:10: Anmerkung: jeder nicht deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, gemeldet
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c: In Funktion »retriveFromFile«:
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2243:12: Fehler: unverträgliche Typen bei Zuweisung an Typ »mm_segment_t« von Typ »int«
 2243 |    oldfs = get_fs();
      |            ^~~~~~
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2245:11: Fehler: »KERNEL_DS« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »KERNFS_NS«?
 2245 |    set_fs(KERNEL_DS);
      |           ^~~~~~~~~
      |           KERNFS_NS
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c: In Funktion »storeToFile«:
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2282:12: Fehler: unverträgliche Typen bei Zuweisung an Typ »mm_segment_t« von Typ »int«
 2282 |    oldfs = get_fs();
      |            ^~~~~~
/var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.c:2284:11: Fehler: »KERNEL_DS« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »KERNFS_NS«?
 2284 |    set_fs(KERNEL_DS);
      |           ^~~~~~~~~
      |           KERNFS_NS
cc1: Einige Warnungen werden als Fehler behandelt
make[2]: *** [scripts/Makefile.build:279: /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build/os_dep/osdep_service.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[1]: *** [Makefile:1805: /var/lib/dkms/rtl88xxau/r1123.e9fbf5c/build] Fehler 2
make[1]: Verzeichnis „/usr/lib/modules/5.10.4-arch2-1/build“ wird verlassen
make: *** [Makefile:2246: modules] Fehler 2
Leider kann ich damit null anfangen.
Versuch doch mal in Zukunft folgenden Ablauf:

1. Update
2. Reboot
3. Neuen Treiber bauen und mit modprobe einbinden

Manchmal macht es Sinn, das Verzeichnis mit den Treibern vor dem Neubau zu löschen.
Bei meinem rtl-Treiber war das auch so notwendig. Ein neuer Kernel macht es halt auch schonmal notwendig, dass der Treiber darauf angepasst ist, was nur mit dem Neubau möglich ist 🙂
HansHiasl schrieb Ich update meinen Rechner mindestens wöchentlich.
Aber die Sache mit dem WLan-Stick passiert nur alle zwei oder drei Monate.
Das Treiberpaket rtl88xxau-aircrack-dkms-git wurde zuletzt am 10.11.2020 aktualisiert.

Kann mir jemand einen Tipp geben, wo ich da mit der Fehlersuche ansetzen kann?
Wenn für die Behebung ein Neubau des Paketes nötig ist wäre eine Idee mal das Tool rebuild-detector zu testen

  • [gelöscht]

  • Beitrag Nr. 6
DKMS soll dazu dienen, die Module automatisch neu zu kompilieren, damit sie zum jeweiligen Kernel passen. Das passiert normalerweise automatisch, wenn entweder ein Upgrade des Pakets oder des Kernels erkannt wird und grundsätzlich funktioniert es auch. Das Problem ist, dass sich die Quellen nicht mehr fehlerfrei unter dem aktuellen Kernel kompilieren lassen, deshalb wird auch kein aktuelles Kernelmodul erstellt.

Es gibt dazu upstream auch einen Bugreport https://github.com/aircrack-ng/rtl8812au/issues/762 und einen Fix https://github.com/aircrack-ng/rtl8812au/pull/773, dazu muss das Paket neu gebaut werden, damit die letzten commits angewandt werden.
@ IceCube63: Der rebuild-detector scheint mir das geeignete Werkzeug zu sein, werd ich testen.

@ Aphae7uu: Mit dem rtl8812au-Paket läuft mein Stick leider nicht.

  • [gelöscht]

  • Beitrag Nr. 8
HansHiasl schrieb @ Aphae7uu: Mit dem rtl8812au-Paket läuft mein Stick leider nicht.
Wer hat denn was vom rtl8812au-Paket erzählt? In meinem Kommentar habe ich mich genau auf das Paket des AUR bezogen, das in deinem Eingangspost genannt wurde.

Der rebuild-detector wird dich nicht weiterbringen, weil er wohl kaum erkennen kann, wenn sich in den Quellen des git-Repos etwas ändert. Genau da liegt ja das Problem, dass der AUR-Paketbetreuer nicht für jeden commit ein neues pkgver erstellen möchte sondern statt dessen die Verantwortung beim Benutzer sieht, Änderungen an den Quellen selber zu beobachten und im Bedarfsfall das lokale git-Repo durch einen pull mit dem des Entwicklers wieder auf einen gemeinsamen Stand zu bringen.
Aphae7uu schriebEs gibt dazu upstream auch einen Bugreport https://github.com/aircrack-ng/rtl8812au/issues/762 und einen Fix https://github.com/aircrack-ng/rtl8812au/pull/773, dazu muss das Paket neu gebaut werden, damit die letzten commits angewandt werden.
Aphae7uu schriebWer hat denn was vom rtl8812au-Paket erzählt? In meinem Kommentar habe ich mich genau auf das Paket des AUR bezogen, das in deinem Eingangspost genannt wurde.
Danke für die freundliche Aufklärung.

Ich dachte, ich hätte in meinem Eingangspost "rtl88xxau-aircrack-dkms-git" geschrieben...

  • [gelöscht]

  • Beitrag Nr. 10
HansHiasl schriebDanke für die freundliche Aufklärung.
Ich dachte, ich hätte in meinem Eingangspost "rtl88xxau-aircrack-dkms-git" geschrieben...
Deine Überheblichkeit kannst du dir sparen.

Das PKGBUILD des von dir genannten Paketes befindet sich auf https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=rtl88xxau-aircrack-dkms-git, und dort wird als Quelle auf die Projektseite des Entwicklers https://github.com/aircrack-ng/rtl8812au verwiesen.

Du hast jetzt alle Informationen, die du für eine Problemlösung benötigst. Mach was draus, oder lass es bleiben.
HansHiasl schrieb@ IceCube63: Der rebuild-detector scheint mir das geeignete Werkzeug zu sein, werd ich testen.
Nö, Aphae7uu hat Recht, auch wenn er auf ein anderes Paket im AUR verlinkt hat. Das Problem ist gleich: Wenn sich etwas im GIT-Repo ändert, bekommt das rebuild-detector auch nicht mit.

Nur ein Rebuild des Pakets zieht die Änderungen (in diesem Fall Fixes für den 5.10er Kernel) aus dem GIT-Repo. Ein einfacher DKMS-Rebuild fällt auf die Schnauze.
Ist eigentlich ne blöde Idee ein DKMS-Modul aus einem GIT-Repo zu ziehen wenn es keine saubere Versionierung bietet. Besser wäre in diesem Fall ein Modul-Paket mit einer festen Abhängigkeit auf eine bestimmte Kernelversion...

  • [gelöscht]

  • Beitrag Nr. 12
drcux schrieb Ist eigentlich ne blöde Idee ein DKMS-Modul aus einem GIT-Repo zu ziehen wenn es keine saubere Versionierung bietet. Besser wäre in diesem Fall ein Modul-Paket mit einer festen Abhängigkeit auf eine bestimmte Kernelversion...
Das würde aber für den Paketbetreuer einen enormen organisatorischen Aufwand nach sich ziehen, weil er immer in Abstimmung mit den Kernel-Maintainern mit einem regulären- oder LTS-Kernel-Release auch sein Modul bereitstellen müsste. Das kann man von einem AUR-Paketbetreuer nicht erwarten und würde auch irgendwie gegen die Philosophie des AUR sprechen, in dem praktisch Bauanleitungen für das Erstellen von Paketen bereitgestellt werden, und keine Binärpakete.

Das DKMS-Verfahren wurde ja gerade deswegen entwickelt, damit man nicht mit jedem Kernel-Release die Modul-Pakete neu verteilen muss, sondern dass nur die Quellen installiert und dann über den DKMS-Trigger neu und passend zum Kernel kompiliert werden. Das bedingt selbstverständlich, dass man auch immer die aktuellen Quellen verwendet. Das ist aber nicht nur bei Quellen aus dem git so.

Das Problem ist eigentlich die fehlende Bereitschaft des Paketbetreuers, nach einem Update der Quellen eine neue Version des PKBUILDS zu liefern. Das hat er ja in der Diskussion zu dem Problem deutlich gemacht und sich dabei auf die VCS package guidelines berufen. Aber jetzt ist es nun mal so wie es ist, und man muss sich halt mit dem arrangieren, was geboten wird. Letztlich muss man ja auch dankbar sein, wenn sich überhaupt jemand findet, der so ein Paket betreut und damit die Module der Gemeinschaft zur Verfügung stellt. Deswegen sollte man da keine Ansprüche oder gar Forderungen stellen.

Ich habe mir übrigens das Paket mal testweise gebaut und installiert, dabei wurde es für beide Kernel (5.10.3-arch1-1 und 5.4.86-1-lts) per DKMS fehlerfrei kompiliert und die Kernelmodule in den entsprechenden Verzeichnissen abgestellt. Ob die Module so funktionieren, kann ich natürlich mangels passender Hardware nicht bestätigen, jedenfalls funktioniert die Kompilation fehlerfrei.

Ich verstehe deshalb nicht, warum der OP hier so ein Riesenfass aufmacht; einfach auf die aktuellen Quellen aktualisieren, das Paket neu bauen, installieren und vom DKMS-Prozess kompilieren lassen, und sich freuen.
Weil er den (unglücklichen) Zusammenhang zwischen DKMS und Quellen aus einem GIT-Repo nicht gesehen hat.

Für eine Nicht-Rollingrelease-Distro macht DKMS Sinn, da der installierte Kernel normalerweise nur Sicherheitspatches bekommt und somit das Bauen der Module zu 99,99% immer funktioniert. Bei Arch sehe ich das anders, bei den häufigen Kernelupdates auf neuere Versionen ist die Wahrscheinlichkeit, das Module angepasst werden müssen schon sehr hoch. Klar ist es für AUR-Maintainer umständlicher, für die Nutzer die u.U. mit einem nicht funktionierendem System da stehen aber auch.

Aber: Wenn man die Augen auf macht, sollte man schon beim installieren der Kernelupdates sehen, wenn DKMS auf die Nase fliegt und gleich das Modul-Paket neu installieren.

  • [gelöscht]

  • Beitrag Nr. 14
drcux schriebWeil er den (unglücklichen) Zusammenhang zwischen DKMS und Quellen aus einem GIT-Repo nicht gesehen hat.
Muss er ja auch nicht; er soll einfach nur die unterbreiteten Lösungsvorschläge umsetzen. Statt dessen diskutiert er jetzt darüber, dass ich mich mit einem vermeintlich falschen Paket beschäftigt habe.
Für eine Nicht-Rollingrelease-Distro macht DKMS Sinn, da der installierte Kernel normalerweise nur Sicherheitspatches bekommt und somit das Bauen der Module zu 99,99% immer funktioniert. Bei Arch sehe ich das anders, bei den häufigen Kernelupdates auf neuere Versionen ist die Wahrscheinlichkeit, das Module angepasst werden müssen schon sehr hoch.
Aber ist gerade bei häufigen Kernelupdates dann nicht DKMS das Mittel der Wahl? Genau dann habe ich doch nicht mehr den Wartungsaufwand, weil sich die Module mit jedem Kernel- oder Paketupdate praktisch selber aktualisieren.
Klar ist es für AUR-Maintainer umständlicher, für die Nutzer die u.U. mit einem nicht funktionierendem System da stehen aber auch.
Ich habe mir das heute noch einmal angesehen (ich habe normalerweise keine AUR-Projekte mit git-Quellen). Es ist in der Tat so, dass ein einfaches rebuild des Pakets reicht weil dabei auch das lokale git-Repo mit dem des Entwicklers synchronisiert wird und damit die aktuellen Quellen vorliegen. Über einen sed wird sogar pkgver des PKGBUILD neu gesetzt, so dass man auch ein vernünftig versioniertes Paket bekommt. Besser kann man es doch nicht machen.

An den Quellen scheint sich auch ständig etwas zu ändern, aktuell liegen schon wieder drei commits vor, die auf einen merge warten. Da muss ich dem Paketbetreuer schon zustimmen, dass man nicht alle paar Tage wieder die Paketversion ändern kann, zumal die das ja auch nur freiwillig in ihrer Freizeit machen. Da muss man auch einen Teil der Aufgaben an den Benutzer übertragen.

Um die Aktualisierung der Pakete aus dem AUR muss ich mich eh immer selber kümmern. Der einzige Unterschied hier ist, dass die gängigen Helper davon nichts mitbekommen, wenn sich an der Version des PKGBUILD nichts ändert. Ich wüsste jetzt auch nicht, wie man es besser machen könnte, vor alle wenn die Anwendungsentwickler keine Quellcodepakete zur Verfügung stellen, wie es sonst üblich ist.
Aber: Wenn man die Augen auf macht, sollte man schon beim installieren der Kernelupdates sehen, wenn DKMS auf die Nase fliegt und gleich das Modul-Paket neu installieren.
Na ja, die Fehlermeldungen in den Logs hat er ja immerhin gefunden. Spätestens da hätte es aber klingeln müssen, dass mit den Quellen etwas nicht stimmt. Erste Anlaufstelle ist in solchen Fällen für mich immer die Projektseite des AUR, denn meistens ist man mit seinem Problem nicht allein, so auch hier. Und wenn man da nicht weiterkommt, dann eben der Bugtracker des Entwicklers der Anwendung, usw.