Its not Windows, no need to treat it like it.

Really all you needed to do to switch disks was to:

1. boot any linux distro's livecd with all 3 disks installed. (must be 
an x64 cd if your previous install was x64 though)
2. create your raid set (MD? or dm? whatever)
3. make a matching filesystem on your raid set for each filesystem on 
your old disk (sizes do not have to match).
4. mount each partition, and cp -a /mnt/oldpartition/* /mnt/newpartition
5.  mount /proc and /dev to their relative new location in the new root
6. chroot into your new root partition.
7. edit fstab and grub lines to reflect new partition names or GUIDs. 
don't forget swap also
8. reinstall grub/lilo to new raid disks via grub install, dpkg 
reconfigure grub, whatever you want.
9. exit chroot, Shutdown, remove old disk, and fire it up. Machine 
should be the same exact machine, just on different HDDs.

I'm sure I'm missing a step or two but that's the gist of it.

Based on your post you seem to have the technical skill for it, just not 
the knowledge of the boot/grub/kernel/filesystem to think of how to make 
it work.

Although IMHO the better way to upgrade is to do basically what you did. 
Get a list of what programs you want to reinstall, and then "cp -a" your 
user home dir from the old setup to the new setup. Then just "chown 
youruser: HOMEDIRNAME -R" to get the UID/GID correct.

On 10/5/2011 5:48 PM, Mike Miller wrote:
> I was running Ubuntu 10.10, but then I replaced a bunch of hardware, 
> including upgrading a single hard drive to a RAID1 array of two 
> drives, so I needed to install Ubuntu on the new system, but I wanted 
> it to be like the old system.
>
> First I tried copying the old files onto the new ones using rsync, but 
> that failed badly.  I think the first obvious problem was that the new 
> /boot and grub were not compatible with the kernel from the old setup. 
> Well, no matter what it was, that went so badly that I repeated the 
> install from scratch (very easy after having done it successfully the 
> night before after about 20 failures).
>
> Next I tried something that worked a lot better.  I mounted my old HDD 
> as /c like so:
>
> sudo mkdir /c
> sudo mount -t ext3 /dev/sdc1 /c
>
> It was an ext3 partition.  Other people trying to do this would have 
> to look for their old drive partition to make sure they have the right 
> one.
>
> Then I went to my old home directory and moved all the "hidden" files 
> and directories (filenames beginning with ".") to their own directory 
> (pretend my username was "user"):
>
> cd /c/home/user
> sudo mkdir dotfiles
> sudo mv .[A-Za-z]* dotfiles
>
> That worked for me.  You might not need sudo -- it depends on 
> permissions. You have to watch for changes in UID/GID between 
> installations and fix them appropriately (e.g., compare /etc/passwd 
> with /c/etc/passwd).
>
> Then I used rsync to copy my old home directory to my new one:
>
> sudo rsync -a /c/home/user /home
>
> I have the same username on both systems, but if they had been 
> different, I would have done this:
>
> sudo rsync -a /c/home/user_old/ /home/user_new
>
> Note the slash after "user_old" -- it is necessary.  The rsync copy 
> skipped ~/.gvfs because of permissions, but that wasn't a problem.  It 
> worked well.  Next I could move certain files from "dotfiles" to ~ and 
> try to recover old settings appropriately (e.g., for browsers).
>
> Before I did much playing with config files in $HOME, I installed a 
> bunch of the old programs I was missing.  To figure out which ones I 
> had installed before but did not have in the new system, I did this 
> (one liner):
>
> grep -h ^Package: /c/var/lib/dpkg/status /var/lib/dpkg/status 
> /var/lib/dpkg/status | cut -c10- | sort | uniq -c | awk '$1==1 {print 
> $2}' | less
>
> I think that's a pretty cool way to go.  I first opened synaptic...
>
> sudo synaptic
>
> ...and while skimming the output the long command in "less", I would 
> see what I was missing and I would go to synaptic and find it.  It 
> worked out quite well and it only took me a few minutes to find 
> everything I wanted. One could do the same kind of thing using the 
> dpkg status file from another computer.  On that other computer (let's 
> call it compA), just do this:
>
> grep -h ^Package: /var/lib/dpkg/status > compA_status_list.txt
>
> Copy that output file (compA_status_list.txt) to another machine and 
> do this:
>
> grep -h ^Package: /var/lib/dpkg/status /var/lib/dpkg/status 
> compA_status_list.txt | cut -c10- | sort | uniq -c | awk '$1==1 {print 
> $2}' | less
>
> To get a list of packages installed on the local machine but not on 
> compA, you would use $1==2 instead of $1==1 in the awk command.  To 
> see a list of packages installed on both machines, you would use $1==3 
> instead of $1==1 in the awk command.
>
> Mike
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list