Resizing the root disk

You paid your provider for a bigger disk, the control panel says the disk is bigger now — but BOA still acts like it's out of space. df -h / shows the old, smaller number. Nothing you deleted seems to help.

That's normal, and it's not a bug. Growing a virtual disk happens in two layers, and your provider only did the first one:

  1. The disk got bigger — your provider did this.
  2. The partition and filesystem still think they're the old size — you have to grow these yourself. That's what this page walks you through.

The good news: on a standard BOA box this is a short, safe job you can do while the server is running and BOA keeps serving sites. You don't reboot, and you don't take anything offline.

The catch: the commands here operate on your disk device directly. Run the wrong one on the wrong device and you can lose data. So this page is deliberately slow and careful — you'll check the disk name twice, take a snapshot first, and confirm what you should see after every step. If the output of any step doesn't look like what this page says, stop and don't improvise — see When something looks wrong at the bottom.

Do you actually need this?

Only run this procedure if all of these are true:

  • You (or your provider) recently increased the disk size of this VM.
  • df -h / still shows the old, smaller size.
  • You are the only person managing this box, and nobody else is mid-way through their own resize.

If your disk was always this size and you're simply full, resizing won't help — you need to free space or buy a bigger disk from your provider first. This page is only for the case where the disk already grew but the system hasn't caught up.

This page covers the common BOA setup: a single Debian or Devuan box with an ext4 root filesystem on a GPT disk. That's what a normal BOA install looks like. If your box is different (see When your disk isn't /dev/sda), some device names change — go slowly and don't guess.

Before you touch anything: take a snapshot

This is the single most important step. Take a snapshot of the VM from your provider's control panel before you run any command below. Almost every VPS provider offers one-click snapshots. If a step goes wrong, a snapshot lets you roll the whole disk back to exactly where it is right now.

Do not skip this because "it's just a resize". The commands touch the partition table — the map of where your data lives on the disk. A snapshot is your undo button. Take it now.

Step 1 — Find your disk, and check its name twice

