Changing the partitioning scheme for a rented VPS
“Is it possible to make an arbitrary disk partitioning scheme on a virtual server?” Such a question once arose in my head. I’ll say right away that this is a case when there is no access to the hypervisor (otherwise it would be too easy). At first glance it may seem that the issue is not resolved. In fact, in order to repartition a partition, it must be unmounted. In the case of home computers, use Live {CD, USB} for this. But if you only have ssh? A couple of seconds to think it over - and I found a solution. It seemed that one could calm down: he invented the problem, decided it himself. But then I jokingly asked the same question to my colleague, being sure that he would also have no difficulty in resolving the issue. The results surprised me. After interrogating others, it turned out that all respondents are sure that it is impossible to repartition a disk on a VPS. Only one guy went further and said: “You can, but not the root partition”.
If you also do not know the solution to this problem, or just want to look at an example of implementation - welcome to the article!
By and large, of course, is not required. The server is still working. But perhaps everyone has their own vision of the “correct” breakdown, which may not coincide with what it really is.
My virtual server with CentOS 6.6 x86-64 had the following scheme:
')
In my philosophy, 200 meters to the boot section is waste. I usually use 32 MB (for the love of "round" numbers). This is enough for me to accommodate 4 cores and still remains. It is quite natural that I would like to use the virtual server space more efficiently - remove the excess from / boot, attach to /. And at the same time change the OS. The company that owns the virtual server provides a fixed list of possible operating systems. Unfortunately, it does not have my favorite Gentoo. But ... Does that really mean that I can't use it?
So how to repartition the root partition? Especially for those who did not immediately guess, I left the above tips. Yes, that's right - swap will save us.
Here is a general scheme for those who need only the principle itself and no need for an explanation:
First, disable the swap partition and create a file system on it. Then remove the line about it from / etc / fstab. Now an interesting step - OS relief. It goes without saying that if you already have any data on the server, collect it. However, this is likely to be not enough. In my case, the xvda2 partition (where the swap was) was just over 0.5 GB in size, and the OS I received after creating the server was just over 1.5 GB. A bit lacking. To reduce the size, I cut out all the applications that I knew about and which did not affect the ability to:
If your server has a pre-installed control panel (in “my” company there is an opportunity to immediately get ISPmanager), then there is guaranteed to be a lot of excess for us at the moment. Save the configs if you wish, and then take down all these mail-web ftp-dns-other servers.
But even without a pre-installed body kit for all occasions in the system costs a lot at the moment superfluous. To get a list of all installed programs in the debian form, run:
And in the family of red-capped:
The method is simple: first go through the entire list and delete what you know, then iterate over each item in the list separately and look at its dependencies. Carefully look at the list of applications that will be deleted with the selected one, and check if any of the list items above will affect their removal.
Well, if you have the opportunity to create a backup of your virtual server image at any time and recover from it. Otherwise be doubly careful.
By the way, there are two other ways to slightly improve the place:
- change the size of the partition with / boot first to add the freed space to the place of the swap partition;
- and more extreme cleaning - deleting (or better transferring to another machine) the contents of / usr - all these doc /, man /, time zone files, fonts, and so on. Be careful when performing these actions three times and do not approach them unless absolutely necessary.
But, suppose, you still managed. Copy the entire contents of the current root to a new location. And don't forget to fix the values in / etc / fstab and in the bootloader configuration.
You can also transfer to the new partition and the / boot directory, if you decide to change the size and boot partition (of course, if you have / boot on a separate partition).
There were no problems with Grub2. But Grub legacy (aka Grub 0.97) does not suspect that partition names can be similar to / dev / xvda2. Teach him this. In the file / sbin / grub-install you need to find the line:
And lower:
In my case, these are lines 99 and 105, but I do not exclude that there may be small differences in different distributions.
Replace this part:
In this way:
Now with the installation of grub 0.97 there will be no problems.
If during the removal of programs, installing the bootloader and editing the configuration files, no errors were made, then, after rebooting, you will receive a system that works on one small section. Now it is enough to delete the old root partition (xvda3 in my case) and create a new one at the end of the vacated space. Once again, dragging the root there - we get the ability to change partitions from the very beginning of the disk.
Since I decided to change the OS at the same time, instead of copying the root partition files back and forth, you can immediately create a future OS file system in a new location. Fortunately, Gentoo does not use all these new-fangled graphical installers. In order to settle in a new place, it is enough for her to unpack her suitcases (the archive of the third stage is the minimum OS environment), fix several configs and execute several commands. Unfortunately, I do not know whether a similar approach will work with other distributions.
Be careful when working with sections. The kernel does not know about the changes you have made until you reboot or inform it. You can do this by using the partprobe command from the parted package. But what is interesting is that if CentOS 6.6 x32 managed to do everything without rebooting, then using the same OS version, but 64-bit, it turned out that the partprobe could not inform the kernel about changes in the partition table and had to reboot. Carefully ensure that you always have a boot loader somewhere and its configuration is correct with the current breakdown scheme.
If, when ordering a VPS, you cannot influence the breakdown scheme, this does not mean that you cannot translate your vision of the “correct” scheme on the server. I changed the size of the boot partition, leaving it the necessary minimum and allocating additional MB for more necessary goals. Made two additional sections. And I changed the OS to the one I needed , rather than choosing from those that were offered to me. However, if you decide to repeat - I strongly recommend that you first check with the company providing the server to you - whether the planned changes to your service will affect it. It is possible that some program or script on the physical server serving your VPS relies on well-defined partition tables.
If you also do not know the solution to this problem, or just want to look at an example of implementation - welcome to the article!
Why all this fuss?
By and large, of course, is not required. The server is still working. But perhaps everyone has their own vision of the “correct” breakdown, which may not coincide with what it really is.
My virtual server with CentOS 6.6 x86-64 had the following scheme:
')
# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda3 24G 1,7G 21G 8% / tmpfs 371M 0 371M 0% /dev/shm /dev/xvda1 194M 29M 156M 16% /boot # free -m ... Swap: 511 0 511 In my philosophy, 200 meters to the boot section is waste. I usually use 32 MB (for the love of "round" numbers). This is enough for me to accommodate 4 cores and still remains. It is quite natural that I would like to use the virtual server space more efficiently - remove the excess from / boot, attach to /. And at the same time change the OS. The company that owns the virtual server provides a fixed list of possible operating systems. Unfortunately, it does not have my favorite Gentoo. But ... Does that really mean that I can't use it?
The answer to the main question of life, the universe and this article
So how to repartition the root partition? Especially for those who did not immediately guess, I left the above tips. Yes, that's right - swap will save us.
Here is a general scheme for those who need only the principle itself and no need for an explanation:
- getting rid of swap - we get a free partition;
- we create on it FS;
- we facilitate the current root partition to the size of the FS on the former swap;
- copy data to a new section;
- transfer the boot partition;
- we turn as we wish the vacated sections;
- if necessary, repeat the actions to transfer the root to full satisfaction.
How to do all this?
First, disable the swap partition and create a file system on it. Then remove the line about it from / etc / fstab. Now an interesting step - OS relief. It goes without saying that if you already have any data on the server, collect it. However, this is likely to be not enough. In my case, the xvda2 partition (where the swap was) was just over 0.5 GB in size, and the OS I received after creating the server was just over 1.5 GB. A bit lacking. To reduce the size, I cut out all the applications that I knew about and which did not affect the ability to:
- server load;
- changes to sections;
- creating FS;
- work with the network;
- connect via SSH.
If your server has a pre-installed control panel (in “my” company there is an opportunity to immediately get ISPmanager), then there is guaranteed to be a lot of excess for us at the moment. Save the configs if you wish, and then take down all these mail-web ftp-dns-other servers.
But even without a pre-installed body kit for all occasions in the system costs a lot at the moment superfluous. To get a list of all installed programs in the debian form, run:
# dpkg --list And in the family of red-capped:
# yum list installed The method is simple: first go through the entire list and delete what you know, then iterate over each item in the list separately and look at its dependencies. Carefully look at the list of applications that will be deleted with the selected one, and check if any of the list items above will affect their removal.
Do not overdo it!
I was so fascinated by the cleaning of the system that I myself did not notice how I was left without any text editor. Since I was too lazy to re-install them, I had to edit all the configuration files with sed. Feelings were ... interesting.
Well, if you have the opportunity to create a backup of your virtual server image at any time and recover from it. Otherwise be doubly careful.
By the way, there are two other ways to slightly improve the place:
- change the size of the partition with / boot first to add the freed space to the place of the swap partition;
- and more extreme cleaning - deleting (or better transferring to another machine) the contents of / usr - all these doc /, man /, time zone files, fonts, and so on. Be careful when performing these actions three times and do not approach them unless absolutely necessary.
But, suppose, you still managed. Copy the entire contents of the current root to a new location. And don't forget to fix the values in / etc / fstab and in the bootloader configuration.
You can also transfer to the new partition and the / boot directory, if you decide to change the size and boot partition (of course, if you have / boot on a separate partition).
There were no problems with Grub2. But Grub legacy (aka Grub 0.97) does not suspect that partition names can be similar to / dev / xvda2. Teach him this. In the file / sbin / grub-install you need to find the line:
tmp_disk=`echo "$1" | sed -e 's%\([shv]d[az]\)[0-9]*$%\1%' \ And lower:
tmp_part=`echo "$1" | sed -e 's%.*/[shv]d[az]\([0-9]*\)$%\1%' \ In my case, these are lines 99 and 105, but I do not exclude that there may be small differences in different distributions.
Replace this part:
[shv]d In this way:
x[shv]d Now with the installation of grub 0.97 there will be no problems.
If during the removal of programs, installing the bootloader and editing the configuration files, no errors were made, then, after rebooting, you will receive a system that works on one small section. Now it is enough to delete the old root partition (xvda3 in my case) and create a new one at the end of the vacated space. Once again, dragging the root there - we get the ability to change partitions from the very beginning of the disk.
Since I decided to change the OS at the same time, instead of copying the root partition files back and forth, you can immediately create a future OS file system in a new location. Fortunately, Gentoo does not use all these new-fangled graphical installers. In order to settle in a new place, it is enough for her to unpack her suitcases (the archive of the third stage is the minimum OS environment), fix several configs and execute several commands. Unfortunately, I do not know whether a similar approach will work with other distributions.
Change sections
Be careful when working with sections. The kernel does not know about the changes you have made until you reboot or inform it. You can do this by using the partprobe command from the parted package. But what is interesting is that if CentOS 6.6 x32 managed to do everything without rebooting, then using the same OS version, but 64-bit, it turned out that the partprobe could not inform the kernel about changes in the partition table and had to reboot. Carefully ensure that you always have a boot loader somewhere and its configuration is correct with the current breakdown scheme.
What is the result?
If, when ordering a VPS, you cannot influence the breakdown scheme, this does not mean that you cannot translate your vision of the “correct” scheme on the server. I changed the size of the boot partition, leaving it the necessary minimum and allocating additional MB for more necessary goals. Made two additional sections. And I changed the OS to the one I needed , rather than choosing from those that were offered to me. However, if you decide to repeat - I strongly recommend that you first check with the company providing the server to you - whether the planned changes to your service will affect it. It is possible that some program or script on the physical server serving your VPS relies on well-defined partition tables.
Source: https://habr.com/ru/post/257269/
All Articles