Mediatek-WLAN-Problem unter Linbo 4.3

Henning · 25. September 2026 um 18:13

Liebe Linuxmuster-Community,

wir haben ein Problem mit Linbo 4.3 und der WiFi-Karte in Lenovo Notebooks, das wir nicht lösen können - und wir haben viel probiert!

Als wir die Geräte letzten Herbst gekauft haben, hatten wir noch Linbo 4.2. Damals half die Änderung der Datei /etc/linuxmuster/linbo/firmware wie folgt:
regulatory.db
regulatory.db.p7s
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
mediatek/WIFI_RAM_CODE_MT7961_1.bin
rtl_nic/rtl8168h-2.fw
In der Datei /srv/linbo/start.conf.GRUPPE haben wir bei den KernelOptions die Einträge
nowarmstart modprobe.blacklist=r8169 modprobe.blacklist=ideapad_laptop hinzugefügt. Nach einem update-linbofs waren die Lenovos dann sowohl über Kabel als auch über WLAN per Linbo nutzbar.

Diese Einträge haben den Weg zu Linbo 4.3 überlebt, helfen aber nicht mehr. Die Infos:

Geräte: Lenovo V15 G4 AMN, neuestes BIOS: L1CN74WW

Linbo: neueste Version für LMN 7.3: Linbo 4.3.38-0 Psycho Killer (mit Longterm-Kernel, siehe unten)

Per linbo-ssh erhalten:

dmesg | grep -i firmware
Spectre V2 : Enabling Speculation Barrier for firmware calls
ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
mt7921e 0000:02:00.0: WM Firmware Version: ____010000, Build Time: 20240219111038
amdgpu 0000:04:00.0: Direct firmware load for amdgpu/psp_13_0_8_toc.bin failed with error -2
amdgpu 0000:04:00.0: Direct firmware load for amdgpu/dcn_3_1_6_dmcub.bin failed with error -2
amdgpu 0000:04:00.0: Direct firmware load for amdgpu/gc_10_3_7_pfp.bin failed with error -2
amdgpu 0000:04:00.0: Direct firmware load for amdgpu/sdma_5_2_7.bin failed with error -2
amdgpu 0000:04:00.0: Direct firmware load for amdgpu/yellow_carp_vcn.bin failed with error -2

modprobe mt7921e
modprobe -r mt7921e funktioniert beides.

lsmod (gekürzt)
Module Size Used by Tainted: G
i2c_hid_acpi 12288 0
i2c_hid 28672 1 i2c_hid_acpi
amdgpu 10207232 0
drm_buddy 12288 1 amdgpu
amdxcp 12288 1 amdgpu
mt7921e 16384 0
mt7921_common 57344 1 mt7921e
drm_display_helper 143360 1 amdgpu
mt792x_lib 45056 2 mt7921e,mt7921_common
mt76_connac_lib 61440 3 mt7921e,mt7921_common,mt792x_lib
mt76 86016 4 mt7921e,mt7921_common,mt792x_lib,mt76_connac_lib
mac80211 634880 4 mt7921_common,mt792x_lib,mt76_connac_lib,mt76
i2c_piix4 20480 0
r8168 466944 0
xhci_pci 16384 0
i2c_smbus 12288 1 i2c_piix4
drm 483328 11 i2c_hid,amdgpu,drm_buddy,amdxcp,drm_exec,gpu_sched,drm_suballoc_helper,drm_display_helper,drm_ttm_helper,ttm,drm_kms_helper
cfg80211 446464 4 mt7921_common,mt76_connac_lib,mt76,mac80211
think_lmi 32768 0
firmware_attributes_class 12288 1 think_lmi
i2c_designware_platform 12288 0
hwmon 20480 3 amdgpu,mt7921_common,fan

Die WiFi-Karte wird im laufenden Debian 13 wie folgt erkannt und funktioniert auch einwandfrei:
02:00.0 Network controller: MEDIATEK Corp. MT7921 802.11ax PCI Express Wireless Network Adapter
Subsystem: Lenovo Device e0bc
Kernel driver in use: mt7921e
Kernel modules: mt7921e

Zwischenzeitlich probiert haben wir Vieles, unter anderem haben wir von einem Gerät, das noch keinen Kontakt zum neuen Linbo hatte, das alte extrahiert. Wenn ich in den folgenden Berichten von „Passenger“ schreibe, meine ich die dort extrahierten Dateien:

