75

I know that it can, in some circumstances, be difficult to move a Windows installation from one computer to another (physically move the hard drive), but how does that work on Linux? Aren't most of the driver modules loaded at bootup? So theoretically would it be that much of a hassle?

Obviously, xorg configs would change and proprietary ATI drivers and such would have to be recompiled (maybe?). Is there more to it than I'm thinking of?

Assume the two computers are from the same era, e.g. both i7s but slightly different hardware.

Update:
Thanks for the answers. This is mostly for my own curiosity. I have my Linux system up and running at work, but eventually I'd like to move to a computer that I can get dual video cards into so I can run more than two monitors. But not any time soon.

Falmarri
  • 13,047
  • 1
    Hi, you can buy a docking station if you want multiple monitors on a laptop without buying a new one ;) – TOPKAT Aug 15 '18 at 06:43

5 Answers5

64

Moving or cloning a Linux installation is pretty easy, assuming the source and target processors are the same architecture (e.g. both x86, both x64, both arm…).

Moving

When moving, you have to take care of hardware dependencies. However most users won't encounter any difficulty other than xorg.conf (and even then modern distributions tend not to need it) and perhaps the bootloader.

  • If the disk configuration is different, you may need to reconfigure the bootloader and filesystem tables (/etc/fstab, /etc/crypttab if you use cryptography, /etc/mdadm.conf if you use md RAID). For the bootloader, the easiest way is to pop the disk into the new machine, boot your distribution's live CD/USB and use its bootloader reparation tool.

    Note that if you're copying the data rather than physically moving the disk (for example because one or both systems dual boot with Windows), it's faster and easier to copy whole partitions (with (G)Parted or dd).

  • If you have an xorg.conf file to declare display-related options (e.g. in relation with a proprietary driver), it will need to be modified if the target system has a different graphics card or a different monitor setup. You should also install the proprietary driver for the target system's graphics card before moving, if applicable.

  • If you've declared module options or blacklists in /etc/modprobe.d, they may need to be adjusted for the target system.

Cloning

Cloning an installation involves the same hardware-related issues as moving, but there are a few more things to take care of to give the new machine a new identity.

  • Edit /etc/hostname to give the new machine a new name.
    Search for other occurrences of the host name under /etc. Common locations are /etc/hosts (alias for 127.0.0.1) and /etc/mailname or other mail system configuration.

  • Regenerate the ssh host key.

  • Make any necessary change to the networking configuration (such as a static IP address).

  • Change the UUID of RAID volumes (not necessary, but recommended to avoid confusion), e.g., mdadm -U uuid.

See also a step-by-step cloning guide targeted at Ubuntu.

