# Mobo/CPU/RAM transplant: what to watch for?

## ExecutorElassus

I'm about to run through the first step of what I'm hoping will be a relatively simple (my brain interrupts: ha ha! Oh, you poor beautiful deluded child of summer) upgrade to the main hardware components of my desktop. Here's what I'm looking at:

I have a CPU/RAM/Mobo combo that uses the AMD 990FX/SB950 chipset, DDR3-2400 memslots, intel LAN, "SupremeFX III" 8-channel audio (?), and a whole boatload of overclocking and other tweaking options that I do not understand. 

My current board is an at-least-five-year-old MSI board, with even older memory and CPU. 

My question is this:

are there new kernel options that I need to enable before installing the new board? I read that there were issues with AMD's IOMMU, USB3, and some other things. I don't recognize the audio chipset, but it says it uses the Realtek codec. Are there other issues I need to worry about?

Thanks in advance,

EE

----------

## eccerr0r

Typically upgrades will just work as newer CPUs will run everything old ones can, but this depends on what CFLAGs you used to build your system and the old CPU.  Also drivers for any onboard peripherals.  RAM usually does not need driver support.  Without knowing your old system board/cpu it's hard to tell what issues you'll run into.

Hopefully you're already using a 64-bit system before? 

You could treat the kernel build as if you were going to build a new system afresh.   Then use the kernel on your old setup (provided your CFLAGS are OK, but usually they are.)

----------

## ExecutorElassus

from make.conf, I have CFLAGS="-march=athlon64 -O2 -pipe". I also have CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a"

I found that I needed to add support for the Intel NIC, but everything else in 'make menuconfig' seems normal. I'm still not sure about the audio chipset, but since it supports Realtek and I have that enabled, I'm not too worried. Only other thing I can imagine is the NB/SB setup, but I'm fairly sure (?) that those are generally transparent to the OS.

Only thing that has me a bit worried is the line in the manual that "this motherboard supports {a list of only Windows OSs}". Do I need to select "Other OS" somewhere in the BIOS? Also, I should probably disable all those switches on the mobo for "fast boot" (which looks like it will skip POST) and using a default BIOS setup (ie, skipping the part where you hit <DEL> to enter BIOS config). 

The new board is a Crosshair V Formula-Z with a 2013 copyright in the manual, using the AMD 990FX/SB950 chipset as I noted previously. The older mobo is an MSI K9A2 Platinum (AMD 790FX chipset). GPU is an eVGA GTX580. New RAM is from "elixir", but I can't imagine RAM reliability is that bad these days (used to be you bought Kingston/Corsair or steeled yourself for running memtest every six months). 

Weirdly, the new mobo has a PS/2 port for the keyboard. Is that a new thing for gaming rigs?

Thanks for the help,

EE

ADDENDUM: according to the manual, the BIOS has an explicit option to enable IOMMU; it claims that this is a Linux option, so it's probably (??) safe to assume that the BIOS doesn't have any weird firmware that locks it to a Windows OS, right?

----------

## eccerr0r

If it's a PC it should be a PC.

The typical things that may be ran into are ACPI problems (now getting more and more rare with new MB) and UEFI if you weren't using it before.  Hopefully it still has compatibility mode, if you were using that to boot your old MB.

It should boot either way with or without IOMMU but you can have a bit better security with IOMMU enabled.

----------

## ExecutorElassus

(several hours and a ripping backache later)

Sweet googly-moogly, this thing is ridiculous. I'm going to have to take at least a couple weeks to work out all the options in the BIOS (which, crazily, has mouse support and a semi-functioning GUI). What are the pros/cons for IOMMU? 

Whew, that was bonkers. Well, next step is to start migrating / and my config directories (including the stuff on /home) onto the SSDs whose brackets arrive tomorrow. 

Man, upgrades are *awesome*. Thanks for the advice.

Time to down a shot or three of gin and watch a terrible movie!

<3

EE

----------

## ExecutorElassus

Update: but now I'm back to my original question, for the last stage: I have three new SSDs, 250GB each. Currently, /boot and / are mirrored across three HDDs, and the rest of the directories (including some system partitions like /var, /usr, /home, etc.) are in an LVM as part of a RAID5 (misprint in the previous post, it's not RAID6) array across the HDDs totaling a couple TB (mostly media storage).

I want to reconfigure this so that all the basic system directories, as well as the parts of /home that house configs, and the one storage partition inside /home that I use for games, are all on the SSDs.

Firstly, what is the best way to arrange the drives? All three SSDs mirrored? Only two of them mirrored and the last left as single? 

Secondly, how do I migrate the data while preserving its integrity onto the new drives?

Cheers,

EE

----------

## ct85711

