Loop devices

From Helpful
Jump to navigation Jump to search

Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts ·· find and xargs and parallel · screen and tmux ·· Shell and process nitty gritty ·· Isolating shell environments ·· Shell flow control notes
Linux admin - disk and filesystem · Linux networking · Init systems and service management (upstart notes, systemd notes) · users and permissions · Debugging · security enhanced linux · PAM notes · health and statistics · Machine Check Events · kernel modules · YP notes · Automounters and permissions · loop devices · unsorted and muck
Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·
Somewhat sorted - dotfiles ·
Remote desktops - XDMCP notes



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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.


Encrypted loopback