The big problem this causes is that any machines with a remote filesystem, such as an NFS share, in their fstab fail to mount the shares at boot; which means I have to manually ssh in and issue a mount command as root.

The solution is to ask rc.inet2 if it would kindly consider waiting just a little longer for the network to come up and not mount remote filesystems if it doesn’t.

The following patch attempts to ping an always-on host, preferably the host that serves the filesystem(s) you are going to mount.

• If a response is received, the boot process continues as normal.
• If there’s no response to the first ping:
  • A further 5 pings are attempted.
  • A countdown is displayed.
  • After 6 failed attempts boot continues, but with no attempt to mount remote filesystems.

rc.inet2.diff (download rc.inet2.diff.gz):

In order to apply the above patch, do the following as root:

Do not forget to manually edit your newly patched file to replace “<known up host, or remote filesystem server>” with a valid hostname or IP address.

• 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.