2

I have a Remote Dedicated Server with no Online control panel to resize partitions after initial OS install, so I am using the debian based rescue environment to manipulate the partitions unmounted. Problem is, I am a bit stupid when it comes to Partition manipulation on remote drives, I have tried using GNU Parted command line tool, since GParted isn't an option, and fdisk is useless since the drive is formatted with GPT, only to find out the resize command has been removed as of version 2.4. So, Below is a list of my partitions from the print command of parted:

Number  Start   End     Size    File system     Name     Flags
1      20.5kB  1049kB  1029kB                  primary  bios_grub
2      2097kB  21.0GB  21.0GB  ext4            primary
3      21.0GB  2000GB  1979GB  ext4            primary
4      2000GB  2000GB  536MB   linux-swap(v1)  primary

What I need to figure out, is how to shrink #3 to about 1.2TB and then expand the #2 to fill what was moved when #3 was shrunk. My #2 Partition is full, and the #3 partition has space to spare.

2 Answers 2

1

Doing what you want might or might not be possible, depending on what is (and must be) currently mounted, and whether you can boot from some other medium to work around mount problems. Factors to consider here:

  • Always keep in mind the distinction between a partition (a simple data structure that defines the start and end point of a chunk of disk space, typically along with other things like a type code) and a filesystem (a more complex data structure that's held within a partition or another container, such as an LVM's logical volume). If you don't already fully understand this distinction, stop now and research it.
  • You can increase the size of a mounted ext2/3/4 filesystem, but AFAIK you cannot decrease the size of a mounted ext2/3/4 filesystem. The resize2fs utility does this job from the command line.
  • To resize a partition, you may have to delete the partition and create a new one in its place. The start and end points may need to be specified with sector-level precision, which parted does not provide by default. You need to set unit s to get this; or you can use gdisk, which provides sector-level precision by default. (Even gdisk, though, automatically aligns partitions to 2048-sector values by default, so you may need to adjust alignment with the d option on the experts' menu.)
  • Filesystem-resize operations typically leave the start point of the filesystem unchanged. Thus, if you need to move the start point of a partition, you must do so by using dd or some other tool to move the entire contents of the filesystem. Depending on the direction of the movement, this may need to be done before or after you delete the original partition, and the new one may need to be created before or after the move. If the move operation overlaps the original location, you must be very careful about how you do this, lest you destroy some partition data!
  • Be very careful about partition and filesystem end points. If you shrink a filesystem and then re-create a new partition that's just a little too small, you can end up trashing important data. I recommend shrinking the filesystem smaller than you intend, creating a new partition, and then using resize2fs to grow the filesystem to the size of the new surrounding partition. This procedure minimizes the chances of getting a size mis-match.
  • Remember that you may need to reboot after you change the partition table to get the kernel to use the new table.

Because of these issues, attempting to do what you want without the help of GParted or some other tool designed to coordinate partition and filesystem changes can be extremely risky. It can be done, but one slip-up in specifying a sector value can leave you with a disk that's totally worthless. The fact that you're asking for help about this makes me wary about suggesting you even make the attempt; the risk of trashing a production system is just too great for somebody who's never before done this sort of thing. If you have no other option, I strongly recommend you re-create your server locally and practice on the copy before you try it on your remote server.

You might want to consider some alternatives:

  • Use GParted -- If you can boot from an external medium, you can use GParted. You say this is a remote server. Many such systems provide a BMC that enables you to attach virtual USB drives and see a virtual console via a Java applet. Using this feature will be extremely slow, but should enable you to run GParted and make your changes much more easily and safely.
  • Create additional partitions -- You may be able to shrink one partition and then, rather than move and grow the other, create a new partition. You'd then move data from a subdirectory to the new partition and mount it in place of that subdirectory. This approach basically splits the difference; you must still shrink one partition, but you avoid the need to do the more dangerous and difficult move operation.
  • Use symlinks -- You may be able to accomplish your goals by splitting off some files from your too-full partition to the less-full one and then using symbolic links to make them accessible on their desired paths. This is likely to be the safest approach.
  • Reinstall -- If you have adequate backup, you could back up the system, re-install with a better setup, and restore your original data.
  • Do it on-site -- If you have physical access to your servers, or if you've got on-site help, you (or your help) can do it in person much as you would with a desktop system, using an Ubuntu installation USB flash drive. Depending on how important this is and where the server is relative to you, it might even be worth a trip to do the job.
  • Add a disk -- You might consider adding a disk, if that's an option, and moving some of your data to it.

In the future, you might want to consider using Logical Volume Management (LVM), which makes these sorts of manipulations much simpler and safer. LVM has a significant learning curve, but once you've got the basics down, it helps a lot because you need not worry about moving partitions; filesystems are stored like files in a filesystem, so once you shrink one, you can expand another into the free space without changing the start point. LVM also helps you add space in the form of new disks.

3
  • Unfortunately, out of The Alternatives you suggested, reinstall is the only option I can use, since this machine is from a dedicated hosting provider, and I won't have the option for on-site access. I AM booted into a rescue system which will allow me to do what I need to do with the partitions, since they are unmounted in this state. I understand that one slip-up could destroy my HDD, but I will have to take that risk...I have already backed up my sql tables, and all of my configuration files from my programs, so if I have to reinstall, I can...But ONLY as a last resort Oct 18, 2015 at 16:14
  • I also just installed LVM on my server...I don't know what that will do, but you mentioned that would be easier Oct 18, 2015 at 16:28
  • Adding the LVM packages to an already-installed system will do no good whatsoever. LVM is used as an alternative to traditional partitions, so you've got to re-install to use it. That's why I said you might want to consider it in the future.
    – Rod Smith
    Oct 19, 2015 at 15:44
0

As a temporary fix, from an article I read. It seemed that %70 of the space being used was coming from the webserver, specifically /var/www. so what I did was:

cd /var
mv www /home
ln -s /home/www www
ll
lrwxrwxrwx  1 root root      9 Oct 18 12:33 www -> /home/www/

Like I said, A temporary fix, but my root directory is now only %30 full instead of %100. so, until I can resize the partitions, this will work.

You must log in to answer this question.

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