Mounten Sie ein virtuelles VFAT-Laufwerk auf Raspberry Pi

Mounten Sie ein virtuelles VFAT-Laufwerk auf Raspberry Pi

Ich versuche, ein virtuelles VFAT-Laufwerk auf Raspberry Pi zu mounten. Diese Lösung hat funktioniert, dann haben wir das virtuelle VFAT-Laufwerk über USB OTG formatiert. Jetzt kann ich das Laufwerk nicht mehr auf Pi mounten, aber ich kann es immer noch auf einem anderen USB-Gerät mounten.

Hier ist die Konfiguration.

Zur Konfiguration nur einmal ausführen

dd if=/dev/zero of=/dir/to/data/data.bin bs=512 count=7680000
mkdosfs /dir/to/data/data.bin
kpartx -a /dir/to/data/data.bin

Wird bei jedem Systemstart nach der Erstkonfiguration ausgeführt

kpartx -a /dir/to/data/data.bin

Die restlichen Befehle werden von einer OTG-USB-Verwaltungsanwendung ausgeführt

Auf sich selbst montieren

mount -o rw,umask=0000 -t vfat /dev/mapper/loop0p1 /mnt/data

Von sich selbst trennen

umount /mnt/data

Auf USB mounten

modprobe g_mass_storage file=/dir/to/data/data.bin stall=0

Vom USB trennen

modprobe g_mass_storage file=/dir/to/data/data.bin stall=0

Als die virtuelle VFAT-Festplatte auf USB OTG gemountet war, haben wir sie von dem Gerät aus formatiert, an dem sie angeschlossen war, um zu sehen, was passieren würde.

Und jetzt können wir das virtuelle Laufwerk nicht wieder auf sich selbst mounten. Auch nicht, nachdem wir das virtuelle Laufwerk gelöscht und neu erstellt haben.

mount -o rw,umask=0000 -t vfat /dev/mapper/loop0p1 /mnt/data
mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p1,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

oder

mount -o rw,umask=0000 -t vfat /dev/mapper/loop0p1 /mnt/data
mount: special device /dev/mapper/loop0p1 does not exist

Was ich versucht habe

modprobe -r g_mass_storage //Unmount from usb
umount /mnt/data //Unmount from itself
kpartx -dv /dir/to/data.bin //unmap virtual drive
rm /dir/to/data.bin //delete the virtual file system
dd if=/dev/zero of=/dir/to/data.bin bs=512 count=7680000 //Create a new virtual drive
mkdosfs /dir/to/data/data.bin //Format to vfat
kpartx -av /dir/to/data.bin //Map to dev
mount -o rw,umask=0000 -t vfat /dev/mapper/loop0p1 /mnt/data //Mount to itself

Ich erhalte immer noch eine der beiden Fehlermeldungen, kann es aber immer noch auf dem USB-Stick mounten und es unter Windows 10 als FAT-Laufwerk lesen.

Wir verwenden Raspbian (basierend auf Debian).

Vielen Dank fürs Lesen.

Antwort1

Dieser Befehl

mkdosfs /dir/to/data/data.bin

erstellt ein Dateisystem auf demgesamte"device" data.bin. Es gibt keine Partitionstabelle darin. Ein solches Setup nennt man Superfloppy. Meine allgemeine Meinung istes sollte vermieden werden, es sei denn, Sie kennen mögliche Fallstricke und akzeptieren sie.

Ich gehe davon aus, dass Windows dies so beibehält, während es eine über g_mass_storageein Modul freigegebene Superdiskette formatiert.

Es gibt keine Partitionstabelle und kpartxist daher unnötig.Sie sollten die gesamte Datei mounten.Moderne mountImplementierungen sollten ein Loop-Gerät automatisch zuordnen:

mount -o rw,umask=0000 -t vfat /dir/to/data/data.bin /mnt/data

(Wenn dies bei Ihnen mountnicht der Fall ist, verwenden Sie losetupoder sogar kpartx. Das resultierende Gerät sieht dann aber etwa so aus wie loop0, zB /dev/loop0; mounten Sie dieses, nicht loop0p1).

Ich bin überrascht, mount ... /dev/mapper/loop0p1 /mnt/datadass es funktioniert hat, als Sie es zum ersten Mal ausgeführt haben. Das ist komisch. Sie sollten von Anfang an die gesamte Datei mounten, da mkdosfsdie gesamte Datei bearbeitet wird.


Ich glaube, ich habe das Grundproblem angesprochen. Die folgende Erklärung dessen, was dann geschah, kann völlig falsch sein.

Beachten Sie, dass folgende Art von Problem möglich ist:Windows mountet USB NTFS Superfloppy nicht. In Ihrem Fall ist es eine FAT32-Superdiskette, und obwohl Windows scheinbar keine Probleme damit hat, kpartxkann es sein, dass …

Das ist weilFAT32-Bootdatensatzspeichert ausführbaren Code dort, wo eine Partitionstabelle im MBR wäre. Dieser Code kann alles sein. Sie führen ihn aus kpartxund er erwartet einen MBR mit einer gültigen Partitionstabelle. Stattdessen erhält er einen FAT32-Boot-Record. Dann:

  • entweder findet es nichts wie eine Partitionstabelle, also special device /dev/mapper/loop0p1 does not existdanach;
  • oder es findet eine halbwegs gültige, erstellt /dev/mapper/loop0p1(und vielleicht loop0p2usw.), die auf einen Teil Ihrer Datei verweist, aber da sich das Dateisystem auf der gesamten Datei befindet, macht diese „Partition“ keinen Sinn und hat wrong fs type, bad option, bad superblock.

Die Geschichte ähneltmeine Antwort auf die bereits verlinkte Frage. Ich schätze, in Ihrem Fall kpartxkommt es zu Verwirrung.


Wenn Sie innerhalb der Datei eine Partitionstabelle erstellt (z. B. mit fdisk data.bin), eine oder mehrere Partitionen definiert, ausgeführt kpartx -a ...und ein Dateisystem auf /dev/mapper/loop0p1-- erstellt haben, sollten Sie es wie mounten mount ... /dev/mapper/loop0p1 /mnt/data.

Ich denke, in diesem Fall könnten Sie laufenmodprobe g_mass_storage

  • entweder mit file=/dir/to/data/data.binund Windows würde das gesamte „Gerät“ mit seiner Partitionstabelle sehen;
  • oder mit file=/dev/mapper/loop0p1und Windows würde ein „Gerät“ erkennen, das eine Superdiskette ist.

verwandte Informationen