cannot mount the 2nd partition of a raspbian image in ubuntu 17.10.1

Question

I'm trying to shrink a raspbian image following this procedure:

The procedure works fine and I am able to get the shrunken image to boot correctly in a raspberry pi.

However, there is a step in the procedure where we improve the compression of the image by filling empty space with zeroes. This requires mounting the image on the filesystem like so.

sudo losetup /dev/loop0 imagename.img -o $((START*512))
sudo mkdir -p /mnt/imageroot
sudo mount /dev/loop0 /mnt/imageroot

I am receiving a strange error when I try to mount the 2nd volume on the image to the file system. Despite my research, I have not yet discovered why I am getting this error or how to work around it.

Step-by-step, I first used fdisk to discover where the 2nd partition starts like so:

$ sudo fdisk -l raspbian-stretch-opencv-2.4.img 
Disk raspbian-stretch-opencv-2.4.img: 9.9 GiB, 10593763840 bytes, 20690945 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: 0xe5723e2e

Device                           Boot Start      End  Sectors  Size Id Type
raspbian-stretch-opencv-2.4.img1       8192    93814    85623 41.8M  c W95 FAT32 (LBA)
raspbian-stretch-opencv-2.4.img2      94208 20785151 20690944  9.9G 83 Linux
sryan@ubuntu-artful:~/images$ 

Then, I attached it to the loopback device like so:

$ sudo losetup /dev/loop0 raspbian-stretch-opencv-2.4.img -o $((94208*512))
$ sudo losetup -f
/dev/loop1

However, when I try to mount, I get this rather generic error:

$ sudo mount /dev/loop0 /mnt/imageroot
mount: /mnt/imageroot: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

I have done surgery on this image by (1) using gparted to shrink the file system, (2) fdisk to change the partition table and (3) truncate to to remove the unused portion of the file, as specified by the procedure. The image itself appears to be okay insofar as I burned it to a microSD card and the raspberry pi booted successfully.

I am mystified as to why I cannot mount the file system following the recommended procedure.

I am doing all of this inside of a virtualbox (5.2.6) virtual machine running ubuntu (17.10.1) where the host os is mac os (10.13.3 Beta). The image file itself resides on an external hard drive which is accessed by the vm via a shared folder with the host os.

One suggestion was to extract the file system from the 2nd partition to a new image and then mount that directly. This would allow mounting without specifying an offset. This seems a little extreme.

Answer 1

There are mainly two reasons for the error message:
1. The partition is not of type ext2, ext3, ext4
2. You don't match the starting sector of the partition

You don't need to create a /dev/loop0 device. You can mount the image direct. You should do to limit error possibilities.

I use parted because it shows me the partition type. For the latest Raspbian Lite image this works for me:

~$ sudo parted 2017-11-29-raspbian-stretch-lite.img unit s print
Model:  (file)
Disk /home/ingo/Downloads/2017-11-29-raspbian-stretch-lite.img: 3629056s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End       Size      Type     File system  Flags
 1      8192s   93236s    85045s    primary  fat32        lba
 2      94208s  3629055s  3534848s  primary  ext4

~$ sudo mount -o loop,offset=$((94208*512)) 2017-11-29-raspbian-stretch-lite.img /mnt/img2/

~$ ls /mnt/img2/
bin/  boot/  dev/  etc/  home/  lib/  lost+found/  media/  mnt/  opt/  proc/  root/  run/  sbin/  srv/  sys/  tmp/  usr/  var/
~$ sudo umount /mnt/img2/

If I do not match the starting sector I get this: look at the offset with -1

~$ sudo mount -o loop,offset=$((94208*512-1)) 2017-11-29-raspbian-stretch-lite.img /mnt/img2/
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.

Hope this helps.