Posts by UncleBens

    Hallo, ja wenn ich boote startet zuerst der Win10 Bootmanager und listet wie zuvor Win 7 und Win 10 zur Auswahl an.
    Das Linux ist Astra Linux. Ich weis tatsächlich gar nicht mehr genau ob nicht doch Grub installiert wurde, jedenfalls nicht so dass der Windows Bootmanager überschrieben worden wäre.

    Ich denke nicht, dass Grub installiert wurde.... sonst wäre das Verhalten anders (zumindest ist es bei mir so):

    Auf einem Rechner hier hatte ich ein DualBoot zwischen Windows 10 und Windows Server 2022 (und der normale Windows Boot-Manager ließ mich beim Boot auswählen welches der beiden ich haben möchte).
    Hab vor einiger Zeit zusätzlich Mint auf eine separate SSD installiert und das Mint-Setup einfach sein Ding machen lassen. Mit dem Resultat: es bootet Grub, der mich wählen lässt ob ich Mint oder den Windows Boot Manager haben möchte. Wähle ich Mint, startet wenig überraschend Mint, wähle ich Windows Boot Manager kommt (ebenfalls wenig überraschend :D ) wieder der schon vorher dagewesene Windows Boot Manager mit der Auswahl zwischen Windows 10 und Windows Server 2022.

    Ich war lange nicht mehr auf Windows unterwegs. Ich glaube, RAR muss man installieren, bevor man es entpacken kann. Auf Linux ist so etwas in den meisten Fällen schon implementiert.

    Man mag es kaum glauben, aber das hat Microsoft mittlerweile in Windows 11 implementiert ;)
    Bis dahin ist Deine Aussage aber korrekt.

    Zum eigentlichen Thema dieses Threads: wow! Beeindruckend, wie viel Herzblut grinseengel in seine Spiele steckt. Tolle Sache :)

    So suche ich mindestens noch einer Alternative für https://www.papyrus.de/ und https://ulysses.app/..
    Programme wie Bibisco und Manuskript gefielen mich so gar nicht...

    Papyrus scheint wohl recht gut mit Crossover unter Mint zum Laufen zu kriegen zu sein:

    Papyrus Autor 10 unter Linux Mint/Ubuntu mit Crossover installieren
    Papyrus Autor kann in Linux Mint und Ubuntu ohne großen Aufwand mit dem Programm Crossover installiert werden. Crossover ermöglicht die Ausführung von…
    community.papyrus.de

    Wobei ich persönlich versuche, auf WINE zu verzichten und native Linux-Anwendungen zu nutzen... und ja, ich stimme Dir zu, dass mir manches auch weniger "gefällt". Da muss man dann mit sich ausmachen, was einem wichtiger ist. Ich liebe z.B. Screenpresso (Tool zum Erstellen/Verwalten/Bearbeiten von Screenshots) oder RoyalTS (Tool zum Verwalten von RDP/SSH-Sitzungen). Für beides gibt es Linux-Alternativen, die mir deutlich weniger gefallen. Aber ausreichen. Man muss versuchen sich die Erwartungshaltung "ich finde etwas, das mindestens genauso ist wie das, was ich bisher genutzt habe" abzugewöhnen... sonst wird man denke ich nicht wirklich glücklich.

    Und: manchmal muss man einfach seinen "Workflow" umstellen. Ich hab z.B. relativ lange damit gehadert, dass iTunes nicht unter Linux läuft (auf WINE wollte ich wie oben gesagt nicht zurückgreifen). Denn ich hab (historisch gewachsen, wie man so schön sagt ;-)) meine iTunes-Bibliothek in hunderte Playlists geordnet (das stammt noch aus Zeiten, wo der Speicherplatz auf iPhone und iPad recht knapp bemessen war und Playlist das Mittel der Wahl war zu steuern was synchronisiert werden soll). Rhythmbox hat zwar ganz schön nach Alben sortiert, aber so ganz warm wurde ich mit rhythmbox leider nie. Irgendwann kam ich auf die Idee, dass man die iTunes-Playlisten ja als m3u exportieren kann. Das hab ich dann hundertfach gemacht... und hab nun Playlists, die ich mit VLC abspiele. Im Prinzip genauso komfortabel wie in iTunes, nur halt etwas anders. Hat mich ein dreiviertel Jahr gekostet bis ich auf die Idee gekommen bin :D

    Eine Alternative ist natürlich immer: Windows in einer VM (mit macOS wirds leider nicht so leicht :-)) oder als Parallelboot für Software, auf die man nicht verzichten möchte/kann..

    kim88 hat oft genug geschrieben das Linux nicht sicherer ist als andere.

    Es gibt nichts was "Sicher" ist.

    Mhh, das sind zwei unterschiedliche Aussagen... der zweiten würde ich zustimmen.

    Der ersten würde ich widersprechen, da es durchaus Konzepte von Linux gibt, die es sicherer machen, als es etwa bei Windows der Fall ist.

    Beispiel "Rechnung.pdf.exe" die jemand mit ausgeblendeten Dateiendungen (was mir unbegreiflich ist, dass MS das im Jahre 2024 nach wie vor als Default verteilt) ausführt. Passiert Dir unter Linux schon allein deshalb nicht, weil Du ein Binary unter Linux erstmal ausführbar machen musst. Natürlich ist auch das nicht 100%ig sicher (wo wir wieder bei meiner Aussage "sicher nein, sicherer ja" wären): einen Anwender, den man dazu bringt, Makros in Office zu aktivieren um den Schadcode auszuführen wird man auch dazu bringen können, das Executable-Bit zu setzen.

    Trotzdem würde ich schon sagen, dass Linux an dieser (!) Stelle sicherer ist als Windows.

    Warnung bei älteren Nvidia-Karten und Upgrade auf Mint 22

    Hi zusammen,

    nachdem hier einige schreiben, dass sie ältere Nvidia-Karten nutzen und über ein Upgrade auf 22 nachdenken, möchte ich eine Warnung loswerden. Denn ich hab mir dadurch gestern auf einem iMac (2013 mit einer "GeForce GTX 780M Mac Edition") mein Mint zerschossen. War nicht weiter schlimm, da es eine reine Surf/Mailmaschine ohne wichtige lokale Daten ist und ich dann einfach eine frische Installation von 22 gemacht habe. Aber das Glück hat vielleicht nicht jeder :)

    Schaut mal in der Treiberverwaltung (heißt das so auf Deutsch? Ich nutz ein englisches Mint, da ist es Driver Manager) nach, was für ein Grafiktreiber aktuell verwendet wird. In meinem Fall wars der Nvidia-Treiber in Version 390. Der älteste Nvidia-Treiber, der von Mint 22 unterstützt wird, ist wohl Version 470.

    Das Upgrade von Mint 21.3 auf Mint 22 lief fast bis zum Ende durch... und brach dann beim Bauen der Kernel-Module ab als er versuchte, den Nvidia-Treiber reinzubauen. Das schlug fehl, denn: Mint 22 (oder genauer Ubuntu 24.04) unterstützt die Treiberversion nicht mehr und mintupgrade hat komplett abgebrochen. Bei mir kam dann auch noch dazu, dass sich der Timeshift-Restore zurück zu 21.3 aufgehängt hat (vielleicht war ich auch zu ungeduldig) und ich letztlich nach einem Reset in eine kernel panic gebootet habe.

    Von daher: im Zweifelsfall lieber vor dem Upgrade den Nvidia-Treiber in der Treiberverwaltung deaktivieren (sprich zurück auf den Nouveau-Treiber wechseln) und nach dem Upgrade wieder den Nvidia-Treiber installieren (wenn ihn Mint 22 nicht mehr anbietet, wird die Karte nicht mehr unterstützt und Ihr müsst bei Nouveau bleiben).

    Bei FOSS Software ist es natürlich so, dass jeder prinzipiell etwas beitragen kann, das aber nicht heißt, dass jeder einfach so seine Änderungen in den Quellcode einbauen kann. Das läuft in etwa so ab, dass sich Leute den Quellcode Klonen, dann beliebig daran „rumschrauben“ können, und dann mit einer Merge request ihre Änderungen hochladen. Diese werden dann aber noch von Leitern der Projekte überprüft bevor sie letztendlich, falls überhaupt, in das Projekt aufgenommen werden. Solange also die Projektleiter nicht einfach alle Änderungen pushen kann da nicht viel passieren.

    Dass durchaus (zumindest beinahe) viel passieren kann, hat sich dieses Jahr im Frühjahr gezeigt... Stichwort "xz tools". Bitte nicht falsch verstehen, damit will ich keinesfalls drauf raus, dass OSS schlecht ist. Eher im Gegenteil :) Denn es hat sich ja gezeigt, dass es glücklicherweise doch noch einem aufmerksamen (ironischerweise: Microsoft-)Entwickler aufgefallen ist. Fand ich einerseits total beeindruckend, wie das rausgekommen ist (nur weil er sich gewundert hat, dass in seinem eigenen Code etwas ein paar Milisekunden länger gedauert hat und er dann tiefer nachgebohrt hat) - und andererseits auch etwas beängstigend, dass solch zentrale Komponenten letztlich an einer einzigen Person hängen.

    Vielleicht ein guter Zeitpunkt dran zu erinnern, dass man einem OSS-Projekt seiner Wahl mal wieder eine kleine Spende zukommen lassen könnte. :)

    Golo Roden hat die ganze "Dramatik" für heise zusammengefasst... ein meiner Meinung nach sehr lesenswerter Artikel:

    Aktenzeichen XZ ungelöst
    In den vergangenen Tagen sind wir mit sehr viel Glück dem wohl größten Fiasko in der Geschichte des Internets gerade so entgangen. Wie konnte das passieren?
    www.heise.de

    Hi,

    ich würde aus meiner persönlichen Erfahrung raus auch Mint mit Cinnamon empfehlen. Das hat's zumindest geschafft, bei mir zum Haupt-OS zu werden.

    Mein erster Linux-Kontakt war Ende der Neunziger mit SuSE (ich glaube 6.3 war das ^^). Und seitdem hatte ich immer wieder "on-off-Beziehungen" mit verschiedenen Distris, teils als VMs, teils auch wirklich auf der Physik (ich glaub der letzte ernsthafte Versuch vorher auf Physik war 2008 mit Ubuntu, danach nur noch VMs). Und damals bei Ubuntu hab ich ich nach 2 Monaten aufgegeben, weil zu viel nicht ging (und mich der "System Seller", die tollen Compiz-Fenstereffekte, nicht auf Dauer darüber hinweg trösten konnten). Mit KDE dagegen konnte ich mich irgendwie bis heute nicht anfreunden.

    Dass ich Mint mal eine Chance auf Physik gegeben habe... daran ist Jean Schuld :P
    Bin letztes Jahr im Sommer durch Zufall über ein Video von LinuxGuides bei YouTube gestolpert, dran hängen geblieben... und dann ist es passiert. Seitdem nutze ich zu weit über 90% Mint... Windows boote ich nur in speziellen Fällen (Sync der iDevices mit iTunes, manche Spiele die nicht via Proton unter Steam laufen, Download von gekauften MP3s mit der Amazon Music App).

    Von daher würde ich auch diese Empfehlung teilen: mach erstmal einen Parallelboot zu Windows. Die Gefahr bei einem "Sprung ins kalte Wasser" ist: irgendwas was Du GANZ DRINGEND brauchst geht nicht. Und dann ist ein "Frust auf Linux" vorprogrammiert :)

    Soderle, ich hab eine gute und eine halbschlechte Nachricht :)

    Die gute Nachricht: ich habe eine Lösung (oder lasst es uns mal mehr einen Workaround nennen) für das eigentlich zugrundeliegende Problem "die NIC funktioniert mit 2,5GBit auf aktuellem 6.5er Kernel nicht mehr" gefunden.

    Meine Vermutung, dass es tatsächlich der Wechsel von cdc_ncm auf r8152 war, trifft zu. Ich bin die Tage schon mal auf die blacklist.conf gestoßen und dachte mir "wäre mal interessant zu sehen was passiert wenn ich den r8152 auf die Blacklist setze... lädt er dann gar keinen Treiber mehr oder vielleicht wieder den alten Funktionierenden?".
    Also hatte ich die Tage schon mal testweise die zwei Zeilen "blacklist r8152-cfgselector" und "blacklist r8152" in der blacklist.conf angefügt, was aber nichts geändert hatte. Den Ausschlag gegeben hat nun eine Anmerkung, die ich in der Doku zu Kernelmodulen bei ubuntuusers.de gefunden habe: "Manchmal kann es erforderlich sein, das initramfs mit dem Befehl update-initramfs -u zu aktualisieren, wenn die Module trotz Blacklisting nach einem Neustart wieder geladen werden."
    Genau das war der Fall... nachdem ich das gemacht habe, kann ich den aktuellen 6.5.0-44-generic booten, es wird automatisch wieder cdc_ncm geladen und 2,5GBit funktioniert tadellos.

    Warum ich es eher als Workaround denn als Lösung bezeichnen würde: es wäre vermessen davon auszugehen, dass sich die Kernel-Entwickler nicht irgendwas dabei gedacht hätten, den Treiber zu wechseln. Von daher gut möglich, dass mir das irgendwann wieder auf die Füße fallen könnte (keine Ahnung, vielleicht soll cdc_ncm wirklich künftig rausfliegen o.ä.). Aber zumindest für den Moment habe ich nun einen aktuell gepatchten 6.5er Kernel in Kombination mit der funktionierenden NIC. Zwischenzeitlich hat das Mint-Team ja auch 6.8 für Mint 21.3 freigegeben, wenn ich zu viel Zeit hab probiere ich mal noch aus ob mein Workaround damit auch noch funktioniert oder ob er mir spätestens beim Update auf Mint 22 (was ja 6.8 mitbringt) schon wieder um die Ohren fliegt :) [EDIT 23.07.24 12:01: grade mit Kernel 6.8.0-38-generic unter Mint 21.3 Cinnamon getestet: funktioniert nach wie vor, wird immer noch cdc_ncm geladen]

    Die halbschlechte (^^) Nachricht: so 100%ig verstanden wie ich steuern kann, welchen Treiber Mint für welches Device lädt hab ich nach wie vor nicht. OK, ich hab jetzt gelernt, wie ich via blacklist verhindern kann, dass ein bestimmter Treiber überhaupt geladen wird und habe Glück, dass dadurch automatisch wieder der alte Funktionierende geladen wird. Aber mein Versuch einer "/etc/modprobe.d/asus-usb-nic.conf" mit dem Inhalt "alias enx107c612b8973 cdc_ncm" hatte nichts gebracht (die hab ich vor meinem erneuten, erfolgreichen Anlauf mit der blacklist.conf auch wieder gelöscht), es wurde trotzdem r8152 geladen. Also entweder war meine Herangehensweise hier einfach komplett falsch... oder es ist ähnlich wie bei der blacklist.conf, dass ich danach noch irgendwas ausführen muss. update-initramfs -u hatte aber in dem Fall nix gebracht :/ Also falls da noch jemand einen Tipp hat, gerne her damit.

    Ansonsten nochmal vielen Dank an Euch drei!

    Du wirst hier wahrscheinlich eth0 durch enx107c612b8973 ersetzen müssen - versuch macht kluch ;)

    Da hast Du völlig Recht, das ist mir gestern direkt nach dem Abschicken meines Posts auch noch aufgefallen ^^
    Hab ich gestern auch noch probiert, in der Tat kam dann auch nicht der Fehler "no such device" sondern gar keine Rückmeldung... funktioniert hats aber leider trotzdem nicht :) Kann natürlich durchaus sein, dass dieser Aufruf den ASUS-eigenen Treiber voraussetzen würde und mit dem mitgelieferten nicht implementiert ist...

    Dem kann ich mich nur anschließen - eventuell kommt ja mit einem neueren Kernel auch wieder Besserung ........

    Das war auch meine Hoffnung, weshalb ich mal die Beta von Mint 22 probiert hatte, die ja den 6.8er mitbringt... der zeigt das Verhalten leider auch noch. Aber die Hoffnung stirbt natürlich bekanntlich zuletzt :D

    Wie sollte ich denn Wissen, dass du schon ganz viel versucht hast. Meine Glaskugel ist leider beim Service ...
    Ich wollte einfach nur helfen .......

    OK - habe dann hier auch nichts mehr zu sagen ....

    Hmm, das klingt jetzt irgenwie verletzt? Wenn ja tut mir das sehr leid. =O
    Ich hatte doch extra geschrieben "nochmal danke für Deine Hilfe... und ich hoffe Du liest in meinen nächsten Zeilen nichts raus, was Du als "Undankbarkeit" auffasst, denn so wäre es nicht gemeint" :?:
    Natürlich konntest Du das nicht wissen (und vermutlich liegt Deine Glaskugel beim gleichen Servicebetrieb wie meine ;)). Das war doch nur der Versuch einer Erklärung warum ich mein Ursprungsposting relativ knapp an Details gehalten und gleich konkret gefragt hatte, wie ich steuere welchen Treiber Mint für ein Device nimmt.

    Wenn Du Dich trotzdem ausklinken möchtest ist das natürlich OK... vielen Dank nochmal für Deine Mühe <3

    Was spricht für dich eigentlich dagegen, mit dem etwas älteren Kernel zu leben? Ich bin hier immer noch auf 5.15 irgendwas und bleibe wohl auch erst mal dabei. Mit irgendeinem sechser Kernel ist ab und zu die Kiste eingefroren und ich sehe keinen Nachteil (für mich) den älteren Kernel weiter zu benutzen.

    Mhh... eigentlich nur, dass diese "Minor Releases" innerhalb der 6.5.0er Reihe (analog der 5.15er Reihe) doch Security-Updates mitbringen die man mitnehmen sollte, oder habe ich das missverstanden?
    Ich hab übrigens auch mit 5.15 getestet... da ist das Verhalten das gleiche... der aktuelle 5.15er zeigt das Problemverhalten, mit einem alten 5.15er gehts. Hier bin ich allerdings nicht so weit gegangen wie bei der 6.5.0er, sprich gesucht ab wann genau in der 5.15er Linie der Treiber gewechselt wurde.
    Auch die Beta von Mint 22 mit 6.8 und (vermutlich wenig überraschend, nachdem Mint 22 drauf basiert :-)) Ubuntu 24.04 zeigen das Problem.

    Man kann entweder eine modprobe.conf erzeugen oder besser, so wird es inzwischen mit den einzelnen Modulen gemacht, unter modprobe.conf.d eine Datei mit entsprechendem Inhalt eintragen.

    Hmm, aber es existiert ja in dem Verzeichnis aktuell keine Datei, die sagt "nimm r8152" für das Device und trotzdem machts der Kernel. OK, wenn ich Dich richtig verstehe meinst Du, ich sollte mal probieren eine "usb-nic.conf" (der Name scheint ja egal zu sein, Hauptsache .conf und in dem Verzeichnis?) in dem Verzeichnis anzulegen? Und dann alias enx107c612b8973 cdc_ncm rein?

    Hi Josefine,

    nochmal danke für Deine Hilfe... und ich hoffe Du liest in meinen nächsten Zeilen nichts raus, was Du als "Undankbarkeit" auffasst, denn so wäre es nicht gemeint. Was durchaus mitklingen könnte ist ein gewisser Frust (der sich aber in keiner Form auf Dich oder ein anderes Forenmitglied bezieht), denn ich hab schon ziemlich viel Zeit in das Thema investiert ^^

    Jetzt sind wir wieder bei meinem Ursprungsposting angekommen, als ich schrieb "ohne zu sehr ins Detail gehen zu wollen um Euch nicht zu erschlagen" So langsam landen wir doch im Detail. :)

    Die Seite kenne ich... den Treiber auch. Leider ist es ja eben kein fertiger Treiber, den man runterlädt, sondern Sources und ein Makefile zum Selberbauen. Make fliegt mit zigtausend Compilerfehlern raus... und der frischeste ist der Treiber ja auch nicht grad, wie man anhand des "Kernel v4.10 and later" sieht. Die README ignoriert den Part des Installierens komplett und spricht nur von "You may have to run the following command after installing the driver"... meine Vermutung wäre "make" und anschließend "make install" gewesen, aber wie gesagt, fliegt mit ziemlich vielen Errors raus. Den Command aus dem ReadMe habe ich auch getestet (allerdings mit dem vom Kernel mitgebrachten r8152 Treiber)

    Code
    sudo ethtool -s eth0 autoneg on advertise 0x80000000002f             
    netlink error: no device matches name (offset 24)
    netlink error: No such device

    Wenn wir schon auf den Weg in das tiefe Hasenloch sind ;) Den ASUS-Support hatte ich frühzeitig kontaktiert... ob ich es mit dem Treiber probieren soll. Deren Aussage war zusammengefasst "den Treiber von unserer Seite brauchst für aktuelle Linux-Versionen nicht, wird out of the box unterstützt".
    Was ja auch stimmt - aber eben leider ab Kernel 6.0.5-27 und neuer nicht mehr. Zumindest nicht mit 2,5GBit. Dazu hat der ASUS-Support bisher auch noch keine schlaue Idee :)

    Achja, und um noch ein bissl weiter runterzusteigen: ich habe das Ganze mal auf einem Rechner getestet, der Windows 10 im Dualboot hat. Unter Windows 10: 2,5GBit kein Problem, funktioniert genauso wie unter Linux pre-6.0.5.-27. Boote ich ein einziges mal einen Linux Kernel neuer als 6.0.5-26, tritt das beschriebene Phänomen nach einem Reboot auch unter Windows 10 auf. Oder wenn ich danach einen Kernel 6.0.5-26 boote: geht auch nicht mehr. Solange bis ich den Rechner wirklich komplett runterfahre. Nach einem Coldboot ist wieder alles OK (so lange bis ich wieder 6.0.5-27 oder neuer boote). Sprich: was auch immer der r8152 mit der Karte "kaputtmacht" (in Ermangelung eines besseren Wortes ;)): es überlebt sogar einen Warmstart und macht es für andere Betriebssysteme "kaputt".

    Das mal so als "kleiner Exkurs" in meine Freizeitbeschäftigung der letzten 2-3 Wochen 8o

    Deshalb wollte ich jetzt einfach mal einen Schritt zurückmachen wollen und nochmal zur ursprünglichen Frage zurückkommen (die mich auch ganz unabhängig von dem konkreten Problem interessiert): anhand welches Kriteriums entscheidet Mint, welcher Treiber für welches Device geladen wird? Ich würde mir erhoffen, dass der bisher funktionierende cdc_ncm auch weiterhin klappt - denn wie schon in meinem Ausgangspost geschrieben: ihn gibts ja nach wie vor. Zumindest würde ich das gerne mal verifizieren (oder eben... ausschließen). Aber da scheiterts eben daran, dass ich nicht mal weiß wie ich Mint beibringe "nimm diesen Treiber". Bei Windows wüsste ich's (amüsantes am Rande... der ASUS-Supporter meinte auch zwischendurch mal "if it is possible reinstall the drivers from the device manager equivalent and restart". Genau... dieses device manager equivalent würde mich interessieren ;-))

    Aus einem Linux-Buch (Kofler) glaube ich verstanden zu haben, dass es dafür eigentlich eine /etc/modprobe.conf gibt, in der z.B. per "alias eth0 8139too" gesteuert wird, dass das Modul 8139too geladen wird. Von daher war meine naive Vorstellung, dass es in der /etc/modprobe.conf auch irgendwo etwas geben muss à la "alias enx107c612b8973 cdc_ncm" bzw "alias enx107c612b8973 r8152" bei neueren Kerneln. Oder hab ich hier einen Denkfehler bzgl. Treiber / Modul?

    Es scheitert aber schon daran, dass ich unter Mint die modprobe.conf gar nicht erst finde :) Es gibt /etc/modprobe.d - aber auch darin keine modprobe.conf oder etwas in der Richtung :/

    Viele Grüße
    Ben
    PS: ich seh schon, mein "nicht zu sehr ins Detail gehen" ging super auf ;)

    Hallo Ihr beiden,

    danke für Eure Rückmeldung, anbei die gewünschten Ausgaben.
    In beiden Fällen wurde frisch gebootet und die USB NIC nach dem Anmelden verbunden

    Gutfall (Boot von 6.5.0-26-generic)

    Code
    Device-4: ASUSTek USB 10/100/1G/2.5G LAN type: USB driver: cdc_ncm
      IF: enx107c612b8973 state: up speed: 2500 Mbps duplex: half
        mac: 10:7c:61:2b:89:73


    Schlechtfall (alles neuer als 6.5.0-26, im konkreten Fall mit 6.5.0-44-generic durchgeführt)

    Code
    Device-4: ASUSTek USB 10/100/1G/2.5G LAN type: USB driver: r8152
      IF: enx107c612b8973 state: up speed: 2500 Mbps duplex: full
        mac: 10:7c:61:2b:89:73


    Wie Ihr seht ist in beiden Fällen der Port up... Unterschied ist einmal der Treiber und einmal Duplex. Ich habe im Schlechtfall (also mit dem r8152 Treiber) auch mal manuell mit ethtool die Karte auf half gesetzt... ändert nichts am Problem.

    Nachdem wir jetzt ja doch recht ins Detail abgetaucht sind: das genaue Problem ist übrigens, dass die Karte mit r8152 zwar hochkommt, ich aber nicht mal die 192.168.178.1 anpingen kann, geschweige denn ins Internet komme. Und damit es noch komplizierter wird: das Problem tritt ausschließlich auf, wenn der Port mit 2,5GBit konfiguriert ist. Lasse ich den Port auf 1GBit/s, ist auch der r8152-Treiber happy. Wie Ihr Euch aber vielleicht denken könnt war der Grund für den Kauf der USB-NIC, dass ich 2,5GBit nutzen möchte ;)
    Aktuell habe ich also die Wahl einen alten Kernel mit 2,5GBit zu nutzen oder einen aktuellen Kernel mit 1 GBit. Ziel wäre - wenig überraschend: aktueller Kernel und 2,5GBit :)

    Gruß
    Ben

    Hallo liebes Forum,

    vorab: ich habe absichtlich den inxi -Fzxi Output nicht mitkopiert, da sich meine Frage nicht auf einen spezfischen Rechner bezieht, sondern recht generell gehalten ist. Falls trotzdem Infos benötigt werden, bitte gerne nachfragen :)

    Könnte mir bitte jemand erklären, wie ich unter Mint 21.3 Cinnammon festlegen kann, welcher Treiber für ein bestimmtes Device geladen wird?

    Hintergrund meiner Frage (ohne zu sehr ins Detail gehen zu wollen um Euch nicht zu erschlagen): ich habe eine ASUS USB-Netzwerkkarte, die problemlos bis einschl. Kernel 6.5.0-26 funktioniert und bei allen neueren Kernel-Versionen nicht mehr.

    Im Rahmen meiner Recherchen habe ich via inxi -n festgestellt, dass Mint für die Karte bis einschl. 6.5.0-26 als Treiber cdc_ncm lädt und bei allen neueren Kernel-Versionen r8152. Und das wäre natürlich erstmal eine naheliegende und plausible Erklärung, warum es ab genau dieser Kernel-Version nicht mehr klappt.

    Nun würde ich gerne testen, ob die USB-Netzwerkkarte auf einem aktuellen 6.5.0-44 funktionieren würde, wenn als Treiber cdc_ncm verwendet wird.
    Nur habe ich leider absolut keine Ahnung, wie ich das anstelle. :/
    Vorhanden ist er anscheinend nach wie vor:
    modinfo cdc_ncm
    filename: /lib/modules/6.5.0-44-generic/kernel/drivers/net/usb/cdc_ncm.ko

    Herzlichen Dank schon mal vorab für Eure Unterstützung :)

    Viele Grüße
    Ben