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.

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.

  • 1
    Hi, you can buy a docking station if you want multiple monitors on a laptop without buying a new one ;)
    – TOPKAT
    Commented Aug 15, 2018 at 6:43

5 Answers 5


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…).


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 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 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. Commented Oct 8, 2010 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 (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
    Commented Feb 27, 2013 at 8: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
    Commented Feb 27, 2013 at 9:18
  • 3
    You may take a look on this guide I wrote: positon.org/clone-a-linux-system-install-to-another-computer Commented Apr 6, 2014 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
    – user77647
    Commented Apr 5, 2018 at 4:04

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.

  • 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
    Commented Mar 20, 2011 at 3: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
    Commented Feb 27, 2013 at 8:04

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.


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
    Commented Jan 20, 2021 at 16:22


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.


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:

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.


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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .