Micha's Blog

Background

My server was provisioned by Contabo as a Debian 9 server with a traditional MBR partition layout. At some point I did manage to at least split /var and /home off from the root partition, leaving the following layout for many years:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   1.2T  0 disk 
├─sda1   8:1    0   237M  0 part /boot
├─sda2   8:2    0    20G  0 part /
├─sda3   8:3    0    20G  0 part /var
├─sda4   8:4    0     1K  0 part 
└─sda5   8:5    0 259.8G  0 part /home

Recently I upgraded the VPS to have more diskspace, as I was starting to run low and, instead of mucking about with an ever-increasing amount of relatively inflexible extended partitions and symlinks, I decided to figure out a way to convert this layout to LVM which will provide me with flexibility to mange the disk space in the future.

After a bit of research and prototyping all the steps in a local VM, I came up with the following procedure which worked for me.

Note that I did NOT convert the /boot partition and that the disk remains an MBR-partitioned disk.

Before Starting

It is strongly recommended to take a backup and/or snapshot of the server before commencing. A singly mistype or issue during the conversion could lead to full data loss.

Initial Conversion

The first step is to convert sda2 and sda3 to use the Logical Volume Manager (LVM) and move the root and var partitions into that. This requires a multi-step process:

1. Create a temporary LVM Physical Volume (PV) and move the data into it
2. Update the system configuration
3. Reboot the system
4. Remove the original partitions and replace them with a new PV
5. Add the PV to the LVM Volume Group (VG)
6. Remove the temporary PV from the VG

To create the temporary PV, I first needed to increase the size of the extended partition to make use of the new disk space. I used cfdisk for this. Note that there seems to be a bug in the Debian 11 version of cfdisk – when first increasing the size of the extended partition, a message is shown stating the maximum size, but nothing happens. Deleting the size and pressing enter again applies the size last specified.

Next is creating the LVM:

pvcreate /dev/sda6
vgcreate vg1 /dev/sda6
lvcreate -n root -L 8G vg1 && mkfs.ext4 /dev/mapper/vg1-root
lvcreate -n var -L 20G vg1 && mkfs.ext4 /dev/mapper/vg1-var

Now we can copy the data. Note that when copying /var, it is useful to shut down as many services on the server as possible to reduce the data being actively written to the partition. It may be a good idea to run the sync again just prior reboot.

mount /dev/mapper/vg1-root /mnt
rsync -avxq / /mnt/
mount /dev/mapper/vg1-var /mnt/var
rsync -avxq /var/ /mnt/var/

And finally we edit the system configuration:

• vim /etc/fstab
  • point the / and /var mounts to the new LVM volumes
• vim /boot/grub/grub.cfg
  • ensure kernel command line is updated to have “root=/dev/mapper/vg1-root”

fstab:

# / was on /dev/sda2 during installation
#UUID=904300f1-5d90-4c10-908a-b8ac334bd021 /               ext4    errors=remount-ro 0       0
/dev/mapper/vg1-root                      /               ext4    errors=remount-ro 0       0
# /boot was on /dev/sda1 during installation
UUID=9d8415e3-5d47-42e5-b169-ab0f5db14645 /boot           ext4    defaults,noatime        0       1

#UUID=8de1d736-5b9e-44b1-ba6f-34984912889e /var            ext4    errors=remount-ro 0       1
/dev/mapper/vg1-var                       /var            ext4    errors=remount-ro 0       1
UUID=70554039-342d-4035-8182-ece5b032ec5b /home           ext4    errors=remount-ro 0       1

grub.cfg:

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
        set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-a5511b28-0df7-48c2-8565-baeaede58cfa' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod ext2
        insmod lvm
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  9d8415e3-5d47-42e5-b169-ab0f5db14645
        else
          search --no-floppy --fs-uuid --set=root 9d8415e3-5d47-42e5-b169-ab0f5db14645
        fi
        echo    'Loading Linux 6.1.0-0.deb11.21-amd64 ...'
        linux   /vmlinuz-6.1.0-0.deb11.21-amd64 root=/dev/mapper/vg1-root ro rootdelay=10 net.ifnames=0 ixgbe.allow_unsupported_sfp=1 quiet 
        echo    'Loading initial ramdisk ...'
        initrd  /initrd.img-6.1.0-0.deb11.21-amd64
}

Now for the scary part – rebooting. Double-check that all configurations have also been applied to the new partitions and everything has been copied correctly. Make sure you have a way to recover should the system not reboot!

Completing the initial conversion

Assuming the reboot went well, the system should now be running on the new LVM Logical Volumes (LV’s).

Now delete the /dev/sda2 and /dev/sda3 partitions, and create a new LVM PV in their place. Mount it and add it to the volume group, then remove the temporary PV:

vgextend vg1 /dev/sda2
pvmove /dev/sda6
vgreduce vg1 /dev/sda6
pvremove /dev/sda6

Now we can delete the temporary /dev/sda6 partition.

Moving the data

Next we have to move the home partition. Again, this is a multi-step process as we first have to move the data out of the extended partition, then remove the extended partition.

First create a new primary partition, /dev/sda3, large enough to hold the data. Make it a PV and add it to vg1 as before, then copy the data. Note that as before, ideally there should be no active users during the copy and any services which write into users’ home directories should be shut down.

vgextend vg1 /dev/sda3
lvcreate -n home -L 250G vg1 && mkfs.ext4 /dev/mapper/vg1-home
mount /dev/mapper/vg1-home /mnt
rsync -avxq /home/ /mnt/

Now remount the new partition in place of the home partition. It may be better and safer to reboot the system instead to avoid any data loss or corruption, since lazy-unmounting a filesystem can lead to all sorts of edge cases.

umount -l /home && mount /dev/mapper/vg1-home /home

Next we delete all the logical partitions and the extended partition. The free data should now be between sda2 and sda3, which lets us increase the size of sda2. We can now increase the LVM PV to make use of the new space. Once we’ve done that, we can pvmove the data from the temporary Physical Volume and remove it:

pvresize /dev/sda2
pvmove /dev/sda3
vgreduce /dev/sda3
pvremove /dev/sda3

Finally, we can delete the /dev/sda3 partition and add the remaining free space to the LVM Volume Group. From now on it is trivial to manage disk layout using LVM.

Final Layout

After all was said and done, the server ended up with a disk layout as follows:

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0  1.2T  0 disk 
├─sda1         8:1    0  237M  0 part /boot
└─sda2         8:2    0  500G  0 part 
  ├─vg1-root 254:0    0    8G  0 lvm  /
  ├─vg1-var  254:1    0   20G  0 lvm  /var
  └─vg1-home 254:2    0  260G  0 lvm  /home

For now I’ve left the LVM partition at 500GiB, which is double what the old disk was, and gives the various volumes plenty of room to grow.