Migrating to a new (larger) HD

I run fdisk and mkfs on the new drive first, from the running system. Then I reboot using my Debian install CD, in rescue mode. I go to a shell, make sure both drives are mounted somewhere. I cd to the location of the old hard drive. I run "cp -ax . ". Then I exit the shell, and go to the menu option in the rescue CD to install grub on the new drive. Shut down, unplug the old drive, and reboot into your new system.

That's what I've done, anyway.

-- Kevin

It would be best to do a clean install on the new drive.

But dd makes a bit-for-bit image copy of a drive, and if you make an img of your old drive and dd it to the new drive, you will only have the space available of the old drive. An image copy is a mirror-image of the old disk.

Can't use cp as that will change all ownership to whoever is doing the copy, it won't copy other users' private files, and it won't handle symlinks properly.

So the answer is, you can not migrate your old data to the new drive.
(j/k)

You can use a backup app, but I don't trust any of them; maybe I'm old-fashioned. I use tar for this kind of operation. Boot to the new disk or a Live CD and as root
# cd /
# mkdir old
# mkdir new
# mount /dev/sda2 old
# mount /dev/sda1 new
# cd new
# tar --show-omitted-dirs --totals -cjf /new/etc.tar.bz2 /old/etc
... etc
bz2 makes an attempt to do error recovery, in contrast with gz. Then somewhere on the new disk:
# tar -jxpvf etc.tar.bz2

If the OS on the new disk is the same as on the old, on the new disk you can boot to a Live CD and mount the new disk:
# mv /new/etc /new/etc.oem
# tar -jxpvf etc.tar.bz2

If the OS on the new disk is different or newer than on the old you basically have to pick through every old and new fiile and update by hand to make sure it's right.

That is simply not true. When I said doing it from a shell from a bootable CD, you're automatically doing it as root, so you can copy all user's files. The -a flag I specified means "archive", so it copies ownership, permissions, symlinks, etc.

I've done exactly what the OP is asking several times. Using cp works just fine.

-- Kevin

Fair enough Kevin, I didn't know about -a. You'd posted while I was composing my post.

But I still wouldn't trust it with symlinks and nodes.

I've basically done the same thing as quantumstate recommends with some minor variations.

First I make the backup of the original drive (onto an external USB drive so that it's readily available regardless of which OS is booted).

Then I went ahead and did a basic install on the new drive so that I don't have to manually fix up the grub menu file and the fstab file to point at the new disk.

Then I "restore" the backup to the new drive making sure that I don't overwrite the grub stuff and the fstab file.

Also, if your new distro is a flavor of Debian you might want to put /tmp in RAM. You have privacy, and access is much faster. (Best if you have at least 4GB)

Just put this in fstab:
... rename /tmp to /tmp.old and reboot. (right away)

Using dd, as QS accurately stated will limit you to the size of your old drive. However, there is nothing stopping you from changing the partition size after the copy to take up the whole disk, then expanding the file system to fill it. This shouldn't be an issue if your data partition is the last partition. However, your situation will dictate whether or not this is the fastest/best method.

You are making it way to complicated, I have done this many times (even works with Windows on the hdd) using 'dd' quickly, with minimal hassle and no re-installations.

Just connect both drives to the PC (even via usb if you don't have spare internal connectors, it doesn't matter were it's connected as long as it's visible from Linux),
boot off a CD or memory stick (anything but the disk you want to copy from), then do:

dd if=/dev/sdX of=/dev/sdY

where sdX is the old disk (note that it needs to be the whole disk device, not the partition device, for example sda not sda1 !) and sdY is the device of the new disk. Make sure you get the devices right, otherwise you might overwrite something you didn't intend to.

Then replace the old disk with the new one and you should be able to boot off it like before with the old disk, no need to reconfigure/reinstall anything.

If you then want to make use of the additional space, you can either create new partitions or resize the existing ones.

Well, it surely has taken you longer (and with more manual tasks) than with 'dd', also with 'dd' you can be 100% sure that you have an identical copy on the new disk, but I didn't say 'dd' is the only method, rather that IMHO it's the simplest and fasted reliable method.

Trust me, I have used the 'dd' method many times without ever experiencing problems, as I said it even works great with Windows disks!


Why should the drive type/device-name change?
As long as in the end (after the 'dd' copy) you connect the new drive on the same SATA/IDE connector where the old drive was connected, nothing will change.

Also you shouldn't be using device names in menu.lst or in fstab, you should be using UUID (as most/all modern Linux distros do by default)!

I'm not sure I understand your question.
UUIDs are unique IDs for each partition stored in the header of the filesystem on each partition, therefore even if device names change, the Linux kernel will still be able to find the correct partitions, even if they have been moved onto different disks/connectors.

Now if you refer to the hd(x,y) entries in grub, those might need editing if you move the disk onto a different connector, but that's not a major issue, you can even do it on the fly when at the grub menu by pressing 'e' twice and entering the grub edit function.
Even if for some odd reason you can't even get to the grub menu at boot from the new disk, you can boot from a CD and edit those entries from there.

UUIDs are used by the Linux kernel once grub has launched the kernel, hd(x,y) devices are used by grub itself to locate the kernel.

It sounds to me like you got it working, so it should be 'stable' too.

Experimenting is all part of the fun and next time you likely will get it done quicker based on the experience you gained this time, so it wasn't wasted time.

Oh man you guys like to live dangerously. The OS is the very foundation of your system, and you should never take shortcuts if you want a good experience.

I've noticed that even root gets copy failures for permissions in Ubongo. Too weird for me.


When you install the OS new, its parts will have different UUIDs. There is a way to determine what UUIDs to use, but we don't use them in Debian and I don't remember. To me UUIDs are a useless abstraction that dissociates you from the hardware and makes life difficult.

UUIDs are actually VERY useful and make life a lot EASIER as explained previously and that's why they are being used by many distros by default.
I can only understand your comment if you refer to human readability but that can be easily solved with comments, as for example Mandriva Linux does as standard, see here an extract from my fstab as an example:

The command 'blkid' can be used to list all /dev/sdX to UUID associations.

I agree that UUIDs may not be that useful for a system with a single IDE/SATA hard drive. I find UUIDs extremely useful for the following setups:

1. My Linksys NSLU2 running Debian. Drives are connected via USB, so the drive order/name tends to change fairly often. UUIDs keep everything working/mounted properly.

2. I have several software raid devices on my server. They aren't always assembled in the same order, leading to the name changing. Once again, UUIDs to the rescue.

zim, maybe I'm overly cautious, but I never do a wholesale overwrite of system directories, even with tar. If I'm replacing the same release I'll overwrite certain system files, although the transition can take two days. That's fine with me, as I need it to work. If I'm transitioning to a different release I examine each etc file in comparison to the old, and hand-make only my settings in the new file. These practices are borne out of hard experience.

tux, to me human readability is important, and human fixability is even more important. The machine isn't going to fix itself, and I am not going to memorize a string of arbitrary symbols for quick reference when their purpose is so minor. True, I keep my hardware pretty simple; maybe I'd think differently if *nix was my job.


Now see; to me this is a strong indication that the UUID devs do not have any common sense. Why didn't they name this lsuuid, as God intended? And there's no need for the UUIDs themselves to be so obfuscated; they could be a letter grouping, starting with x:x:x for simpler configs and building to xxx:xxx:xxx, like a Canadian zip code. But the devs don't seem to have any common sense. This is why I object to UUID; it's a Micro$oftization, for no good reason.