SUSE Support

Here When You Need Us

How to Migrate the Root Filesystem to a New Disk

This document (7018639) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11

Situation

The root filesystem needs to be moved to a new disk or partition.

Resolution

Boot the Rescue System

Use the installation media to enter rescue mode on the system. This is the safest way to copy data from the root disk as it prevents a situation where data is changing while we are copying from it. Make sure the new disk is available.
 

Copy the Data to the New Device

Copy data at the block(a) or filesystem(b) level depending on preference from the old disk to the new disk.

a. Here is an example dd command for copying at the block level:
# dd if=/dev/<old root disk> of=/dev/<new root disk> bs=64k conv=noerror,sync
NOTE: If the dd command is not being used to copy data from an entire disk to an entire disk, the partition(s) will need to be created prior to this step.

Important: The disks being copied do not need to be mounted. However, if you do mount any filesystem from the disks to be copied, please ensure that you mount these filesystems as read-only, or remount them as read-only before starting any copy using dd. This will ensure that any filesystem is copied in a consistent manner (using dd on a read/write mounted filesystem carries a major risk of introducing corruption on the target device should anything change on the source during the copy process).

b. To copy at the filesystem level, use an rsync command after mounting both the old and new root partitions. Make sure that the new root partition has a filesystem on it.
# mount /dev/<old root disk> /mnt
# mkdir /mnt2
# mount /dev/<new root disk> /mnt2
# rsync -zahP /mnt/ /mnt2/


Set the Boot Label

The boot flag needs to be set to the correct partition using either fdisk(a) or parted(b).

NOTE: This step is not always necessary. For example, this step can be skipped if the boot partition is separate from the root partition and has not changed. As another example, if dd was used on an entire disk to an entire disk in step 2, you can skip this step since the partition table will have been copied to the new disk. Finally, this step can be skipped on systems that do not use a boot label.

a. Using fdisk to label the new root partition (which contains /boot) as bootable.
# fdisk /dev/<new root disk>
From the fdisk prompt, type 'p' to list and verify the root partition is there.
Command (m for help): p
If the "Boot" column of the root partition does not have an "*" symbol then it needs to be activated. Type 'a' to toggle the bootable partition flag:
Command (m for help): a
Partition number (1-4): <root partition number>
After that use the 'p' command to verify the bootable flag is now enabled. Finally, save changes:
Command (m for help): w


b. Using parted to label the new root partition (which contains /boot) as bootable.

# parted /dev/<new root disk>
From the parted prompt, type "print" to list and verify the root partition is there.
(parted) print
If the "Flags" column of the root partition doesn't include "boot" then it will need to be enabled.
(parted) set <root partition number> boot on
After that, use the "print" command again to verify the flag is now listed for the root partition. Exit parted to save the changes:
(parted) quit
 

Update Bootloader Configuration

The config for GRUB(a) on SLE 11 or GRUB2(b) on SLE 12 and SLE 15 needs to be updated to boot from the new root.

NOTE: This and the remaining steps in this document will need to be done in a chroot environment on the new root disk. Knowledge Base article 7018126 covers how to use chroot in rescue mode.


a. Updating GRUB on SLE 11
 
There are two changes that may need to be made in the file /boot/grub/menu.lst on the new root.
  1. If the contents of /boot are in the root partition which is being changed, we'll need to update the line "root (hd#,#)" which points to the disk with the contents of /boot. Refer to the grub legacy documentation for disk naming conventions.
  2. In the line starting with the word "kernel", there should be a root=/dev/<old root disk> parameter. That will need to be updated to match the device name of the new root partition. It is recommended to use persistent device names such as the following: root=/dev/disk/by-id/<new root partition UUID>. If the swap partition was changed to the new disk, you'll need to reflect that in the resume=<swap device> parameter.
Save the file after making the above changes. Then, YaST2 can be used to update the grub installation.
# yast2 bootloader

Go to the "Boot Loader Installation" tab with ALT + a. Verify it is set to boot from the correct partition. For example, if  the content of /boot is in the root partition, then make sure it is set to boot from the root partition. Lastly hit ALT + o so that it will save the configuration. While the YaST2 module is existing it will also install the boot loader.

b. Updating GRUB2 on SLE 12 and 15
 
The file /etc/default/grub needs to be edited to reflect the partition changes.
 
The GRUB_CMDLINE_LINUX_DEFAULT line need to be updated. Edit the existing root=/dev/<old root disk> parameter to root=/dev/<new root disk>. If there is no root= parameter, then add it. It is recommended to use a persistent device name for this parameter. Each parameter is space-separated so make sure there is a space separating it from the other parameters. If the swap partition was changed to the new disk, you'll need to reflect that in the resume=<swap device> parameter.
 
It might look something like this afterward:
GRUB_CMDLINE_LINUX_DEFAULT="root=/dev/disk/by-id/<new root UUID> resume=/dev/disk/by-id/<swap UUID> splash=silent quiet showopts"

After saving changes to that file, run this command to save them to the GRUB2 configuration:
# grub2-mkconfig -o /boot/grub2/grub.cfg

After that, run grub2-install on the disk with the root partition. For example, if the new root partition is sda2, then run the command on sda:
# grub2-install /dev/sda


Update /etc/fstab

Update the root (/) partition line so that it points to the new root. If any other partitions were changed they will need to be updated as well. For example, the root line could be changed from:
/dev/<old root device>    /    ext3    defaults    1    1
to:
/dev/<new root device>    /    ext3    defaults    1    1

Save and exit after making needed changes.
 

Rebuild the initrd

Lastly, run the following command to rebuild the initrd to match updated information:
# mkinitrd


Exit and reboot

Exit chroot and reboot the system to test if it will boot using the new disk. Make sure to adjust the BIOS boot order so that the new disk is prioritized.

Additional Information

Differing Environments

Environments vary and different environments can impact the necessary steps to migrate a root filesystem. Be sure to consider your own unique environment before performing the above steps. As always in administration, have backups ready and proceed with caution.
 

The dd Command

The dd command is not verbose and could take some time to complete. While it is running the command will look like it is just hanging. If needed, to verify it is still running, use the ps command on another terminal window to find the dd command's PID and use strace to follow that PID and make sure there is activity.
# ps aux | grep dd
# strace -p<process id>
After confirming activity, hit CTRL + c to end the strace command. Once the dd command is complete, the terminal prompt will return allowing for new commands to be run.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7018639
  • Creation Date: 17-Feb-2017
  • Modified Date:30-Mar-2023
    • SUSE Linux Enterprise Desktop
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.