1

I'm copying an Ubuntu Server install from an x86 machine with a single hard disk to a new machine with x64 and two identical disks. Two partitions will span the new disks: One small-ish RAID1 for the OS and my critical data, and one large RAID0 partition, mounted from /home/media, that will hold all my movies and music.

I'd also like to upgrade from Hardy to Lucid if it's not a total pain-- I've got quite a lot of software/daemons configured and running on the old machine which I'd rather not have to re-create by hand.

I've found this helpful post on copying linux installs, and a few articles on setting up RAID with mdadm. I am less clear, though, about how these processes might interfere with each other. Also, the installation post warns about copying from x86 to x64, but wasn't very specific about why.

So my questions are:

  • What extra concerns are there for copying to x64?
  • In what order should I partition the drives, install the OS, set up the raid, and copy the data? Does it matter much? Since some of these are time-consuming steps, I thought I'd get some advice before I start.
  • How should booting from the RAID disks work? (I've heard Grub may have issues?)
Community
  • 1
trbabb
  • 153
  • I'm not clear if you want to convert from a 32 bit to a 64 bit installation, or you just want to copy a 32 bit install to a 64 bit machine, and will still be running 32 bit. In the latter case, the 64 bitness really isn't relevant to anything. – Faheem Mitha Oct 05 '11 at 16:26

2 Answers2

1

You don't "copy to x64". You want to copy the system from one machine that is x86 only to a new one that also supports 64bit mode. If you aren't using that support, then it may as well not be there; put it out of your mind.

To copy the system to the new machine, there is no need to waste time installing a new OS on the new machine first, just to overwrite it with the old one. Simply partition the drives, create the raid array, format the fs, mount it, mount the old disk, and copy all files over ( cp -ax ). Once all of the files have been transferred, you just need to update /etc/fstab to point to the new filesystem UUID ( see blkid ), and reinstall grub.

psusi
  • 17,303
1

I actually did something similar at the beginning of 2011. My hardware raid card died (RAID 10), so I took one of the two disks, and converted to software raid. It was a bit tricky but doable. I'm using Debian squeeze.

0) I'm not clear if you want to convert from a 32 bit to a 64 bit installation, or you just want to copy a 32 bit install to a 64 bit machine, and will still be running 32 bit. In the latter case, the 64 bitness really isn't relevant to anything. If the former, the system at least is incompatible. You'll just be able to copy your data (/home etc) and have to do a system reinstall.

1) I'd recommend using LVM on top of software raid.

2) Grub 2 can boot from a LVM device on top of a software raid device. GRUB 1 can't. Actually, I think it probably can't boot from a software raid device at all. I had some issues with Grub 2 working smoothly with SW raid + LVM, and had to upgrade to the bleeding edge GRUB 2 package in experimental, but hopefully GRUB 2 is more stable now. As long as you stick to recent versions of GRUB 2 you will probably be Ok.

3) First create the sw raid device, then LVM devices on top of that. Then copy your filesystems onto the LVM devices. I recommend using partimage for this.

4) For booting I used another system to mount the new system as chroot, and then chrooted into the new system to install GRUB 2. That will probably work for you too. Note that

grub-install /dev/md0

should work in the chroot, though for this to work, you'll have to rebind the devices in the host to the chroot. You'll also want to rebind the usual things like /proc, /sys, /dev/pts etc.

Feel free to ask questions (if you have them) in the comments, and if I have anything useful to add, I'll update this answer.

EDIT: Update in response to questions from @trbabb.

Could you talk a little bit more about the advantages of LVM? I'll want to keep my two raid arrays separate, so it seems like each array will get a volume group with 1 logical volume each. That seems like an unnecessary extra layer of abstraction...?

LVM is useful if you later want to resize your volumes or add a second physical device to the volume. I think traditional devices aren't quite that convenient to work with.

Also, can you tell me a little bit more about chrooting? What will I use chroot for, > and why?

The chroot is for you to be able to install grub and generate the config file for your new system. You need to install grub somehow, and you need to do it before you can boot. If you are (re)installing the OS, and only copying user data over to /home or whatever, you can use the Debian installer for example, but if you don't want to (re)install the OS, the Debian installer probably won't work for you. It insists on installing a system. There might be other ways of doing this, but chroot is quite standard I think.

And will partimage be necessary if I have the old/new drives connected simultaneously?

partimage is a nice clean, way to copy partitions, regardless of whether you have both partitions connected simultaneously. You don't need to use it. You can use dd or even cp -a but IMO partimage is better.

Faheem Mitha
  • 35,108
  • This is helpful.
    • Could you talk a little bit more about the advantages of LVM? I'll want to keep my two raid arrays separate, so it seems like each array will get a volume group with 1 logical volume each. That seems like an unnecessary extra layer of abstraction...?

    Also, can you tell me a little bit more about chrooting? What will I use chroot for, and why? And will partimage be necessary if I have the old/new drives connected simultaneously?

     – trbabb Oct 08 '11 at 22:55
  • Thanks again. Luckily I was able to figure out some of those answers since I posted.

    I did end up using an Ubuntu liveCD for its partitioning/raid/lvm setup tools (whoops), and just as you say it forced an install. I mounted from the livecd and rm -rf'd its attempted install, then cp'd everything over from the old disk. That seemed to work. (The install was botched; it failed to install grub).

    I'm stuck now because when I boot from my old system, the new /dev/md*'s aren't visible. I am contemplating starting over completely and using cmd line tools while mounted from the old system. Sigh.

     – trbabb Oct 10 '11 at 04:21
  • @trbabb: If you removed the attempted install, and copied everything over from the old disk, then grub would not be configured correctly. As I already said, you need to either do a complete new install, or install and configure grub from a chroot. – Faheem Mitha Oct 13 '11 at 10:29
  • Grub failed before I even did the copying; I'm not sure what went wrong there. At any rate, the problem with my raid array turned out to be that the homehost was set incorrectly. Manually re-assembling with a homehost update did the trick. Once that was fixed I was able to mount the new system, chroot, and install grub. Everything is working now.

    Thanks again for your help!

     – trbabb Oct 13 '11 at 17:36