3

I am studying the command here in the post about How to compile and install Qt, qwt and overclock the RPI

sudo mount -o loop,offset=62914560
<date>-wheezy-raspbian.img /mnt/rasp-pi-rootfs

I do fdisk 2016-02-26-raspbian-jessie.img and I get

Disk: 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?

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232

2 Answers2

10

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_part
0

To 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=8

After this, you could try to manually set-up the loop-device for your image by doing

# losetup /dev/loop0 /path/to/<date>-wheezy-raspbian.img

Now, 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 (see losetup script example).

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.iso
Disk archlinux-2016.03.01-dual.iso: 268.3 MiB, 281339392 bytes, 549491 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: 0x2237702c

Device Boot Start End Sectors Size Id Type archlinux-2016.03.01-dual.iso1 * 0 1452031 1452032 709M 0 Empty archlinux-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 /mnt
total 4
drwxr-xr-x 4 root root 2048 Mar  1 15:49 EFI
drwxr-xr-x 3 root root 2048 Mar  1 15:49 loader

Voila.

AdminBee
  • 22,803
Andreas Wiese
  • 10,400
2

As per the "losetup" man page.

-o, --offset offset the data start is moved offset bytes into the specified file or device

e.g. If you have "dd" of a device then you can mount any of it's partition by using offset option.

This offset value is calculated by multiplying the start value of partition by sector size

e.g.

SHW@SHW:/tmp # fdisk -lu 040614.dd
Disk 040614.dd: 1.9 GiB, 2048385024 bytes, 4000752 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: 0x5324798e

Device                          Boot   Start     End Sectors  Size Id Type
040614.dd1 *       2048   30719   28672   14M 83 Linux
040614.dd2        30720 1054719 1024000  500M 83 Linux
040614.dd3      1054720 1095679   40960   20M 83 Linux

SHW@SHW:/tmp # mount -o loop,offset=`echo 1054720 \* 512|bc` 040614.dd1 /mnt/loop

UPDATE:

040614.dd is created by following command:

SHW@SHW:/tmp # fdisk -l /dev/sdb
Disk /dev/sdb: 1.9 GiB, 2048385024 bytes, 4000752 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: 0x5324798e

Device                          Boot   Start     End Sectors  Size Id Type
/dev/sdb1 *       2048   30719   28672   14M 83 Linux
/dev/sdb2        30720 1054719 1024000  500M 83 Linux
/dev/sdb3      1054720 1095679   40960   20M 83 Linux

SHW@SHW:/tmp # dd if=/dev/sdb of=040614.dd
SHW
  • 14,786
  • 14
  • 66
  • 101
  • How did you find first 040614.dd? I really like your second command because it is general i.e. exactly what I need because I have so many images that I want to test. Anything about that thing would be greatly appreciated. – Léo Léopold Hertz 준영 Mar 16 '16 at 12:23