Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Note to close-voters: This is not a dupe of the referenced question because there is a twist here: fully remote. – sysadmin1138 Dec 14 '12 at 23:25
up vote 0 down vote accepted

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.

share|improve this answer
It is possible to resize an ext3 filesystem while it is mounted: . – 200_success Dec 14 '12 at 22:05
Never say never... – the-wabbit Dec 14 '12 at 23:56

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):

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:

savedefault --default=1 --once

And finally:


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.

share|improve this answer
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 '13 at 23:29

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.

share|improve this answer
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. – rackandboneman Dec 14 '12 at 9:48

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!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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