Moving a Linux Install to a Different Drive

Pilchie asks: "I recently bought a new hard drive for my box at home that is much larger and faster than my old one. For those reasons, I would like to have Linux installed on it instead of leaving it on my old disk. The problem is that I have spent a lot of time and effort tweaking my box, and I don't want to go through it again. So far, all I have tried is using: "dd if=/dev/hdc1 of=/dev/hda1 bs=2048k" While this seems to work (can boot and everthing), once it has booted if I run df, it reports the size as the same as the original partition, even though fdisk reports the size correctly. Anyone have any ideas?" For file moving, I've always preferred the tar approach, but moving the files isn't the only thing you have to worry about: there are some system configurations you will HAVE to changem, /etc/lilo.conf being the one particular one that stands out in my mind. I'm sure there are others.

Comments

cp -a you putz

[Anonymous Coward]

cp -a you putz

Easisest Way

[Anonymous Coward]

put the new hd and format it and partition it how you want when the system is running. Put in a boot cd or boot disk and get into a shell and mount each disk as /mnt and /mnt2 or however you want the partitions set up. Just type cp -a /mnt/* /mnt2/ and then do lilo -r /mnt2 and then it should work. The only problem i have is once in a while lilo just boots up 1/2 way and says LI so i just boot up again on the cd and run it again and it seems to work.

I don't know what these guys are smokin'

[Anonymous Coward]

I prefer :
cd /
find . |cpio -p dest
tar doesn't do it all for you.
cp -a is LAME
---
Just call me:
Sir Spank-o-tron

I did this on a critical system

[Anonymous Coward]

I used this tactic on a critical system here in Brazil. It worked almost perfectly, and actually I had got to tweak some minor details. Anyway, it worked, and the new disk was bigger than the old one. Maybe it's time for us to think about a better way to do this, it's too manual. Working with AIX, I love the concept of an image backup, where you back up the entire structure of the rootvg... oh, wait, there's no rootvg on linux yet, the journaled filesystems (LVM and XFS) are still in development. It doesn't matters, the concept fits. It would be nice to have a program suited for this. I mean, the means to restore an image backup in AIX are: just boot the tape where you saved the image backup and it restores the machine for you. We could adapt this for linux: maybe the image backup utility creates a bootdisk with a restoration program, which would recognize the respective image devices and get them from, say, a tape, burned CD or file on HD (whether it's ext2fs or FAT) and restore it to the desired format (if it's a journaled / X file system, it would have to apply the concepts of volume groups already). Anyone willing to / interested in coding this? Maybe it would be a good programming exercise, and could be integrated into linuxconf. How's that for a new free software project idea? Patola

filesystem ne partition

[William Aoki]

Both df and fdisk are reporting sizes correctly; they're just reporting sizes of diffirent things. df is reporting the filesystem's size, while fdisk is reporting the partition's size. Your dd command simply copied the contents (the filesystem) of the old partition into the new one, but dd can't update filesystem accounting information to resize a filesystem.

There was a free nondestructive filesystem/partition resizer that understood e2fs announced 1-2 weeks ago (I think this is it, or you could go buy PartitionMagic (which I belive handles e2fs). Either way, you'll want to make the new partition the *same* size as the existing one, use dd to copy the filesystem, and *then* run the filesystem/partition resizer. Alternately, you could probably do what you've already done (dd a filesystem into a bigger partition) and use debugfs to size the filesystem by hand, but that's deeply magical and requires an understanding of the filesystem beyond what I have to offer.

You could also just make a new filesystem in the new partition and use 'cp -a' to copy files over, although it won't preserve ext2 attributes (lsattr) and you'll need to run lilo again on the new disk to make it bootable.

Copying Linux filesystem from one drive to another

[kwalker]

What I did when I installed a new drive was basically the following:

0) Boot into Linux single mode (LILO: linux single). That will keep all your normal stuff from booting and create less potential conflicts.

1) Setup the partitions as you want them. Personally, I run a four-partition machine, and I recommend it to everyone I install Linux for. First partiton is about 200mb for the root directory. Second is a 24-128mb partition for swap space. Third is 350-1024mb for the /home directory. Fourth is whatever is left for the /usr directory; I recommend at least 1gb for a serious /usr partition.

(Why a multi-partiton system? Well, you can backup your important dirs (mainly /etc) to your /home directory (/home/etc) so you can format / and /usr, re-install, then restore them if any of your RedHat/SuSE/Caldara/Debian upgrades to south. Had to do that a couple of times.)

2) Format the new partition(s).

3) make a new directory called /new and mount your new partition(s) under that (/new/root, /new/home, /new/usr, etc.).

4) Use tar and a little black magic to copy your whole filesystem in one easy step:

(cwd: /)
tar -cf - (all dirs except /new and /proc) | (cd /new ; tar -xvf - )

(ex: tar -cf - bin/ boot/ dev/ etc/ home/ lib/ lost+found/ mnt/ opt/ root/ sbin/ tmp/ usr/ var/ | (cd /new ; tar -xvf - ) )

You'll see all the files on your drive go zipping by (You can bypass this by omitting the v on the second tar). That's it copying all your files.

5) make the /proc dir ("mkdir /new/proc").

6) Make any changes necessary to your /etc/fstab.

7) make a temporary boot disk ("dd if=/boot/vmlinuz of=/dev/fd0 bs=1024").

8) Shutdown the box normally and swap drives.

9) Boot using the temporary boot disk.

10) Login as root and run LILO ("/sbin/lilo").

11) Remove the bootdisk and reboot. Everything should work right.

GET OUT OF MY HEAD!

[Rendus]

Heh... I was asking myself this very question not more than 48 hours ago, but I'm moving Linux to a -smaller- disk (400mb drive on the server, 100mb of it being used. Got a 200 sitting here).

What I'll end up doing is either taring all the files, or cping them. Directions of how to do either are above (And this article is now bookmarked :)

there is a HOWTO for this

[josepha48]

There is a HOWTO out there that tells how to upgrade to a bigger hard disk drive, he should have read that at LDP. Why is it stuff like this makes it to 'ask slashdot' rather than things that are not documented?

Dual Boot Linux

[Royster]

Others have given the cp -a and tar solutions to copying your files. When I have done this, I created a new entry in /etc/lilo.conf with the label 'new' and made sure I could boot into the new partition before giving up the old partition. After I got it to work, I put a label 'old' in the new /etc/lilo.conf (where the default boot label was new) and kept the old one around for a week to make sure there weren't any issues.

Read the How-Tos

[Biolo]

I've got to do exactly the same thing to a Server I run for my old University Union in a few weeks time. I found that the Linux Documentation Project has a mini-howto that, at first glance, appears to cover all the steps required. Has anyone actually followed this?

You will find the file in HOWTO/mini/Hard-Disk-Upgrade.html. Remember to use the mirrors folks, hence no direct link.

Different slant on the question

[Biolo]

Taking the original question and twisting it a bit..

What if you want to move across just the /home and user accounts to a fresh install on a new hard-disk? Obviously you copy /etc/passwd, but what else? (Yeah, I've checked the how-to's first).

HOWTO

[Shabazz]

I did the exact same thing a few weeks ago.
I just used "cp -ax / /newdisk"
It worked fine. For more info check out the
HOWTO: http://metalab.unc.edu/LDP/HOWTO/mini/Hard-Disk-Up grade.html

cp -a etc

[zmooc]

I see most ppl say "cp -a". I usually do it that way too, but you'd better not do that when the system is up and running since a running system keeps changing files (logfiles etc). In my opinion the best way to deal with this is to boot the system from a bootdisk (I use hal91, which is a Linux-distro on 1 floppy), then mount all the old partitions under /mnt/hda? and the new ones under /mnt/hdb?. Then I copy them with "cp -a /mnt/hda1/* /mnt/hdb1" etc. Then I run mkswap, unmount all the partitions and reboot the system with a bootdisk. Then I rerun LILO (don't leave CHS-settings for your old disk in the append-line!). So my two tips: (1) Use a bootdisk like hal91 and (2) Use cp -a (-a is for archive)

I've done this

[jfunk]

I had no trouble. I just mke2fs'ed the new partition, copied everything over, and ran LILO on it.

To run LILO on it edit lilo.conf on the running filesystem to install on /dev/hdc, and pointing to /dev/hda[whatever]. This will install LILO on the new HD pointing to partitions on it's own disk drive (which will be /dev/hda*). Then shutdown and physically swap the drives.

It should work. If not use a LILO disk (I like Slackare's no-BS boot disk: "mount root=/dev/hda1"). After it has successfully booted, update the /etc/lilo.conf to install on /dev/hda, for the next time you "make [b]zlilo" your kernel. If you had to use a LILO disk to boot, run lilo after you have made sure your lilo.conf is correct.

How about dump/restore?

[David_W]

I've never actually done this under Linux, but whenever I wanted to move the contents of drives on other Unixes, I always ran dump and restore. Create a new fs on the new drive, mount it on /new, then try something like:

dump -0 -f - / | (cd /new && restore -rf -)

(You may want to refer to the man pages to make sure the switches are correct -- it's been a while since I've done this. The idea is to dump to stdout and restore from stdin.)

BTW, using dd to copy filesystems is a BAD idea -- the fact your FS is the same size as the old one is evidence of that. There are some things dd just shouldn't be used for. =)

mini-HOWTO on this very subject!

[mahonri]

I was in this same position recently and found the Hard Disk Upgrade Mini How-To very helpful. In fact, it went without a hitch. It can be found at http://metalab.unc.edu/LDP/ HOWTO/mini/Hard-Disk-Upgrade.html