Introduction

The growpart error saying there is no space left does not usually mean the filesystem is full. It usually means the partition cannot be extended because there is no unallocated disk space immediately after that partition, or the disk itself was never enlarged in the first place.

What growpart Actually Does

growpart changes the partition table so an existing partition can occupy more sectors on the disk. It does not create space. It only consumes free space that already exists after the partition boundary.

That distinction matters. If the disk has not been expanded, or another partition sits directly after the target partition, growpart has nothing to grow into.

A common cloud workflow looks like this:

1. enlarge the virtual disk in the cloud console
2. confirm the operating system sees the larger disk
3. run growpart on the right partition
4. expand the filesystem with the filesystem-specific tool

Check the Real Layout First

Before changing anything, inspect the disk layout:

lsblk
sudo fdisk -l

You want to confirm two things:

• the disk itself is larger than before
• there is free space after the partition you want to grow

If lsblk shows the disk and the partition are the same size, growpart cannot help yet.

Example of a Successful Resize

Suppose /dev/sda was expanded and partition 1 should consume the new space:

sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1

If the filesystem is xfs, use:

sudo xfs_growfs /

The partition and the filesystem are separate layers. growpart handles the partition; resize2fs or xfs_growfs handles the filesystem.

Why the Error Appears

The most common reasons are straightforward:

The Disk Was Not Expanded

In virtual environments, people often resize the volume in their infrastructure code but forget to confirm the guest operating system sees the new size. Until the kernel detects the larger disk, there is no new space for growpart to use.

Another Partition Is Blocking the Path

If the next partition starts immediately after the target one, there is no contiguous free region available. growpart does not move neighboring partitions out of the way.

You Are Targeting the Wrong Device

On systems with NVMe or cloud naming conventions, /dev/sda1 may not be the actual root partition. Running growpart against the wrong disk or partition is an easy mistake.

LVM Is in the Stack

If you use LVM, partition growth may only be the first step. After the partition is larger, you may still need pvresize, lvextend, and a filesystem resize before the extra space becomes usable.

A Simple LVM Example

1sudo growpart /dev/nvme0n1 3
2sudo pvresize /dev/nvme0n1p3
3sudo lvextend -l +100%FREE /dev/vg0/root
4sudo resize2fs /dev/vg0/root

That sequence is common on Linux systems where the root filesystem sits on a logical volume rather than directly on a partition.

Common Pitfalls

• Assuming the error means ordinary disk usage is high. It is usually about partition geometry, not used blocks.
• Forgetting to enlarge the underlying cloud volume before running growpart.
• Skipping the filesystem resize after the partition grows.
• Running growpart on the wrong partition number.
• Ignoring LVM layers and expecting partition growth alone to make space visible in the mounted filesystem.

Summary

• 'growpart can only consume unallocated space that already exists after a partition.'
• If there is no contiguous free space, the partition cannot be extended.
• Always verify disk layout first with tools such as lsblk and fdisk -l.
• After partition growth, resize the filesystem or LVM layers as needed.
• Most fixes come from identifying the missing layer in the resize chain, not from rerunning growpart repeatedly.