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 12
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 11
Situation
The root filesystem needs to be moved to a new disk or partition.
Resolution
1. Use the media to go into rescue mode on the system. This is the safest way to copy data from the root disk so that it's not changing while we are copying from it. Make sure the new disk is available.
2. Copy data at the block(a) or filesystem(b) level depending on preference from the old disk to the new disk.
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 on the new disk so that the data can copied from partition to partition.
a. Here is a dd command for copying at the block level (the disks do not need to be mounted):
# dd if=/dev/<old root disk> of=/dev/<new root disk> bs=64k conv=noerror,sync
The dd command is not verbose and depending on the size of the disk 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 process ID 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.
b. Alternatively to dd, mount the disks and then use an rsync command for copying at the filesystem level:
# mount /dev/<old root disk> /mnt
# mkdir /mnt2
(If the new disk's root partition doesn't have a filesystem yet, create it now.)
# mount /dev/<new root disk> /mnt2
# rsync -zahP /mnt/ /mnt2/
This command is much more verbose than dd and there shouldn't be any issues telling that it is working. This does generally take longer than the dd command.
3. Setting up the partition boot label with either fdisk(a) or parted(b)
NOTE: This step can be skipped if the boot partition is separate from the root partition and has not changed. Also, if dd was used on an entire disk to an entire disk in section "a" of step 2 you can still skip this step since the partition table will have been copied to the new disk (If the partitions are not showing as available yet on the new disk run "partprobe" or enter fdisk and save no changes. ). This exception does not include using dd on only a partition.
a. Using fdisk to label the new root partition (which contains boot) as bootable.
# fdisk /dev/<new root disk>
From the fdisk shell 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:
After saving changes to that file run this command to save them to the GRUB2 configuration:
After that run this command on the disk with the root partition. For example, if the root partition is sda2 run this command on sda:
# grub2-install /dev/<disk of root partition>
5. Correct the fstab file to match new partition name(s)
# vim /etc/fstab
Correct the root (/) partition mount row in the file so that it points to the new disk/partition name. If any other partitions were changed they will need to be updated as well. For example, changed from:
6. Lastly, run the following command to rebuild the ramdisk to match updated information:
2. Copy data at the block(a) or filesystem(b) level depending on preference from the old disk to the new disk.
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 on the new disk so that the data can copied from partition to partition.
a. Here is a dd command for copying at the block level (the disks do not need to be mounted):
# dd if=/dev/<old root disk> of=/dev/<new root disk> bs=64k conv=noerror,sync
The dd command is not verbose and depending on the size of the disk 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 process ID 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.
b. Alternatively to dd, mount the disks and then use an rsync command for copying at the filesystem level:
# mount /dev/<old root disk> /mnt
# mkdir /mnt2
(If the new disk's root partition doesn't have a filesystem yet, create it now.)
# mount /dev/<new root disk> /mnt2
# rsync -zahP /mnt/ /mnt2/
This command is much more verbose than dd and there shouldn't be any issues telling that it is working. This does generally take longer than the dd command.
3. Setting up the partition boot label with either fdisk(a) or parted(b)
NOTE: This step can be skipped if the boot partition is separate from the root partition and has not changed. Also, if dd was used on an entire disk to an entire disk in section "a" of step 2 you can still skip this step since the partition table will have been copied to the new disk (If the partitions are not showing as available yet on the new disk run "partprobe" or enter fdisk and save no changes. ). This exception does not include using dd on only a partition.
a. Using fdisk to label the new root partition (which contains boot) as bootable.
# fdisk /dev/<new root disk>
From the fdisk shell 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): <number from output p for root partition>
After that use the 'p' command to verify the bootable flag is now enabled. Finally, save changes:
After that use the 'p' command to verify the bootable flag is now enabled. Finally, save changes:
Command (m for help): w
b. Alternatively to fdisk, use parted to label the new root partition (which contains boot) as bootable.
# parted /dev/sda
From the parted shell type "print" to list and verify the root partition is there.
(parted) print
b. Alternatively to fdisk, use parted to label the new root partition (which contains boot) as bootable.
# parted /dev/sda
From the parted shell 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. then exit parted to save the changes:
After that use the "print" command again to verify the flag is now listed for the root partition. then exit parted to save the changes:
(parted) quit
4. Updating Legacy GRUB(a) on SLE11 or GRUB2(b) on SLE12.
NOTE: Steps 4 through 6 will need to be done in a chroot environment on the new root disk. TID7018126 covers how to chroot in rescue mode: https://www.suse.com/support/kb/doc?id=7018126
a. Updating Legacy GRUB on SLE11
# vim /boot/grub/menu.lst
There are two changes that may need to occur in the menu.lst file.
NOTE: Steps 4 through 6 will need to be done in a chroot environment on the new root disk. TID7018126 covers how to chroot in rescue mode: https://www.suse.com/support/kb/doc?id=7018126
a. Updating Legacy GRUB on SLE11
# vim /boot/grub/menu.lst
There are two changes that may need to occur in the menu.lst file.
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.
Since the sd[a-z] device names are not persistent it's recommended to find the equivalent /dev/disk/by-id/ or /dev/disk/by-path/ disk name and to use that instead. Also, the device name might be different in chroot than it was before chroot. Run this command to verify the disk name in chroot:
Since the sd[a-z] device names are not persistent it's recommended to find the equivalent /dev/disk/by-id/ or /dev/disk/by-path/ disk name and to use that instead. Also, the device name might be different in chroot than it was before chroot. Run this command to verify the disk name in chroot:
# mount
For this line Grub uses "hd[0-9]" rather than "sd[a-z]" so sda would be hd0 and sdb would be hd1, and so on. Match to the disk as shown in the mount command within chroot. The partition number in Legacy Grub also starts at 0. So if it were sda1 it would be hd0,0 and if it were sdb2 it would be hd1,1. Update that line accordingly.
2. in the line starting with the word "kernel" (generally just below the root line we just went over) there should be a root=/dev/<old root disk> parameter. That will need to be updated to match the path and device name of the new root partition. root=/dev/disk/by-id/<new root partition> Also, if the swap partition was changed to the new disk you'll need to reflect that with the resume= parameter.
2. in the line starting with the word "kernel" (generally just below the root line we just went over) there should be a root=/dev/<old root disk> parameter. That will need to be updated to match the path and device name of the new root partition. root=/dev/disk/by-id/<new root partition> Also, if the swap partition was changed to the new disk you'll need to reflect that with the resume= parameter.
Save and exit after making the above changes as needed.
Next, run this command:
# yast2 bootloader
( you may get a warning message about the boot loader. This can be ignored.)
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 should also install the boot loader.
( you may get a warning message about the boot loader. This can be ignored.)
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 should also install the boot loader.
b Updating GRUB2 on SLE12
# vim /etc/default/grub
The parameter to update is the GRUB_CMDLINE_LINUX_DEFAULT. If there is a "root=/dev/<old root disk>" parameter update it so that it is "root=/dev/<new root disk>". If there is no root= parameter in there add it. Each parameter is space separated so make sure there is a space separating it from the other parameters. Also, if the swap partition was changed to the new disk you'll need to reflect that with the resume= parameter.
Since the sd[a-z] device names are not persistent it's recommended to find the equivalent /dev/disk/by-id/ or /dev/disk/by-path/ disk name and to use that instead. Also, the device name might be different in chroot than it was before chroot. Run this command to verify the disk name in chroot before comparing with by-id or by-path:
The parameter to update is the GRUB_CMDLINE_LINUX_DEFAULT. If there is a "root=/dev/<old root disk>" parameter update it so that it is "root=/dev/<new root disk>". If there is no root= parameter in there add it. Each parameter is space separated so make sure there is a space separating it from the other parameters. Also, if the swap partition was changed to the new disk you'll need to reflect that with the resume= parameter.
Since the sd[a-z] device names are not persistent it's recommended to find the equivalent /dev/disk/by-id/ or /dev/disk/by-path/ disk name and to use that instead. Also, the device name might be different in chroot than it was before chroot. Run this command to verify the disk name in chroot before comparing with by-id or by-path:
# mount
It might look something like this afterward:GRUB_CMDLINE_LINUX_DEFAULT="root=/dev/disk/by-id/<partition/disk name> resume=/dev/disk/by-id/<partition/disk name> 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
(You can ignore any errors about lvmetad during the output of the above command.)
After that run this command on the disk with the root partition. For example, if the root partition is sda2 run this command on sda:
# grub2-install /dev/<disk of root partition>
5. Correct the fstab file to match new partition name(s)
# vim /etc/fstab
Correct the root (/) partition mount row in the file so that it points to the new disk/partition name. If any other partitions were changed they will need to be updated as well. For example, changed from:
/dev/<old root disk> / ext3 defaults 1 1
to:
/dev/disk/by-id/<new root disk> / ext3 defaults 1 1
The 3rd through 6th column may vary from the example. The important aspect is to change the row that is root (/) on the second column and adjust in particular the first column to reflect the new root disk/partition. Save and exit after making needed changes.
The 3rd through 6th column may vary from the example. The important aspect is to change the row that is root (/) on the second column and adjust in particular the first column to reflect the new root disk/partition. Save and exit after making needed changes.
6. Lastly, run the following command to rebuild the ramdisk to match updated information:
# mkinitrd
7. 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 first.
Additional Information
The range of environments that can impact the necessary steps to migrate a root filesystem makes it near impossible to cover every case. Some environments could require tweaks in the steps needed to make this migration a success. As always in administration, have backups ready and proceed with caution.
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:29-Dec-2021
-
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com
Run SAP
SUSE for Public Cloud
Security