My current desktop computer installation was cloned from its predecessor by unplugging one of two RAID-1 mirrored disks, moving it into the new computer, creating a RAID-1 volume on the already present disk, letting the mirror resynchronize, and making the changes outlined above where applicable.

  • 2
    The other day I put the hard drive from my notebook into my desktop and everything booted up completely fine with no need to change anything. Granted: the proprietary video driver didn't load and I haven't customized fstab or modprobe.conf. So it definitely is easy. – Mr. Shiny and New 安宇 Oct 08 '10 at 20:17
  • 2
    Don't forget to edit /etc/hosts as well - often this has an entry for the old machine's hostname with address 127.0.1.1 (at least on Ubuntu and maybe Debian). Generally you can just boot the old Linux image or drive in the new hardware then adjust afterwards. – RichVel Feb 27 '13 at 08:05
  • 3
    The same goes for the UUIDs of lvm and physical partitions, if you ever expect to move drives around. tune2fs -U $(uuid) /dev/sda pvchange --uuid /dev/sdb vgchange --uuid volgrp. LV's don't expose an interface for changing the UUID but don't get confused if you have duplicates. e2fs UUID changes will sometimes need /etc/fstab and grub or bootloader changes if the uuid's are referenced there. – Matt Feb 27 '13 at 09:18
  • 3
    You may take a look on this guide I wrote: http://positon.org/clone-a-linux-system-install-to-another-computer – Marc MAURICE Apr 06 '14 at 17:41
  • what about the whole thing where the computer checks the UUID and there is a mismatch and refuses to boot due to errors in mounting the partition? i had a problem like this in the past trying to do something similar –  Apr 05 '18 at 04:04
  • @NickBailuc Usually, they're filesystem UUIDs which are preserved if you copy the filesystem. If you've used UUIDs of RAID volumes… don't do this? Do distributions set up files that depend on UUIDs of physical volumes (as opposed to UUIDs of filesystems)? – Gilles 'SO- stop being evil' Apr 05 '18 at 06:33
  • @Gilles i guess it would be UUID's for hardware, it was a laptop with no working usb's, onto which i tried to insert an hdd with a presintalled ubuntu –  Apr 05 '18 at 23:39
  • @Nick I've done that several times. If you transfer the disk, even "hardware" UUIDs are the same. What mostly risks not working is the GUI, if you need proprietary drivers. And wifi connections might not come up automatically as they're tired to a MAC address. – Gilles 'SO- stop being evil' Apr 06 '18 at 06:56
  • I've just done this and it worked really well. Here are some additions: on the origin machine I was using btrfs and I have external drives with btrbk backups. So, I created a btrfs filesystem mounted it to /mnt send/received the latest snapshot to /mnt, renamed it (respectively @, @home, ...) and made the subvolume rw. Another change was necessary in NetworkManager since the name of the network device is different and some are "restricted to device". – Marko Nov 08 '22 at 18:00
26

I'm not sure if this answers your question, but typically you do the exact opposite -- you move your user folder and reinstall everything. In theory all your customization and individual configuration files should be in your user folder, so that's the only thing you really need to transfer.

Some package managers have a way to list all installed packages (Debian/Ubuntu have dpkg --list, Gentoo has /etc/world, etc.), so you can just:

  1. Install the base distro on a new system
  2. Tell it "install all the packages I had on the other computer"
  3. Copy your user folder

And you should end up with a functionally identical system.

Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
  • 1
    I do that when I'm upgrading a distro. (Say, Fedora 13 to Fedora 14). There's a few packages here and there that changed names, but they're usually dependencies of the critical ones, so it's OK to ignore them -- the important ones will pick their new-name dependencies. – JCCyC Mar 20 '11 at 03:13
  • You only need the full reinstall if you are changing Linux distribution, or making a major distro upgrade. If you are just switching hardware, you can usually just boot on the new hardware from the old hard drive (or an image copy) - Linux is very good at automatically adjusting to the new hardware, unlike Windows. GParted is easiest way to reliably copy and paste partitions to new drive. (For Windows, try Paragon backup which is quite reasonable and works OK for machine changes.) – RichVel Feb 27 '13 at 08:04
9

Indeed while under Windows it is almost impossible to move an installation to a new PC by just copying harddrive contents or switching the harddrive between the PCs, this works amazingly well under Linux. I switched from a Thinkpad R52 to a Thinkpad T400 by just copying the contents of my old harddrive to the new one (by putting the old one in an external closure connected via USB and copying everything under a Gparted-Live-CD). All I had to do after that was manually putting Grub into the MBR and boot. Everything still worked for me.

As Michael said, normally a new PC is a nice opportunity to get rid of the cruft accumulated over time, however sometimes you just have to get into work again really fast and then just copying the harddrive contents work great with Linux, as all drivers included in the kernel are available to the kernel without installation, nowadays the drivers are auto-loaded instead of manually listed in modprobe.conf and even xorg autoconfigures itself for me.

Only if you had to manually configure drivers on the old PC (e.g. Raid systems, proprietary graphic drivers etc) you might run into problems.

fschmitt
  • 8,790
2

I guess this will answer your question: https://wiki.debian.org/Wajig

