Mount: could not find any free loop device

isoloop-devicemount

When I try to mount an ISO image with mount -o loop I get

mount: could not find any free loop device

Running losetup -a shows

/dev/loop0: [0005]:2464 (/dev/sda1)
/dev/loop1: [0005]:3439 (/dev/loop0)
/dev/loop2: [0005]:4482 (/dev/loop1)
/dev/loop3: [0005]:4486 (/dev/loop2)
/dev/loop4: [0005]:4490 (/dev/loop3)
/dev/loop5: [0005]:4494 (/dev/loop4)
/dev/loop6: [0005]:4498 (/dev/loop5)
/dev/loop7: [0005]:4502 (/dev/loop6)

What is the purpose of a loop device which refers to sda1? And what is the purpose of all the other loop devices referring to the previous one?

Is it safe for me to disconnect these loop devices so that I can use them? If so how do I do so? (Running losetup -d /dev/loop[0-7] gives loop device is busy.) If I cannot disconnect these, how do I create new loop devices that I can use for mounting ISO images?

p.s. I am running Debian "wheezy" v 7.1.0.

Best Answer

Take a look and see if there are any mounts using any of the above loopback devices. You can use the mount command to see this:

$ mount

If they are mounted, they you'll likely need to unmount (umount) them prior to getting losetup -d <loopdevice> to detaching them.

$ umount /dev/some/mount

As to if it's safe or not, that really depends on what these are being used for. I'd probably hold off till I had a better grasp of what these loop devices are for, before I started unmounting them. Just a guess but they might have something to do with an encrypted drive.

Therefore I'd create another one just to be safe.

making another loop device

Here are the steps:

$ sudo mknod -m640 /dev/loop8 b 7 8

-m640 define the permission of the device
/dev/loop8 define the name of the device
b for the creation of the special block device
7 8 the number 7 AND 8 define the MAJOR AND the MINOR

Check if the loop is created:

$ ls -l /dev/loop8
brw-r----- 1 root root 7, 8 Oct 3 14:54 /dev/loop8

Now set ownership on the device:

$ sudo chown root:disk /dev/loop8

References

Howto create Loop Device on Linux

Related Solutions

Mounting an old floppy image file (.ima format) – how hard can it be

If you can't mount the image you might still be able in some cases to "stream out" some of its data with cpio.

Once you've ascertained whether the image is:

An image using a supported filesystem and a partition --> mount
An image using a supported filesystem and more than one partition --> mount with offset, or use dd to extract a partition with offset then mount that partition only or use something like kpartx
An image not using a supported filesystem or with no filesystem at all --> kernel support and further investigation...

You can use the hexdump and strings utilities to try to analyze the header and to extract text strings from the image and gain more information about the image file and its structure.

Something captured my interest in doing so:

@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF

There's a line like this for every single binary in the image so you somewhat know what's in there. Also, in this case, when you take a closer look at how the installation process occurs on the original platform with installpkg, you find out that:

The basic mechanism to transfer software from a floppy disk to the UNIX System V /386 hard disk is cpio.

Basically, the data is extracted with cpio to /usr/tmp/install and a series of files are included with this (an install, ascii, file, name and size file). It so happens here that this command:

cat U19.IMA | cpio -imdv

outputs malformed number errors to begin with, but then creates a /usr/bin folder with the contents of the image! The tr I was looking for is there:

#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.

Trying cpio in the first place can't hurt!

Mount an ISO virtually using /dev/sr0 device

The thing here is that /dev/sr0 is linked to a kernel device driver. That device driver will allow access to a physical CDROM if available through that node; VMWare and VirtualBox emulate hardware as you mention and hence the kernel and device driver think they're communicating with hardware.

The /dev/sr0 doesn't point to a certain buffer directly, it provides an interface to the block device interface that allows userspace processes to acces the contents of the hardware device.

If you want to make an image available as a block device, then your only choice (besides virtualization and emulating hardware) is to use loop devices with losetup... or to write your own replacement device driver, but I expect that's not a viable option for now.

If you want to make that image available as /dev/sr0 (are we talking about faking out some software that demands access to a CDROM at that location?) then you could move that file to e.g. /dev/sr0.moved and then symlink the appropriate /dev/loopX to /dev/sr0. Of course, if the software in question tries special commands that only apply to CDROM devices, then this won't work. Otherwise it shouldn't be a problem.