I created an image using dd and restored it to the same size drive (64MB) with no issues, it boots fine into CE and our software works great.

When i try to restore the image to a larger drive (128MB), it doesn't boot.

From reading many articles online, dd should not have any problems restoring an image to a larger drive.

Here are the dd commands use to capture and restore:

Capture image:
dd if=/dev/hda conv=sync,noerror bs=64K | gzip -c > /trk/RDC_Images/hda.img.gz

Restore image:
gunzip -c /trk/RDC_Images/hda.img.gz | dd of=/dev/hda

When i restore to both drives 64MB or 128MB, they both completed the process successfully with no errors.

When i compare both drives using FDISK after they are imaged, all 3 partition are the same and the boot marker is on /dev/hda1. The only diffence between the 2, are the cylinder size, 64MB is 977 Cyl and the 128MB is 1954 cyl. Not sure if this would cause a problem for booting.

Has anyone experience the same problem? Any ideas why it won't boot on a larger drive?

Any help would be greatly appreciated.

Thanks,
Zaldoor

Have you tried something like?I don't know how dd works by the way if you don't give it an if= argument.

To make it easier, I'd recommend not gzipping your file until you debug how to get it right. But you are correct that if you have a full byte by byte copy of an entire drive, you can write that to a larger drive using dd. The actual result will be that the physically larger drive will become the logical size of the smaller drive when the dd operation is done.

No i have not tried that yet. I will give it a try and let you know the results.
Thanks for the quick reply.

Zaldoor

Hi there,

I don't want to be a spoil-sport, but I don't think that will help - don't forget that the OP mentioned it worked fine as long as the target device is the same size as the image. To me, that is a clear indication that the general logic is right.

Very simple: It takes its input from stdin instead, as any decent Unix tool does. Just issue a 'dd --help' and look at the explanation:

Should do no harm unless you're going to mount the image or examine the file system inside it.

Right. And you can resize the partition later or create an additional one to use the extra space.

[X] Doc CPU

I'd agree that it is something to do with some issue between sizes. dd is a bit by bit so any reference to any size or unique name or such will/may fail.

How far does it boot? Any reference to where it stops?


It could even be that some protection scheme is in play. Some set file has to be at some place in order to boot or run.

I use G4U to clone some very old stuff that has protection on it. I think the original drive was 128M and some of the smallest drives we get are 8g so the image still thinks it is on 128m. I never use all those extra options on dd.

A drive as small as 64M could well have been in use with a BIOS that understood only C-H-S addressing, and the boot loader on that disk would have been set up accordingly. With only a single partition on the drive, your BIOS may be guessing (and yes, there is some guesswork involved) a geometry that differs from the original, and that would cause the C-H-S boot loader to fail.

Can you run "fdisk -l" on both drives and see if it reports the same geometry?

Oops. Looking back, I see that the drive has multiple partitions. Still, it's worth checking that the same geometry is detected.

Maybe with the same size drive the data is being put back at the right location on the drive for the bootloader to find boot files, but on the larger driver the data is being spread over a larger portion of the drive so that the bootloader isn't finding the boot files.

Restoring a full drive image to another drive puts everything back in exactly the same LBA locations.

64MB is 977 Cyl and the 128MB is 1954 cyl.

Some of the adapters have a jumper to limit the cylinders. Thought it was 4K.

Guess there was some older limit or oddity of bios.


Some oddity of design difference.

OP, can you use a different clone app or tool than dd?

It's the number of heads and sectors per track that are important. Since the number of cylinders are in the same 2:1 ratio as the total size, odds are that the other parameters are the same for the two drives, but I can't imagine what else would cause the boot to fail.

Once I bypass PXE boot, it tries to boot into windows CE and it stops there.

I did run fdisk -l and compared both hard drives 64MB and 128MB, both had the same geometry except for the Cylinders.

Yes, we have been using Ghost in the past with no issues, but we are getting away from commercial licensing products and going open source. I am playing with Partition Saving, but i don't think it will do what I want it to do. In means of creating an image of /dev/hda and save it to a NFS share. Do you have any suggestions of another tool that I might be able to try?

I'd recommend redoing that dd command without the conv= arguments.

From the manpage:

My interpretation is that the conv argument is causing padding to be added and using SPACES for that padding. And there's a default ibs-size, mine shows 512. Further, if you have a read error, it's continuing.

Try dd without gzip, just create an image file matching your disk size.

Then try dd of the .img file to the 64M and 128M disks and indicate if you still see problems.

Fine to gzip something, just since things aren't working; I'd remove the conv= and gzip complications.

Hi,

If the drive has a separate boot partition, perhaps you could try recreating a similar partition table on the new disk then copying the partitions separately. This might avoid geometry problems. This is something of a manual method, and as previous posters have said, an application designed to do such things may be a better direction to go.