Mounten Sie virtuelles Vfat-Laufwerk auf Himbeer-Pi

506
serv92

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

Hier ist die Konfiguration.

Führen Sie zur Konfiguration nur einmal aus

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

Nach der ersten Konfiguration bei jedem Start ausführen

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

Die Restbefehle werden von einer OTG USB-Verwaltungsanwendung ausgeführt

Zu sich selbst zu montieren

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

Unmount von sich selbst

umount /mnt/data

An USB anschließen

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

Unmount von USB

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

Als das virtuelle vfat-Laufwerk an USB OTG angehängt wurde, formatierten wir es mit dem Gerät, mit dem es verbunden war, um zu sehen, was passieren würde.

Und jetzt können wir das virtuelle Laufwerk nicht wieder in sich selbst einbinden. Auch nachdem Sie 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

Es wird immer noch eine der beiden Fehlermeldungen angezeigt, aber ich kann sie immer noch an den USB-Stick anschließen und als fettes Laufwerk mit Windows 10 lesen

Wir betreiben Raspbian (Debian-basiert)

Danke fürs Lesen.

0

1 Antwort auf die Frage

1
Kamil Maciorowski

Dieser Befehl

mkdosfs /dir/to/data/data.bin

erstellt ein Dateisystem auf dem gesamten "Gerät" data.bin. Es enthält keine Partitionstabelle. Ein solches Setup wird als Superfloppy bezeichnet. Meiner allgemeinen Meinung nach sollte es vermieden werden, es sei denn, Sie kennen mögliche Fallstricke und akzeptieren diese.

Ich erwarte, dass Windows es auf diese Weise beibehält, während es eine über das g_mass_storageModul freigegebene Superfloppy formatiert .

Es gibt keine Partitionstabelle und kpartxist daher nicht erforderlich. Sie sollten die gesamte Datei einhängen. Moderne mountImplementierungen sollten ein Schleifengerät automatisch verknüpfen:

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

(Wenn mountdies nicht der Fall ist, verwenden Sie losetupoder sogar kpartx. Das resultierende Gerät wird jedoch wie loop0z /dev/loop0. B. dieses einhängen, nicht loop0p1).

Ich bin überrascht, mount ... /dev/mapper/loop0p1 /mnt/dataals Sie es zum ersten Mal laufen ließen. Es ist fischig. Sie sollten von Anfang mkdosfsan die gesamte Datei einhängen, da sie für die gesamte Datei gilt.

Ich glaube, ich habe das Grundproblem angesprochen. Die folgende Erklärung des nächsten Ereignisses ist möglicherweise völlig falsch.

Beachten Sie, dass diese Art von Problem möglich ist: Windows mounten keine USB-NTFS-Superfloppy . In Ihrem Fall ist es FAT32 superfloppy und obwohl Windows damit kein Problem zu haben scheint, kpartxkann es sein.

Dies liegt daran, dass der FAT32-Startdatensatz ausführbaren Code speichert, in dem sich eine Partitionstabelle in MBR befinden würde. Dieser Code kann alles sein. Sie führen aus, kpartxund es erwartet MBR mit einer gültigen Partitionstabelle. Stattdessen erhält es einen FAT32-Boot-Record. Dann:

  • entweder findet es so etwas wie Partitionstabelle nicht special device /dev/mapper/loop0p1 does not existdanach;
  • oder es findet eine halbgültige, erstellt /dev/mapper/loop0p1(und vielleicht loop0p2etc.), die auf einen Teil Ihrer Datei verweist, aber da das Dateisystem sich auf der gesamten Datei befindet, macht diese "Partition" keinen Sinn wrong fs type, bad option, bad superblock.

Die Geschichte ähnelt meiner Antwort auf die bereits verknüpfte Frage . Ich denke, in Ihrem Fall wird es kpartxverwirrt.

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

Ich denke in diesem Fall könnte man laufen modprobe 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" sehen, das eine Superfloppy ist.

Verwandte Probleme