13

I have a server with Debian that have 3 physical partitions covering all the disk: boot, root y swap. Now I want to replace that partitions with LVM partitions. I know how install Debian with LVM at beginning, but in this case I can't install the system at beginning because the provider gets me a server with remote access and the system installed in this way.

How can I change that partitions using only an ssh connection and possibly other remote server where to put some temporal data?

1
  • 2
    Note to close-voters: This is not a dupe of the referenced question because there is a twist here: fully remote.
    – sysadmin1138
    Dec 14, 2012 at 23:25

5 Answers 5

1

You can't possibly replace them on a running server with only /, /boot and <swap> partitions. The only way to do it is to unmount the / partition, shrink it and create a new LVM partition at the end, but as you only have remote ssh access, you can't possibly shrink a live, mounted partition without data corruption.

3
  • 3
    It is possible to resize an ext3 filesystem while it is mounted: linux.die.net/man/8/ext2online . Dec 14, 2012 at 22:05
  • 8
    Never say never...
    – the-wabbit
    Dec 14, 2012 at 23:56
  • Indeed. Plenty of solutions in the other answers. Next time, wait at least 24 hours before accepting "it cannot be done". Feb 15, 2022 at 10:38
22

A quick update from my side. Context: today I got online a dedicated server installed with physical partition scheme instead of LVM. There were 3 partitions:

/boot (ext4) - 512M / (ext4) - 730G swap - 8G

Due to the nature of not having console access the final goal was the convert the existing root partition to LVM.

Considering the ext4 is not shrinkable the only way was to reuse the swap partition as temporary root. I also decided to set up the temporary root with LVM to be sure the process can work in the right way.

First turned out the swap:

swapoff -a

Then resized the partition via parted (originally it was started from 742 to 750):

parted
resize 3 742 744

and created a partition for the LVM:

mkpart primary ext2 744 750
set 4 lvm on

PV/VG/LV/filesystem creation for the temp root:

pvcreate /dev/sda4
vgcreate VolGroup00 /dev/sda4
lvcreate -L 5.73G -n tmproot VolGroup00
mkfs.ext4 /dev/VolGroup00/tmproot

Next step was to copy the root to the temporary place:

mount /dev/VolGroup00/tmproot /media
rsync -ravzxq / /media/

Once everything was there then the entry for the root filesystem in /media/etc/fstab had to be changed as well:

/dev/VolGroup00/tmproot /                       ext4    defaults        1 1

Almost there, the last and let say the most unwanted part without console access was to modify the /boot/grub/grub.conf:

original entry:

