geometria incorreta: a contagem de blocos 967424 excede o tamanho do dispositivo (415232 blocos)

2

Estou tentando entender o que fiz de errado com o seguinte comando mount .

Pegue o seguinte arquivo aqui:

Basta fazer o download do arquivo img de aqui .

Depois, verifiquei que md5sum está correto na página do upstream:

$ md5sum nand_2016_06_02.img
3ad5e53c7ee89322ff8132f800dc5ad3  nand_2016_06_02.img

Aqui está o que file tem a dizer:

$ file nand_2016_06_02.img 
nand_2016_06_02.img: x86 boot sector; partition 1: ID=0x83, starthead 68, startsector 4096, 3321856 sectors, extended partition table (last)1, code offset 0x0

Então, vamos verificar o início da primeira partição desta imagem:

$ /sbin/fdisk -l nand_2016_06_02.img

Disk nand_2016_06_02.img: 1.6 GiB, 1702887424 bytes, 3325952 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
Disklabel type: dos
Disk identifier: 0x0212268d

Device               Boot Start     End Sectors  Size Id Type
nand_2016_06_02.img1       4096 3325951 3321856  1.6G 83 Linux

No meu caso, o tamanho Unidades é 512 , e Start é 4096 , o que significa que o offset está no byte 2097152 . Nesse caso, o seguinte deve funcionar, mas não é:

$ mkdir /tmp/img
$ sudo mount -o loop,offset=2097152 nand_2016_06_02.img /tmp/img/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

E, o dmesg revela:

$ dmesg | tail
[ 1632.732163] loop: module loaded
[ 1854.815436] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem
[ 1854.815452] EXT4-fs (loop0): bad geometry: block count 967424 exceeds size of device (415232 blocks)

Nenhuma das soluções listadas aqui funcionou para mim:

  • resize2fs ou
  • sfdisk

O que eu perdi?

Algumas outras experiências que experimentei:

$ dd bs=2097152 skip=1 if=nand_2016_06_02.img of=trunc.img

que leva a:

$ file trunc.img 
trunc.img: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=960b67cf-ee8f-4f0d-b6b0-2ffac7b91c1a (large files)

e o mesmo acontece na mesma história:

$ sudo mount -o loop trunc.img /tmp/img/
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Não é possível usar resize2fs , pois tenho de executar e2fsck primeiro:

$ /sbin/e2fsck -f trunc.img 
e2fsck 1.42.9 (28-Dec-2013)
The filesystem size (according to the superblock) is 967424 blocks
The physical size of the device is 415232 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
    
por malat 04.05.2017 / 21:42

1 resposta

0

Uma vez que você tenha extraído o sistema de arquivos no qual você está interessado (usando dd ), simplesmente adapte o tamanho do arquivo (967424 * 4096 = 3962568704):

$ truncate -s 3962568704 trunc.img

E então simplesmente:

$ sudo mount -o loop trunc.img /tmp/img/
$ sudo find /tmp/img/
/tmp/img/
/tmp/img/u-boot-spl.bin
/tmp/img/u-boot.img
/tmp/img/root.ubifs.9
/tmp/img/root.ubifs.4
/tmp/img/root.ubifs.5
/tmp/img/root.ubifs.7
/tmp/img/root.ubifs.2
/tmp/img/root.ubifs.6
/tmp/img/lost+found
/tmp/img/root.ubifs.3
/tmp/img/boot.ubifs
/tmp/img/root.ubifs.0
/tmp/img/root.ubifs.1
/tmp/img/root.ubifs.8

Outra solução mais simples é truncar diretamente no arquivo img original:

$ truncate -s 3964665856 nand_2016_06_02.img
$ sudo mount -o loop,offset=2097152 nand_2016_06_02.img /tmp/img/

Onde 3962568704 + 2097152 = 3964665856

    
por 10.05.2017 / 14:53