![]() |
Unable to boot after using dd to restore an image to a larger drive
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?
Code:
dd if=`gunzip -c /trk/RDC_Images/hda.img.gz` of=/dev/hda 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,
Quote:
Quote:
Code:
if=FILE read from FILE instead of stdin Quote:
Quote:
[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.
|
Quote:
|
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.
|
Quote:
|
Quote:
|
Quote:
|
I'd recommend redoing that dd command without the conv= arguments.
From the manpage: Quote:
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. |
All times are GMT -5. The time now is 06:44 PM. |