I am studying the command here in the post about How to compile and install Qt, qwt and overclock the RPIsudo mount -o loop,offset=62914560<date>-wheezy-raspbian.img /mnt/rasp-pi-rootfsI do fdisk 2016-02-26-raspbian-jessie.img and I getDisk: 2016-02-26-raspbian-jessie.img    geometry: 976/128/63 [7870464 sectors]  Signature: 0xAA55       Starting       Ending   #: id  cyl  hd sec -  cyl  hd sec [     start -       size]  ------------------------------------------------------------------------   1: 0C    0 130   3 -    8  40  32 [      8192 -     122880] Win95 FAT32L   2: 83    8  40  33 -  489 232  63 [    131072 -    7739392] Linux files*   3: 00    0   0   0 -    0   0   0 [         0 -          0] unused         4: 00    0   0   0 -    0   0   0 [         0 -          0] unused       Why is offset specific in mount?
Why offset specific in loop mount?
debian;mount
As 62914560 points exactly 60MiB into the file, I think the best guess would be that the Raspian disk image is actually partitioned.  The offset tells mount (or actually losetup) the actual offset of the root file-system (I suggest this is the second of two partitions, the first most-probably being /boot resp. the bootloader/firmware files).The problem here is that even though the loop driver actually supports partitioned images, the number of maximum partitions per loop device has to be specified as a module parameter when loading the module (or on the kernel command line).  As there are many distros out there that won't do this by default, ...,offset=XXX is the most reliable way to cope with partitioned images when loop uses the default parameter (which is 0, hence no partition support).You can test whether your loop driver was loaded with partition-support by looking into /sys/module/loop/parameters/max_part.  On my current system (ArchLinux), after loading loop without parameters this is:$ cat /sys/module/loop/parameters/max_part0To enable partitioning-support, you will have to unload loop and load it again with the desired value for the max_part options, e.g.# modprobe -r loop# modprobe loop max_part=8After this, you could try to manually set-up the loop-device for your image by doing# losetup /dev/loop0 /path/to/<date>-wheezy-raspbian.imgNow, you should not only see /dev/loop0 representing the whole image, but (as long as my theory is correct ;) also have /dev/loop0p1, /dev/loop0p2, etc., for all partitions in the image.Edit:If you want to do this yourself the tedious way (I'd suggest simply reloading loop with the correct max_part option and simply using the partitions), you could find out which offset is required by using fdisk directly on the image-file (shown with an ArchLinux ISO, as I had it on hand, but the idea is the same):$ fdisk -l archlinux-2016.03.01-dual.isoDisk archlinux-2016.03.01-dual.iso: 268.3 MiB, 281339392 bytes, 549491 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0x2237702cDevice                         Boot Start     End Sectors  Size Id Typearchlinux-2016.03.01-dual.iso1 *        0 1452031 1452032  709M  0 Emptyarchlinux-2016.03.01-dual.iso2        172   63659   63488   31M ef EFI (FAT-12/16/32)The second partition starts at sector 172 with a sector size of 512 bytes.  Multiplying both values gives you the offset in bytes, thus to mount the partition, you'll use:# mount -o loop,offset=$((172*512)) archlinux-2016.03.01-dual.iso /mnt# ls -l /mnttotal 4drwxr-xr-x 4 root root 2048 Mar  1 15:49 EFIdrwxr-xr-x 3 root root 2048 Mar  1 15:49 loaderVoila.