Monte a unidade vfat virtual para pi de framboesa

Question

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

Aqui está a configuração.

Executar 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

Executar a cada inicialização após a configuração inicial

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

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

Para montar a si mesmo

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

Desmontar de si mesmo

umount /mnt/data

Monte na 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 em que ele estava conectado para ver o que aconteceria.

E agora não podemos montar o drive virtual de volta para si 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 recebendo uma das duas mensagens de erro, mas ainda posso montá-lo no USB e lê-lo como uma unidade com o Windows 10

Estamos executando o Raspbian (baseado no Debian)

Obrigado pela leitura.

    

Answer 1

Este comando

mkdosfs /dir/to/data/data.bin

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

Espero que o Windows continue assim enquanto formata um superfloppy compartilhado via g_mass_storage module.

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

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

(Se o seu mount não, use losetup ou mesmo kpartx . Mas o dispositivo resultante será como loop0 , por exemplo, /dev/loop0 ; monte este, não loop0p1 ). / p>

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

Eu acredito que abordei a questão raiz. A explicação abaixo sobre o que aconteceu em seguida pode estar totalmente errada.

Observe que esse tipo de problema é possível: O Windows não monta o superfloppy USB NTFS . No seu caso, é superfloppy FAT32 e enquanto o Windows parece não ter nenhum problema com isso, kpartx may.

Isso ocorre porque registro de inicialização FAT32 armazena o código executável onde uma tabela de partição no MBR seria . Este código pode ser qualquer coisa. Você executa kpartx e espera o MBR com uma tabela de partição válida. Em vez disso, ele obtém o registro de inicialização FAT32. Então:

• ou não encontra nada parecido com a tabela de partições, então special device /dev/mapper/loop0p1 does not exist depois;
• ou ele encontra um semi-válido, cria /dev/mapper/loop0p1 (e talvez loop0p2 etc.) 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 à minha resposta à pergunta já vinculada . Eu acho que no seu caso é kpartx que fica confuso.

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

Acho que neste caso você pode executar modprobe g_mass_storage

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