Identical disks that are not identical

staphanes · 03-08-2006, 07:24 AM

I'm looking for a way to copy my 60GB drive to a new one, and I bought a drive whose geometry on the outside label looks identical to the old drive:

Cyl 16383, Head 16, Sect 63, LBA 117,210,240

But I get problems trying to dd the old to the new, as it turns out that the two drives look different when checking with Linux fdisk:

Old: 240 heads, 63 sect/trk, 7752 cyls
New: 255 heads, 63 sect/trk, 7296 cyls

I guess the BIOS is playing games here. I'm using a ThinkPad T30 with the following BIOS:

Version: 2.03b (1IET64WW)
Date: 2003-03-13

My new disk is a Hitachi Travelstar HTE721060G9AT00,
the old is a Toshiba MK6021GAS.

I'm not sure this is a Linux-related problem, but I couldn't think of a better think-tank to approach. Thanks in advance for any suggestions how this can be solved, I mean how to make the disks look the same so I can use dd to copy the old to the new.

satinet · 03-08-2006, 07:40 AM

what commad are you actually using please..... (dd if=/dev/hda ......)

staphanes · 03-08-2006, 07:54 AM

I've simply tried dd if=/dev/hda of=/dev/hdc.

PTrenholme · 03-08-2006, 07:58 AM

Try a cat /dev/hda > /dev/hdc It might work, and what do you have to lose? You can always redo the partition...

marozsas · 03-08-2006, 09:47 AM

The correct way to copy contents beetween disks is:
1) Create a partition on the target disk, which is equal or greater than the source disk.
2) Create a filesystem on the target partition with checking for bad blocks (optional, recommended).
3) mount source partition as read-only and target partition as read-write.
4) transfer the files using tar:

Code:

# cd /mnt/source;
# tar -cf - . | ( cd /mnt/target; tar -xpf - )
# umount /mnt/source /mnt/target
# fsck /dev/target-partition

Repeat steps above for the remaining partitions.

Using dd or cat, whatever to clone a disk is not a good idea, since you will clone the fragmentation on the target disk as any badblocks on the source disk. And it will work only if the geometry is identical, which is not the case.

cheers,

staphanes · 03-08-2006, 10:01 AM

Thanks, but in my case I don't think this will work. About 55GB out of the 60 on the disk consists of one extended partition with LVM logical volumes that are not visable from Linux. So I can't think of any other tool than dd to do the copy.

My question is still why these two 'identical' disks not show up the same way in fdisk. Because of this, fdisk complains about partitions not ending on cylinder boundaries. Strangly enough, the BIOS doesn't even let you see the disks, so there is no way to tell what the hardware thinks about them :-(

marozsas · 03-08-2006, 11:42 AM

Quote:

Originally Posted by staphanes

consists of one extended partition with LVM logical volumes that are not visable from Linux.

Why not ? I just did that yesterday ! I am not kidding ! I have a 80G disk from IBM and it becomes defective. It has a 60G LVM partition with 5 logical volumes (home, extra, var, tmp, opt).
Starting my computer with a live CD, and only the new and old disks, I just did what I explained. The new disk is 80G too, but it has 6 cylinders more than the old one.

If you want I can help you in the process. You can have the benefit of a real experience, not just theory.

I think this path is more safe than struggling with different geometries.

cheers,

PTrenholme · 03-10-2006, 09:14 AM

Quote:

Originally Posted by staphanes

Thanks, but in my case I don't think this will work. About 55GB out of the 60 on the disk consists of one extended partition with LVM logical volumes that are not visable from Linux. So I can't think of any other tool than dd to do the copy.

My question is still why these two 'identical' disks not show up the same way in fdisk. Because of this, fdisk complains about partitions not ending on cylinder boundaries. Strangly enough, the BIOS doesn't even let you see the disks, so there is no way to tell what the hardware thinks about them :-(

(Emphasis added.)

Why are the LVs not visible from Linux? They should be in /dev/mapper, but, in any case, a pvscan should find them. If the problem is that the old LV has the same name as the new LV, you can deactivate and rename, say, the old LV, and then reactivate it so you can access both LVs via /dev/mapper.

By the way, running fsck on a LVs physical volume is, I discovered, a really good way to destroy a LV. fsck works fine if run on /dev/mapper/..., but not if run on dev/<raw LV disk>. Be warned!

staphanes · 03-11-2006, 11:50 AM

Thanks all for your feedback. I feel stupid to say that this was all my fault and that dd if=/dev/hda of=/dev/hdc actually worked as expected. I realised that I made a mistake after the dd command was issued (no need for details!), but now all is fine. In response to some comments, /dev/mapper doesn't exist on my Redhat 8 system, but if I run pvscan, it reports /dev/hda5 as ACTIVE and shows how much space is allocated and used. Linux can't see what's inside the LVM, as the data is in a non-Linux, proprietary format, and requires unique tools for copying etc. And thanks for the fsck warning!!!