Mount an ISO virtually using /dev/sr0 device

block-devicedevicesisoloop-devicemount

I'm doing a study about how CD-ROM can be mounted virtually and all I could find out was mounting using loop devices.

mount -o loop disk1.iso /mount-point

This is fairly easy.

I understand that /dev/sr0 is a block device and it point to some buffer in kernel and the kernel device driver puts the filesystem (ot whatever it puts i am not sure) in that buffer and when we use mount it mounts the filesystem to the specified mount-point.

But am wondering whether we can mount an ISO of our choice (e.g. disk1.iso) by using SCSI CD-ROM device /dev/sr0 (without changing anything in the kernel) as it is done in Vmware and Virtualbox, where we can specify the ISO and it automatically emulates a CD-ROM hardware and the ISO can be mounted using /dev/sr0 device?

The major problem which i see here is that how /dev/sr0/ will be linked to the iso?

Best Answer

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.

Related Solutions

Linux Kernel – Using devtmpfs for /dev

devtmpfs is a file system with automated device nodes populated by the kernel. This means you don't have to have udev running nor to create a static /dev layout with additional, unneeded and not present device nodes. Instead the kernel populates the appropriate information based on the known devices.

On the other hand the standard /dev handling requires either udev, an additional daemon running or to statically create device nodes on /dev.

Mount: could not find any free loop device

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