title CentOS (2.6.32-279.22.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=UUID=e769af21-d9e1-455f-a6a7-7a9c84d8cbea rd_NO_LUKS LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=hu rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-279.22.1.el6.x86_64.img

modified entry:

title CentOS (2.6.32-279.22.1.el6.x86_64) LVM
insmod lvm
kernel /vmlinuz-2.6.32-279.22.1.el6.x86_64 ro LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=hu SYSFONT=latarcyrheb-sun16 crashkernel=auto dolvm root=/dev/mapper/VolGroup00-tmproot panic=10 
#rd_NO_DM rd_NO_MD rd_NO_LUKS
initrd /initramfs-2.6.32-279.22.1.el6.x86_64.img

Just to be on the safe side: insmod lvm was added along with the dolvm parameter for the kernel and the root path was also changed to root=/dev/mapper/VolGroup00-tmproot. Important to use the /dev/mapper/ path at this time. As a safty deposit I also added the panic=10 parameter and didn't change the default boot entry in the header. Instead of that I went for a try with telling the grub to boot with the new setting only one time and in case of failure the original entry could work:

grub
savedefault --default=1 --once

And finally:

reboot

It was OK for me at the first time so I repeated the whole procedure with creating a new volume group on top of the original root partition and finally I got the root at the right place using LVM.

Hope this helps.

2
  • 1
    This worked very well for me converting my 2 disk raid 1 setup to LVM on raid 1 fully remote (had some spare disks pre-installed). In grub2 though the new way to reboot to a menu entry just once is to first edit your /etc/default/grub file to make sure GRUB_DEFAULT=saved. Then update-grub. Then you run grub-reboot # to set the menu item to use for the next reboot only. Then you can reboot.
    – casey
    Apr 17, 2013 at 23:29
  • 1
    Ubuntu (and debian) has its own system for modifying grub configuration. Updating root partition in it can be done cleaner in a manner specified here: unix.stackexchange.com/a/5318/192211
    – EFraim
    Jan 6, 2020 at 9:41
4

Nothing is impossible in Linux, but you would have to be determined and crazy to attempt what you describe. Keep in mind that if you only have SSH access, there's a good chance that you will lose access to the server if you make a mistake. If you have a remote "serial" console and virtual power switch, that could help a bit. That said, if you have a brand new installation with no data to lose, why not try it? I found a tutorial to remotely convert a Linux system to RAID1; the steps you would attempt for LVM would be analogous.

First, let's consider the necessity of temporary storage space. Assuming you don't have a second disk on the server, you could shrink the existing partitions using parted. Of course, this requires that your boot and root partitions use less than half of the disk, and they must use a shrinkable filesystem. (XFS and JFS, for example, are not shrinkable.)

After shrinking your existing partitions, you can create an LVM physical volume in the freed space, a volume group and logical volumes inside it. Replicate your filesystems. (When replicating your root filesystem, you should kill everything except sshd, and ideally be in single-user mode. You will probably have to use rsync rather than dd since you are replicating a mounted filesystem.)

Then, you would prepare an initrd with LVM support and tell GRUB to boot into the new system, as described in Warren Togami's tutorial. Once you do that, it's a simple matter to delete the old filesystems using parted and growing the LVM volumes.

Good luck! Let us know if it worked!

3

I have previously migrated my root partition "/" that was pointing to a disk partition "/dev/sda2" with 10G on centos 6 to a LV partition, the steps performed were the following :

  • Add a hard disk on VMware of 10G.
  • recognize the disk without reboot the system.
ls /sys/class/scsi_host/| while read x ; do echo "- - -" > /sys/class/scsi_host/${x}/scan ; done
  • Create a partition on the new disk, lets suppose my new disk is /dev/sdb
  • Working with :
fdisk /dev/sdb
  • Being in the "fdisk" interface lets create a partition with the key "n" assigning +9G of capacity, then change the type partition with key "t" assigning "8e" (lvm partition) and finally key "w" to apply changes, if u wanna see how looks partition table u can press key "p".
  • once the partition is been created, we can validate that the device is been created with the following command ( the command works when the disk is not been used):
partprobe /dev/sdb
  • once the device physically exits, lets create the LVM objects on the following order :
pvcreate /dev/sdb1
vgcreate vg_root /dev/sdb1
lvcreate -v -n lv_root vg_root -L 9G
  • once the LV units have been created, lets assign a FS and mount it to the current system.
mkfs -t ext4 /dev/vg_root/lv_root
mkdir /mnt/new_root/
mount -t ext4 /dev/vg_root/lv_root /mnt/new_root/
  • if you dont know what's the FS of ur current partition it can be find out with commands such as :
df -lhT
cat /etc/fstab
blkid
  • when the new LV is been mounted we can proceed to copy all the files of the system.
find / -xdev | cpio -pmvd /mnt/new_root/
  • once the files are been copied we can proceed to change the "chroot" but before lets mount some partitions :
cd /mnt/new_root/
mount -t proc /proc proc
mount -t sysfs /sys sys/
mount --rbind /dev dev/
  • lets now change the chroot
chroot /mnt/new_root/
  • once we are in the new root modify the file :
vi /etc/fstab
  • leaving the file almost similar to :
#UUID=98dd25ba-feed-4ddb-80be-5e2d1ab2bdaa /                       ext4    defaults        1 1
/dev/mapper/vg_root-lv_root /           ext4    defaults        1 1
  • Once the file is been properly modified, lets create a file in the root with the name "./autorelabel" just in case ure working with SELINUX "enforcing" or "permissive".
touch ./autorelabel
  • Lets now leave from the chroot environment of /mnt/new-root
exit
  • If changes are been done based on ur scenario, lets perform one of the last changes, that is modify the grub file "/boot/grub/grub.conf", adding a new menu (do not modify ur current boot option til the new one added works correctly).
# before
title CentOS 6 (2.6.32-573.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-573.el6.x86_64 ro root=UUID=98dd25ba-feed-4ddb-80be-5e2d1ab2bdaa rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
        initrd /initramfs-2.6.32-573.el6.x86_64.img

# now
title CentOS 6 (2.6.32-573.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-573.el6.x86_64 ro root=UUID=98dd25ba-feed-4ddb-80be-5e2d1ab2bdaa rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
        initrd /initramfs-2.6.32-573.el6.x86_64.img

title CentOS 6 (2.6.32-573.el6.x86_64-lvroot)
        root (hd0,0)
        insmod lvm
        kernel /vmlinuz-2.6.32-573.el6.x86_64 ro dolvm root=/dev/mapper/vg_root-lv_root rd.lvm.lv=vg_root/lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
        initrd /initramfs-2.6.32-573.el6.x86_64.img

# the line added was 
title CentOS 6 (2.6.32-573.el6.x86_64-lvroot)
        root (hd0,0)
        insmod lvm
        kernel /vmlinuz-2.6.32-573.el6.x86_64 ro dolvm root=/dev/mapper/vg_root-lv_root rd.lvm.lv=vg_root/lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
        initrd /initramfs-2.6.32-573.el6.x86_64.img
  • Once changes on grub file are been done, lets finish regenerating a new initrd iso file :
cd /boot
cp -av initramfs-$(uname -r).img initramfs-$(uname -r).img.old
dracut -f
  • finally a reboot :
init 6
# or
reboot
  • Once the grub menu appears, choose the new one added "CentOS 6 (2.6.32-573.el6.x86_64-lvroot)" and validate that it is working properly.
  • If the system is working properly and not using the "/dev/sda", it can be removed and detach from ur VM or physic server.
dd if=/dev/zero of=/dev/sda bs=1
  • Last steep set as default entry the new item added on the grub menu "/boot/grub/grub.conf":
#default=0
default=1

Hope the information previously provided gonna helpful for someone.

thanks in advance,

Manuel Lazo

2

He could setup an intermediate rescue system into the (previously disabled) swap partition (nerve wrecking work to do if you dont have a RAC in the machine) and work from there. Also, online resize tools exist for certain filesystems, and then shrinking the partition afterwards and rebooting is a case of KWYD but possible.

2
  • To describe two even more crazy ideas that would even work with literally just ONE partition on the disk: a) create a big empty file on the root partition making sure it is contigously allocated, work on it via the loopback driver... then munge the partition table to have the partition start at the physical first block of that file. b) chroot (or even pivot_root if still possible) yourself into a ramdisk and set up a base and backup there... nuke the actual root filesystem under you. Dec 14, 2012 at 9:48
  • Done that once about 20 years ago. A few years later, with good broadband, I found it more convenient to upload a disk image prepared in a VM. Having a network card in the remote machine that is also available as a virtual card in qemu probably made things easier. Feb 15, 2022 at 10:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .