How to migrate XP, Vista, Linux, BSD and Solaris to a bigger hard disk

shortz,

Welcome to JustLinux.


Xp or any MS Windows system does not support booting from an external device, except eSata that is factory-fitted at the rear panel or a specially hacked version.

Also it is not wise to have two Xp systems, with identical system files in any booting operation. It is much safer to remove one of the two disks and arrange it in exactly the same hardware condition as such information would have been embedded into the system during installation. This is to say it will not boot from e: if it was originally installed in c:.

As far as I can tell your original disk may have some corruption resulting reading difficulties with some sectors. The rest appears to have been successfully cloned.

Depending on the age of the laptop your old disk may be a Pata and the cloned Sata may not be physically fitted into its internal hard disk position.

If you intend to replace the hard disk get one that is of the same type. You can clone the 3rd disk from either of the two disks you have got.

saikee,

Thanks for the quick and thorough response!

I did not know that XP could not boot from an external drive, with the exception of eSATA, etc. Good to know.

What I termed IDE (incorrectly) is likely PATA. Yes, the external drive is too large to fit into the laptop. My original plan was to backup XP, resize the NTFS partition smaller and install another OS for multiboot. In case I messed things up or wanted to return the system to original setup I hoped I could use the backup and dd from external drive to internal drive.

I will obtain a matching disk (interface, enclosure, etc) and try the backup and replace method next go round.

Again, thanks for all your help as well as the contribution from others on this thread!

--shortz

The Dell Latitude D420 is a laptop. All laptops use 2.5" hard disk as oppose to the 3.5" size hard disk used in the desktop.

I would advise you to remove the hard disk of the laptop and check the connection. The IDE or Pata has two rows of pins whereas a Sata doesn't, otherwise the two look exactly the same externally. It may be possible for you to check the original spec to find out if it is a Pata or Sata hard disk.

First off, wanted to give a big thank you to everyone here for comments and suggestions, and would like to get thoughts from those there on my situation.

I need to re-image drives quite often, and for my purposes I need to do the WHOLE drive. (All partitions, including boot record.) (If you REALLY need to know why, PM me. :D)

Because my images are stores on a CIFS mountpoint, speed and size is an issue. (i.e. I CAN do a dd if=/dev/sda of=/mnt/cifs/image.out but it would take quite longer than necessary.) So, looking at alternatives, 'partimage' will copy ''just what's filled'' on the drive. However, it only does partitions and not the whole drive.

So my proposed solution (working on now) is this, in high-level, using a custom Live Linux CD that will boot up into Text mode and run the following in a script:
1. Mount the network share.
2. Write the new partition table - sfdisk /dev/sda < table.txt
3. (Resync the table?)
4. Use partimage to restore all the partitions.
5. Use dd to write the first 1k (1024) bytes of the drive, to make sure the full MBR is there.

Again, this is high level, but does that seem like it has any huge holes in it? And, is there an easy way (other than rebooting) to resync the table? I saw someone mention "partprobe" but not sure if that'll do anything it needs to.

Thanks in advance all,
Mike.

Coyttl,

Welcome to Justlinux!

I suppose your backup system is always bootle-necked by the network speed.

You idea of breaking up the hard disk image into parts should work as long as you make sure the first sector, which contains the partition table, is saved as part of the procedure.

I often back up a large hard disk, say 1 TB large, but only interested in the first partition. The quickest way is to "dd" the first sector out and put it on a say a smaller disk. The transferred partition table makes the smaller hard disk a outcast because its partition table points to higher number of cylinders the disk hasn't got and most partitioning software would not touch it. The fdisk program in Linux can be used to delete the unwanted partitions making the smaller disk "legal" again.

The partition table is the guide for program like dd to carry out cloning as each partition's boundary limit is adequately defined.

Thus if you restore the first sector, only 512 bytes by command

Code:

---

dd if=/dev/sda of=/mnt/sda_1st_sector bs=512 count=1

---

You can restore any partition in piece meal fashion.

You do need to make sure the partition table isn't altered.

Also if you use logical partitions and LVM it will be necessary for you to adhere to the partition layout rigidly as these partitions addresses are hard-coded between partitions and not inside the first 512 bytes.

Quote:

---

Originally Posted by saikee

I suppose your backup system is always bootle-necked by the network speed.

---

Right now that's true, and as soon as I get everything 're-imaged' to a new, more useable fashion, the net's going to be upgraded to a fiber backbone to speed up data transfers. :) But that's a little ways off...

