плохая геометрия: количество блоков 967424 превышает размер устройства (415232 блока)

Я пытаюсь понять, что я сделал не так со следующей командой mount .

Возьмите следующий файл отсюда:

  • http://elinux.org/CI20_Distros#Debian_8_2016-02-02_Beta

Просто загрузите файл img .

Затем я подтвердил, что md5sum является правильным для восходящей страницы:

 $ md5sum nand_2016_06_02.img 3ad5e53c7ee89322ff8132f800dc5ad3 nand_2016_06_02.img 

Вот какой file должен сказать:

 $ 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)\011, code offset 0x0 

Итак, давайте проверим начало первого раздела этого изображения:

 $ /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 

В моем случае размер Units равен 512 , а Start4096 , что означает смещение в байте 2097152 . В этом случае следующее должно просто работать, но это не так:

 $ 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. 

И, dmesg показывает:

 $ 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) 

Ни одно из перечисленных здесь решений не помогло мне:

Что я пропустил?


Некоторые другие эксперименты, которые я пробовал:

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

что приводит к:

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

и одна и та же история:

 $ 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. 

Я не могу использовать resize2fs так как мне нужно сначала запустить e2fsck :

 $ /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 

После того, как вы извлекли интересующую вас файловую систему (используя dd ), просто измените размер файла (967424 * 4096 = 3962568704):

 $ truncate -s 3962568704 trunc.img 

А потом просто:

 $ 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 

Другим более простым решением является усечение непосредственно в исходном файле img:

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

Где 3962568704 + 2097152 = 3964665856