Re: having trouble mounting disk image on loopback device

On Sun, 09 Jul 2006 23:30:17 -0700, iforone wrote:


Douglas Mayne wrote:
On Sun, 09 Jul 2006 18:13:42 -0700, jasonmbowen wrote:

Here is the output I'm getting when trying to mount a disk image
created by dd that has been assosciate with /dev/loop0

root@ubuntu:~# losetup -d /dev/loop0
root@ubuntu:~# losetup /dev/loop0 ./hdd.dd
root@ubuntu:~# fdisk -l /dev/loop0

Disk /dev/loop0: 4303 MB, 4303290368 bytes
255 heads, 63 sectors/track, 523 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 1 280 2249068+ 83 Linux
/dev/loop0p2 281 523 1951897+ b W95 FAT32
root@ubuntu:~# mount -r -t ext3 /dev/loop1 /mnt/ext3

FWIW, the syntax isn't the same as /etc/fstab reads
Not sure if you did that just to 'distinguish' between the 2 for us...

mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or other error
(could this be the IDE device where you in fact use
ide-scsi so that sr0 or sda or so is needed?)
In some cases useful info is found in syslog - try
dmesg | tail or so

I have another image created with dd that I got off a DVD that came
with the book I'm going through and I get the same problem with it.
I'm at a loss as to why this is happening.

Caveat: I have never tried this with a real disk, that is, starting with
a dd image taken from a physical disk.

I agree with the other response that images of partitions are easily
mountable using loopbacks. I thinks that an entire disk image is also
possible, but it is more tricky. To do it, you need to use losetup using
the offset option to indicate the start of each partition. This is a
useful command for getting the correct values for the offset:

# fdisk -lu /dev/loop0

Normally, fdisk specifies cylinders, but the start sector is more useful
in this case. To get the correct value multiply by 512 to get the byte
offset.

To verify this is could work, I setup a test file of 100M with two
partitions, approximately 50M each. Here is the resulting partition
table on the "loopback disk" that I tested:

# losetup /dev/loop0 test.file
# fdisk -lu /dev/loop0

Disk /dev/loop0: 102 MB, 102400000 bytes
255 heads, 63 sectors/track, 12 cylinders, total 200000 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 63 96389 48163+ 83 Linux
/dev/loop0p2 96390 192779 48195 83 Linux

Therefore, to mount each partition, I used these commands:
losetup -o 32256 /dev/loop1 test.file

losetup -o 32256 /dev/loop1 test.file
mount /dev/loop1 /mnt/vhda1

losetup -o 49351690 /dev/loop2 test.file

losetup -o 49351680 /dev/loop2 test.file
mount /dev/loop2 /mnt/vhda2


Final Notes:
Sectors on hard disks were originally addressed by CHS (cylinder,
head, sector), but now LBA is used. LBA should be compatible with
this method, but I am not positive. I'll watch this thread to see
if this is refuted.

I assume these images could be used with VMWare as a "flat" disk.

--
Douglas Mayne

Hi Doug;
I think I learned a little while back that one "mounts" filesystems,
(partitions, not devices) -- hence if one device contains many
*different* filesystem types (ext3, vfat, reiserfs), normally, one
mount command will not suffice...For that matter, even if they are of
the same FS type - I think)

Do I misunderstand ?

On a real hard disk, there are separate devices for partitions. In my way
of thinking, devices are mounted. I think about it this way:

1. A device and and mount point are linked together by the
mount command.
2. At a minimum, these conditions must be met for a mount
command to succeed:
a. The device must exist
b. The mount point must exist
c. The device must contain a filesystem recognizable
by the kernel.

There are other considerations (such as user permissions, etc.), but I think
the above is the fundamental. It is also possible to write directly to the
device without using a filesystem and without mounting it (raw I/O). But you
are correct- when a device is mounted, it implies the a filesystem is being
used, not raw I/O to the device, so it could be just a matter of how to
visualize the work done by the mount command.


I believe your 'offset' option can be of use here, but not sure how to
actually implement it...so

Regards

I forgot to show the mount command after using losetup. I also made a typo
for one of the offset values. I have fixed both errors above.

Other mount options can be specified for the filesystem, etc. can be used.
The simple form usually works for me because mount can usually determine
the filesystem type before mounting it.

--
Douglas Mayne
.

Relevant Pages

  • Re: multi volume with tar
    ... a disk definitely won't result in a filesystem-like structure. ... won't mount that floppy. ... You *never* write to the raw device node of a mounted filesystem ... because writing directly to the device mangled the ...
    (comp.os.linux.misc)
  • Re: USB stick access freezing up system?
    ... would expect the application to fail, but the stick is just a mount in ... How can it corrupt a filesystem on a device that's been removed? ... corruption of its filesystem, ... I have transported an MFM disk that had not been parked with the ...
    (comp.unix.bsd.freebsd.misc)
  • Hints for precision benchmarking...
    ... and run into the usual problem of noisy data preventing any ... * Don't mount filesystems you do not need. ... This removes atime updates to disk from your I/O picture. ... This results in a consistent filesystem layout. ...
    (freebsd-current)
  • Re: mount --bind question.
    ... I would *highly* suggest more than two partitions; ... something specific for whatever disk space you have left. ... >back into the right place in the filesystem through symlinks in the root ... but I'm wondering if it would be better to use mount ...
    (comp.os.linux.misc)
  • Re: /include/nocopy
    ... This means that if I lose a disk, ... > one at a time when you issue the mount. ... > all potential shadow set members, but it looped through the list, ... OK, instead of having a fixed MOUNT command, I construct it on the fly ...
    (comp.os.vms)