• Migrating to or from virtual hardware (VirtualBox, VMware etc)
• Duplicating an installation across multiple new servers
• Using temporary hardware to set up a new OS for a server to minimise downtime
• Plain old hardware failure
• etc.

Under many other Operating Systems, especially Windows, this can be painful and perhaps not even worth doing. As usual it is easy with Slackware.

In the simplest case (default install, default kernel, desktop environment) there’s literally nothing you need to do. Just put the disk or image in the new hardware and boot.

If you are using a custom kernel (as you should be) then you will need to create a new kernel and update lilo either before or after you do the migration. If you have any sense of self-preservation, your lilo config will include the default “huge” kernel and so the minimum you need to do is just boot the huge kernel on the new hardware, then you can go about making a new custom kernel later.

The bit that will catch you out:
There is one thing that might make you stumble: you moved the installation, booted up and all is well.. but the network isn’t working. You run `ifconfig -a` and find your two network interfaces are now called eth2 and eth3 and neither is configured.. “What’s going on?”, you ask. The answer is udev.

udev knows that your two new network interfaces are different to your old ones because they have different MAC addresses and decides you might not want to have them configured the same; perhaps you are going to swap in the old cards later and have four, so it reserves the previously used “ethX” labels in case it sees those cards again.

Since you are migrating to new hardware, you want it to forget about your previous network interfaces and re-use the labels with your new hardware. Head to /etc/udev/rules.d and find the file called 70-persistent-net.rules. Take a look at it.. it should look something like this:

See how it has an entry for both the old interfaces and the new ones? That’s what’s meant by persistent net rules. If you moved to a new machine again, it would add the two new interfaces as eth4 and eth5.

You have two choices for fixing the situation:

1. Delete the file. It will be re-created on next boot and start again from eth0.
2. Manually modify the file to reflect the configuration you want.

Note: There is also a 70-persistent-cd.rules file that it’s worth keeping an eye on during hardware migration, but usually it’s only the net rules that actually cause people problems.

On my desk, I have two machines, both with identical Big Ol’ Dell Keyboards. But I have swapped the keys around on the one on the left to make it a Dvorak-UK layout. The box on the right is my main working desktop (Slackware-13.0) and the one on the left is mainly for IRC run out of tty2 although I also use it for live testing when writing code. Because the IRC box is the Dvorak box, all I do is type which gives me a lot of practice.

I got past the hunt-and-peck stage in about 6 weeks, and slowly started getting better from there. I still have trouble with M and W being next to each other, and I often grab the wrong vowel, but other than that I’ve gotten pretty good. Sometimes I get so comfortable I reach over to the QWERTY keyboard and momentarily forget how to type; but that’s only occasionally. I think I do pretty well swapping between the two.

I now have a new skill for my CV and the ability to fend off RSI later in life. I feel I have accomplished something.

Some notes:

• Do not bother trying to find a Dvorak keyboard – people just don’t sell them – rearrange one you have.
• Pick a good keyboard to re-arrange. Try to find one that has no curvature so the keys are all the same dimensions and set at the same angle.
• In a linux console: `loadkeys dvorak` will give you a Dvorak (US) layout instantly.
• In Slackware 13.0, tell hald about your new keyboard as in my earlier post so it works in X.

I urge everyone to spend a little time reading DVZine to rid you of fear, uncertainty and doubt (FUD) about Dvorak. There’s a lot of misinformation out there and DVZine will put you straight.

Have fun.

• Web interface sometimes works, sometimes doesn’t. If it can be arsed to provide the images (because ALL links are image links), it does so at its own discretion and provides no guarantee the right image will be in the right place.
• Switches enjoy failing completely at random intervals prompting a hard-reset.
• Sometimes, when they feel like challenging me, a single port will have a hissy-fit requiring that I reallocate the device plugged into the port, or hard-reset the whole switch.
• Upon reboot, the switch with the VLAN suddenly has a selective memory and forgets to put the VLAN back in place and so the segregated customer network suddenly has full internal network access.
• And, of course, there’s the GBICs, which die on average once every three months or so.

Thanks SO much Allied Telesyn,
No love.

If the HEC PSUs are fine, there is NO excuse for UPGuards to have nearly a 90% failure rate.

Buyer beware!