Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I created an image of a Windows PC using the dd command. I want to mount the image in SuSE 10.3. Whenever I issue the command
Code:
mount -o loop file.name /mnt/dir
it says file type must be specified. When I attempt to specify file type there are no options for fat32 or ntfs (I am pretty sure it was a fat32 system). I tried using vfat by using the command
Code:
mount -t vfat -o loop file.name /mnt/dir
but I get the following error.
Code:
mikem-mininote:/home/mike # mount -t vfat -o loop dianer /mnt/diane
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
mikem-mininote:/home/mike # dmesg | tail
VFS: Can't find a valid FAT filesystem on dev loop0.
NTFS driver 2.1.28 [Flags: R/W MODULE].
NTFS-fs warning (device loop0): is_boot_sector_ntfs(): Invalid boot sector checksum.
NTFS-fs error (device loop0): read_ntfs_boot_sector(): Primary boot sector is invalid.
NTFS-fs error (device loop0): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
NTFS-fs error (device loop0): ntfs_fill_super(): Not an NTFS volume.
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev loop0.
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev loop0.
mikem-mininote:/home/mike #
Can anyone tell me how to resolve this issue? Any help is greatly appreciated! Thanks so much. Mike
Use vfat as the filesystem for fat32 filesystems. Did you backup a partition ( e.g. /dev/sda1 ) or the entire drive (e.g. /dev/sda ). You may need to use losetup with an offset so the device starts at the correct place.
Look at the output of "file -s <imagefile>". It will tell you what is on the file if it can.
Use vfat as the filesystem for fat32 filesystems. Did you backup a partition ( e.g. /dev/sda1 ) or the entire drive (e.g. /dev/sda ). You may need to use losetup with an offset so the device starts at the correct place.
Look at the output of "file -s <imagefile>". It will tell you what is on the file if it can.
I did the whole drive. My command was something to the matter of fact of
I successfully decompressed the file so now it is just dianer, and I am attempting the mount of that image file.
Here is the results of the file command.
Code:
mikem-mininote:/home/mike # file -s dianer
dianer: x86 boot sector, Microsoft Windows XP MBR, Serial 0xc766c766
mikem-mininote:/home/mike #
I am confused about how I would set the offset for this image file with the losetup command. I issue a command previous to mount like
You need to include the loop-device or -f option and include the image filename when using losetup. Be sure to read the info page. Another thing is that the first partition begins on cylinder 1 and not sector 1. So your offset is probably wrong.
Here I tried a simple experiment. I used fdisk to list the partition table. I used the -u option so that the offsets are listed in 512 byte sectors. Then I used dd to cut out a small part of the partition and save it as a file, and then used the "file" command to examine that file.
Code:
Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders, total 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x94e494e4
Device Boot Start End Blocks Id System
/dev/sda1 * 63 60818636 30409287 7 HPFS/NTFS
/dev/sda2 60822090 63970829 1574370 82 Linux swap / Solaris
/dev/sda3 63970830 195366464 65697817+ f W95 Ext'd (LBA)
/dev/sda5 63970893 74461274 5245191 83 Linux
/dev/sda6 74461338 195366464 60452563+ 83 Linux
jschiwal@hpamd64:~> sudo dd if=/dev/sda of=test.img skip=63 bs=512 count=4096
4096+0 records in
4096+0 records out
2097152 bytes (2.1 MB) copied, 0.0675431 s, 31.0 MB/s
jschiwal@hpamd64:~> file -s test.img
test.img: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80)
I prefer using fdisk with the -u option and setting the block size of dd (bs=512) to 512 bytes to match the "-u" fdisk option. It is easier to match the offsets in the different commands this way, and 512 is the lowest common denominator for various utilities dealing with block sizes.
Here is another experiment more applicable to your situation. I copied a portion of /dev/sda to a file. Then I used losetup. Then I used file to examine the loop device.
If I had copied the entire device using dd, then I should be able to mount the file using:
sudo mount -t ntfs /dev/loop1 testdir
One thing I can't answer is what you do to limit the extent of /dev/loop1 when you have more than one partition. The mounting process will prevent you from writing past the first partition.
Another thing I'm not sure about is if you need to create the loop devices in reverse order (top-down) so that the last partition is created first.
Also, whether it is possible to mount a loop device for the entire file (including the partition table and MBR) and have the separate partitions show up as devices in /dev/ without needing more loop devices.
----
Making an image of a partiton instead might be a better idea. You could make a separate backup of the MBR as well. Restoring the MBR will partition the new drive. Then you can use dd to restore th e partition.
In a slightly unrelated topic, before creating an image backup of a disk or partition, consider filling the partition(s) with files containing zeroes. Then delete these files before creating the images. The drive or partition will compress to a much smaller size if the empty spaces contain old file patterns. I tested out this idea using my /boot/ partition on my desktop and the difference in sizes was dramatic.
Code:
df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 155543 24602 122911 17% /boot
jschiwal@hpmedia:~> sudo dd if=/dev/zero of=/boot/zero.file bs=1024 count=122910
122910+0 records in
122910+0 records out
125859840 bytes (126 MB) copied, 1.6724 s, 75.3 MB/s
jschiwal@hpmedia:~> df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 155543 147996 0 100% /boot
jschiwal@hpmedia:~> sudo rm /boot/zero.file
Notice how I matched the unit size again. 1024 bytes this time. I subtracted 1 from the available blocks to leave room for any extension to the directory.
Code:
sudo dd if=/dev/sda1 | bzip2 - >boot.img.bz2
321237+0 records in
321237+0 records out
164473344 bytes (164 MB) copied, 26.7602 s, 6.1 MB/s
jschiwal@hpmedia:~> ls -lh boot.img.bz2
-rw-r----- 1 jschiwal jschiwal 19M 2008-05-24 08:17 boot.img.bz2
jschiwal@hpmedia:~> file boot.img.bz2
boot.img.bz2: bzip2 compressed data, block size = 900k
jschiwal@hpmedia:~> bunzip boot.img.bz2
-bash: bunzip: command not found
jschiwal@hpmedia:~> bunzip2 boot.img.bz2
jschiwal@hpmedia:~> file -s boot.img
boot.img: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, 1st sector stage2 0x6441, GRUB version 0.97, code offset 0x48
jschiwal@hpmedia:~> ls -l boot.img
-rw-r----- 1 jschiwal jschiwal 164473344 2008-05-24 08:17 boot.img
jschiwal@hpmedia:~> ls -lh boot.img
-rw-r----- 1 jschiwal jschiwal 157M 2008-05-24 08:17 boot.img
Last edited by jschiwal; 05-24-2008 at 05:12 PM.
Reason: fixed bad grammer on 1st line.
I think you lost me. I read the losetup info page, but I am still having a hard time determining what offset I should use in order to mount the file with my back up image. Perhaps I am thinking about it all wrong. I just assumed that I could mount the image even though my image was of the entire disk because the disk contained only one partition. I didn't think about the fact that the MBR may cause issues with mounting the image. I should have just created an image of the partition instead of the entire disk, but it is too late now because I assumed it worked and overwrote the old disk. All I really need to do is extract some files from the partition contained in this image. I thought perhaps mounting the image file would be the easiest way to do so, but perhaps because I imaged the whole disk that is not the case. I could restore the image to disk I guess and then browse through the files I need and perhaps then just image the partition this time. Thanks for the help. If you have tips on determining my offset in order to mount this image I would love to hear them. Otherwise I think I am going to get started on restoring the whole image file to a disk. Thanks again! Next time I will be sure to image the partition in these cases instead of the whole disk. Mike
In case no one figured it out or someone needs clearer info...
I recently had the same conundrum. I imaged my vista laptop's drive in anticipation of upgrading to window's 7. I then realized that I couldn't actually access the partitions as I imaged the whole drive itself rather than a partition (using a really helpful windows version of DD). Of course, how else are you going to restore the drive precisely...(NOTE: If you do it this way, using the \\?\Device\Harddisk0\DR0 backs up the entire disk...)
Here's what you can do to map/mount the partitions if you don't know anything about the image...as root (or via sudo...):
2. # fdisk -ul <image_file> (optional: as you can see, file successfully guessed the offset above)
E.g. # fdisk -ul vista.img
You must set cylinders.
You can do this from the extra functions menu.
Disk vista.img: 0 MB, 0 bytes
240 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x7d760e5b
Device Boot Start End Blocks Id System
vista.img1 63 36136799 18068368+ 27 Unknown
Partition 1 has different physical/logical endings:
phys=(1023, 239, 63) logical=(2389, 239, 63)
vista.img2 * 36136960 390719487 177291264 7 HPFS/NTFS
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 239, 63) logical=(2390, 2, 35)
Partition 2 has different physical/logical endings:
phys=(1023, 239, 63) logical=(25841, 56, 40)
Not sure if you *have* to set cylinders...see how modern fdisk automagically figured out my partitions?
3. Take the partition's offset you want to access, in my case Partition 2/vista.img2 (partition1/vista.img1, I believe, is my laptop's recovery drive or possibly some vista/magic waste of space partition).
You can also alternately mount the device image with an offset via the mount -o ro,loop,offset=########## -t ntfs <image_file> /some/dir command.
E.g. mount -o ro,loop,offset=18502123520 vista.img /tmp/test
4. You can check the file here if you'd like: file -s /dev/loop#
...Note: it uses the first available loopback device...
E.g. # file -s /dev/loop0
/dev/loop0: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 240, hidden sectors 36136960, dos < 4.0 BootSector (0x80)
I recently had the same conundrum. I imaged my vista laptop's drive in anticipation of upgrading to window's 7. I then realized that I couldn't actually access the partitions as I imaged the whole drive itself rather than a partition (using a really helpful windows version of DD). Of course, how else are you going to restore the drive precisely...(NOTE: If you do it this way, using the \\?\Device\Harddisk0\DR0 backs up the entire disk...)
Here's what you can do to map/mount the partitions if you don't know anything about the image...as root (or via sudo...):
2. # fdisk -ul <image_file> (optional: as you can see, file successfully guessed the offset above)
E.g. # fdisk -ul vista.img
You must set cylinders.
You can do this from the extra functions menu.
Disk vista.img: 0 MB, 0 bytes
240 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x7d760e5b
Device Boot Start End Blocks Id System
vista.img1 63 36136799 18068368+ 27 Unknown
Partition 1 has different physical/logical endings:
phys=(1023, 239, 63) logical=(2389, 239, 63)
vista.img2 * 36136960 390719487 177291264 7 HPFS/NTFS
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 239, 63) logical=(2390, 2, 35)
Partition 2 has different physical/logical endings:
phys=(1023, 239, 63) logical=(25841, 56, 40)
Not sure if you *have* to set cylinders...see how modern fdisk automagically figured out my partitions?
3. Take the partition's offset you want to access, in my case Partition 2/vista.img2 (partition1/vista.img1, I believe, is my laptop's recovery drive or possibly some vista/magic waste of space partition).
You can also alternately mount the device image with an offset via the mount -o ro,loop,offset=########## -t ntfs <image_file> /some/dir command.
E.g. mount -o ro,loop,offset=18502123520 vista.img /tmp/test
4. You can check the file here if you'd like: file -s /dev/loop#
...Note: it uses the first available loopback device...
E.g. # file -s /dev/loop0
/dev/loop0: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 240, hidden sectors 36136960, dos < 4.0 BootSector (0x80)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
In case no one figured it out or someone needs clearer info...
