Mounting a raw dump (using dd) of a removable media
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
Mounting a raw dump (using dd) of a removable media
Hi everyone
I am trying to recover some data from Jaz drives.
I am starting with the Jaz disks that are not bad and can be mounted. After the mount I can easily use 'mkisofs' to create a .ISO image of the disk and mount it on any other linux box using:
Code:
>> mount -o loop -t iso9660 jaz.iso /mnt
Using the same Jaz disk, I want to try and do the same thing but this time use 'dd' command instead.
Try 1: (after unmounting the Jaz drive)
Code:
>> dd if=/dev/jaz of=jaz.img bs=2048 conv=notrunc
>> mount -o loop -t msdos jaz.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Try 2:
Code:
>> dd if=/dev/jaz of=jaz.img bs=1 conv=notrunc
>> mount -o loop -t msdos jaz.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
>> mount -o loop -t vfat jaz.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
When I check 'jaz.img' file using 'file' command, I get:
Obviously I am doing something wrong. My guess is that I need to change the size of the blocks that 'dd' uses to read my device.
I am sure that my Jaz disk is formatted using msdos because this is the output of the 'mount' command on the machine that Jaz drive is connected to: (It's Octane machine running Irix 6.5)
Code:
/dev/rdsk/dks1d4vol on /jaz type dos (rw,partition=4,nosuid)
The reason I do not want to use the straightforward 'mkisofs' command is that some of my Jaz disks are not mountable due to I/O error and I was hoping that 'dd' might help me to recover the data!
Any input is really appreciated.
thanks in advance,
spam.wax
I don't understand why you want to create CD images. You can create a fileimage of a different filesystem.
Look at the jaz.img file with the "/sbin/fdisk -ul jaz.img" command. If the filesystem has partitions, then you need to add an offset to the losetup command to be able to mount it.
Here is an example where I just used dd to copy the first 2 partitions from a disk:
Code:
fdisk -ul sdi.img
You must set cylinders.
You can do this from the extra functions menu.
Disk sdi.img: 0 MB, 0 bytes
216 heads, 32 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xa4cd3ef1
Device Boot Start End Blocks Id System
sdi.img1 32 241919 120944 83 Linux
sdi.img2 241920 2204927 981504 83 Linux
sdi.img3 2204928 7831295 2813184 83 Linux
hpmedia:~ # losetup -s -f sdi.img -o $((32*512))
/dev/loop4
hpmedia:~ # losetup -s -f sdi.img -o $((241920*512))
/dev/loop5
hpmedia:~ # file -s /dev/loop4
/dev/loop4: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
hpmedia:~ # file -s /dev/loop5
/dev/loop5: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)
I used the -u option to fdisk to get the offsets listed in 512 byte blocks. This seems to work better for me.
If you know the offset, you can do this from the mount command. The losetup command is used by the mount command. Example:
mount -t ext3 sdi.img sdi -o loop,offset=$((512*32))
I don't understand why you want to create CD images. You can create a fileimage of a different filesystem.
Look at the jaz.img file with the "/sbin/fdisk -ul jaz.img" command.
Thanks for your reply.
I really don't care if it's CD image or not. As long as I can mount the dd dump, I will be extremely happy.
Following what you showed helped me mount the raw image and I can see its content
Although doing:
Code:
file -s /dev/loop1
only gives me:
Code:
$ file -s /dev/loop1
/dev/loop1: writable, no read permission
Now I need to try the Jaz disks that can not be mounted cleanly and using dd gives me I/O errors.
Here is a link to a Jaz Disk HOWTO for Linux. Iomega provided disks use the fat32 filesystem. The data is contained on partition 4 for Mac compatibility. So if your system detects the drive, you can simply try mounting the forth partition on the device, e.g. "sudo mount -t vfat /dev/sdb4 /mnt/jaz -o uid=<yourusername>,gid=<your-default-group>,fmask=117,dmask=007".
These options are just an example. So creating an image may not be necessary. However the important part is to use partition 4 and the vfat filesystem when mounting them. If partition 4 shows up in the devices, e.g. /dev/sdb4, you can use "file" and verify the filesystem.
You may have a problem if you used an offset for a different partition. If you created an image of a entire Jaz disk, then use fdisk to print out what the offset to the 4th partition is and use that in your losetup command.
The file command should mention the filesystem.
If you have a disk that has damage, you might look into ddrescue or dd_rescue. They are similar but won't quit if there is a read error. If you have two disks, and one is a copy but both have errors (maybe they are 20 years old), you can use these programs to read what they can from the good parts of one disk and reread from the second disk, overlaying the good information from the second disk to try to fill in the gaps from errors reading the first disk. http://www.forensicswiki.org/wiki/Ddrescue
The ddrescue and dd_rescue are distinct programs. They both do something similar , and have very similar names.
---
Another thing to try, in the case where the damage is to the partition table, is to use the offset information from a good disk (for partition 4); use losetup to setup a loop device at that offset and see if you can mount that loop device. Look at the offsets given for the good disks. I'll bet they are identical.
---
There were different sizes of Jaz disks and a Jaz disk preformatted by Iomega may have had been repartitioned and reformatted differently. Be careful of course. when in doubt, mount the device read-only. If you won't be writing to any of the disks, you can set up the loop devices read-only as well. Also remember the loop and offset options for mount if you are working on an image, or a disk with a bad partition table.
I am sincerely grateful for the time you have taken to provide me with these information... wow!
Quote:
Originally Posted by jschiwal
http://users.rcn.com/hsd/HOWTO/Jaz-HOWTO-4.html#ss4.1
Here is a link to a Jaz Disk HOWTO for Linux. Iomega provided disks use the fat32 filesystem. The data is contained on partition 4 for Mac compatibility. So if your system detects the drive, you can simply try mounting the forth partition on the device, e.g. "sudo mount -t vfat /dev/sdb4 /mnt/jaz -o uid=<yourusername>,gid=<your-default-group>,fmask=117,dmask=007".
The problem is these Jaz disks, formatted under fat16, have been used in a drive connected to an IRIX machine.
IRIX can detect some of them and mount them but some of them don't seem to have any partition information.
Although, I think some of it can be my fault because I didn't know about the partition 4 issue and I have created the images using only the 4th partition as the argument for dd:
Code:
dd if=/dev/rdsk/dks1d4vol ...
So basically I don't have 1 real 1:1 image of the jaz disk.
(Just curious about what's the reason behind using partition 4 under Mac )
I am waiting to receive a SCSI-to-USB interface so I can hook these to my Linux box and see if that makes any difference.
Quote:
Originally Posted by jschiwal
If you created an image of a entire Jaz disk, then use fdisk to print out what the offset to the 4th partition is and use that in your losetup command.The file command should mention the filesystem.
Unfortunately it seems I've lost the partition info on the bad disks. This is what I get checking them:
Code:
$ sudo fdisk -ul jaz-7.img
Disk jaz-7.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Disk jaz-7.img doesn't contain a valid partition table
Though for a mountable jaz disk I get this:
Code:
$ sudo fdisk -ul okjaz.img
You must set cylinders.
You can do this from the extra functions menu.
Disk okjaz.img: 0 MB, 0 bytes
64 heads, 32 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xc4f9014e
Device Boot Start End Blocks Id System
okjaz.img4 * 32 2091007 1045488 6 FAT16
I will definitely give ddrescue and dd_rescue a try as soon as I hook my drive to a Linux box, as it seems they are not available for IRIX.
Quote:
Originally Posted by jschiwal
Another thing to try, in the case where the damage is to the partition table, is to use the offset information from a good disk (for partition 4); use losetup to setup a loop device at that offset and see if you can mount that loop device. Look at the offsets given for the good disks. I'll bet they are identical.
Very good tip, I will try this tomorrow
Quote:
Originally Posted by jschiwal
Also remember the loop and offset options for mount if you are working on an image, or a disk with a bad partition table.
Can you please explain why I need to use loop and offset options if I am working on a jaz disk (not image) with a bad partition ?
One last question: Do I need to be concerned about byte orders (big-endian, little-endian) when using dd command ? Will it affect the partition info ?
thanks again
spamwax
Parallel SCSI and FC-AL
/dev/rdsk/dkscontroller#ddrive#{spartition#|vh|vol}
/dev/rdsk/dkscontroller#ddrive#llun#{spartition#|vh|vol}
/dev/dsk/dkscontroller#ddrive#{spartition#|vol}
/dev/dsk/dkscontroller#ddrive#llun#{spartition#|vol}
So you have controller# = 1; ddrive# = d4
I think that the 4 in dks1d4vol has nothing to do with the partition on the disk. I think that they are both 4 may be a coincidence. If it had been /dev/rdsk/dks1d4s4, then I think that would be a device for the 4th partition. Do you know what the "vol" signifies? {spartition#|vh|vol}.
Code:
/dev/rdsk/dks1d4vol on /jaz type dos (rw,partition=4,nosuid)
The partition to mount was in your mount option (partition=4). Linux doesn't have this kind of option. It looks like using the rdsk device, the raw drive device is used. Someone using Irix may chime in if this is the wrong info.
---
Quote:
Unfortunately it seems I've lost the partition info on the bad disks. This is what I get checking them:
Code:
$ sudo fdisk -ul jaz-7.img
Disk jaz-7.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Disk jaz-7.img doesn't contain a valid partition table
Though for a mountable jaz disk I get this:
Code:
$ sudo fdisk -ul okjaz.img
You must set cylinders.
You can do this from the extra functions menu.
Disk okjaz.img: 0 MB, 0 bytes
64 heads, 32 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xc4f9014e
Device Boot Start End Blocks Id System
okjaz.img4 * 32 2091007 1045488 6 FAT16
It seems to me that okjaz.img was repartitioned and formatted so that it contains a single partition. Although there is a 4 in the device name (okjaz.img4). This may mean that the first three partition entries in the MBR are blank and the 4th entry is used. Maybe this is what gives Mac compatibility.
On one of the images such as jaz-7.img try creating the loop device with same offset as a good disk:
sudo /sbin/losetup -s -f jaz-7.img -o 16384
/dev/loop1
Then examine this device with the "file" command.
sudo file -s /dev/loop1
If that doesn't work, try to determine if the good disks were pre-formatted or reformatted. If someone hasn't reformatted them, then my best guess is that they are simply bad or there was a problem when you copied them. See of you can mount them on the Irix system. If not, I'm guessing that they simply are bad. Maybe it's time to look at ddrescue or dd_rescue in that case. Use these programs on the device for the disks and not on the image files.
I just got my scsi-to-usb1.1 adapter and hooked up the drive to a Ubuntu box (It was recognized as sdb)
I inserted a cartrdige that neither Irix nor Vista could mount. This is the output of fdisk:
Code:
$ sudo fdisk -ul /dev/sdb
Disk /dev/sdb (SGI disk label): 33 heads, 62 sectors, 1022 cylinders
Units = sectors of 1 * 512 bytes
----- partitions -----
Pt# Device Info Start End Sectors Id System
8: /dev/sdb1 3072 2091007 2087936 a SGI xfs
9: /dev/sdb2 0 3071 3072 0 SGI volhdr
11: /dev/sdb3 0 2091007 2091008 6 SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----
0: sgilabel sector 3 size 512
So it seems that the someone has re-formatted the Jaz cartridge from the preformatted vfat to SGI.
Next, I tried to make loop devices and mount them, with no success
Code:
$ sudo losetup -s -f /dev/sdb -o $((3072*512))
/dev/loop0
$ sudo file -s /dev/loop0
/dev/loop0: data
$ sudo mount -t xfs /dev/loop0 /mnt
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
I did try another loop device but this time with no offset and it gave me the same error.
Based on what I found, partition 9 is where Irix would look for kernel and partition 11 is the whole volume of the disk.
Also It seems that my partition table is messed up. For example this is what other users had reported:
Code:
---- partitions -----
Device Info Start End Sectors Id System
/dev/sdb1 boot 5 3424 1846576 a SGI xfs
/dev/sdb2 swap 3425 3804 205408 3 SGI raw
/dev/sdb9 0 4 2620 0 SGI volhdr
/dev/sdb11 0 3804 2054604 6 SGI volume
----- bootinfo -----
Bootfile: /unix
----- directory entries -----
0: sgilabel sector 2 size 512
1: sash sector 4 size 140800
2: ide sector 558 size 977920
As you can see, I don't have any directory entries but doing a hexdump reveals the file/folder names I am expecting to see on the Jaz drive.
I can only guess that either the partition table is messed up or xfs on SGI/IRIX partitions the media differently than xfs on Linux expects it ?!!!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.