☰

Monte a unidade vfat virtual no Raspberry Pi

tag-icon • tag-icon linux debian mount raspberry-pi virtual-drive
Monte a unidade vfat virtual no Raspberry Pi

Estou tentando montar uma unidade vfat virtual no Raspberry Pi. Esta solução estava funcionando, então formatamos a unidade vritual vfat via USB OTG, agora não consigo montar a unidade de volta no pi, mas ainda posso montá-la em outro dispositivo USB.

Aqui está a configuração.

Execute apenas uma vez para configuração

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

Execute em cada inicialização após a configuração inicial

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

Os demais comandos são executados por um aplicativo de gerenciamento OTG USB

Para montar em si mesmo

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

Desmontar de si mesmo

umount /mnt/data

Montar em USB

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

Desmontar do USB

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

Quando o disco virtual vfat foi montado no USB OTG, nós o formatamos a partir do dispositivo ao qual estava conectado para ver o que aconteceria.

E agora não podemos montar o drive virtual de volta nele mesmo. Mesmo depois de excluir a unidade virtual e reconstruí-la.

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

O que eu tentei

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

Ainda recebo uma das duas mensagens de erro, mas ainda consigo montá-lo no USB e lê-lo como uma unidade gorda com o Windows 10

Estamos rodando Raspbian (baseado em Debian)

Obrigado por ler.

Responder1

Este comando

mkdosfs /dir/to/data/data.bin

cria um sistema de arquivos nointeiro"dispositivo" data.bin. Não há tabela de partição dentro dele. Essa configuração é chamada de superfloppy. Minha opinião geral édeve ser evitado, a menos que você conheça possíveis armadilhas e as aceite.

Espero que o Windows mantenha assim enquanto formata um superdisquete compartilhado via g_mass_storagemódulo.

Não há tabela de partições, portanto kpartxé desnecessário.Você deve montar o arquivo inteiro.Implementações modernas mountdevem associar um dispositivo de loop automaticamente:

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

(Se mountnão, use losetupou mesmo kpartx. Mas o dispositivo resultante será como loop0, por exemplo /dev/loop0; monte este, não loop0p1).

Estou surpreso mount ... /dev/mapper/loop0p1 /mnt/dataque funcionou quando você o executou pela primeira vez. É suspeito. Desde o início você deve montar o arquivo inteiro porque mkdosfsoperou no arquivo inteiro.

Acredito que abordei a questão raiz. A explicação abaixo do que aconteceu a seguir pode estar totalmente errada.

Observe que esse tipo de problema é possível:O Windows não monta superdisquete USB NTFS. No seu caso, é um superdisquete FAT32 e, embora o Windows pareça não ter problemas com isso, kpartxpode.

Isto é porqueRegistro de inicialização FAT32armazena código executável onde estaria uma tabela de partição no MBR. Este código pode ser qualquer coisa. Você executa kpartxe espera MBR com uma tabela de partição válida. Em vez disso, obtém o registro de inicialização FAT32. Então:

  • ou não encontra nada parecido com tabela de partição special device /dev/mapper/loop0p1 does not existdepois;
  • ou encontra uma semi-válida, cria /dev/mapper/loop0p1(e talvez loop0p2etc.) que aponta para alguma parte do seu arquivo, mas como o sistema de arquivos está no arquivo inteiro, essa "partição" não faz sentido, tem wrong fs type, bad option, bad superblock.

A história é semelhante aminha resposta para a pergunta já vinculada. Acho que no seu caso é kpartxisso que fica confuso.

Se você criou uma tabela de partições dentro do arquivo (por exemplo, com fdisk data.bin), definiu uma ou mais partições, executou kpartx -a ...e criou um sistema de arquivos /dev/mapper/loop0p1- então você deve montá-lo como mount ... /dev/mapper/loop0p1 /mnt/data.

Eu acho que neste caso você poderia corrermodprobe g_mass_storage

  • com file=/dir/to/data/data.bine o Windows veria todo o "dispositivo" com sua tabela de partições;
  • ou com file=/dev/mapper/loop0p1e o Windows veria um "dispositivo" que é um superdisquete.

informação relacionada