Migrating an Arch Linux installation to new hardware requires precise inventory of custom software and storage configurations. You can list all manually installed AUR packages using
pacman -Qm and identify currently mounted filesystems with the
mount or
lsblk commands. This data forms the foundation for restoring your specific environment on the target machine without losing critical user settings or drive mappings.
Inventorying Custom Software
The primary challenge in an Arch migration is preserving the exact state of your user-installed software. The default package manager,
pacman, distinguishes between repository packages and those built from the Arch User Repository (AUR). To generate a complete list of these custom installations, you must query the local database for packages that are not found in any configured sync database.
Run the following command in your terminal to export this list to a file:
pacman -Qm > aur_packages.txt
This output includes only packages marked as "orphaned" or explicitly built outside the official repositories. It is crucial because reinstalling these on the new system ensures you retain tools like
yay,
paru, or specific kernel modules that were compiled locally. If you have previously used helpers like
yaourt or
trizen, their logs might be stored elsewhere, but
pacman -Qm remains the authoritative source for what
pacman itself tracks as non-standard.
For a more robust backup strategy, consider combining this with a list of explicitly installed packages from official repos. Use
pacman -Qeqn to get packages that were manually installed rather than pulled in as dependencies. This prevents the new system from cluttering with unnecessary libraries that were only needed on the old hardware architecture.
Documenting Storage Layout
Storage configuration often breaks during migration due to differing UUIDs or partition schemes. Before wiping the old drive or formatting the new one, you must document exactly how your drives were mounted. The
mount command provides a human-readable view of active filesystems, showing device paths, mount points, and filesystem types.
Execute this command to capture the current state:
mount | grep -E "^/dev" > mounted_drives.txt
However,
mount can sometimes show virtual filesystems like
tmpfs or
sysfs if not filtered correctly. A cleaner approach is using
lsblk with JSON output, which preserves hierarchical relationships between disks and partitions. This is particularly useful if you use LVM (Logical Volume Manager) or RAID arrays, as text-based outputs often fail to represent these complex structures accurately.
lsblk -f > block_layout.json
Review the resulting files carefully. Note the UUIDs of your root, home, and swap partitions. During the installation on the new machine, you will need to match these UUIDs in your
/etc/fstab file. If the new machine has different hardware controllers, the device names (like
sda vs
nvme0n1) may change, making UUID-based mounting essential for a bootable system.
Preserving Configuration Files
Beyond packages and drives, your dotfiles and system configurations define your workflow. While
pacman handles binaries, it does not back up
/etc or
~/.config. Create a compressed archive of your home directory, excluding large temporary folders like
.cache or
Downloads to save space.
tar -czf home_backup.tar.gz --exclude='.cache' --exclude='.local/share/Trash' ~/
Simultaneously, back up your system configuration directory. Be cautious with
/etc/pacman.conf and
/etc/mkinitcpio.conf, as these contain hardware-specific hooks that may need adjustment for the new machine. For example, if you switched from SATA to NVMe storage, you might need to add the
nvme hook to
mkinitcpio.conf.
If you use encryption via LUKS, ensure you also note the keyslot numbers and the order of hooks in your initramfs. Failure to update these hooks after migration will result in a system that fails to decrypt the root partition at boot.
Restoring on the New Hardware
Once the base Arch Linux system is installed on the new machine, begin the restoration process. First, install the AUR helper if you do not already have one. Then, iterate through the
aur_packages.txt file to reinstall each package. Using a script to automate this loop saves significant time compared to manual installation.
while read pkg; do yay -S --noconfirm "$pkg"; done < aur_packages.txt
Next, restore your
/etc/fstab using the UUIDs recorded earlier. Verify that the mount points align with your restored home directory structure. Finally, extract your dotfiles archive into the new home directory. Remember to adjust permissions so that the user owns their configuration files.
If you encounter issues with proprietary drivers or specific kernel parameters, refer to the original
mkinitcpio configuration and rebuild the initial ramdisk. Regularly check the Arch Wiki for updates related to your new hardware components, as driver requirements may have shifted since your last installation. For more detailed insights on managing these transitions, see our guide on
Migrating Arch Linux to a New Machine: Installing listpacman AUR packages and mounted drives.
Frequently Asked Questions
What happens if I skip backing up my /etc/fstab?
Your system will likely fail to boot because the kernel will not know where to mount the root and home partitions. Without UUID references, the system may assign random device names that do not match your previous setup, leading to a drop into emergency mode.
Can I use Pacman to list packages from third-party repositories like Chaotic-AUR?
Yes,
pacman -Qm lists all packages not found in the official core, extra, multilib, or community repos. This includes packages from any enabled third-party mirror, provided they are tracked by pacman's local database.
Why is lsblk preferred over df for migration planning?
df shows disk usage per mounted filesystem but lacks structural details about partitions and physical disks.
lsblk reveals the hierarchy of devices, including LVM volumes and encrypted containers, which is vital for recreating the exact storage layout on new hardware.
Should I include the .cache directory in my home backup?
No,
.cache contains temporary data generated by applications that can be safely regenerated. Including it wastes bandwidth and storage space during transfer and may cause conflicts if cached data from the old hardware interferes with the new environment.
How do I handle different CPU architectures during migration?
Arch Linux generally supports multiple architectures within the same release, but you must ensure you are installing the correct version (e.g., x86_64) on the new machine. Packages compiled for AUR may require rebuilding if they depend on architecture-specific binaries, so always verify compatibility before installation.