Hi! I have a 160GB harddrive which I installed a F12, would like to upgrade to a bigger drive, but I hate to have to re-install everything.

Could someone please recommend a good disk copy utility? The utility should be able to not only copy files, but boot sector and everything. So I just need to make a copy, change my BIOS to boot from the new drive and run everything as before. Thanks!

I think dd would be a bad choice, as it would just duplicate what you have, rather than giving you your installation in a larger system.

For the BSDs dump and restore are the standard, but I don't see them mentioned very often in conjunction with Linux--I vaguely remember reading that with various kernel changes, dump and restore will miss things, but I am not sure about that.

It seems the most popular ways are using gparted, and tar. I don't know the gparted method, but with tar.

Here's a post from the Tokyo Linux group that I keep on hand. DISCLAIMER--haven't done this for over a year, so cannot guarantee it works with all latest and greatest.

Quote:

1) Install both drives into a machine.
2) Boot from a live CD, preferably for the same distribution you are
running.
3) Create 2 directories somewhere, i'll say /mnt/src and /mnt/dest.
4) Mount the source drive on /mnt/src. Look in etc/fstab on the drive
and make sure you mount all partitions in the appropriate places.
5) Partition and format the destination drive the way you want it, and
mount it as /mnt/dest. Run mkswap on a swap partition (if any). If you
are using multiple data partitions, create the mount points and mount
those partitions.
6) Run this to copy the files. There are many other commands that will
do this; this is just the one i use since tar seems to handle device
and other weird files acceptably:
(cd /mnt/src ; tar -cf - .) | (cd /mnt/dest ; tar -xvpf -)
7) If the drives are different enough to use different device names (say
when migrating from ATA to SCSI), edit etc/fstab and possibly whatever
config file your boot loader uses.
8) Install a boot loader on the new drive. How to do this will differ
depending on which one you use (most likely either Lilo or Grub).
Usually you'd do something like chroot to /mnt/dest, and then run
whatever command installs the loader, possibly with an argument telling
it what device to put it on (if different from what it will be after
install).

That might sound like a lot of stuff to do, but it really doesn't take
long. Just be careful when partitioning and formatting the destination
drive that you are working on the correct one. In my experience the
easiest place to experience problems is with installing the bootloader.
Sometimes i remove the source drive and put the destination in its
final place and then boot from the live CD again to install the
bootloader. That way device names are usually the same as they will be
when booting from the drive and the process is often smoother.

I would use dd then gparted to expand the partition on the newer bigger disk. If you don't mess with the partition size you'll have a perfectly good working copy in a partition the size of your old disk.

If you're planning to ultimately replace the drive with the newer one you don't have to reinstall fedora.

I'm always inclined to re-install. One reason - you really will have to re-install and some point and if you record the procedure you can get do it quickly in the future.

Still - there are some pluses and minuses to the methods described.

If you dd the entire disk image to the same or larger size disk, then you retain all the old UUIDs (universally unique IDs). So then, unless you remove or clean the old disk, you have the same UUID twice in the system and things can get ugly and confusing. dd just does a block-by-block copy, so it includes the partition table, grub and everything. Yoo will probably have to re-install grub to make the new disk bootable.

Dump/restore are old simple but effective file-copy utilities. One reason why it's not widely used in modern Linux is that our file systems (as opposed to BSD) contain metadata which are not handled by dump/restore. For example tar -Z will store/restore Selinux contexts, --acl will save/restore the ACL metadata. The dump/restore utilities have no ability to do this. The Linux version are reportedly only effective for ext2/ext3 file systems too. So if you really wanted to create a backup story you'd be far better off using tar -Z... than dump restore. Still this is a file-by-file method. You have to partition the new disk (which means brand-new UUIDs), copy all the files from an archive with 'tar' or 'retore' or other and then re-install grub.

In either case you need to repair the new /etc/fstab.
If the drives use a different driver - you may need to use mkinitrd to erbuild the initramfs.

My strong preference would be to create new partitions and do a file-by-file copy with a competent file copy utility. It's a bit more work,

==

Anyway - I don't see any reason to use dump/restore or tar for the file copy - 'cp' works fine and more efficiently.

In smr54's procedure, at step "6" instead of

Quote:

(cd /mnt/src ; tar -cf - .) | (cd /mnt/dest ; tar -xvpf -)

Use (as root)cp -aT /mnt/src /mnt/dest

It's sort of silly to use tar or dump/restore unless you need the intermediate archive or pipe-able stream.

I do plan to get rid of the old drive and replace it with a new larger size one. So duplicated UUID is probably not my main concern. Thank you all who replied, looks like I got myself a big project for Labor Day weekend!

Moving your os to a bigger disk should not be a big project. With a little care and pre-planning, you should be able to do it in an hour or two. If you are uncomfortable and/or unfamiliar with the tools involved, post a step-by-step plan here before you start. I can't speak for anyone else, but I'll probably be watching this forum throughout the weekend.

I did successfully copied the enitre disk. dd is quite useful. I copied all data from my old 160GB disk to a new 1TB disk and then take the old 160GB disk off line. Booting from the new 1TB disk is not a problem. Everything seems to be working fine. Except one thing: The new disk only has a 160GB partition with 800GB+ unused space. That make sense, since dd is just a bit to bit copy, it would not automatically extend the disk.

So now my problem is: How do I extend the new disk using the unpartitioned space? I tried cfdisk, but couldn't get it working. Here is what reported by cfdisk:

There are several ways you could go about extending the partition. I think the easiest, since everything other than "/boot" is in an lvm container, is to create an additional partition ,or partitions, on the un-partitioned space and add each additional partition to the correct lvm group. Once addition space has been added to the lvm group, the partition can be expanded using and disk tool, such as parted or gparted. You should be aware that the file-system in question should be unmounted in order to extend it.

If you want to do anything to the "root" partition, you must have an external boot source. Take a look at:

Although RobinQi seems to already have completed the task, I would like to add the awesomeness of the Clonezilla livecds. You can clone the disk or do an image. If you go the clone route, you can then turn around and use gparted to expand the partitions if need be on the new disk.

Needless to say you have many options to solve this task. I do like dd, but sometimes a predone tool just is the simpler and safer solution