Loop devices
| Linux-related notes
Shell, admin, and both:
|
For context, a *nix OS looking to mount a filesystem will only look to do so from a block device.
So when for any reason you have a file that, byte-for-byte, can be considered to contain a filesystem,
you can't directly mount that file, that's not how that API works.
A loop device takes a file stored on a filesystem, and presents a block device, so that the OS can mount it like any other. Basically it's one part of the OS tricking another in a useful way.
This is done e.g. for
- an encrypted filesystem-in-a-file,
- images of a hard drive, CD, DVD, floppy, or such
Loop devices on various systems:
- In linux, the devices are /dev/loop0 and so on. Management is done via losetup (util-linux package)
- In BSD and many derivations, this is called a virtual node device and often at /dev/vnd0, /dev/rvnd0 or /dev/svnd0. Management is done via vnconfig.
- except for FreeBSD, which merged the functionality into the memory disk driver (md). Management is done via mdconfig (verify)
- Solaris calls it lofi, and places the devices at /dev/lofi/1 and so on. Management via lofiadm
- OSX internalizes the functionality. You don't have to manage it.
- Windows doesn't support this at OS level - though there are many available programs that do the required trickery -- for the case of CD/DVD images, anyway
Linux loop devices
Mounting an image, or partition from an image, requires use of a /dev/loop* device to expose a file as block device.
The least-bother way to allocate a loop device is to let mount figure out a free one.
There are roughly two variants of this, because
- USB sticks usually do not have partitions, and directly contain a filesystem
- hard drives often contain a partition table and multiple partitions, as do CDs, in a different way
...there is an extra step in figuring that out.
Partitionless
To make mount figure out a loop device and mount the image:
mount -o loop -t iso9660 image.iso /mnt/myimage
In older versions you would do this explicitly:
mount -o loop=/dev/loop3 -t iso9660 image.iso /mnt/myimage
What it's doing (and what you could also do more manually) amounts to:
- figure out unused loop device from output of
losetup
- Associate loop3 with a specific image
losetup /dev/loop3 /images/image.iso
- Now /dev/loop3 acts like a block device, and is backed by that iso, so you can mount it:
mount /dev/loop3 /mnt/isoimage
Once you're done, you'll probably want to detach the file from the loop device. It seems newer versions of umount (since 2.6.25(verify)) can do this for you:
umount -d /dev/loop3
In older versions you would do it explicitly:
umount /mnt/isoimage losetup -d /dev/loop3
See also:
Partitions in image file
If your image is a whole-disk image coming from a partitioned disk, you have a few options:
The more automatic option is to make losetup effectively do a --partscan (-P), e.g.
losetup -f --show -P sdcard_image.img
This makes it add devices for each partition it finds, e.g. prints /dev/loop3 and makes /dev/loop3p1 through /dev/loop3p6 (whatever's in the partition table)
The same, slightly more manually (and with you choosing a free loop device):
losetup /dev/loop3 /images/sdcard_image.iso
partprobe /dev/loop3 # makes the kernel aware of the partitions,
# sets up partition-specific block devices (e.g. /dev/loop3p5)
fdisk /dev/loop3 # to figure out the partition device name you want
mount /dev/loop3p5 /mnt/sd_part/
And, when you're done:
umount /mnt/sd_part/ losetup -D /dev/loop3 # -D seems preferred, TODO: figure out exact difference to -d
Another option is using kpartx, which is focused on that scanning part
- may need to be installed, though
- and can also -a to add, -d to remove
You could even figure out the offset of your filesystem, e.g. from reading the partition table.
This is more annoying to do, but you can do more without involving the kernel or specific tools.