Quote:

---

Originally Posted by saikee

You idea of breaking up the hard disk image into parts should work as long as you make sure the first sector, which contains the partition table, is saved as part of the procedure.

I often back up a large hard disk, say 1 TB large, but only interested in the first partition.
...
The partition table is the guide for program like dd to carry out cloning as each partition's boundary limit is adequately defined.

---

Yeah, I got that.. In my case, since we're doing software testing on many different flavors of OSes (mostly Windows), sometimes I need the entire disk (read: All partitions and data. Empty space I don't care about) since an OS on a machine from a manufacturer may have a "backup" or "data" partition. Unfortunately, I gotta save those as well.

Quote:

---

Originally Posted by saikee

Thus if you restore the first sector, only 512 bytes by command

Code:

---

dd if=/dev/sda of=/mnt/sda_1st_sector bs=512 count=1

---

---

Ah, okay! So I can use these commands together:[CODE]sfdisk < partitions.txt
dd if=/dev/sda of=/mnt/sda_1st_sector bs=512 count=1[/COUNT]..instead of saving 1024 bytes, I only need the first 512... Right?

Quote:

---

Originally Posted by saikee

You can restore any partition in piece meal fashion.

Also if you use logical partitions and LVM it will be necessary for you to adhere to the partition layout rigidly as these partitions addresses are hard-coded between partitions and not inside the first 512 bytes.

---

I'm not two worried about ever having to change partitions - since the main point of my imaging is to 'restore an operating system back to it's fresh standing' without the software we're testing on it, the drives themselves will never change.

My main concern for this whole process I mad-scientist-formulated was because of MBR issues and my old way of imaging. Newer OSes (Win08, Vista) didn't like my previous imaging way. Add newer AHCI controllers to the mix, and I'm dead in the water on newer machines now. Hence, my foray into handling it this way. :)

thanks for the pointers!
Mike.

Quote:

---

Originally Posted by Coyttl

2. Write the new partition table - sfdisk /dev/sda < table.txt
3. (Resync the table?)

---

