Replacing root filesystem: from sdb2 to /dev/mapper/system-r

Hello everybody,

I need your help again. We want to replace a filesystem into another- so far no problem. The main problem is, that we want to replace the root “/” filesystem from sdb2 into /dev/mapper/system-root.

I tried it already with yast to replace the other paths and it worked perfectly. It just dont want to replace root “/”. Is it possible to replace root with /dev/mapper/system-root? Umount “/” wouldn’t working and will shut the system down :smiley:

Thank you in advance.
kind regards,


Hi Lordig,

you didn’t specify which other file systems you were able to move “live” - I guess it wasn’t /usr then :wink:

My recommendation is to reboot from media into maintenance mode, so that no processes are accessing the on-disk root, and then to move the content of you old root fs to the new one (and don’t confuse the “rescue” system’s root fs (ramdisk) with your on-disk root fs :wink: ). You’ll have to make a few adjustments after that, especially /etc/fstab and concerning your initrd - are you familiar with that?


Hello jmozdzen,

thank you for your reply…and sorry I dont really understand it. Is it possible to do that at the beginning of installment of SLES? I tried it out to install it on the btrfs device: /dev/mapper/system-root, but after reboot the system doesn’t boot properly and stuck. I dont even could resize the sdb2 device from 40 Gb to 100 Gb. 40Gb ist max, but we still owe about 350Gb of free space.

Could you please tell me the steps to resolve that issue? I’m not really good to preform on SLES. I only know the basics :frowning:


Hi Lordig,

replacing the root file system isn’t for the faint of heart - so IMO knowing only the basics of Linux isn’t the perfect starting point for this operation.

The alternatives I see are a - reinstall the server, with your new choice of file system /partition layout or b - get someone with sound SLES / Linux experience to assist you. I know that option a may be out of the question, but wanted to mention it anyhow.

Nobody knows this from birth, but gotta learn it - so let me point out some of the basics of this operation you’re after. It’s from memory and I did not have to do this in quite a while, so there may be quicker/other/better ways for some of the steps:

  • the root file system is special in two regards: First of all, it will always have open file handles or mounts, which will keep the system from changing it’s underlaying partition or relocating it wheile the system is “live” - you’ll usually reboot from external media, with sorts of a “rescue system” that offers a basic environment for maintenance tasks, but uses RAM for its own, temporary root file system. Secondly, the root file system needs to be known to the boot loader environment, so that the boot loader will know where to load the system from. So if you relocate the root fs to a different device (as opposed to simply resizing it), you’ll have to make sure the boot loader knows about the new root fs.

  • it seems you’re about to move your whole system from partition-based disk layout to LVM. I second that , as LVM is much more flexible in future maintenance, i. e. live disk replacement, volume resizing and others.You seem to have started that process already (“I tried it already with yast to replace the other paths and it worked perfectly”), so I’d be interested to know how your actual current partition layout and PV / LV structure is: You say you have 350 GB free space on the disk, is that actualy free space or space allocated to LVM, but not yet used there?

  • While still running your server, you should prepare a new logical volume (LV) to carry the new root FS, and prepare it file system wise.

  • The installation media for your current SLES 12 version should offer you an option to boot into a rescue environment. (I’ve not booted SLES from ISO in quite a while, so I cannot tell you the action steps - but look for “rescue mode” or alike in the boot option menu, when booting the SLES12 media).

  • once in rescue mode, you’ll need to active the volume group that carries the LV for your new root fs (vgchange -ay ) and mount bot the old and the new root fs in parallel - i.e. to /mnt/ and /mnt2/ (you#ll likely have to mkdir /mnt2)

  • use i.e. “tar” to create a 1:1 copy of the files from your old root fs on the new root fs (tar -C -cf- . | tar -C -xvf-)

  • bind-mount the rescue system’s dynamic file systems (/proc, /sys, /dev) to your new root fs (i.e “mount -o bind /dev /mnt2/dev”) - this will later allow the “chroot environment” to access current hardware information

  • once all mounts are done, “chroot /mnt2” (or where-ever your new root fs is mounted) to simulate and environment close to the running server"

  • inside that chroot shell, edit /etc/fstab to point / to your new root fs (and if BtrFS, all subvols accordingly)

  • “mkinitrd” to create a new boot environment, incorporating thie information about the new root fs

  • trace back your steps (exit chroot, umount all mounts, vgchange -an to be on the safe side) and reboot the server

  • check that it is coming up correctly, using the desired new root fs.

Again - much can go wrong and you should be confident to handle such situations - so above steps are for an experienced admin. And as usually: You should have a working backup of your server, since even complete data loss may happen if doing something awfully wrong.

If you have no access to an experienced SLES / Linux admin, your best option might be to reinstall the server, this time creating the desired LVM setup from start.