Kernel: In /etc/linuxmuster/linbo/custom_kernel wurde probiert:

KERNELPATH="legacy" => Gerät bleibt bei „Starting systemd-udevd …“ hängen, noch bevor es zum DHCP kommt.
KERNELPATH="longterm" => 6.12.100 => bootet immer
KERNELPATH="stable" => gibt es nicht, wird benutzt, wenn kein KERNELPATH gesetzt => 7.x => bleibt manchmal bei „Starting systemd-udevd …“ hängen und bootet manchmal normal
KERNELPATH="/var/lib/linuxmuster/linbo/passenger/linbo64" => von Gerät extrahiert, das noch The Passenger drauf hatte
MODULESPATH="/var/lib/linuxmuster/linbo/passenger/lib/modules/6.12.33" => dito

In /etc/linuxmuster/linbo/firmware wurden alle mediatek/WIFI_MT… und mediatek/WIFI_RAM sowie auch BT_RAM… probiert, weil die Karte eine WiFi-Blutooth-Kombikarte ist.

In /lib/firmware/mediatek wurden die .zst-Dateien zu .bin-Dateien entpackt, um eventuelle Fehler beim Entpacken auszuschließen. Zudem wurden die Dateien WIFI_MT7961_patch_mcu_1_2_hdr.bin und WIFI_RAM_CODE_MT7961_1.bin vom alten Passenger geholt und getestet. Auch eine neuere Version dieser beiden Dateien, die wir in einem Forum gefunden haben, wurden probiert.

Vor dem Erstellen des Linbo-FS wurde zudem das Verzeichnis /var/cache/linuxmuster/firmware/ gelöscht, um eventuelle Überreste nicht einzubauen.

Lässt man den Mediatek-Treiber ganz weg (oder verschiebt ihn in der firmware-Datei und im Dateisystem direkt nach /lib/firmware) wird er nicht geladen. Die dmesg-Meldung sieht dann analog zur Grafikkarte aus und endet auf error -2.

Der einzige Workaround, der funktioniert, besteht darin, die Dateien linbo64 und linbofs64 sowie die zugehörigen .md5-Dateien nach /srv/linbo zu kopieren. Dann wird das alte Linbo an die Notebooks verteilt, was funktioniert, weil sich nicht arg viel im Unterbau geändert hat. Das ist aber keine Dauerlösung und bei jedem Systemupdate, dass unser Service-Partner macht, wird es überschrieben. Bootet man danach die Lenovos, holen sie das neue Linbo und funktionieren danach erst wieder im WLAN, wenn sie sich per Kabel das alte Linbo gezogen haben.

Mein Eindruck ist, dass irgendein Schritt am Anfang zu schnell läuft oder in einer falschen Reihenfolge, weshalb der Treiber noch nicht zur Verfügung steht. Beim Booten von Debian braucht der NetworkManager auch wenige Sekunden, bis es weiter geht. Nach den DHCP-Versuchen der LAN-Karte rennt Linbo 4.3 durch. Es finden keine DHCP-Versuche auf der WLAN-Karte statt. (Wir haben einen guten Vergleich, weil ältere HP- und Dell-Geräte mit 4.3 (Realtek- bzw. Intel-WiFi) funktionieren.)

Nun hoffe ich, dass ich hier mindestens Lösungshinweise bekommen, und sei es der, wo ich all diese Infos besser posten muss. Vielen Dank im Voraus!

(Versuch mit 7.4 kommen nicht in Frage, da die Basis von einem Servicepartner gewartet wird. Wir kümmern uns nur um den Feinschliff.)

Viele Grüße - Henning

Henning · 1. Oktober 2026 um 17:21

Hallo zusammen,

das Problem ist gelöst, aber ganz anders. Eine bekannt KI brachte mich auf die Idee, per linbo-ssh bzw. linbo-Shell die WLAN-Karte zu testen, denn dmesg | grep -i firmware zeigte ja keine WLAN-Fehler. Die Befehle zum Testen lauten:

ip link set dev wlan0 up
wpa_supplicant -B -c/etc/wpa_supplicant.conf -iwlan0
udhcpc -O nisdomain -n -i wlan0

Wenn das alles funktioniert, funktioniert das WLAN! Die Ursache war nun, dass die WLAN-Hardware einfach zu langsam initialisiert wurde. Nach Studium der init.sh im linbofs64 ist meine Lösung folgende:

