Unable to boot after using dd to restore an image to a larger drive
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
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.
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
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
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
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.
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.
Last edited by rknichols; 03-21-2014 at 09:45 PM.
Reason: Add "Oops..."
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.
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.
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.
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?
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.