cannot mount .img file - “not a directory” error

Question

I try to execute the following command on an ubuntu 12.04 system:

sudo mount minix203.img -o loop -t minix /mnt/myminix/

in order to mount an .img file with minix partition; and get the following error instead:

mount: Not a directory

what is wrong with my command?

Answer 1

I assume that it's true what Bruce said - that it contains whole partition table. Then there isn't anything unusable in that. For the following command you need util-linux in version 2.21 or higher.

sudo losetup --find --show -P minix203.img

That should attach your image to a loopback device and show you which loop device the image is attached to (eg. /dev/loop0). Assuming that, fdisk -l /dev/loop0 should show you the partition table and device names for you to be able to mount those. So you'll end up with something like:

sudo mount /dev/loop0p1 -t minix /mnt/myminix

Should work. Note that loop option is gone, losetup takes care of that part.

However, if you happen to not have util-linux package in right version, you can do this manually using fdisk and losetup (or better - install the package from external source). You'll just have to do some calculations in that case. First thing is to attach the image of whole drive:

sudo losetup --find --show part.img

That should tell you the device name - let's assume it's /dev/loop0. Then, try fdisk -l on it to get the partition layout:

fdisk -l /dev/loop0

For my file I get output like this:

Disk /dev/loop0: 67 MB, 67108864 bytes, 131072 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
Disk identifier: 0x2645940b

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1            2048       63487       30720   83  Linux
/dev/loop0p2           63488      131071       33792   83  Linux

Don't get deceived, these might not be existent device names. You'll have to determine which partition do you want to mount using this table. Size or filesystem type should let you make some assumptions.

Now it's calculation time - you'll need an offset of your partition and it's size. You get that by multiplying sector sizes by unit size, to get result in bytes. You can see fdisk tells me that my sector size is 512 bytes, so if I want to mount /dev/loop0p1, it starts at (2048 * 512)-th byte. That is the offset and it's equal to 1048576 (in case of that example of course).

Size in sectors is end_sector_number - start_sector_number + 1, because these numbers are inclusive (end sector is within that size). Here it equals 61440 sectors == 31457280 bytes. That's what we needed.

You can detach loopback device now and reattach it limiting it's size constraints to the particular partition you'd like to mount (substite those numbers with your own):

sudo loopback -d /dev/loop0
sudo loopback -f --show -o 1048576 --sizelimit 31457280 part.img

It will probably attach it to /dev/loop0, which you can now safely mount:

mount -t minix /dev/loop0 /mnt/myminix

That should be almost fully operational, except for things that would normally affect the MBR of whole drive (like formatting with mkfs).

How does it work?

MBR partition table has a simple layout - there's 512 bytes of description first, where do partitions start, where they end, and then goes the data. With extended partitions it might be a little more difficult. You can set limits to your partition manually and that's kind of what kernel does for you on it's own, for your regular hard disk drives.

Answer 2

That's a pretty old version of Minix.

There's a Google Groups page that has your answer on it. Quoting from that artilce:

In minix203.img there is a entire hd image including partition table. What mount finds at the beginning isn't the first partition but partition table. And so mounting fails.

I believe the same thing is true of newer Minix 3 ISO images, too. There's a little bitty Joliet filesystem, and a bigger Minix filesystem that the installer knows about. So you can't just mount the ISO image (loopback) and look at things.

Answer 3

This answer might not be immediately relevant, but I found it during a chroot rescue.

My circumstance:
I installed Windows after Ubuntu on my computer and my boot loader(grub) got corrupted and os-prober couldn't see the Ubuntu images on the system.

Here is what I did:

1) Booted using a Ubuntu Live CD.

2) From the disk manager found out the location of my volumes:
root - /dev/sda6
boot - /dev/sda8

3) Created a temporary directory /tmp/mydir and executed the following commands as root.

   mount /dev/sda6 /tmp/mydir
   mount --bind /proc /tmp/mydir/proc
   mount --bind /sys /tmp/mydir/sys
   mount --bind /dev /tmp/mydir/dev
   mount --bind /dev/pts /tmp/mydir/dev/pts

Finally, I wanted to bind the boot device ie /dev/sda8 to the /tmp/mydir/boot folder and then came the trouble.

   mount --bind /dev/sda8 /tmp/mydir/boot

and I got the below error:

   mount : not a directory

Initially I was a bit confused about this one and this GitHub Article helped me resolve it. The problem occurred when I tried to mount the device(here /dev/sda8) into an already mounted device(here /dev/sda6). Simply put, you cannot do that as the --bind option expects a directory and not a block device like /dev/sda8 as input.

Now the good news! There is a workaround. I mounted the boot volume to another directory in /tmp and then binded this directory to /tmp/mydir/boot.

    mount /dev/sda8 /tmp/booty
    mount --bind /tmp/booty /tmp/mydir/boot

This resolved the mount : not a directory error.

4)I did a chroot rescue to resolve my ultimate problem.