Auf dem Server in /var/lib/linuxmuster/hooks/update-linbofs.pre.d eine Datei erstellen, z.B. 10_warte-wegen-wlan.sh und mit chmod +x ausführbar machen.
Inhalt:
#!/bin/bash
set -eu
#sed -i '/local ipaddr/a cat /proc/net/dev' init.sh
sed -i '/local ipaddr/a sleep 1' init.sh
echo "- Mein Hook gelaufen - 1 Sek. Wartezeit für Mediatek-WLAN hinzugefügt -"

Am Anfang hatte ich 10 Sekunden und cat /proc/net/dev drin, um zu sehen, welche Schnittstellen erkannt wurden. Ohne Wartezeit fehlte wlan0.

Evtl. wäre ein Kernel-Parameter wie „wait_wifi=x“ interessant, weil die Wartezeit, falls sie mal länger ausfallen muss, dann nur betroffene Gruppen betrifft. Vielleicht ist aber einfach nur der Ryzen zu schnell für die Mediatek-Schnittstelle, die ihre extra Firmware braucht, und alle anderen Computer funktionieren.

Eine Bitte an die Admins: Ich finde meine Lösung natürlich total hilfreich für die ganze Welt, nur bei dem ersten Post liest kaum jemand bis zum Ende - zumal er nicht zielführend ist. Kann man das irgendwie aufräumen? Soll ich diese Lösung getrennt neu posten und sofort als gelöst markieren? Nimmt die Lösung jemand in https://docs.linuxmuster.net/de/latest/clients/use_linbo4/index.html auf? Kriegt das Linbo-Team diese Problematik mit, oder soll ich jemandem mailen? Ich finde Linuxmuster toll und möchte im Rahmen meiner Möglichkeiten unterstützen. Vielen Dank!

Viele Grüße - Henning

baumhof · 1. Oktober 2026 um 20:16

Hallo Henning,

Super, dass du den Fehler gefunden hast.

Zu deinen Anmerkungen am Ende:

durch das „Lösung“ Markieren, steht am ersten Post unten schon ein Link zu Lösung. Derartige Probleme finden die meisten sowiso per Suchfunktion: da stört ein „unatraktiver erster Post“ wenig.

Insofern sehe ich als Admin erstmal keine Handlungsnotwendigkeit.

das Dokuteam liest hier eigentlich mit: ich stubs die aber auch mal an.
ich nehme an, dass „das Linboteam“ das hier mitbekommen hat. Wenn du aber einen „Denkzettel“ machen willst, damit es nicht unter den Tisch fällt, dann empfehle ich ein „issue“ in Github zu erstellen.

LG
Holger

thomas · 5. Oktober 2026 um 14:40

Hallo Henning,

danke für den Beitrag. Wenn die Hardware keine Ethernet-Schnittstelle hat, könntest du mit dem aktuellen Linbo 4.3.39 folgendes testen:

Den Hook 10_warte-wegen-wlan.sh entfernen und update-linbofs ausführen.
Den Client booten und prüfen, ob er über WLAN eine IP bekommt.

Mit netwait=20 in KernelOptions der start.conf lässt sich die Wartezeit erhöhen, falls der Defaultwert von 10 Sekunden nicht reicht.

Falls das nicht klappt, bitte folgendes durchführen:

