Moving Your Arch Linux Root Partition to a New NVMe Drive: A Comprehensive Guide to Mounting Both Drives

At revWhiteShadow, we understand the complexities of optimizing your Linux system. Migrating your root partition to a faster, larger drive, particularly an NVMe SSD, is a significant upgrade. This process, while rewarding, often leaves users questioning the precise steps for mounting existing and new drives. This guide provides an in-depth, step-by-step approach to successfully move your root partition from your current SATA SSD to your new 2TB NVMe drive, ensuring you can mount both drives correctly for a seamless transition on Arch Linux.

Understanding the Core Challenge: Mounting Multiple Drives for Migration

The fundamental hurdle you’re facing lies in the initial mounting phase when preparing for a data migration like this. When undertaking a standard Arch Linux installation, the target drive for the new root partition is typically mounted at /mnt. However, when you intend to copy data from an existing root partition to a new one, you require access to both the source and destination filesystems simultaneously. This necessitates a clear strategy for mounting both your old SATA SSD and your new NVMe drive within the live Arch Linux environment. The key is to establish distinct mount points that allow rsync to access both locations without conflict.

Pre-Migration Preparations: Ensuring a Smooth Transition

Before embarking on the physical or data migration, meticulous preparation is paramount. This phase is designed to safeguard your data and ensure you have all the necessary tools and information readily available.

1. Verifying Your Current System Configuration

It’s crucial to have a clear understanding of your current disk layout. Even though you know your root partition is on a 480GB SATA SSD, it’s wise to confirm its exact device name and partition identifier. Similarly, identify any other critical partitions, such as the EFI System Partition (ESP).

  • Identifying Current Partitions: Boot into your existing system (or use a live environment) and use tools like lsblk or fdisk -l to list all block devices and their partitions. Look for your 480GB SSD and note its device name (e.g., /dev/sda, /dev/nvme0n1) and the specific partition designated as your root (/) and EFI (/boot/efi).

2. Backing Up Your Data: The Absolute Essential Step

No system migration should ever be attempted without a robust backup. While rsync is an excellent tool for copying files, it’s not a substitute for a comprehensive data backup.

  • Comprehensive Backup Strategy: Consider backing up your entire system to an external drive or cloud storage. This could involve using tools like timeshift (if you have it configured), dd for disk imaging, or simply backing up your /home directory and any other essential data. Ensure you have a reliable way to restore your system should any unforeseen issues arise during the migration process.

3. Preparing the New NVMe Drive: Partitioning and Formatting

Your new 2TB NVMe drive needs to be partitioned according to your desired layout, mirroring your existing setup but scaled for the new drive.

  • Partition Table Creation: Boot from your Arch Linux live USB. You will use partitioning tools like fdisk, gdisk (recommended for GPT, which is standard for NVMe), or parted to create the partition table on your new NVMe drive.

  • Replicating the Partition Layout: The Arch Linux installation guide typically recommends an EFI System Partition (ESP) formatted as FAT32, a root partition (/), and potentially a swap partition.

    • EFI System Partition (ESP): This partition is crucial for booting. Create a small partition (e.g., 512MB to 1GB) and format it as FAT32. You will later set the boot flag on this partition.
    • Root Partition (/): This will be the primary partition for your migrated system. Allocate the majority of your 2TB NVMe drive to this partition. For an Arch Linux installation, ext4 is a common and robust choice for the root filesystem.
    • Swap Partition (Optional but Recommended): While NVMe drives are fast, a swap partition can still be beneficial for managing memory, especially if you have limited RAM or run memory-intensive applications. You can create a swap partition of a size that suits your needs (often equal to or double your RAM, though this is becoming less critical with ample RAM).
  • Example gdisk Commands (Illustrative):

    # Assuming your NVMe drive is /dev/nvme0n1
    sudo gdisk /dev/nvme0n1
    

    Inside gdisk:

    • o - Create a new empty GPT partition table.
    • n - Create a new partition.
      • Partition number (default 1)
      • First sector (default)
      • Last sector (e.g., +1G for 1GB ESP)
      • Hex code or GUID: ef00 for EFI System Partition.
    • n - Create another new partition for root.
      • Partition number (default 2)
      • First sector (default)
      • Last sector (default, to use remaining space)
      • Hex code or GUID: 8300 for Linux filesystem.
    • w - Write table to disk and exit.
  • Formatting Partitions:

    • ESP: sudo mkfs.fat -F 32 /dev/nvme0n1p1 (assuming /dev/nvme0n1p1 is your ESP)
    • Root: sudo mkfs.ext4 /dev/nvme0n1p2 (assuming /dev/nvme0n1p2 is your root partition)
    • Swap (if created): sudo mkswap /dev/nvme0n1p3 (assuming /dev/nvme0n1p3 is your swap partition)

The Critical Step: Mounting Both Drives in the Live Environment

This is where your primary question arises, and it’s crucial to establish a logical and organized mounting scheme. The goal is to have access to both your old root partition (the source) and your new root partition (the destination) within the live environment.

1. Mounting the New Root Partition

