Increase /root Partition in CWP?

Is there a way in CWP to edit partitions and resize? I have a 100% full /root and it's causing issues. I rebooted and it's still full. I want to increase it from 7oGB to 200GB? If not in CWP how to do this cli on Almalinux 8.10.

CWP is webhosting control panel. It doesn't have any tools to manage disk partitions because in most cases such tasks can be done in "rescue mode"/"single user mode". If you need to resize partitions then use linux tools like parted, lvm, etc. However, I recommend you to read docs and tutorials before you make any changes because you could kill the system and make it unbootable.

I found the following but it doesn't seem to 100% follow with Almalinux 8.10 and it's kind of scary hehe. I did a snapshot just now before I try anything. I wish there was a way to get a gparted gui from cli remotely as it is a vps account on Contabo.


To increase the size of the root partition from the command line (CLI), you typically need to use the fdisk command to modify the partition size, then use resize2fs to resize the filesystem within that partition, ensuring your system is using Logical Volume Management (LVM) if applicable to simplify the process. 

Key steps:
Check current partition size:
Use df -h / to see the current size of your root partition. 

Access disk partition editor:
Without LVM: Run sudo fdisk /dev/sda (replace "sda" with your disk identifier from fdisk -l). 

With LVM: Identify the logical volume associated with your root partition using vgdisplay and lvdisplaycommands. 

Modify partition size:
In fdisk:1

Press 'p' to view partitions. 

Select the partition you want to resize using the partition number. 

Use the 'n' command to create a new partition or extend the existing one. 

Press 'w' to write changes and exit. 

Resize filesystem:
Run sudo resize2fs /dev/sdX(replace "sdX" with the device name of your root partition). 

Important considerations:
Backup data: Always back up your system before making significant partition changes. 

LVM usage: If your system uses LVM, use commands like lvextend to expand the logical volume associated with your root partition. 

Reboot: Depending on your system configuration, you might need to reboot after resizing the partition.

I have to do this periodically when my customers run their disk usage up -- constant upward growth in disk space due to never emptying trash, hoarding e-mails, etc. That's a decent guide you posted, but more details can be necessary. Good to test on a local copy before you commit to doing it on a remote VM. And yes, always snapshot first, and/or a full backup image of your VM!

[root@viking ~]# df -h /
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/almalinux-root   70G   70G   20K 100% /

[root@viking ~]# fdisk -l
Disk /dev/sda: 1.6 TiB, 1717986918400 bytes, 3355443200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x064e8d9a

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sda1  *       2048    2099199    2097152    1G 83 Linux
/dev/sda2       2099200 3355443199 3353344000  1.6T 8e Linux LVM

Disk /dev/mapper/almalinux-root: 70 GiB, 75161927680 bytes, 146800640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/almalinux-swap: 23.6 GiB, 25375539200 bytes, 49561600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/almalinux-home: 1.5 TiB, 1616371515392 bytes, 3156975616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@viking ~]# df
Filesystem                  1K-blocks     Used  Available Use% Mounted on
devtmpfs                     24564712        0   24564712   0% /dev
tmpfs                        24583732        0   24583732   0% /dev/shm
tmpfs                        24583732   305664   24278068   2% /run
tmpfs                        24583732        0   24583732   0% /sys/fs/cgroup
/dev/mapper/almalinux-root   73364480 73364460         20 100% /
/dev/sda1                     1038336   347532     690804  34% /boot
/dev/mapper/almalinux-home 1577717064 50447700 1527269364   4% /home
tmpfs                         4916744        0    4916744   0% /run/user/1002
tmpfs                         4916744        0    4916744   0% /run/user/0


I don't have partition names and numbers like this tut is talking about.

Your system uses LVM. Therefore you need to follow the steps from the tutorial marked as "With LVM". However, I don't recommend you to make any changes on the production server if you resize the partitions the first time.

It is better to setup a VPS for testing purposes and try to resize partitions there. You must understand what you do before you make any changes. It is very very danger operation.

One system I manage uses traditional partitions, therefore fdisk and growpart are needed:
https://thelinuxcode.com/extend-xfs-filesystem-linux-without-lvm/


But other systems I manage use LVM, so this is a good guide:
https://sleeplessbeastie.eu/2020/04/22/how-to-expand-an-existing-xfs-filesystem-on-lvm-logical-volume/

