Moving root partition to a new drive how do I mount both drives?
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
orfdisk -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), orparted
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)
- ESP:
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:(Replace
sudo mount /dev/nvme0n1p2 /mnt
/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:(Replace
sudo swapon /dev/nvme0n1p3
/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 tellsrsync
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 theirUUID
values.Editing
/mnt/etc/fstab
: You will edit thefstab
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 isvfat
.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
, andYOUR_SWAP_UUID
with the actual UUIDs you obtained fromblkid
.)
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:
- Install GRUB to the NVMe drive:(Ensure
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ArchLinux --recheck
/boot
is the correct mount point for your ESP within the chroot environment, which it should be if you followed the mounting steps.) - Generate the GRUB configuration file:
grub-mkconfig -o /boot/grub/grub.cfg
- Install GRUB to the NVMe drive:
If using
systemd-boot
:- Ensure your ESP is mounted at
/boot
. - You might need to copy your kernel and initramfs to the ESP if they aren’t already there or re-generate them.
- The
systemd-boot
configuration files in/boot/loader/entries/
should generally work if thefstab
is correctly updated, as they refer to the root partition by UUID.
- Ensure your ESP is mounted at
3. Updating Kernel Image and Initramfs (Optional but Recommended)
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:(The
sudo umount -R /mnt sudo umount /mnt/old_root sudo umount /mnt/old_boot # If you mounted the old ESP separately
-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:Confirm that
lsblk findmnt /
/
is indeed mounted on your new NVMe drive. - Check
fstab
:Ensure the UUIDs and mount points are as expected.cat /etc/fstab
- Test Applications: Launch some of your frequently used applications to ensure they function correctly.
- Swap Check:Verify that your swap partition is active.
swapon --show
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.