Posts by Huetti

    live-stick wirst du wohl nur von Mint haben? Dann Partition und Verzeichnisse nach /mnt eingehängt?

    Ja, es musste die Partition gemounted werden. Dann mussten die Verzeichnisse /dev, /proc und /sys und /run mittels bind-Befehl eingebunden werden. Dann letztlich der chroot-Befehl und das Grub-Update konnte geschehen. Dann noch exit und reboot und hoffen. Hat letztlich geklappt.

    Moin,

    diese Frage an die KI gerichtet
    "dell latitude 7706 erkennt nach installation von linux manjaro den fingerabdrucksensor nicht."
    ergibt folgende Antwort:

    1. Hardware-ID prüfen

    Stellen Sie zunächst sicher, dass der Sensor vom System überhaupt gesehen wird. Öffnen Sie ein Terminal und geben Sie ein:
    lsusb
    Suchen Sie nach einem Eintrag wie 0a5c:5834 (Broadcom) oder 27c6:xxxx (Goodix).

    2. Unterstützung abgleichen

    Prüfen Sie Ihre ID in der Liste der unterstützten Geräte von libfprint.

    fprintd +1

    • Wichtig: Viele Latitude-Modelle nutzen Dell ControlVault 3. Diese Sensoren gelten unter Linux oft als "unsupported", da die Hersteller keine Spezifikationen für Open-Source-Treiber bereitstellen.

    3. Installation notwendiger Pakete

    Falls Ihr Gerät gelistet ist oder Sie es testen möchten, installieren Sie die Basis-Software:

    1. Software laden: sudo pacman -S fprintd.
    2. PAM-Konfiguration: Damit der Fingerabdruck für Logins genutzt wird, führen Sie sudo pam-auth-update aus und aktivieren Sie die Fingerabdruck-Authentifizierung (falls verfügbar).
    3. AUR nutzen: Für spezielle Dell-Sensoren gibt es im Manjaro AUR (Arch User Repository) oft Pakete wie libfprint-2-tod1-broadcom.

    4. BIOS-Check

    Stellen Sie sicher, dass der Fingerabdruckleser im BIOS unter Integrated Devices oder Security aktiviert ist.

    Hinweis: Sollte Ihr Sensor ein Broadcom-Modell (z.B. 0a5c:5834) sein, gibt es aktuell leider oft keine funktionierende Lösung für Linux.

    Welche ID wird Ihnen nach dem Befehl lsusb für den Sensor angezeigt?

    Ich hatte dieses Problem mit einem Dell Latitude 5530 und dort einem Broadcom und konnte das Problem dort mit der KI lösen.

    Moin zusammen,

    mir wurde gestern auch der Kernel 6.17.0-14 als Update installiert und ich zum Neustart aufgefordert. Gesagt, getan und...

    ... es erscheint noch das LM Logo und nix geht mehr! :(

    Guter Rat nun teuer, irgendwie herausgefunden, dass der Realtek WLAN Treiber Mucken macht.

    Leider konnte ich kein Grub-Menü aufrufen, da dieses sowohl auf "hidden" als in der Zeit auch auf "0" gestellt war. Zwar konnte ich mittels USB-Stick ein Mint Live-System booten, dort meine SSD mounten und im Verzeichnis etc/default/ auch die Datei "grub" so editieren und abspeichern, dass wieder ein Grub-Menü erscheint und mir die Möglichkeit gibt, mit einem älteren Kernel wieder zu starten.

    Problem nun aber: wie bekomme ich diese Aktion dann final mit dem Befehl "update-grub" für das nicht laufende System auf der gemounteten geregelt? Hier halt mir ein sehr versierter Linux-Kenner und ich lernte die Verwirklichung mittels "chroot" Befehl. Dazu sind noch einige Vorarbeiten notwendig, damit das Live-System mein,t es wäre auf der gemounteten SSD tätig.

    Letztlich hat es geklappt und ich bin zurück zu einem 6.14er Kernel und konnte mein System so wieder ans Laufen bekommen. Aber der erste Schreck nach Kernel-Update... :(

    Und in 22.3 funktioniert anscheinend die Ladestandsanzeige auf zumindest meinem Notebook (Elitebook 845 G10) nicht mehr korrekt. Zeigt zwar jetzt farblich an, aber keinen Fortschritt des Ladens mehr. In der Energieverwaltung wird der Ladefortschritt korrekt angezeigt, danach ändert sich auch die Leistenanzeige, jedoch ohne weiteren Fortschritt.

    Bin wohl lt. Reddit auch nicht alleine mit dem Problem...

    Moin Pinin ,

    mit dem Zumo XT und allen nachfolgenden Geräten gibt es die Problematik. Garmin hat das Übertragungsprotokoll geändert und damit kommen anscheinend nicht alle OS mit klar.

    In einer Windows VM kann ich meine Garmin Forerunner F35 ohne Probleme mit Garmin Express bedienen, alles klappt so wie es soll. Ist halt auch schon älter... Mit Zumo XT geht's nicht.

    Servus Huetti , ohne jetzt den ganzen Fred gelesen zu haben. Wiso benötigts du eigentlich Garmin Express? :/ Ich habe auch ein Zumo XT und spiele alle Software und Kartenupdates direkt über das WLAN in mein XT ein.

    Moin, weil es sehr selten einfach nicht via WLAN klappt! Im Normalfall mache ich es immer via WLAN.

    Moin Andi,

    den 1/2 Schritt habe ich mittlerweile auch hinbekommen. Wenn ich das XT einstecke erhalte ich auch seitens Linux Mint ja ne Fehlermeldung, dass das MTP-Gerät nicht eingehängt werden kann, aber in 9 von 10 Fällen kann ich dennoch mit dem Nemo auf das Gerät zugreifen, auf die internen und externen Speicher, lesend und auch schreibend. In den Windows VMs geht das tatsächlich nicht.

    Basecamp hatte ich gar nicht erst probiert, wäre evtl. dann noch gekommen, wenn Express einen Zugriff ermöglicht hätte. Mein Hauptziel war zunächst einmal, Kartenupdates via Express hinzubekommen. Beim vorletzten Kartenupdate musste ich nämlich via Windows PC meiner Frau das Update machen, da über WLAN selbst das XT eine Updatedauer von zuerst 23 Stunden zunehmend anzeigte und ich dann bei 133 Stunden den Vorgang abgebrochen habe. Gleiches Spiel dann auch leider die nächsten zwei oder drei Tage, dann hatte ich die Geduld verloren und Express auf dem noch vorhandenen Win 11 PC meiner Frau installiert und das Kartenupdate innerhalb einer Stunde abgeschlossen.

    Aber: mittlerweile ist auch der Win11 PC meiner Frau auf Linux Mint umgerüstet, es gibt kein Windows mehr in diesem Haushalt, geht nur noch auf meinem Notebook in VMs.

    Ich bin in der Sache noch nicht weiter gekommen, ich probiere es halt immer mal wieder, wenn entweder die VMs oder der Linux Kernel Updates bekommen haben, leider bisher ohne Erfolg. Grundsätzlich bin ich auch auf BC nicht mehr angewiesen, ich plane mit Kurviger und exportiere dann die Routen im GPX Format, schiebe die dann drahtlos auf mein XT. Das klappt sehr gut. Kartenupdates mache ich am Gerät via WLAN selbst, das letzte ging wieder tadellos. Meine Sorge ist, wenn das mal wieder nicht klappen sollte...

    Moin zusammen,

    kurzes Update: ich gebe auf! :(

    Ich hatte letzte Nacht noch stundenlang mit Gemini die Thematik systematisch behandelt, dabei kamen noch wirklich hilfreiche, aber vor allem lehrhafte Punkte zum Vorschein. Es gab sehr viele Versuche, das Zumo mit Garmin Express in der VM zum Laufen zu bekommen, alles, wirklich alles fruchtete nicht. Immerhin konnte die Durchleitung des Zumo von Linux zur VM ohne Probleme erreicht werden, aber dann zickte Garmin Express rum.

    Hier die finale Aussage von Gemini, als ich mitteilte, aufzugeben:

    Das ist absolut verständlich, und Sie haben Recht. Ihre Frustration spiegelt die häufige Erfahrung vieler Benutzer von modernen Garmin-Geräten (wie dem zūmo XT) und deren MTP-Protokoll in virtualisierten Umgebungen wider.

    Gerade weil wir alle gängigen und erweiterten Lösungen (USB-Controller-Wechsel, udev-Regeln, Treibermanipulation, Moduswechsel im Navi) ohne Erfolg durchgegangen sind, ist der Schlussfolgerung, dass die Kombination aus Virtualisierung und MTP-Geräten eine technische Sackgasse darstellt, korrekt.


    🛑 Die technische Realität und der Grund für das Scheitern

    Die Nichterkennung ist kein Fehler in Ihrer Konfiguration, sondern ein grundlegendes Kompatibilitätsproblem auf Protokollebene.

    1. MTP ist kein Massenspeicher

    Ältere Garmin-Geräte verwendeten den Mass Storage Mode (MSM). Hierbei präsentiert sich das Gerät dem PC wie ein USB-Stick, was in VirtualBox problemlos funktioniert, da der Zugriff auf Dateisystemebene erfolgt. Das Media Transfer Protocol (MTP) hingegen ist ein protokollbasierter Zugriff. Es erfordert, dass Host- und Gastsystem spezielle MTP-Treiber laden und über definierte API-Aufrufe miteinander kommunizieren.

    2. Der Bruch durch die Virtualisierung

    Die VirtualBox-USB-Emulation kann das MTP-Gerät zwar an Windows durchreichen, aber die Art und Weise, wie die virtuelle USB-Verbindung die notwendigen MTP-spezifischen Datenpakete von Garmin Express zur Hardware leitet, wird durch die Virtualisierung gestört oder blockiert.

    3. Garmin Express und Proprietäres Protokoll

    Garmin Express erwartet wahrscheinlich nicht den generischen Windows-MTP-Treiber, sondern einen proprietären Garmin-Treiber (der den MTP-Stream spezifisch verpackt). Wenn dieser proprietäre Stream durch VirtualBox läuft, wird er oft korrumpiert, sodass Garmin Express das Gerät zwar sieht, aber die Initialisierung der Kommunikation (der "Handshake") fehlschlägt.

    ✅ Ihre nächsten Schritte

    Da die VM-Methode gescheitert ist, bleiben Ihnen zwei zuverlässige Alternativen, um Ihr zūmo XT mit Garmin Express zu synchronisieren:

    1. Native Windows-Umgebung nutzen

    Verwenden Sie Garmin Express auf einem nativ installierten Windows-PC (oder Laptop) oder in einer separaten Windows-Boot-Partition (Dual-Boot). Hier gibt es keine Emulation, und die USB-Kommunikation ist direkt und stabil.

    2. Spezifische Linux-Programme nutzen

    Für Kartenverwaltung und Backups können Sie eventuell spezifische Linux-Programme nutzen, die nicht auf Garmin Express angewiesen sind. Tools wie BaseCamp (via Wine/Proton) oder QMapShack können manchmal Garmin-Geräte besser erkennen als Garmin Express in einer VM, da sie weniger proprietäre Kommunikationsschichten benötigen.

    Fazit: Sie haben alles richtig gemacht. Das Problem liegt nicht an einer fehlerhaften Einstellung, sondern an den technischen Einschränkungen der Virtualisierung im Umgang mit dem MTP-Protokoll.

    Ich wünsche Ihnen viel Erfolg mit der nativen Nutzung! Möchten Sie, dass ich Ihnen eine Anleitung zur Nutzung von BaseCamp über Wine in Linux Mint suche, falls Sie die Windows-VM komplett vermeiden möchten?

    === Gemini Ende

    Abschließend noch ein Wort zur Nutzung von KI: ich bin zuerst gar nicht darauf gekommen eine KI zum Thema zu nutzen, erst die Recherche nach den Bedeutungen der Menüpunkte des geheimen Zumo Diagnosemenüs brachte mich auf die Idee, die KI danach zu befragen. Das gezeigte Ergebnis veranlasste mich, mein Problem einfach mal zu prompten und ich war angenehm überrascht, wie gut das ging. Schrittweise wurde ich durch die Tiefen von Linux und der VM-Steuerung geführt, lernte Bereich kennen, in die ich niemals gekommen wäre. Vor allem wurde alles ausführlich erläutert, nicht einfach ein Eingabebefehl gegeben, den man machen sollte. Ich befürchte, ich habe einen kleinen Blick in die Zukunft bekommen. ;)

    Euch allen hier, die mir mit gut gemeinten Vorschlägen und Beiträgen zur Problemlösung beitragen wollten, danke ich SEHR HERZLICH und wünsche Euch eine gute Adventszeit. Vielen Dank...

    OK, Gemini gibt folgende Erklärungen:

    ⚙️ Explanation of MTP Mode Settings


    The MTP Settings menu on the zūmo XT is sparse and usually contains options related to file visibility when connected to a computer. The most commonly discussed and used option is:

    Menu ItemExplanationPurpose
    Show .System (or similar)A checkbox or toggle option that controls the visibility of the hidden .System folder on the device's internal storage when connected to a computer in MTP (Media Transfer Protocol) mode.When checked/enabled, it makes the critical and usually hidden system folder (.System) visible to the computer, allowing advanced users to access, modify, or backup essential system files, maps, and other configuration data. This is often necessary for certain maintenance tasks or using older third-party mapping software that relies on seeing these files.

    That's a great question, as these options are part of the advanced configuration for how your device manages its USB connection. The Garmin zūmo XT and similar modern Garmin automotive devices use the Media Transfer Protocol (MTP) by default, which functions differently from the older Mass Storage Mode (MSM).

    Here is the explanation for the items you see in the MTP Mode Settings on your zūmo XT's diagnostic menu:


    💻 MTP Mode Settings Explanation

    These settings primarily determine the behavior of the device when it is physically connected to a computer via a USB cable.

    Menu ItemExplanationFunction & Context
    MTP Auto DetectThis is the default and standard connection mode for modern Garmin devices, including the zūmo XT.When selected, the device automatically attempts to connect to the computer using the Media Transfer Protocol (MTP). MTP treats the device as a "Portable Device" rather than a standard drive letter (like C: or D:), which is generally more secure and compatible with modern operating systems (especially Windows).
    USB EthernetThis mode is functionally equivalent to the older Mass Storage Mode (MSM) on many Garmin devices.Selecting this option forces the zūmo XT to present itself to the computer as a Mass Storage Device (a standard removable drive with a dedicated drive letter). This mode is often preferred by advanced users or for compatibility with older Garmin utilities (like MapSource) because it allows direct, unrestricted access to the device's entire file system, including the hidden .System folder. It is often referred to internally as "USB Ethernet" because the USB connection is sometimes managed via a virtual network interface, a modern way of handling the file access.
    USB Ethernet Single SessionThis is a variant of the USB Ethernet/Mass Storage Mode.When selected, the device attempts to present itself as a Mass Storage Device, but with the additional constraint of allowing only one connection or file session at a time. This is a very specific, restrictive setting, likely used for troubleshooting or highly controlled file operations, preventing multiple applications from accessing the device simultaneously.

    Und dann noch der Unterschied zwischen MTP und Mass Storage Device:

    MTP Mode vs. Mass Storage Mode

    • MTP (Media Transfer Protocol): This is the modern, default connection mode for the zūmo XT. It treats the device more like a media player or modern smartphone, where files are accessed via a protocol rather than a distinct drive letter. In this mode, certain sensitive system files are hidden by default.
    • Mass Storage Mode (MSM): This mode, common on older Garmin devices, treats the GPS unit like a simple USB flash drive (a "Mass Storage Device") with a dedicated drive letter. The zūmo XT generally does not natively use a full Mass Storage Mode like its predecessors, but the "Show .System" option provides a functional workaround to expose the device's critical files, behaving somewhat like the older Mass Storage Mode in terms of file visibility.

    Da habe ich ja morgen ordentlich etwas zum Probieren. ;)

    Welcher Modus (MTP?) ist denn in deinem Garmin XT aktiviert?

    Diese Anleitung funktioniert bei meinem Nüvi anstandslos, ob es auch bei deinem XT funktioniert weiß ich nicht, aber Versuch mach Klug.

    Whow, ist schon enorm, was ich hier noch alles so lernen kann! Dieses geheime Menü kannte ich noch gar nicht.

    Meine Einstellung:

    Im zweiten Bild traue ich mich noch nicht, das "Show System" zu enablen, da muss ich mich erst einmal etwas schlauer lesen.

    Vielleicht einfach mal die Autodetect Einstellung abschalten und das Gerät von Hand einbinden.

    Das Autoplay hatte ich nun abgeschaltet und Win-VM neugebootet. Aber das bringt nix, da im Gerätemanager trotzdem ein tragbares MTP-USB Gerät eingetragen wird, jedoch keine Aktion bei Start ausgeführt werden. Dann hatte ich im Gerätemanager das Gerät deinstalliert und versucht, es anschließend ale ein neues Gerät im System zu finden, klappt nicht, es wird nicht gefunden.

    Mir schwant immer mehr, dass Garmin bei den Zumo-Geräten sich nicht kompatibel zum MTP Protokoll verhält, denn es gibt ja auch unter Linux MTP-Fehlermeldung, auch wenn der Zugriff anschließend häufig klappt. Windows selbst (nicht in VM) ist da evtl. fehlertoleranter.