ls /sys/class/net und cat /proc/net/dev auf der Linbo-Clientkonsole: Welche Interfaces gibt es, und gibt es ein Ethernet-Interface?
dmesg | grep -i -E "mt79|wlan0|phy0": Zu welchem Zeitpunkt (Sekunden seit Boot) taucht wlan0 auf, und wann beginnt „Requesting ip address“? Das zeigt, wie spät der Treiber ist.
cat /sys/bus/pci/devices/*/class: Ob die MediaTek-Karte die Klasse 0x0280xx hat. Das brauche ich für die Erkennung der WLAN-Hardware.

VG, Thomas

Henning · 5. Oktober 2026 um 15:11

Hallo Thomas,

ich schreibe es auf die ToDo-Liste.

Der Client hat eine LAN-Schnittstelle, sonst hätte ich erheblich größere Probleme gehabt, die zahlreichen Versuche durchzuführen, die ich nach dem Upgrade von 4.2, wo die Zeit für die WLAN-Schnittstelle ausreichte, auf 4.3 gebraucht habe. So konnte ich einfach mit eingestecktem Kabel das neueste linbofs laden und nach einem Neustart ohne Kabel testen, ob WLAN funktionierte.

netwait hatte ich probiert, allerdings nicht mit 20 Sekunden. Da netwait keine Änderung brachte, ging ich davon aus, dass netwait nur für eine und nicht für alle Netzwerkschnittstellen gilt, sprich, wenn die LAN-Schnittstelle da ist, wird nicht auf eine weitere Schnittstelle gewartet. Gefühlt verstreichen auch so keine 10 Sekunden, d.h. ich nehme an, dass meine Einschätzung stimmt.

Die Dinge probiere ich demnächst aus. Jetzt muss ich für meine Fachschaft die Einkäufe tätigen. (Wir bekommen das Geld im September und haben dann keine 2 Monate Zeit bis Rechnungsschluss. Zudem aktualisieren die Kolleginnen jetzt die Lenovos. Jeder Fehlversuch macht die WLAN-Schnittstelle unbrauchbar und sie müssen die Notebooks wieder einmal per Kabel starten. Folglich kann ich nur ab dem späten Nachmittag testen.)

Vielen Dank und viele Grüße - Henning

Henning · 15. Oktober 2026 um 16:16

Hallo Thomas,

heute hatte ich etwas Zeit zwischen Bestellungen und Lieferungen für meine Fachschaft. Hier die Ergebnisse der Tests:
Hook entfernt und netwait=20 gesetzt, danach linuxmuster-import-devices und update-linbofs => WLAN-Karte wird nicht gefunden, was meine Vermutung bestätigt, dass netwait zufrieden ist, sobald eine Netzwerkkarte gefunden wurde.

Ausgehend von dieser Situation per Kabel gebootet und über linbo-ssh Deine Befehle ausgeführt =>

~ # ls /sys/class/net eth0 lo wlan0

Zu diesem Zeitpunkt ist wlan0 vorhanden, es fehlt ja nur 1 Sekunde beim Booten.

~ # cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 60646 425 0 0 0 0 0 0 45380 388 0 2 0 0 0 0 wlan0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

WLAN ist nicht „up“ und somit nicht verbunden, ich habe ja über Kabel gebootet.

~ # dmesg | grep -i -E "mt79|wlan0|phy0" mt7921e 0000:02:00.0: enabling device (0000 -> 0002) mt7921e 0000:02:00.0: ASIC revision: 79610010 mt7921e 0000:02:00.0: sar cnt = 0 mt7921e 0000:02:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240219110958a mt7921e 0000:02:00.0: WM Firmware Version: ____010000, Build Time: 20240219111038

Hinweis zur Firmware: Ich habe verschiedene Firmware-Versionen ausprobiert: Die von LMN 7.2, die von LMN 7.4, die von Debian 13 und eine neuere, die ich im Internet gefunden habe.

~ # cat /sys/bus/pci/devices/*/class
0x060000
0x080600
0x060000
0x060000
0x060400
0x060400
0x060400
0x060000
0x060400
0x060400
0x0c0500
0x060100
0x060000
0x060000
0x060000
0x060000
0x060000
0x060000
0x060000
0x060000
0x010802
0x028000
0x020000
0x030000
0x040300
0x108000
0x0c0330
0x0c0330
0x048000
0x040300
0x0c0330

=> 0x028000 gefunden

Irgendwie fürchte ich, dass der dmesg-Befehl nicht ganz das lieferte, was Du Dir erhofft hast. Aber hoffentlich helfen die Informationen trotzdem.

Eine Lösungsidee wäre aus meiner Sicht, ein waitwlan als eigene Kerneloption einzubauen. (Und wenn ich schon Ideen äußere: Schöne wäre, wenn das, was set timeout=X in /usr/share/linuxmuster/linbo/templates/grub.cfg.global bzw. /srv/linbo/boot/grub/GRUPPE.cfg (diese Datei lasse ich immer auf „managed by linuxmuster“) bewirkt, über die start.conf.GRUPPE einstellbar wäre. Und ebenfalls über start.conf.GRUPPE würde ich gerne einstellen können, ob zuerst die WLAN-Karte auf Verbindung getestet werden soll. Gefühlt dauert der Start nämlich beim DHCP-Versuch der LAN-Schnittstelle lange und über 80% unserer Computer nutzen Linbo-WLAN.)

Vielen Dank und viele Grüße - Henning