From the page:

One slick trick: suppose you want to install all the packages on one system on a new system? Do:

$ wajig listinstalled > filename

where filename is now a file that lists all the installed packages. You perhaps want to use this line instead, so it excludes the lib files:

$ wajig listinstalled | grep -vP ^lib* > filename

You might want to edit this file to remove things you don't think you want anymore, etc.

Now move your file filename to the new machine and:

$ wajig install --fileinput filename

Install a fresh Linux, copy your home, and use wajig to reinstall all packages.

  • The previous link broke, so a Debian-based link is better than no link at all. I would just point out that it "uses traditional Debian administration and user tools" – Jeff Schaller Jan 20 '21 at 16:22
1

Outline

Recently, I moved an Arch Linux installation to another drive that was smaller than the original drive.

The original drive used only one partition which simplified things. If you have a boot partition separate from the root partition, here's an answer that might help you.

The steps were:

  1. Back up the data.
  2. Create a partition containing an ext4 filesystem on the target drive.
  3. Copy all data from the source partition to the target partition.
  4. Install GRUB as the bootloader on the target drive.

Hints

A hint before we start: To determine the paths of my connected devices (e.g. /dev/sdb) and generally keep an eye on the state of devices as well as partitions, I use watch combined with lsblk:

watch lsblk -o tran,name,model,fstype,label,mountpoints,fssize,fsavail,fsused,fsuse%

It updates every two seconds and produces output like this:

TRAN   NAME   MODEL                   FSTYPE LABEL        MOUNTPOINTS                FSSIZE FSAVAIL FSUSED FSUSE%
sata   sda    SanDisk SSD PLUS 1000GB
        ├─sda1                         ext4   VM partition /sda1                        108G     50G  53.4G    49%
        └─sda3                         ext4                /                            808G  561.3G 205.7G    25%
usb    sdb    SABRENT
        └─sdb1                         ext4   new_daedalus /run/media/me/new_daedalus  29.2G   25.3G   2.4G     8%
sata   sr0    MATSHITADVD-RAM UJ8A2

Since we're going to copy the contents of one partition to another, it's a good idea to get rid of cruft that takes up lots of space: Check the source partition with ncdu for directories that contain the most data and delete or move them if possible.

Another thing: I use SATA to USB adapters such as these to connect source and target drives to my computer.

Details

Assuming you've backed up your data and your target drive is at /dev/sdb, let's go into detail:

  1. Create a partition containing an ext4 filesystem on the target drive:

    • Create a Linux partition (type 0x83 in the MBR):
      sudo sfdisk /dev/sdb <<< "type=83"
      
    • Create the file system on the new partition:
      sudo mkfs.ext4 -L new_partition /dev/sdb1
      
  2. Copy all data from the source partition to the target partition:

    • The following assumes both your old and new partition are mounted:
      sudo rsync -a --hard-links --delete --progress --human-readable --stats /run/media/me/old_partition/ /run/media/me/new_partition/
      
    • I used rsync here. You could also use good old cp to achieve the same:
      sudo cp --recursive -a /run/media/me/old_partition/* /run/media/me/new_partition/
      
  3. Install GRUB as the bootloader on the target drive:

    • Add the virtual file systems to your new partition which are needed to run grub-install:
      sudo mount --bind /dev /run/media/me/new_partition/dev; sudo mount --bind /proc /run/media/me/new_partition/proc
      
    • Make the root of your new partition the current root:
      sudo chroot /run/media/me/new_partition/
      
    • Install GRUB on the target drive (see this for more on what happens here):
      grub-install /dev/sdb; grub-mkconfig -o /boot/grub/grub.cfg
      
    • Exit chroot with Ctrl+d or exit
    • Unmount virtual file systems and the partition itself:
      sudo umount --recursive /run/media/me/new_partition
      

That's it, you should now be able to use your Linux install on new_partition residing on the drive /dev/sdb.