Not if sfdisk is at least halfway intelligent. (Though I don't know whether it is.) If it's at least halfway intelligent, then it will send the proper ioctl to /dev/sda for you, so that the kernel re-reads the (new) partition table off the disk. The only way this should ever fail is if any other partitions on the disk are currently mounted.

The partprobe program does send this same ioctl -- but if sfdisk is doing it for you, you don't need partprobe. ;)

Quote:

---

Originally Posted by bwkaz

Not if sfdisk is at least halfway intelligent. (Though I don't know whether it is.) If it's at least halfway intelligent, then it will send the proper ioctl to /dev/sda for you, so that the kernel re-reads the (new) partition table off the disk. The only way this should ever fail is if any other partitions on the disk are currently mounted.

The partprobe program does send this same ioctl -- but if sfdisk is doing it for you, you don't need partprobe. ;)

---

Thanks for that. I'll test it later today and see what happens. I have more than a few systems I can (potentially) destroy. :)

I'll post what I find (for anyone else's reference..)

Very useful topic - so far! I've succesfully migrated my XP installation from an 80GB IDE to a 250 GB SATA. Due to errors on the disk I did have to use ddrescue rather than dd but I got there eventually and it all boots up just fine.

However, resizing the cloned partition has not been so easy. the new disk shows up as having one NTFS partition of 80GB and the rest as Unallocated space. I've tried using Gparted and the Parted Magic Live CD but nothing seems to allow me to expand the existing partition to take advantage of the additional space on the new drive. I am allowed to set up the new partition size but when I "apply" the operation I get a rather unhelpful message telling me that the operation couldn't be performed.

From the description of the migration process detailed at the start of the thread there is no indication that this operation should present any problems but all my attempts to accomplish it have met with failure.
Am I missing something obvious?

TarsTarkas,

Welcome to Justlinux!

Xp from a 80Gb disk source to a 250Hb disk should be plain sailing. The expansion of 80Gb to 250 should take about a minute or two as only the right hand side boundary is changed and the filing system can remain unmoved. I believe the operation only adjusts the end point of the hard disk and generates the indexing system for the NTFS filing system between 80 and 250Gb space.

I would suggest you defrag the Xp partition first, use Gaprted or Parted Magic to drag the right boundary from 80Gb to 250Gb and give the green light to go ahead.

If you still have a problem post the disk management details here (i.e. telling us how manay partitions and where they are primary or logical.)

The resizing may not work with encrypted filing system though.

Hi Saikee!

Many thanks for swift response. I've subsequently defragged my disk (three times to make sure there are no red bits left) and retried Parted Magic but I still get the same error. Here's the details:

GParted 0.4.1

Libparted 1.8.8
Grow /dev/sda1 from 76.68 GiB to 116.45 GiB 00:00:00 ( ERROR )

calibrate /dev/sda1 00:00:00 ( SUCCESS )

path: /dev/sda1
start: 63
end: 160810649
size: 160810587 (76.68 GiB)
calculate new size and position of /dev/sda1 00:00:00 ( SUCCESS )

requested start: 63
requested end: 244204064
requested size: 244204002 (116.45 GiB)
new start: 63
new end: 244204064
new size: 244204002 (116.45 GiB)
check file system on /dev/sda1 for errors and (if possible) fix them 00:00:00 ( ERROR )

ntfsresize -P -i -f -v /dev/sda1

ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 82335019520 bytes (82336 MB)
Current device size: 82335020544 bytes (82336 MB)
Checking for bad sectors ...
Bad cluster: 0x50829 - 0x50829 (1)
Bad cluster: 0xdd0f92 - 0xdd0f92 (1)
ERROR: This software has detected that the disk has at least 2 bad sectors.
************************************************** **************************
* WARNING: The disk has bad sector. This means physical damage on the disk *
* surface caused by deterioration, manufacturing faults or other reason. *
* The reliability of the disk may stay stable or degrade fast. We suggest *
* making a full backup urgently by running 'ntfsclone --rescue ...' then *
* run 'chkdsk /f /r' on Windows and rebooot it TWICE! Then you can resize *
* NTFS safely by additionally using the --bad-sectors option of ntfsresize.*
************************************************** **************************

========================================

I followed the advice and ran "chkdsk /f /r", rebooted twice then reattempted to resize the partition but the bad-sectors are still reported. The information above asks me to run ntfsresize to resize the file system but I'm unsure how I can do this without first increasing the size of the partition ...

... or are they the same thing?

If you have bad sectors in the hard disk then these can be corrupted patches which are not readable or writable. This is a hardware problem and can only be the case if you are using a used 250Gb hard disk.

A brand new disk should not have bad sectors. I certainly have not run into one of such disks myself.

Quote:

---

Originally Posted by saikee

If you have bad sectors in the hard disk then these can be corrupted patches which are not readable or writable. This is a hardware problem and can only be the case if you are using a used 250Gb hard disk.

---

That's a little disturbing since the 250Gb drive was purchased from PC World a month ago (today) with no indication that it was either second hand or refurbished. I bought it to replace the 80Gb drive which did have bad sectors and was generally getting a bit creaky.

Now if you'll pardon my ignorance as to how dd and dd_rescue actually work, but if either command is just making a "dumb" copy of the original drive is it possible the bad sectors have been copied "intact" from the original drive. I believe that bad sectors are marked as "no-go" areas and I'm guessing that the cloning process simply copied over the marker flags. If this is case would you know how to "unmark" them.

Failing that, it'll have to be a trip back to PC World. What a pain! Glad I held on to my receipt.

Many thanks for all your help, however it turns out. 'Tis much appreciated!

dd has an option to proceed after encountering an error. My guess is dd_rescue may do a bit more.

If you copy from a source with bad sectors the defective areas cannot be read and it would not be copied but just left blank on the target disk. The blank area should have no problem to be read and written. Only when the file is being used then the missing information would be shown up.

Technically the bad sectors cannot be transferred and that is certainly my experience when cloning dying disks.

If the disk is bad the defective areas will be reported by any cloning software. You can try one from Windoze like Ghost or Acronis. dd just copies the binary pattern of "1" and "0". It is a pretty basic operation. The good thing about it is the resident operating system is not used and its type, health and defects are immaterial to the cloning operation.

The dd method is solid and simple and resolved my first question of whether or not I could migrate my system as is to a larger hard drive; two quhow to migrate linux system to a new driveestions still:

1. I have been reading about increasing speed and optimizing ubuntu for laptops and wanted to change the default ext3 file system to xfs or or another faster file system. Is this possible to do before or after the dd process?

2. Is it possible to use this method to create a bootable sd card of a current ubuntu setup? how to migrate linux system to a new drive