☰

Monte la unidad virtual vfat en raspberry pi

tag-icon • tag-icon linux debian mount raspberry-pi virtual-drive
Monte la unidad virtual vfat en raspberry pi

Estoy intentando montar una unidad vfat virtual en Raspberry Pi. Esta solución estaba funcionando, luego formateamos la unidad vritual vfat a través de USB OTG, ahora no puedo volver a montar la unidad en pi, pero aún puedo montarla en otro dispositivo USB.

Aquí está la configuración.

Ejecutar solo una vez para la configuración.

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

Ejecutar en cada arranque después de la configuración inicial

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

El resto de comandos se ejecutan mediante una aplicación de gestión de USB OTG.

Para montarse a sí mismo

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

Desmontarse de sí mismo

umount /mnt/data

Montar en USB

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

Desmontar del USB

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

Cuando el disco virtual vfat se montó en USB OTG, lo formateamos desde el dispositivo al que estaba conectado para ver qué pasaba.

Y ahora no podemos volver a montar la unidad virtual. Incluso después de eliminar la unidad virtual y reconstruirla.

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.

o

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

lo que he probado

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

Sigo recibiendo uno de los dos mensajes de error, pero aún puedo montarlo en el USB y leerlo como un disco duro con Windows 10.

Estamos ejecutando Raspbian (basado en Debian)

Gracias por leer.

Respuesta1

Este comando

mkdosfs /dir/to/data/data.bin

crea un sistema de archivos en elcompleto"dispositivo" data.bin. No hay ninguna tabla de particiones dentro de él. Esta configuración se llama superfloppy. Mi opinión general esdebe evitarse, a menos que conozca los posibles obstáculos y los acepte.

Espero que Windows lo mantenga así mientras formatea un superdisquete compartido a través del g_mass_storagemódulo.

No hay tabla de particiones por lo que kpartxes innecesario.Deberías montar el archivo completo.Las implementaciones modernas mountdeberían asociar un dispositivo de bucle automáticamente:

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

(Si mountno lo hace, use losetupo incluso kpartx. Pero el dispositivo resultante será como loop0, por ejemplo /dev/loop0, monte este, no loop0p1).

Me sorprende que mount ... /dev/mapper/loop0p1 /mnt/datahaya funcionado cuando lo ejecutas por primera vez. Es sospechoso. Desde el principio debes montar el archivo completo porque mkdosfsopera en todo el archivo.

Creo que abordé el problema de raíz. La siguiente explicación de lo que sucedió después puede ser totalmente errónea.

Tenga en cuenta que este tipo de problema es posible:Windows no monta el superdisquete USB NTFS. En su caso, es un superdisquete FAT32 y, aunque Windows parece no tener problemas con él, kpartxpuede que sí.

Esto es porqueRegistro de arranque FAT32almacena código ejecutable donde estaría una tabla de particiones en MBR. Este código puede ser cualquier cosa. Lo ejecuta kpartxy espera MBR con una tabla de particiones válida. En su lugar, obtiene el registro de arranque FAT32. Entonces:

  • o no encuentra nada parecido a una tabla de particiones, así que special device /dev/mapper/loop0p1 does not existluego;
  • o encuentra uno semiválido, crea /dev/mapper/loop0p1(y tal vez loop0p2etc.) que apunta a alguna parte de su archivo, pero como el sistema de archivos está en todo el archivo, esta "partición" no tiene sentido, tiene wrong fs type, bad option, bad superblock.

La historia es similar ami respuesta a la pregunta ya vinculada. Supongo que en tu caso es kpartxlo que se confunde.

Si creó una tabla de particiones dentro del archivo (por ejemplo, con fdisk data.bin), definió una o más particiones, ejecutó kpartx -a ...y creó un sistema de archivos /dev/mapper/loop0p1, entonces debe montarlo como mount ... /dev/mapper/loop0p1 /mnt/data.

Creo que en este caso podrías correr.modprobe g_mass_storage

  • ya sea con file=/dir/to/data/data.biny Windows vería el "dispositivo" completo con su tabla de particiones;
  • o con file=/dev/mapper/loop0p1Windows vería un "dispositivo" que es un superdisquete.

información relacionada