(gelöst) devuan 3, Eigenbaukern, pmount, Tolino

[fischig]

Ich habe ein Problem mit devuan 3, Eigenbaukern, pmount, vfat (Tolino-Lesegerät).
Auf dem einen System kann ich als Nicht-Root einen Tolino mit Vanilla-Eigenbaukern 4.19 via vfat problemlos einhängen (so wie auch auf Debian 11 Maschinen), auf dem anderen nur mit Standardkern 4.19. Es geht im folgenden nur um Devuan.
Dort, wo's funktioniert, ist vfat (ich nehme das wird benötigt) fest im Kern einkompiliert, auf dem anderen nur als Modul, das aber geladen ist.
Fehlermeldung

Code: Alles auswählen

$ pmount sdc ust
mount: /media/ust: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
mount: /media/ust: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
Fehler: konnte Mount-Verzeichnis nicht löschen: Datei oder Verzeichnis nicht gefunden

Das Verzeichnis /media/ust ist vorhanden.
Auch im Standard-Kern sitzt vfat lediglich als Modul, das kann dann den Unterschied wohl nicht ausmachen.

Irgendwie meine ich dunkel zu erinnern, dass man in Debian noch eine pmount-konfig-Datei editieren musste, um ein vfat-Dateisystem via pmount einhängen zu können. Lang, lang ist's her und unter /etc habe ich vergleichend bisher nichts gefunden.

edit:
Die letzte dmesg-Ausgabe:

Code: Alles auswählen

[  226.674662] usb 5-2: new high-speed USB device number 3 using xhci_hcd
[  226.833059] usb 5-2: New USB device found, idVendor=1f85, idProduct=6053, bcdDevice=99.99
[  226.833163] usb 5-2: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[  226.833237] usb 5-2: Product: tolino
[  226.833302] usb 5-2: Manufacturer: Rakuten Kobo Inc.
[  226.833369] usb 5-2: SerialNumber: 95057438,d85d97dbf9fb496cb135bfa4d0ee0c6d
[  226.846889] usb-storage 5-2:1.0: USB Mass Storage device detected
[  226.847427] scsi host2: usb-storage 5-2:1.0
[  227.860052] scsi 2:0:0:0: Direct-Access     Linux    File-CD Gadget   0000 PQ: 0 ANSI: 2
[  227.861215] sd 2:0:0:0: Attached scsi generic sg2 type 0
[  227.862887] sd 2:0:0:0: Power-on or device reset occurred
[  227.868991] sd 2:0:0:0: [sdc] Attached SCSI removable disk
[  231.962154] sd 2:0:0:0: [sdc] 12204102 512-byte logical blocks: (6.25 GB/5.82 GiB)
[  231.966280] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  231.981903]  sdc:
[  249.481075] FAT-fs (sdc): codepage cp437 not found
[  249.501203] FAT-fs (sdc): codepage cp437 not found
[  249.574876] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.586936] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.599212] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.611620] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.624072] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.636209] EXT4-fs (sdc): VFS: Can't find ext4 filesystem
[  249.810805] ntfs: driver 2.1.32 [Flags: R/W MODULE].
[  249.825123] ntfs: (device sdc): parse_options(): NLS character set utf8 not found.
[  249.843421] ntfs: (device sdc): is_boot_sector_ntfs(): Invalid boot sector checksum.
[  249.843528] ntfs: (device sdc): read_ntfs_boot_sector(): Primary boot sector is invalid.
[  249.843617] ntfs: (device sdc): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
[  249.843708] ntfs: (device sdc): ntfs_fill_super(): Not an NTFS volume.

[fischig]

So, ich hab's:

Code: Alles auswählen

~$ lsmod
Module                  Size  Used by
nls_iso8859_1          16384  1
nls_cp437              20480  1
nls_ascii              16384  0
vfat                   20480  1
fat                    86016  1 vfat
[...]

Sollte auf jedes aktuelle Debian-System übertragbar sein.
ohne nls_iso8859_1 funktioniert's nicht, auch wenn die anderen Module geladen sind. Scheint zusammen mit vfat das Notwendige zu sein. Den Rest teste ich jetzt nicht mehr auf Entbehrlichkeit. Für heute schickt's (hessisch!)

[Livingston]

Der devuan-Kernel ist meines Wissens nach mit dem debian-Kernel identisch. Die Paketquellen von devuan nutzen den sog. merged-Mechanismus, d.h. soweit Pakete unverändert unter devuan genutzt werden können, werden sie durch eine Umleitung aus dev.debian.org bezogen. Der devuan-spezifische Anteil des Repositorys stammt dann von devuan.org. Ich meine, dass es seitens der Devuaner bislang keinen Anlass gab, am debian-Kernel herumzuschrauben.

Achte mal beim Update darauf, woher der Kernel stammt.

[fischig]

Danke für die Rückmeldung!

Der Devuan-Kernel ist meines Wissens nach mit dem debian-Kernel identisch.

So hatte ich das auch vermutet. Anders, als sich darauf zu beschränken, das abzuändern, was eine Abhängigkeit von systemd nach sich zieht, werden die Devuan-Macher auch kaum zurechtkommen.

Um den Standardkern ging's mir auch gar nicht. Den hatte ich nur zum Vergleichen herangezogen, um zu sehen, wo die für das Einhängen des Tolinos relevanten Abweichungen zu finden wären. Ansonsten sehe ich für mich keinen Sinn in einer initrd. Anfangs dachte ich, dass vfat als Modul genügte. Zwischenzeitlich hatte ich sogar mal ntfs einkompiliert. Das Tolino-System ist halt brutalstmöglich vernagelt. Und man muss ausprobieren. Ich hatte bei den Versuchen den Eindruck, dass der Linux Kern auch nur verzweifelt versucht, was Passendes aus dem MS-Universum auszuprobieren, um zu erfahren, was der Tolino denn haben möchte. Dass er zusätzlich auf einem bestimmten Charset besteht, hatte ich nicht erwartet.
Speck macht er immer noch, der Tolino, auch auf allen Debian-Maschinen: Pmount im Terminal zeigt keine Fehlermeldung. In der Konsole ausgeführt, kommt sinngemäß regelmäßig: „nicht sauber ausgehängt, fschk versuchen“. Aber nutzbar eingehängt wird das Teil dann trotzdem. Ich wüsste auch nicht, was ich da noch mit pumount falsch machen könnte.