Se o arquivo de imagem estiver hospedado em um sistema de arquivos estranho como, por exemplo, vboxsf isso pode ser o problema.
Estou tentando criar uma imagem de disco rígido a partir do zero usando um arquivo. Isso inclui o MBR, a tabela de partições, o número de partições, etc. Eu não posso, no entanto, fazer com que o Linux monte as partições que eu faço.
edit: veja o final da pergunta para atualização - parece estar relacionado ao vboxsf
Já tentei muitas abordagens diferentes, mas as que mais me levaram até o fim acabaram no mesmo lugar. Eu fiz uma versão simplificada abaixo, que deve ser suficiente para explicar o meu problema
Gerar arquivo vazio usando dd (ou truncar para velocidade)
dd if=/dev/zero of=test.img bs=1M count=150
Criar tabela de partições
parted -s test.img mklabel gpt
Warning: The resulting partition is not properly aligned for best performance.
Criar partição (s)
parted -s test.img -- mkpart logical 0 5M
parted -s test.img set 1 bios_grub on
parted -s test.img -- mkpart logical 5M 50M
etc.
Montar como dispositivo de loop (módulo de loop carregado com max_part = 31)
losetup /dev/loop0 test.img
lsblk para verificar
loop0 7:0 0 150M 0 loop
├─loop0p1 7:1 0 4.8M 0 loop
├─loop0p2 7:2 0 43M 0 loop
└─loop0p3 7:3 0 4M 0 loop
até aí tudo bem - eu acho. Formatar as partições
mkfs.ext4 /dev/loop0p1
mkfs.ext4 /dev/loop0p2
mkfs.ext4 /dev/loop0p3
Agora vamos montar nossas novas partições
[root@localhost vmdk test]# mount /dev/loop0p2 boot
mount: /dev/loop0p2 is write-protected, mounting read-only
mount: unknown filesystem type '(null)'
Aqui é onde termina - todas as vezes. Eu tentei montar a imagem em um loop logo após sua criação e chamada dividida em / dev / loop0. Isso produz o mesmo resultado. Eu tentei losetup com offsets manualmente. Eu tentei o kpartx - não consigo descobrir como ir além desse ponto.
Devo observar que também tentei este procedimento com um disco rígido real (bem, estou usando uma VM, mas você sabe o que quero dizer). Neste caso eu chamei exatamente os mesmos comandos, mas em / dev / sdb. No final, eu consegui montar / dev / sdb2 sem problemas.
Eu não sei se é relevante, mas aqui vai
[root@localhost vmdk test]# uname -a
Linux localhost.localdomain 3.10.0-327.36.2.el7.x86_64 #1 SMP Mon Oct 10 23:08:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost vmdk test]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root@localhost vmdk test]# file test.img
test.img: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 307199 sectors, extended partition table (last)1, code offset 0x0
[root@localhost vmdk test]# file -s /dev/loop0
/dev/loop0: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 307199 sectors, extended partition table (last)1, code offset 0x0
[root@localhost vmdk test]# file -s /dev/loop0p2
/dev/loop0p2: data
[root@localhost vmdk test]# fdisk -lu /dev/loop0
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/loop0: 157 MB, 157286400 bytes, 307200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
# Start End Size Type Name
1 34 9765 4.8M BIOS boot parti logical
2 10240 98303 43M Microsoft basic logical
3 98304 106495 4M Microsoft basic logical
Eu não entendo porque o dispositivo de loop não se comporta exatamente da mesma maneira que o disco rígido quando eu sigo o mesmo procedimento. Se alguém tiver alguma ideia, será muito apreciado!
Por coincidência, observei que uma reinicialização corrige meu problema, então minha mente foi imediatamente para a sincronização. Depois de alguns testes, parece que o meu problema só ocorre quando o arquivo test.img é colocado na minha montagem vboxsf (pasta compartilhada entre o host e a VM). Eu realmente não pensei nisso, mas talvez ele armazene arquivos em cache de uma forma estranha? Deixarei a questão em aberto por enquanto - talvez alguém possa elaborar.