LinuxQuestions.org

LinuxQuestions.org (http://www.linuxquestions.org/questions/index.php)
-   Linux - Software (http://www.linuxquestions.org/questions/forumdisplay.php?f=2)
-   -   Unable to boot after using dd to restore an image to a larger drive (http://www.linuxquestions.org/questions/showthread.php?t=4175498981)

zaldoor 03-21-2014 09:21 AM

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

rtmistler 03-21-2014 12:25 PM

Have you tried something like?
Code:

dd if=`gunzip -c /trk/RDC_Images/hda.img.gz` of=/dev/hda
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.

zaldoor 03-21-2014 01:10 PM

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

Doc CPU 03-21-2014 01:41 PM

Hi there,

Quote:

Originally Posted by rtmistler (Post 5138790)
Have you tried something like?
Code:

dd if=`gunzip -c /trk/RDC_Images/hda.img.gz` of=/dev/hda

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.

Quote:

Originally Posted by rtmistler (Post 5138790)
I don't know how dd works by the way if you don't give it an if= argument.

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:

Code:

if=FILE        read from FILE instead of stdin
Quote:

Originally Posted by rtmistler (Post 5138790)
To make it easier, I'd recommend not gzipping your file until you debug how to get it right.

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

Quote:

Originally Posted by rtmistler (Post 5138790)
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.

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

[X] Doc CPU

jefro 03-21-2014 08:18 PM

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.

rknichols 03-21-2014 08:42 PM

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.

colorpurple21859 03-21-2014 10:26 PM

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.

rknichols 03-21-2014 11:38 PM

Quote:

Originally Posted by colorpurple21859 (Post 5139086)
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.

jefro 03-22-2014 03:05 PM

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?

rknichols 03-22-2014 08:35 PM

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.

zaldoor 03-25-2014 02:20 PM

Quote:

Originally Posted by jefro (Post 5139028)
How far does it boot? Any reference to where it stops?

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

zaldoor 03-25-2014 02:22 PM

Quote:

Originally Posted by rknichols (Post 5139044)
Can you run "fdisk -l" on both drives and see if it reports the same geometry?

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

zaldoor 03-25-2014 03:24 PM

Quote:

Originally Posted by jefro (Post 5139440)
OP, can you use a different clone app or tool than dd?

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?

rtmistler 03-25-2014 03:32 PM

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

From the manpage:

Quote:

noerror
continue after read errors

sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs
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.

little_wolf_e 03-26-2014 04:12 AM

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 04:35 PM.