A little HOW-TO on moving a running web server to new hardware. This is not a complete guide but describes my personal experiences. This guide covers the basics of NIC configuration and booting after moving a working server hard drive to new hardware. It does not cover blade or rack mounted remote hard drive configurations.
Generally a hard drive can be simply moved from one machine to another and, assuming you use the same hard drives as before, the basic configuration will work. At least long enough to install a new kernel to take advantage of any new CPU options. However there are instances when the new hardware changes how the kernel sees the devices. A recent frustration illustrates this issue. I moved an ATA drive to new hardware that had a SATA controller with drives attached so the previous /dev/hdx was no longer valid. Needless to say it didn't boot. To correct this issue I edited the entry at boot time (E key when at grub menu) and tried sda1 (“E” again to edit, enter then “B” to boot ) rather than hda1 as the boot device and it booted fine. After editing the menu.lst file it booted fine and life was OK. Then a new kernel was installed and it quit booting. A quick look at menu.lst and I noted that update-grub had reverted to hdax on all boot items. After a little more reading I discovered that grub reads a specific line in the menu.lst file to generate the new menu entries. The line read “Kopt=root=/dev/hda” when it should be /dev/sda. A quick edit of the line (yes it's commented out) and another update-grub and all the entries are correct. Newer versions of either OS use a UUID to identify a particular volume or partition. You can replace all /dev/sdx or /dev/hdx using the UUID for each drive and the boot code will search for the appropriate drive based on it's UUID. To find the UUID of all volumes, issue the command 'blkid', like this:
~ $ blkid
/dev/sda1: UUID="a8131aa0-c532-404f-bcbc-104f42a9b282" TYPE="ext3"
/dev/sda5: TYPE="swap" UUID="7d7702bb-0a4b-4958-a108-eb9178af67d7"
/dev/sda3: UUID="b96f778e-22ae-4154-967d-9526fb6a4b92" TYPE="ext4"
/dev/sdb5: TYPE="swap" UUID="058a00cc-5659-407a-a539-5a0e02fcd975"
/dev/sde1: UUID="CC06F12A06F115E4" LABEL="BACKUP" TYPE="ntfs"
/dev/sde2: UUID="C4CCFAEACCFAD620" LABEL="AUXII" TYPE="ntfs"
/dev/sdb1: UUID="84046f78-d4db-45c8-95dc-8056fd5e8edb" TYPE="ext4"
/dev/sdc1: UUID="F2A0FA63A0FA2DAB" LABEL="Elements" TYPE="ntfs"
The format for /etc/fstab is the same regardless. Just replace the /dev/xxx entry with UUID="uuid of your drive from blkid command"
UUID=a8131aa0-c532-404f-bcbc-104f42a9b282 / ext3 errors=remount-ro,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 1 UUID=7d7702bb-0a4b-4958-a108-eb9178af67d7 none swap sw 0 0 UUID=058a00cc-5659-407a-a539-5a0e02fcd975 none swap sw 0 0
IMPORTANT: I noticed that my Comcast modem would not correctly connect to the new NIC, even if the MAC address is the same, until I rebooted the modem. Therefore I recommend you reboot the modem at the same time you restart or start your new server hardware to be sure the modem sends all the proper upstream data for a successful new connection.
Basically you can remove the
/udev/rules.d/XX-persistent-net-rules, reboot and let the kernel tell
you what it found. Then you can edit the lines in the newly created
perstent-net-rules file to map ethx to the correct interface. If that
fails to work you can add
hwaddress xx:xx:xx:xx:xx <-MAC address
to the top of each NIC entry in your /etc/network/interfaces file to force a NIC to respond as the device under which entry you noted. This option generates an interface "rename" option in the startup scripts somewhere.
Nics are probed at boot time by either the kernel or the udev scripts. On Debian and debian-like systems, udev writes a list of what it finds for NICS in a file named /etc/udev/rules.d/70-persistent-net-rules. I make it a point to move my external NICS with the HD to the new hardware so they work without fiddling (same MAC address) but sometimes that's not possible. If all else fails you can remove the xx-persistent-net-rules and remove all entries from /etc/network/interfaces that point to ethx (leave the loopback intact) and reboot. Udev and other scripts will generate the necessary lines for a DHCP connection. From there it's relatively easy to edit network/interfaces to match the udev rules. This is important because your iptables firewall rules will be interface specific. I've wrestled with this nonsense several times and always managed to get it working by deleting both /udev/rules.d/xx-persistent-net-rules and editing the /etc/network/inrerfaces (after making a copy), then remapping the NICS manually. Thankfully I only have two but some of you may have more NICs installed.
Then it's off the the races...
siggma [at] trbailey.net