[root@viking ~]# ls -lh
total 68K
-rw-------.  1 root root 1007 Aug  6 03:03 anaconda-ks.cfg
-rw-r--r--   1 root root  735 Nov 18 23:34 cron
drwxr-xr-x  81 root root 4.0K Dec  9 05:12 node_modules
-rw-r--r--   1 root root  105 Dec  9 05:12 package.json
-rw-r--r--   1 root root  40K Dec  9 05:12 package-lock.json
-rw-r--r--   1 root root 3.0K Dec  9 05:12 server.js
-rw-r--r--.  1 root root 1.1K Aug  6 03:15 viking.dratgocom.xyz.csr
-rw-------.  1 root root 1.8K Aug  6 03:15 viking.dratgocom.xyz.key.org


[root@viking ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
devtmpfs                     24G     0   24G   0% /dev
tmpfs                        24G     0   24G   0% /dev/shm
tmpfs                        24G  2.3G   22G  10% /run
tmpfs                        24G     0   24G   0% /sys/fs/cgroup
/dev/mapper/almalinux-root   70G   70G   20K 100% /
/dev/sda1                  1014M  340M  675M  34% /boot
/dev/mapper/almalinux-home  1.5T   49G  1.5T   4% /home
tmpfs                       4.7G     0  4.7G   0% /run/user/0
tmpfs                       4.7G     0  4.7G   0% /run/user/1002

I am trying to find safe stuff in /root I can delete to make enough room to install gparted. I can get in ssh and vnc both but I am not sure what is safe to delete. I can't install anything or update because I get an error that it's full.

One system I manage uses traditional partitions, therefore fdisk and growpart are needed:
https://thelinuxcode.com/extend-xfs-filesystem-linux-without-lvm/


But other systems I manage use LVM, so this is a good guide:
https://sleeplessbeastie.eu/2020/04/22/how-to-expand-an-existing-xfs-filesystem-on-lvm-logical-volume/

[root@viking ~]# sudo pvs
  PV         VG        Fmt  Attr PSize PFree
  /dev/sda2  almalinux lvm2 a--  1.56t    0
[root@viking ~]# sudo lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                  8:0    0  1.6T  0 disk
├─sda1               8:1    0    1G  0 part /boot
└─sda2               8:2    0  1.6T  0 part
  ├─almalinux-root 253:0    0   70G  0 lvm  /
  ├─almalinux-swap 253:1    0 23.6G  0 lvm  [SWAP]
  └─almalinux-home 253:2    0  1.5T  0 lvm  /home
[root@viking ~]# sudo pvcreate /dev/sdb
  No device found for /dev/sdb.
[root@viking ~]#

I'm not sure I could give you a boilerplate recipe you could blindly follow... I think this is a case where you really, actually need to know what you are doing.

If you can access the server using VNС and the server can be booted from a bootable USB flash drive then the simplest way to resize partitions is:

(Make backup of your data before you do any changes.)

1. Make bootable USB drive using "SystemRescue Disk". The image can be downloaded here:
https://www.system-rescue.org/Download/

2. Boot the server from the created USB drive.

3. Run "startx" to run graphical interface if the server is booted in text mode.

4. Find and run "GPARTED" from the start menu. GPARTED allows you to manage the partitions using mouse (shrink "/home" and increase "/")

5. Apply the changes and wait some time to allow all necessary steps to be performed by GPARTED.

6. Reboot the server.

Please note you do it on your own risk.

I finally fixed it by moving all log files over to / home until they fill up again and then I'll move them over again but I also moved/backup over to /home/backup and that brought it down to 52%, so I was able to start my SQL backup and get everything going but now I'm not sure if this has to do with my SQL being down during that time but I have an issue now that I don't get...

Warning: Attempt to read property "name" on null in /home/hmudate/public_html/assets/includes/core.php on line 1251

Warning: Attempt to read property "id" on null in /home/hmudate/public_html/assets/includes/core.php on line 1260

Warning: Attempt to read property "fake" on null in /home/hmudate/public_html/assets/includes/core.php on line 1269

Warning: Attempt to read property "lang" on null in /home/hmudate/public_html/assets/includes/core.php on line 1270

Warning: Attempt to read property "gender" on null in /home/hmudate/public_html/assets/includes/core.php on line 1270

Fatal error: Uncaught mysqli_sql_exception: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'order by q_order asc' at line 1 in /home/hmudate/public_html/assets/includes/core.php:2199 Stack trace: #0 /home/hmudate/public_html/assets/includes/core.php(2199): mysqli->query() #1 /home/hmudate/public_html/assets/includes/core.php(1270): profileQuestion() #2 /home/hmudate/public_html/mobile/index.php(13): getUserInfo() #3 {main} thrown in /home/hmudate/public_html/assets/includes/core.php on line 2199

Consider periodically looking at your log files and truncating them to zero bytes:
https://blog.alphagnu.com/how-to-clean-all-log-files-in-cwp-control-webpanel-to-gain-disk-space/

Or better still, set up logrotate to keep them at a manageable size.