Re: Moving Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11Mar2008 17:53, Mike <mjwestkamper@xxxxxxxxxx> wrote:
> I need to move a Fedora system from one HDD to another.
>
> Here is the configuration:
>
> I have Fedora as the only OS on a 80GB HDD PATA. It boots and plays nice. I 
> spent a lot of time getting the system to do exactly what I want and it 
> does so very well. My problem is that I need to move it to a larger disk.
>
> I want to move it to a 500GB SATA drive on the same machine. I can solve 
> the BIOS problem of pointing to the right drive.
>
> Any pointers on formatting the SATA drive and moving the whole kit and 
> caboodle to the new drive without trashing weeks of work?
>
> The partition sizes can remain the same.

I would do the following steps (roughly). Make sure you understand them
all and that you agree with them. Or change them to suit your own plans.
But whatever you do, be sure 

  - backup the data you care about

  - note down all the partitions and sizes and drive names on some paper so
    you don't miss anything

  - partition the new drive, with a slightly bigger / and /var
    (simply because you have gobs of room) and a huge /home
    (or my habit, /app with /app/home symlinked to /)

  - make new filesystems on the new partitions; I like xfs in preference
    ext3 (if you change that for /boot - or / if you don't have a
    separate /boot - make sure grub supports xfs)

      mkfs -L /root2 /dev/the-new-drive's-root-partition

    IMPORTANT: give the new filesystems _different_ labels
    from the existing ones

  - mount all the filesystems from the new drive, eg:

      mkdir /mnt/root2
      mount /dev/the-new-drive's-root-partition /mnt/root2

    and so on.

  - copy the system "live":
      for each mounted filesystem from the 80GB drive:
        rsync -aHx / /mnt/root2/
      (and so forth)
      this should get the vast bulk of the data across

      make sure the "mount" command succeeds - it helps protect from
      mistakes, my big fear

  Now the fun part:

    - shut down
    - boot single user off a rescue disc
    - unmount the automatic mounts the rescue disk probably made

    - for each partition on the old drive, mount it and the matching
      partition from the new drive - probably the rescue disc will have
      done this for you - you may want to umount those and mount your
      own pairs to avoid having the automatic mounts hide stuff

      IMPORTANT: mount the old filesystem READ ONLY!
                 this help prtect against accidents
                 _verify_ the output of the "mount" command
                 to be sure you are mounting the right things!
      Then:
        rsync -axH -v /mnt/old-partition/ /mnt/new-partition/
        rsync -axH --delete /mnt/old-partition/ /mnt/new-partition/
      for each pair of filesystems.
      The first is to complete the copy, saying what it does.
      It should be relatively little, since your copies of the "live"
      system should be almost everything. It serves as a sanity check
      for the rsync command line, to prevent damage.
      The second is "for real", making the copies exact. But with the
      --delete, if you had it wrong, you could do a lot of damage.

      Then follow up with:
        rsync -v -axH --delete /mnt/old-partition/ /mnt/new-partition/
      to esnure no changes got missed.
      It should be silent.

      Repeat for each pair.

    - IMPORTANT: on the new /, edit the etc/fstab file to use the new
      filesystem labels instead of the old
      Otherwise nothing much will mount on boot.

    - shut down
    - pull the old drive
    - install the new drive as the boot disc

    - boot single user off a rescue disc and grub the new drive

      This is MUCH easier than grubbing the new drive when it's not the
      boot disc because grub is very messy and historical BIOS design
      (and lots of buggy BIOS implementations) make naming the new
      boot disc an error prone operation when it's not the boot disc.

    - shut down, remove rescue disc, try to boot

Basicly, this approach:
  - avoids using dd to dupe a filesystem from one drive to another,
    which doesn't always mesh with the drive geometries, _and_ requires
    you to play resize games afterwards
  - makes all the new filesystems nice and contiguous and clean

Does all this make sense? Don't do it if it does not!

Cheers,
-- 
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/

Language... has created the word "loneliness" to express the pain of
being alone. And it has created the word "solitude" to express the glory
of being alone. - Paul Johannes Tillich

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux