3

I am trying to understand what I did wrong with the following mount command.

Take the following file from here:

Simply download the img file from here.

Then I verified the md5sum is correct per the upstream page:

$ md5sum nand_2016_06_02.img
3ad5e53c7ee89322ff8132f800dc5ad3  nand_2016_06_02.img

Here is what file has to say:

$ 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

So let's check the start of the first partition of this image:

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

In my case Units size is 512, and Start is 4096, which means offset is at byte 2097152. In which case, the following should just work, but isn't:

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

And, dmesg reveals:

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

None of the solutions listed here worked for me:

  • resize2fs or,
  • sfdisk

What did I missed ?

Some other experiments that I tried:

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

which leads to:

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

and same goes the same story:

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

I cannot use resize2fs since I am required to run e2fsck first:

$ /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
malat
  • 2,708
  • 4
  • 27
  • 47

2 Answers2

0

Once you have extracted the filesystem you are interested in (using dd), simply adapt the file size (967424*4096=3962568704):

$ truncate -s 3962568704 trunc.img

And then simply:

$ 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

Another simpler solution is to truncate directly on the original img file:

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

Where 3962568704 + 2097152 = 3964665856

malat
  • 2,708
  • 4
  • 27
  • 47
0

As the truncate from this answer didn't solve the issue, I've experimented a little more. At some place I found the suggestion using resize2fs to fix the image (resize2fs <image> <size>, e.g. resize2fs nand_2016_06_02.img 3779M given the above data), but that didn't work out for me either (claiming the size was already thus).

For me, the following two steps solved it:

  1. e2fsck -y -f nand_2016_06_02.img (you can first check without y if there are any errors at all – if not, this is not needed)
  2. testdisk nand_2016_06_02.img, walking through the menu (proceed › (partition table) none › advanced › image creation) and letting testdisk create an image.

The image created by testdisk (goes by the name image.dd) mounted perfectly then:

sudo mount image.dd /tmp/img -t ext4 -o loop,ro

(I knew it was ext4, and I explicitly wanted it mounted read-only to not accidentally modify it – and in my case it was not a downloaded image, but a "salvaged" SD card which had given up on me, data scraped with myrescue -r 1000 -b 4096 /dev/sdf2 sdpart2.img, which took about 24h for an 8 GB partition with 1014 bad blocks)

Izzy
  • 233
  • 1
  • 9