
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_storage
ein Modul freigegebene Superdiskette formatiert.
Es gibt keine Partitionstabelle und kpartx
ist daher unnötig.Sie sollten die gesamte Datei mounten.Moderne mount
Implementierungen 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 mount
nicht der Fall ist, verwenden Sie losetup
oder 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/data
dass 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 mkdosfs
die 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, kpartx
kann 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 kpartx
und 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 exist
danach; - oder es findet eine halbwegs gültige, erstellt
/dev/mapper/loop0p1
(und vielleichtloop0p2
usw.), die auf einen Teil Ihrer Datei verweist, aber da sich das Dateisystem auf der gesamten Datei befindet, macht diese „Partition“ keinen Sinn und hatwrong fs type, bad option, bad superblock
.
Die Geschichte ähneltmeine Antwort auf die bereits verlinkte Frage. Ich schätze, in Ihrem Fall kpartx
kommt 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.bin
und Windows würde das gesamte „Gerät“ mit seiner Partitionstabelle sehen; - oder mit
file=/dev/mapper/loop0p1
und Windows würde ein „Gerät“ erkennen, das eine Superdiskette ist.