Monter un disque virtuel vfat sur framboise pi

J'essaie de monter un lecteur virtuel vfat sur Raspberry Pi. Cette solution fonctionnait, puis nous avons formaté le lecteur vrital vrital via USB OTG. À présent, je ne peux plus remonter le lecteur sur pi, mais je peux toujours le monter sur un autre périphérique USB.

Voici la configuration.

Exécuter une seule fois pour la 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

Exécuter à chaque démarrage après la configuration initiale

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

Les commandes restantes sont exécutées par une application de gestion OTG USB

Se monter à soi

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

Démonter de lui-même

umount /mnt/data

Monter sur USB

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

Démonter de l'USB

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

Lorsque le disque virtuel vfat a été monté sur USB OTG, nous l’avons formaté à partir du périphérique auquel il était connecté pour voir ce qui se produirait.

Et maintenant, nous ne pouvons pas monter le lecteur virtuel sur lui-même. Même après la suppression du lecteur virtuel et sa reconstruction.

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.

ou

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

Ce que j'ai essayé

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

Je reçois toujours l’un des deux messages d’erreur mais je peux quand même le monter sur le périphérique USB et le lire comme un disque dur sous Windows 10

Nous courons Raspbian (basé sur Debian)

Merci pour la lecture.

Cette commande

mkdosfs /dir/to/data/data.bin

crée un système de fichiers sur l' ensemble du "périphérique" data.bin. Il n'y a pas de table de partition en son sein. Une telle configuration est appelée superfloppy. Mon opinion générale est que cela devrait être évité , à moins que vous ne connaissiez les pièges possibles et que vous les acceptiez.

J'attends de Windows qu'il le garde ainsi pendant qu'il formate un super floppy partagé via un g_mass_storagemodule.

Il n'y a pas de table de partition, donc kpartxinutile. Vous devez monter le fichier entier. Les mountimplémentations modernes doivent associer automatiquement un périphérique en boucle:

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

(Si ce mountn'est pas le cas, utilisez losetupou même kpartx. Mais le périphérique résultant sera loop0, par exemple /dev/loop0, montez celui-ci, pas loop0p1).

Je suis surpris de mount ... /dev/mapper/loop0p1 /mnt/datatravailler lorsque vous l'exécutez pour la première fois. C'est louche. Dès le début, vous devez monter le fichier entier car mkdosfsutilisé sur le fichier entier.

Je crois avoir abordé le problème fondamental. L'explication ci-dessous de ce qui s'est passé ensuite peut être totalement fausse.

Notez que ce type de problème est possible: Windows ne monte pas le superfloppy USB NTFS . Dans votre cas, il s’agit d’un superfloppy FAT32 et, bien que Windows ne semble pas avoir de problème avec cela, kpartxvous pouvez.

Cela est dû au fait que l' enregistrement de démarrage FAT32 stocke le code exécutable à l'emplacement d'une table de partition dans MBR. Ce code peut être n'importe quoi. Vous exécutez kpartxet attend MBR avec une table de partition valide. Au lieu de cela, il obtient un enregistrement de démarrage FAT32. Ensuite:

• soit il ne trouve rien de semblable à la table de partition, donc special device /dev/mapper/loop0p1 does not existaprès;
• ou il en trouve une semi-valide, crée /dev/mapper/loop0p1(et peut-être loop0p2etc.) qui pointe vers une partie de votre fichier, mais puisque le système de fichiers se trouve sur tout le fichier, cette "partition" n'a aucun sens wrong fs type, bad option, bad superblock.

L'histoire est similaire à ma réponse à la question déjà liée . Je suppose que dans votre cas, c'est ce kpartxqui est confus.

Si vous avez créé une table de partition dans le fichier (par exemple, avec fdisk data.bin), défini une ou plusieurs partitions, exécuté kpartx -a ...et créé un système de fichiers, /dev/mapper/loop0p1vous devez alors la monter de la manière suivante mount ... /dev/mapper/loop0p1 /mnt/data.

Je pense que dans ce cas, vous pourriez courir modprobe g_mass_storage

• soit avec file=/dir/to/data/data.binet Windows verrait le "périphérique" entier avec sa table de partition;
• ou avec file=/dev/mapper/loop0p1et Windows verrait un "périphérique" qui est un super floppy.