Home > Hardware, Linux, Slackware > Migrating Slackware to New Hardware

Migrating Slackware to New Hardware

Sometimes it is necessary to retain a Slackware installation, but change the hardware it runs on:

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

# This file was automatically generated by the //lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:f3:7c:75:31", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:f3:7c:75:32", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:f3:7c:75:b7", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:f3:7c:75:b8", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

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.

Be Sociable, Share!
  1. michael foulard
    July 2nd, 2013 at 08:25 | #1

    salut Jean,
    Michael here, new to slack, new to linux.

    I’m trying to get slack14_64bit, v.3.8.1 running on a new machine with these specs:
    Intel IvyBridge Desktop (CPU) with inbuilt graphics
    7.7GB memory

    1. KDE crashes
    2. Xfce won’t render the gui properly and crashes as soon as i launch firefox or thunderbird
    3. Konsole works well; whereas Terminal Emulator does not (it exhibits same patchy quality described at #2

    I was just wondering if you would mind taking a look at my post on linuxquestions.org to see if you can help at all, as so far, no-one there has been able to diagnose the problem:

    http://www.linuxquestions.org/questions/slackware-installation-40/fresh-install-of-14-0-64-bit-to-new-machine-frozen-gui-at-startx-4175465855/

    and, most recently, here:

    http://www.linuxquestions.org/questions/slackware-installation-40/kde-crashing%3B-xfce-patchy-on-new-install-of-14_64-v-3-81-a-4175468008/

    I would really appreciate your input but I understand if this is asking too much; I am not expecting a personal consultant!!!!

    Bonne continuation, Oncle Jean!

  1. July 5th, 2010 at 10:15 | #1
  2. March 8th, 2014 at 12:06 | #2

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).