Bin grad´ nochmal das lspci oben durchgegangen. Wenn da kein chip erkannt wird riecht das doch nach BIOS-disabled oder defekt - soll ja auch manchmal vorkommen.
Wäre es da nicht einfacher und zielführender, so wie ganz früher, einfach eine ethernet-karte reinzustecken, von der sicher ist, daß sie ordentlich läuft?
Übrigens: gibt es vielleicht ein BIOS-update?
Edit2: schonmal versucht, den chip zu disablen und dann wieder anzumachen?
Also dein Vorschlag wäre, den r8125-dkmsaus dem AUR noch einmal zu installieren, den r8169wieder über sudo bash -c 'echo "blacklist r8169" > /etc/modprobe.d/r8169.confzu blacklisten? Das hatte ich ja genau so bereits versucht und es hat nicht funktioniert.
Ich schreibe Heiner Kallweit gerne mal eine Mail. Main C/C++ ist leider etwas eingerostet, weil ich die letzten Jahre nicht mehr als Entwickler sondern als Linux Admin gearbeitet hatte. Weswegen mich dieses Problem gerade auch ganz besonders frustet. Falls nötig kann ich mit meinem Handwerkszeug ja auch ein fehlendes Kernel Modul der Community beitragen, solange ich das Problem nicht mit Hilfe hier oder anderweitig gelöst bekomme.
Über weitere Lösungsvorschläge wäre ich natürlich trotzdem dankbar.
Das BIOS habe ich gestern noch vor meinem initialen Post mit der aktuellsten Version geflasht.
Eine sicher funktionierende Ethernet Karte habe ich nicht hier. Da ist mit der Radeon 7900XT sowie Halterung dafür auf dem Steckplatz mit 16 lanes auch gar kein Platz mehr für eine weitere PCIe Karte.
Das Kabel funktioniert auf jeden Fall mit dem Router an meinem ThinkPad mit Debian. Das hatte ich als allererstes geschaut.
Den Klassiker disablen und wieder enablen habe ich noch nicht ausprobiert, das mache ich natürlich jetzt mal.
Wenn die Hardware weder bei lspci noch bei inxi auftaucht bin ich skeptisch das ein Kernel modul das richten kann.
Genauso sehe ich das auch. Da fällt mir allenfalls noch ein USB-Eth-Adapter ein, ist natürlich ne Krücke…
Vielleicht kannst du ja mal ein live iso einer anderen distro starten? Ubuntu und Fedora sind bekannt für ihre gute Hardware Unterstützung. Wenn die beiden dein LAN chip nicht entdecken dann find ich einen hardware defekt am wahrscheinlichsten.
Einfach ein ISO runterladen und per popsicle auf einen USB Stick schieben und dann davon booten.
Woran kann es denn noch liegen, dass das Device nirgendwo autfaucht? Das ist halt auch das, was mich am meisten stört.
hardware defekt ?
Probier mal Ubuntu 25.04 oder Fedora (siehe mein vorherigen post)
Ja, das kann ich gern gleich mal machen. Mit dem aktuellen Endeavour OS live image hatte ich gestern auf jeden Fall das gleiche Problem. Fedora kann ich gleich gern mal ausprobieren. Falls es da funktionieren sollte, wäre es zumindest eindeutig ein Software Problem.
Wenn der Controller auch dort nicht auftaucht steigt die Wahrscheinlichkeit natürlich für ein defektes Mainboard. Was ziemlich mies wäre.
Als burning tool kann ich vor allem Caligula aus dem offiziellen Arch Repo voll empfehlen.
Jo, der RTL8125BG müsste auch eine PCIe-Anbindung haben, habe grade mal auf der “halb-chinesischen” realtek.com-Seite geschaut. Ich behaupte an sich auch mal, dass der sich unter lspci einfinden sollte. Leider habe ich bei realtek deren Linux-Treiber nicht gefunden, ein Link bei Linux Mint hat nur 404 gebracht und die Suchfunktion bei Realtek … naja.
Noch ne wüste Idee: Nach Deaktivieren/Aktivieren im BIOS PC mal runterfahren und stromlos machen, dann wieder starten und mit lspci gucken. Man hat ja schon Pferde kotzen sehen … vor der Apotheke … 
Ich bin eigentlich ziemlich sicher, dass der Chipset mit der im Kernel vorhandenen r8169-Codebase funktionieren müsste, nur scheint einfach der Eintrag für die Modellnummer mit dem “bg” noch zu fehlen. naja, und ich glaube kaum, dass der – selbst bei Einreichung – noch für 6.17 akzeptiert würde, allenfalls für 6.18.
Du könntest natürlich richtig mutig werden und den Kernel-Source patchen und dir deinen eigenen Kernel kompilieren … nee, oder?
Realtek war schon immer eine Katastrophe mit deren -zig “Unter-Modellvarianten”, wobei die Hardware/die Chipsets an sich ganz gut sind und wegen der Schleuderpreise halt gern von MoBo-Herstellern verbaut werden.
Wenn man wenigstens wüsste, ob der derzeitige Treiber aus dem AUR schon das “BG”-Modell enthält … Könntest du da mal reingucken? Wenn nicht, ist das ja eh aussichtslos. Wenn aber doch, könnte man ja den verwenden.
Ja, aber solange lspci rein garnix liefert, ist doch das ganze modul-gedöns total für die Katz - oder?
Denke schon, ja. Deswegen ja nochmal die Idee mit dem ganz Ausschalten.
Allerdings bin ich nicht 100% sicher, ob Linux eine Methode hat, beim Start ein PCI(e)-Gerät zu “verstecken”, wenn es keinen Treiber dafür hat. Ich hatte mal so ein Notebook mit exotischen Sachen drin, ich meine, die wären dann mit lscpi auch nicht mehr sichtbar gewesen.
Allerdings sollte man in einem solchen Fall unbedingt in dmesg oder journalctl -b eine entsprechende Fehlermeldung finden.
Ich meine mich zu erinnern, dass Arch in dem Fall diesen “obskuren” Geräten einen Dummy-Treiber zugewiesen hatte, damit sie nicht den Betrieb stören.
Die Idee mit dem Aus- / Einschalten hatte mich vorhin schon zur Frage gebracht:
Läßt sich mit Eth-Kabel stecken / ziehen irgendeine Reaktion erzeugen?
Zum Vorschlag von @mbod mit einer anderen Distro testen: Halte ich für eine gute Idee – Ausschlussverfahren ist immer gut. Ich hab für sowas einen 256GB-Stick mit Ventoy und allen für mich wichtigen ISOs drauf.
Aber zumindest bei Ubuntu/Mint wirst du auch wohl um ein sudo apt install r8125-dkms (in den offiziellen Repos) und ein blacklisting des r8169 nicht drumrumkommen …
Ich hab für sowas einen 256GB-Stick mit Ventoy und allen für mich wichtigen ISOs drauf.
Meine Güte, da ist wohl alles drauf, was grad bei Distrowatch Platz 1-100 hat?
Nee, nur meine paar Wichtigen, im Wesentlichen Mint, EOS, Arch, Debian, Ubuntu, kubuntu, Clonezilla, HBCD usw. Allerdings arbeite ich viel mit Persistence, die brauchen leicht schonmal 8–16GB. Und mir spart’s das ewige Nachinstallieren von Zeug wie gparted, deutschen Tastaturtreibern, WiFi-Credentials usw.
Den Stick hatte ich hauptsächlich wegen Geschwindigkeit und beidseitigen Anschlüssen gewählt (USB-A und USB-C). [Achtung: Sau-lahmer Webserver bei SP!]
Oh, interessant. Da muß ich wohl mal zur Nachhilfe kommen…
Das hatte ich bisher überhaupt nicht auf dem Schirm. Gibts da was zum Einlesen?
Da steht eigentlich alles drin. Für Persistence musst du allerdings bei manchen Distros (Arch, EOS) arg kämpfen und Dateien aus /efi/loader/entries rumkopieren und lauter so Zeugs. Nervig, aber noch ungelöst, siehe u.a. https://github.com/ventoy/Ventoy/issues/3213.
Danke!
Ventoy habe ich hier auch, aber das mit der Persistance hatte ich bisher ignoriert.
Bin dann mal weg - Wochenende gelaufen
@FluepkeSchaeng: Habe gerade die Download-Seite bei Realtek wiedergefunden: https://www.realtek.com/Download/List?cate_id=584
Was mich allerdings etwas stört:
2.5G Ethernet LINUX driver r8125 for kernel up to 6.12 9.016.01 2025/08/15
Wir sind ja schon bei Kernel 6.15.9 bei Arch/EOS. Da der offizielle Kernel-Support ja im r8169-Kernelmodul ab Kernel 6.13 begann, kann das natürlich sein.
Habe im AUR mal einen diesbezüglichen Kommentar hinterlassen und das Paket als “out-of-date” geflagged.