Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Linux Software

Moving a Linux Install to a Different Drive 16

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.
This discussion has been archived. No new comments can be posted.

Moving a Linux Install to a Different Drive

Comments Filter:
  • 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 [slashdot.org] 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.
  • 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.
  • 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 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?
  • 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.
  • 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 [unc.edu] 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.

  • 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).

  • 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
  • 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 [home.sol.no], 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 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.
  • 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. =)

  • 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

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Working...