The conventional approach for installing Arch Linux is to mount the target root partition at /mnt. We will adopt this convention for your new NVMe drive.

  • Mounting the Destination:
    sudo mount /dev/nvme0n1p2 /mnt
    
    (Replace /dev/nvme0n1p2 with the actual device name of your new root partition on the NVMe drive.)

2. Mounting the Old Root Partition: The Key to rsync

This is where the typical installation process differs. You need a separate mount point for your existing root partition so that rsync can read from it.

  • Creating a Mount Point for the Old Root: It’s best practice to create a dedicated directory within the live environment to mount your old root partition. A logical choice is to create a directory within /mnt that clearly signifies its purpose, such as /mnt/old_root.

    sudo mkdir /mnt/old_root
    
  • Mounting the Source: Now, mount your current SATA SSD’s root partition to this newly created directory. Let’s assume your old SATA SSD’s root partition is /dev/sda2.

    sudo mount /dev/sda2 /mnt/old_root
    

    (Replace /dev/sda2 with the actual device name of your current root partition on the SATA SSD.)

3. Mounting the EFI System Partition (ESP)

You will also need to mount both your old and new EFI System Partitions. This is essential for updating bootloader configurations later.

  • Mounting the New ESP: The new ESP should be mounted to /mnt/boot (or /mnt/efi, depending on your previous setup and preference, though /mnt/boot is common for UEFI systems).

    sudo mkdir /mnt/boot
    sudo mount /dev/nvme0n1p1 /mnt/boot
    

    (Replace /dev/nvme0n1p1 with the actual device name of your new ESP on the NVMe drive.)

  • Mounting the Old ESP: Similarly, mount your old ESP to a temporary location, for example, /mnt/old_boot.

    sudo mkdir /mnt/old_boot
    sudo mount /dev/sda1 /mnt/old_boot
    

    (Replace /dev/sda1 with the actual device name of your old ESP on the SATA SSD.)

4. Mounting the Swap Partition (Optional)

If you created a swap partition on your new drive, you can activate it.

  • Activating New Swap:
    sudo swapon /dev/nvme0n1p3
    
    (Replace /dev/nvme0n1p3 with the actual device name of your new swap partition.)

Summary of Mounting Strategy

By following these steps, your mount structure will look something like this within the live environment:

  • /mnt: This is where your new root filesystem resides (on the NVMe drive).
  • /mnt/old_root: This is where your old root filesystem resides (on the SATA SSD), allowing you to access its contents.
  • /mnt/boot: This is where your new EFI System Partition resides.
  • /mnt/old_boot: This is where your old EFI System Partition resides.

This organized approach ensures that all necessary directories and files from your old system are accessible for the copying process, while your new system is being prepared at the standard mount point.

Migrating Your Root Filesystem with rsync

With both your old and new root partitions mounted correctly, you can now proceed with copying your system files. rsync is the tool of choice for its efficiency, ability to preserve file permissions, ownership, and timestamps, and its resilience.

1. Executing the rsync Command