Well, the way I did it when I migrated all my data from 1 drive to another; was simply just using cp.  Sadly, I don't remember all the flags I used when I migrated the data, but I do remember I preserved ownership and preserved symbolic links, otherwise I excluded like /proc and /dev since both on my system are populated during run time.  I did maintain the old drive for a week or 2 before I wiped the original drive to make sure I didn't screw anything up when I copied everything over (don't forget to update your fstab, and rebuild your boot partition).  I'm no expert on rsync or cp,  but I went with the tool I felt more comfortable with and went through the man page really well and figure out what all I'd want to make sure was copied over (I knew file ownership and symbolic links were 2 critical items that I needed to preserve when I moved everything from a spinning disk to SSD).

----------

## ExecutorElassus

I found a good solution with this article, suggesting rsync with a bunch of options. I worked well.

However, that was just for the storage of the games directory. I'm still not sure how to migrate the system partitions ('/' on down, of which many filesystems are on separate lvm partitions), nor how best to set up the remaining two SSDs to contain them. 

RAID1? Put it on an LVM? How, then, to copy over the various parts of the root file tree, leaving stuff created by the filesystem (/dev and /proc, for example), so that I can simply change the UUID in grub and /etc/fstab when I'm done and have a seamless switchover?

Thanks for the help! One drive is already copied; just one last step!

EE

----------

## Hu

Although tedious, the safe thing to do would be to copy each filesystem separately.  You can use bind mounts to accomplish this while the system is up, if you do not mind the potential inconsistency caused by copying a file that a running program might have open and partially updated.

Pick some unused directories, possibly newly created.  Mount your destination filesystem on one.  Bind mount your source filesystem on the other.  The bind mount does not, by default, bring along submounts, so you can use a recursive copy (via rsync, cp, etc.) on the bound source without worrying about traversing into other filesystems.  For example:

```
cd /mnt

mkdir bind-src

mkdir dst

mount /dev/disk/destination-drive dst

mount --bind / bind-src

rsync --preferred-rsync-options-here bind-src dst
```

This will copy the files that are part of the filesystem on /, but will not traverse into the virtual filesystems mounted on /proc, /dev, /sys, and so on, nor will it see or copy from /home (if /home is a separate filesystem from /).

I suggest you try this on small scale with some test data first.

----------

## ExecutorElassus

Ah, thank you: this was a missing piece that I was looking for. Now, excluding the storage partitions I'm not going to copy right now, I have the following mounts on my system:

```
$ mount

/dev/md126 on / type ext3 (rw,noatime,data=ordered)

/dev/mapper/vg-usr on /usr type ext3 (rw,noatime,stripe=256,data=ordered)

/dev/mapper/vg-var on /var type ext3 (rw,noatime,stripe=256,data=ordered)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

tmpfs on /run type tmpfs (rw,nodev,relatime,size=3291000k,mode=755)

dev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=4104549,mode=755)

mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)

cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)

openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc)

cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)

/dev/md1 on /boot type ext2 (rw,noatime,errors=continue)

/dev/mapper/vg-portage on /var/portage/repos type ext2 (rw,noatime,errors=continue,user_xattr,acl)

/dev/mapper/vg-distfiles on /var/portage/distfiles type ext2 (rw,noatime,errors=continue)

/dev/mapper/vg-home on /home type ext3 (rw,noatime,stripe=256,data=ordered)

/dev/mapper/vg-opt on /opt type ext3 (rw,noatime,stripe=256,data=ordered)

/dev/mapper/vg-tmp on /tmp type ext2 (rw,noatime,errors=continue)

/dev/mapper/vg-vartmp on /var/tmp type ext2 (rw,noatime,errors=continue)

rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)

nfsd on /proc/fs/nfsd type nfsd (rw,nosuid,nodev,noexec,relatime)

none on /run/user/0 type tmpfs (rw,relatime,mode=700)

none on /run/user/1000 type tmpfs (rw,relatime,mode=700,uid=1000)

```

Which of those should be copied over in the way you specify (that is, using a bind mount, then rsync)?

Addendum: the old system was a RAID5 array, so a lot of the partitions are volume groups. The new system is two mirrored SSDs, which I am assuming I can partition simply as a small /boot partition and then fill the rest with the / partition, yes?

Thanks for the help,

EE

----------

## Ant P.

You haven't said what your new CPU is, but things will start breaking if it's new enough to lack 3DNow instructions (which you've enabled using -march=athlon64).

----------

## ExecutorElassus

oh dear. What should the CFLAG be? It's an AMD FX-9590 (which is just a factory-overclocked FX-8530, iirc).

Cheers,

EE

EDIT: using the GCC optimization wiki, I see that the march returned is 'bdver2'. Is that a correct march value to put as the CFLAG in make.conf? 

Sigh. I should go through my CFLAGS and re-check them to optimize for this cpu  :Sad: 

----------

## eccerr0r

I was worried about that, so AMD dropped their 3DNow! instructions in favor for SSE (since no Intel CPUs have 3DNow!)?  I would have imagined they would keep adding onto the instruction set for backward compatibility.

----------

## Ant P.

In the old days, 3DNow had its own silicon on the chip. On all their 64-bit models it's just SSE2 with a funny looking ABI. It's been kept around for 10 years for compatibility - plenty of time to move on.

----------

## eccerr0r

One would think Intel should drop MMX too since SSE* is pretty much a superset, yet MMX is still there.

----------

## Hu

With regard to mounts, you have two choices.  The first choice is to sync each filesystem individually.  The second choice is to sync all the real filesystems (excluding dev, proc, sys, any NFS, etc.) at once.  If you go with the first choice, you need the sync source not to have any mountpoints under it, which may mean using bind mounts.  You can still avoid bind mounts for any filesystem that has nothing mounted below it.  If you go with the second choice, it is sufficient that all mountpoints under it be real filesystems that you intend to copy, which only requires a bind mount if the regular filesystem view mounts a virtual filesystem there.

Regardless of your choice, / will need to be bind mounted since you have /dev, etc. directly under it.  If you choose the composite rsync, then based on the output shown, / and /var (due to rpc_pipefs) need special handling.  Everything else looks like it would be fine.

----------

