When working with VPS environments, we often encounter storage limitations on mounted root partitions. The key challenge is that most Linux filesystems (like ext4) cannot be resized while mounted - especially when it's the root filesystem (/). Here's what makes this particularly tricky:

• The partition is actively being used by the system
• Critical system processes have open file handles
• Kernel has the filesystem locked for writing

Many VPS providers suggest that partition resizing is simply an admin task, but they often overlook the technical constraints:

# This WON'T work on a mounted filesystem:
sudo resize2fs /dev/sda1
# Returns: "Filesystem at /dev/sda1 is mounted on /; on-line resizing required"

Here are the actual working approaches for this scenario:

Option 1: Boot into Rescue Mode

Most reputable VPS providers offer rescue mode:

1. Reboot into provider's rescue environment
2. unmount /dev/sda1 if auto-mounted
3. fdisk /dev/sda
   - Delete partition (don't worry, data remains)
   - Create new partition with same start sector
   - Larger end sector (using all available space)
   - Set bootable flag
4. reboot

Option 2: LVM Alternative (Future-Proofing)

If you can rebuild the server, consider LVM for future flexibility:

# Example LVM setup during OS installation:
pvcreate /dev/sda1
vgcreate vg_root /dev/sda1
lvcreate -l 100%FREE -n lv_root vg_root
mkfs.ext4 /dev/vg_root/lv_root

Option 3: Temporary Workaround

For immediate space needs without resizing:

# Clean up package cache
sudo apt-get clean

# Remove old kernels (keep current + one backup)
sudo apt-get autoremove --purge

# Analyze disk usage
sudo du -sh /* | sort -h

The fundamental limitation comes from how Linux handles mounted filesystems. The kernel maintains metadata about:

• Inode tables
• Journal logs
• Block allocation maps

Modifying these structures while in use risks catastrophic corruption. Even with resize2fs -f, the operation requires exclusive access.

When discussing with your provider (especially through intermediaries), clarify these points:

- Do you offer rescue mode or single-user boot?
- Is there a way to attach this disk as secondary to another instance?
- Can you provide temporary storage for a dd backup?

Remember: Always have complete backups before attempting partition operations.

---

When examining the disk layout with fdisk -l and df -h, we observe:

Disk /dev/sda: 25 GiB (only 5G allocated to /dev/sda1)
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       4.9G  3.0G  1.7G  64% /

The critical challenge is that you cannot resize a mounted partition that contains the running OS. The root filesystem (/dev/sda1) being actively used by the system creates a lock on the partition.

While traditional wisdom says this is impossible, modern Linux systems offer partial solutions:

Method 1: Using LVM (Recommended for Future Setup)

If your system uses LVM (Logical Volume Manager), resizing becomes trivial:

# Check for LVM setup
sudo vgdisplay
sudo lvextend -l +100%FREE /dev/mapper/vg-root
sudo resize2fs /dev/mapper/vg-root

Method 2: Cloud Provider-Specific Tools

Many VPS providers offer resize capabilities through their control panel or API. For example:

# AWS example (if applicable)
aws ec2 modify-volume --volume-id vol-123456 --size 25

Method 3: Temporary Filesystem Expansion

For emergency space needs, you can mount additional space elsewhere:

sudo mkdir /mnt/tempstore
sudo mount /dev/sda2 /mnt/tempstore  # Assuming sda2 exists
sudo ln -s /mnt/tempstore /var/lib/mysql  # Example for MySQL

For traditional partitions like your /dev/sda1 setup:

1. Boot into rescue mode (provider should offer this)
2. Unmount the filesystem
3. Use fdisk to delete and recreate the partition with larger size
4. Run resize2fs

Sample rescue mode commands:

sudo fdisk /dev/sda
# (Delete partition, recreate with same start sector but larger size)
sudo e2fsck -f /dev/sda1
sudo resize2fs /dev/sda1

After successful resizing:

df -h
lsblk
grep sda /proc/partitions

Remember to always backup critical data before partition operations. The safest method is to request your VPS provider perform the resize through their hypervisor layer.