The rsync command needs to be carefully crafted to copy everything from your old root partition to the new one, excluding certain directories that are either temporary, system-generated, or will be handled separately.

  • The rsync Command Structure:

    sudo rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt/old_root/ /mnt/
    

    Let’s break down this command:

    • -a (archive mode): This is a combination of options that preserves permissions, ownership, timestamps, symbolic links, and device files. It’s essential for a proper system copy.
    • -A (ACLs): Preserve Access Control Lists. Important for advanced file permissions.
    • -X (extended attributes): Preserve extended attributes.
    • -v (verbose): Shows you the files being copied, providing real-time feedback.
    • --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}: This is a critical part. We exclude directories that are dynamically generated by the kernel or contain temporary files. Copying these would lead to issues or incorrect data.
      • /dev/*: Device files. These are created by the kernel based on the hardware detected.
      • /proc/*: Process information filesystem. Dynamic.
      • /sys/*: System information filesystem. Dynamic.
      • /tmp/*: Temporary files.
      • /run/*: Runtime data.
      • /mnt/*: Mount points for other filesystems (including the temporary mount points we created for migration).
      • /media/*: Mount points for removable media.
      • /lost+found: Filesystem recovery directory, typically empty.
    • /mnt/old_root/: The source directory. The trailing slash is important; it tells rsync to copy the contents of /mnt/old_root rather than the directory itself.
    • /mnt/: The destination directory. This is where the new root filesystem resides.

2. Verifying the Copy

After rsync completes, it’s good practice to do a quick verification. You can spot-check a few directories and files on both /mnt/old_root and /mnt to ensure that the copy was successful and that permissions seem intact.

Reconfiguring the Bootloader and Essential System Files

Once the data migration is complete, you need to ensure that your system will boot from the new drive. This involves updating essential configuration files and reinstalling/reconfiguring your bootloader.

1. Preparing fstab

The /etc/fstab file dictates how filesystems are mounted at boot time. You need to update it to reflect the new partition UUIDs for your NVMe drive.

  • Obtaining New Partition UUIDs: Use the blkid command to find the UUIDs of your new partitions.

    sudo blkid
    

    Look for the lines corresponding to /dev/nvme0n1p1 (your new ESP) and /dev/nvme0n1p2 (your new root partition). Note their UUID values.

  • Editing /mnt/etc/fstab: You will edit the fstab file on your new root partition.

    sudo nano /mnt/etc/fstab
    
    • Update the Root Entry: Find the line that mounts your old root partition (likely identified by its old UUID or device name) and replace it with the UUID of your new root partition (/dev/nvme0n1p2). Ensure the mount point is / and the filesystem type (e.g., ext4) is correct.

    • Update the EFI System Partition Entry: Find the line for your old ESP (likely mounted at /boot or /efi) and replace its UUID with the UUID of your new ESP (/dev/nvme0n1p1). Ensure the mount point is correct (e.g., /boot or /efi) and the filesystem type is vfat.

    • Add Swap Entry (if applicable): If you created a swap partition on the new drive, add an entry for it using its UUID.

    Example fstab entries:

    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device; this may be used with UUID= as a more robust way to name devices
    # that your fstab depends on. See fstab(5).
    #
    # <file system>  <dir>     <type>  <options>       <dump>  <pass>
    
    UUID=YOUR_NEW_ROOT_UUID  /     ext4      defaults,noatime,discard 0  1
    UUID=YOUR_NEW_ESP_UUID   /boot vfat      umask=0077,shortname=lower 0  2
    UUID=YOUR_SWAP_UUID      none  swap      sw              0  0
    

    (Replace YOUR_NEW_ROOT_UUID, YOUR_NEW_ESP_UUID, and YOUR_SWAP_UUID with the actual UUIDs you obtained from blkid.)

2. Reinstalling/Reconfiguring the Bootloader

This is a critical step to ensure your system boots from the new drive. The process varies slightly depending on your bootloader (GRUB, systemd-boot, etc.). We’ll focus on GRUB as it’s very common.

  • Chrooting into the New System: To interact with your newly migrated system as if you were booted into it, you need to chroot.

    sudo arch-chroot /mnt
    
  • Reinstalling GRUB:

    1. Install GRUB to the NVMe drive:
      grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ArchLinux --recheck
      
      (Ensure /boot is the correct mount point for your ESP within the chroot environment, which it should be if you followed the mounting steps.)
    2. Generate the GRUB configuration file:
      grub-mkconfig -o /boot/grub/grub.cfg
      
  • If using systemd-boot:

    1. Ensure your ESP is mounted at /boot.
    2. You might need to copy your kernel and initramfs to the ESP if they aren’t already there or re-generate them.
    3. The systemd-boot configuration files in /boot/loader/entries/ should generally work if the fstab is correctly updated, as they refer to the root partition by UUID.

Sometimes, it’s beneficial to regenerate your kernel image and initramfs after a migration, especially if there were any subtle differences in the system context during the rsync.

  • From within the arch-chroot environment:
    mkinitcpio -P
    

Finalizing the Migration and Rebooting

You’ve reached the final stages of the migration. It’s time to clean up and attempt to boot into your new system.

1. Unmounting Partitions

Before rebooting, it’s good practice to unmount all the partitions you mounted in the live environment.

  • Unmounting Command:
    sudo umount -R /mnt
    sudo umount /mnt/old_root
    sudo umount /mnt/old_boot # If you mounted the old ESP separately
    
    (The -R flag ensures that all mounted filesystems within /mnt are unmounted recursively.)

2. Rebooting Your System

Now, carefully reboot your computer.

  • Remove the Live USB: Make sure to remove your Arch Linux live USB drive.
  • BIOS/UEFI Settings: You may need to enter your BIOS/UEFI settings to ensure that your new NVMe drive is set as the primary boot device.

3. Post-Reboot Checks

Once your system boots up, perform a few checks to confirm everything is working correctly.

  • Verify Root Partition: Open a terminal and run:
    lsblk
    findmnt /
    
    Confirm that / is indeed mounted on your new NVMe drive.
  • Check fstab:
    cat /etc/fstab
    
    Ensure the UUIDs and mount points are as expected.
  • Test Applications: Launch some of your frequently used applications to ensure they function correctly.
  • Swap Check:
    swapon --show
    
    Verify that your swap partition is active.

Dealing with the Old SATA SSD

Once you are completely confident that your new NVMe drive is booting and operating flawlessly, you can decide what to do with your old 480GB SATA SSD.

  • Reformatting: You can reformat it and use it as a secondary storage drive for backups, media, or other data.
  • Leaving as is: You could also leave it as is, but ensure your BIOS/UEFI boot order prioritizes the NVMe drive to prevent accidental booting from the old SATA SSD.

By meticulously following these steps, from the initial preparation and precise mounting of both your old and new drives to the critical rsync operation and bootloader reconfiguration, you can successfully move your root partition to a new NVMe drive on Arch Linux. This detailed guide, provided by revWhiteShadow, aims to provide the clarity needed to overcome the common challenges associated with such system migrations, ensuring a robust and well-configured setup.