Everything below assumes your disk is called /dev/sda and your root partition is /dev/sda1. That's the usual name on a BOA box, but you must confirm it, because every later command names the device explicitly and there's no undo (that's why you took the snapshot).

Ask the system where your root filesystem actually lives:

findmnt -n -o SOURCE /

You should see something like:

/dev/sda1

Now list the whole disk so you can see the partition and its sizes:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT /dev/sda

You should see something like:

NAME    SIZE FSTYPE MOUNTPOINT
sda     100G
├─sda1   50G ext4   /
├─sda2  ...  vfat   /boot/efi

Read that carefully. In this example the disk (sda) is 100G but the root partition (sda1) is still only 50G — that's the gap you're about to close.

Check both outputs agree: findmnt said /dev/sda1, and lsblk shows sda1 mounted on /. If they match, /dev/sda is your disk and /dev/sda1 is your root partition — carry on. If findmnt reported anything other than /dev/sda1 (for example /dev/vda1 or /dev/nvme0n1p1), your device has a different name — jump to When your disk isn't /dev/sda before doing anything else.

Step 2 — Install the small tools you'll need

BOA ships on a lean system, so a couple of the resize helpers may not be installed yet. Install them (it's harmless if they're already there):

apt-get update
apt-get install -y gdisk cloud-guest-utils parted

These give you three commands used below: sgdisk (fixes the partition table after a disk grows), growpart (grows the partition safely), and partprobe (asks the kernel to re-read the partition table). The resize2fs command that grows the filesystem itself is almost always installed already.

Step 3 — Back up the partition table

Before changing the partition table, save a copy of it. This is quick and gives you a second safety net alongside your snapshot:

sgdisk --backup=/root/sda.gpt.backup /dev/sda

You should see:

The operation has completed successfully.

You now have a copy of the current partition table at /root/sda.gpt.backup. Leave it there; you can delete it once you've confirmed everything worked.

Step 4 — Repair the partition table for the new disk size

When a disk grows, the small bookkeeping record GPT keeps at the end of the disk is left behind at the old spot. This command moves it to the new end so the disk knows how big it really is:

sgdisk -e /dev/sda

You should see:

The operation has completed successfully.

Don't panic if you saw warnings earlier. Before you run this, commands like fdisk -l may complain with lines such as:

GPT PMBR size mismatch (...) will be corrected by write.
The backup GPT table is not on the end of the device.

That's exactly the situation this step fixes — those warnings are expected on a disk that just grew, and they go away after this command. A line reading Partition table entries are not in disk order is also normal on cloud images and is nothing to fix.

Step 5 — Grow the root partition to fill the disk

Now stretch the root partition so it uses all the new space. Note the 1 at the end — that's the partition number (sda1):

growpart /dev/sda 1

You should see something like:

CHANGED: partition=1 start=... old: size=... end=... new: size=... end=...

The word CHANGED tells you it worked. If instead you see NOCHANGE: partition 1 is size ... it cannot be grown, the partition was already full-size — that's fine, it just means someone (or your provider) grew the partition already and you only need the filesystem step. Carry on.

Step 6 — Let the kernel notice the new partition size

Ask the running kernel to re-read the partition table so it sees the bigger partition:

partprobe /dev/sda

This usually prints nothing at all — no news is good news. If it prints a small warning about the device being busy, that's common on a live root disk and usually harmless; the next check will tell you whether the size updated regardless.

Confirm the partition is now the full size:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT /dev/sda

sda1 should now show the full disk size (100G in our example), not the old 50G. If it does, you're almost done — one step left.

Step 7 — Grow the filesystem

The partition is now big, but the ext4 filesystem inside it still needs to expand to fill it. This is the step that finally gives BOA the extra room. It's safe to run while the disk is mounted and in use:

resize2fs -p /dev/sda1

You should see something like:

Filesystem at /dev/sda1 is mounted on /; on-line resizing required
The filesystem on /dev/sda1 is now ... blocks long.

Step 8 — Confirm it worked

Check the free space one more time:

df -h /

The Size column should now show the new, bigger number, and Avail should reflect all that reclaimed space. That's the whole point — if df now agrees with what your provider gave you, you're done. BOA never went offline and your sites kept serving throughout.

You can now delete the partition-table backup if you like:

rm /root/sda.gpt.backup

When something looks wrong

If any step's output didn't match what's described above, stop here. Don't run the next command "to see if it fixes itself" — on a disk device, guessing is how data gets lost. You already have a snapshot, so nothing is urgent.

A few specific things to watch for, and what they mean:

  • findmnt in Step 1 showed a device that wasn't /dev/sda1. Your disk has a different name — see the next section. Do not run the sgdisk/growpart commands against /dev/sda if that's not your disk.
  • A command reported errors about "can't find PARTUUID=…", or a failed mount. This means your /etc/fstab (the file that says which partition to mount as /) is out of step with the disk. Fixing it by hand is easy to get wrong. BOA ships a root-only tool, fixmounts, that normalizes /etc/fstab safely — run plain fixmounts and it only previews the changes it would make; it writes the file only when you add --apply (fixmounts --apply). Even so, repairing a boot-critical file is beyond a "just works" task, so if the preview isn't obviously right, get help rather than applying it blindly (see the escalation link below).
  • You're worried the box won't boot next time. If partitions look right but you're unsure the bootloader agrees, don't reboot to "test it" on a box you can't easily rescue. Rolling back to your snapshot is always safer than a failed boot you can't reach.

In all of these cases the safe move is the same: you have a snapshot — roll back to it if needed, and get a second pair of eyes before continuing.

When your disk isn't /dev/sda

Most BOA boxes use /dev/sda, but some don't. If Step 1's findmnt showed one of these instead, the procedure is the same — you just substitute the right names everywhere /dev/sda and /dev/sda1 appear:

  • NVMe disks show up as /dev/nvme0n1, and the root partition as /dev/nvme0n1p1.
  • virtio disks (common on KVM-based VPS) show up as /dev/vda, root as /dev/vda1.

Go extra slowly here: it's easy to mistype these longer names, and the commands don't ask for confirmation. Check every command names your device before you press Enter.

One setup is genuinely different and not covered here: if lsblk shows your root on something like /dev/mapper/... or an lvm type, your box uses LVM, which resizes with a different set of commands. Growing an LVM root the wrong way can lose data. Don't follow this page — get help from someone comfortable with LVM.

Going further

Advanced (root required): if your /etc/fstab or bootloader is out of sync, or a reboot won't come back cleanly, that's a recovery job, not a resize — see Operating → Recovery cycles & cache faults for repairing a box that won't come up cleanly. That guide assumes comfort with Linux internals.