This is my root volume, it is 32GB and contains /boot, and on LVM LV's are / and swap.

sdb                           8:16   0 29.8G  0 disk 
├─sdb1                        8:17   0  200M  0 part /boot/efi
├─sdb2                        8:18   0  256M  0 part /boot
└─sdb3                        8:19   0 29.4G  0 part 
  ├─AntergosVG-AntergosRoot 254:0    0 26.4G  0 lvm  /
  └─AntergosVG-AntergosSwap 254:1    0    3G  0 lvm  [SWAP]

I want to clone this onto a larger SSD. Is the following the correct procedure? I will be using another computer so my original computer won't have both old and new disks inside it at the same time

  1. dd, where if=old_ssd and of=new_ssd
  2. Increase the size of partition sdb3 (LVM PV) to fill up the new space using gparted
  3. Boot into the new system, the use lvresize to expand AntergosRoot to the entire space of the newly resized PV
  4. Resize the (ext4) filesystem of / to the entire space of the previously resized LV

My main problem is I don't know which commands to use, and secondly, when resizing the LV AntergosRoot, will the swap volume cause it to become non-contiguous?


You're missing a step. After resizing the sdb3 partition and booting into the new system, you'll need to use the pvresize command to tell LVM that it is allowed to use the new space within the extended sdb3.


2.5. Boot into the new system, then pvresize /dev/sdb3

In step 3, I would generally prefer using lvextend instead of lvresize - just as a failsafe: if I would accidentally mistype the new size, lvresize might shrink the LV rather than extend it, while lvextend would just tell me that the specified new size is smaller than the current one. Safer that way.

But if you want to use all the new space immediately, you could do it like this:

  1. lvextend -l +100%FREE /dev/mapper/AntergosVG-AntergosRoot

Step 4 is quite simply:

  1. resize2fs /dev/mapper/AntergosVG-AntergosRoot

All these steps (2.5 ... 4) can be done while the root filesystem is mounted and writeable.

And yes, the root filesystem would become physically non-contiguous on the disk - but that's not a problem: when viewed as a LVM LV, it is accessible as a contiguous set of block numbers, and LVM hides the jump over the swap partition. And in terms of performance, a single discontinuity is not much of an issue at all.

If there's an actual requirement to keep a LV physically contiguous on disk, you can set lvchange -C y <name of LV> to tell that to the LVM. But then, you cannot extend the LV as easily: you would have to ensure that there is free space after the current tail end of the LV (using pvdisplay --maps and, if necessary, pvmove to rearrange things) before extending. In most cases, this is not necessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.