Mount virtual vfat drive to raspberry pi

Question

I'm trying to mount virtual vfat drive to Raspberry Pi. This solution was working then we formatted the vritual vfat drive via USB OTG, now I cannot mount the drive back to pi but I can still mount it to another USB device.

Here is the configuration.

Run only once for configuration

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

Run on every boot after initial configuration

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

The rest commands are executed by a OTG USB management application

To mount to itself

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

Unmount from itself

umount /mnt/data

Mount to USB

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

Unmount from USB

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

When the vfat virtual disk was mounted to USB OTG we formatted it from the device it was connected to it to see what would happen.

And now we can't mount the virtual drive back to itself. Even after deleting the Virtual drive and rebuilding it.

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.

or

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

What I have tried

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

Still getting one of the two error messages but I can still Mount it to the USB and read it as a fat drive with Windows 10

We are running Raspbian(Debian based)

Thank you for reading.

Answer 1

This command

mkdosfs /dir/to/data/data.bin

creates a filesystem on the entire "device" data.bin. There's no partition table within it. Such setup is called superfloppy. My general opinion is it should be avoided, unless you know possible pitfalls and accept them.

I expect Windows to keep it this way while it formats a superfloppy shared via g_mass_storage module.

There's no partition table so kpartx is unnecessary. You should mount the entire file. Modern mount implementations should associate a loop device automatically:

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

(If your mount doesn't, use losetup or even kpartx. But the resulting device will be like loop0, e.g. /dev/loop0; mount this one, not loop0p1).

I'm surprised mount ... /dev/mapper/loop0p1 /mnt/data worked when you run it for the first time. It's fishy. From the very beginning you should mount the entire file because mkdosfs operated on the entire file.

---

I believe I addressed the root issue. The below explanation of what happened next may be totally wrong.

Note this kind of issue is possible: Windows does not mount USB NTFS superfloppy. In your case it's FAT32 superfloppy and while Windows seems to have no problem with it, kpartx may.

This is because FAT32 boot record stores executable code where a partition table in MBR would be. This code may be anything. You run kpartx and it expects MBR with a valid partition table. Instead it gets FAT32 boot record. Then:

• either it doesn't find anything like partition table so special device /dev/mapper/loop0p1 does not exist afterwards;
• or it finds a semi-valid one, creates /dev/mapper/loop0p1 (and maybe loop0p2 etc.) that points to some part of your file, but since the filesystem is on the entire file, this "partition" makes no sense, has wrong fs type, bad option, bad superblock.

The story is similar to my answer to the already linked question. I guess in your case it's kpartx that gets confused.

---

If you have created a partition table inside the file (e.g. with fdisk data.bin), defined one or more partitions, run kpartx -a ... and created a filesystem on /dev/mapper/loop0p1 -- then you should mount it like mount ... /dev/mapper/loop0p1 /mnt/data.

I think in this case you could run modprobe g_mass_storage

• either with file=/dir/to/data/data.bin and Windows would see the entire "device" with its partition table;
• or with file=/dev/mapper/loop0p1 and Windows would see a "device" that is a superfloppy.