Skip to content

Root Volume Expansion (Debian Appliance) — AWS EC2 and VMware ESXi

This runbook covers expanding the root filesystem on the Securitaas Appliance when the underlying virtual disk has been increased.

It supports two deployment environments:

  • AWS EC2 (EBS root volume resized)
  • VMware ESXi / vSphere (VMDK resized)

The Linux-side procedure is largely the same (expand partition/LVM → expand filesystem). The key differences are how the guest OS detects the new disk size and the disk device naming.

⚠️ Important Access Requirement: This operation requires elevated access (e.g., securitaas user with sudo). Perform only with authorization. If in doubt, contact Securitaas Support.

Core Concepts

What you are changing

  • Virtual disk size (EBS volume or VMDK) is increased first in the hypervisor/cloud.
  • The guest OS partition table still reflects the old size.
  • You then expand: 1) the partition (or LVM PV/LV), 2) and the filesystem (ext4/xfs).

Common layouts

1) Plain partition + ext4 (most common): /dev/<disk>p1 mounted at / 2) LVM: partition → PV → VG → LV mounted at / 3) Swap partition after root (your previous case): blocks root partition growth; simplest fix is to replace with a swapfile.

Prerequisites (Both EC2 and ESXi)

  • The disk has been expanded at the platform layer:
  • EC2: EBS volume size increased (e.g., 20 GiB → 50 GiB)
  • ESXi: VMDK size increased in vCenter/ESXi
  • You can log in and run sudo commands.
  • You can identify disk and root partition:
  • Often NVMe on EC2: /dev/nvme0n1p1
  • Often SCSI on ESXi: /dev/sda1 or /dev/vda1 (varies)
  • Filesystem type (ext4/xfs) and whether LVM is in use.

Step 1 — Validate Current Layout (Do this first)

Run:

lsblk -f
df -h /
sudo fdisk -l

What to look for: - Disk shows the new total size (e.g., 50G) - Root partition still shows the old size (e.g., 19G) - Any partitions after root that may block growth (swap/extended/etc.)

If fdisk is not available

On some locked-down systems, fdisk may be missing. Try:

sudo parted -l

If neither exists, you’ll need support assistance or a rescue workflow.

A) AWS EC2 (EBS) Workflow

A1 — Confirm EC2 sees the new EBS size

Usually the OS sees the new EBS size immediately, but confirm:

lsblk
sudo fdisk -l

If the disk size is still the old size, you may need to reboot the instance.

B) VMware ESXi / vSphere Workflow

B1 — Expand the VMDK in vSphere first

In vCenter/ESXi: - Edit VM settings → Hard disk → increase size.

B2 — Rescan inside the Linux guest (usually no reboot needed)

VMware often presents disks via SCSI. After resizing the VMDK, run:

Option 1: Rescan all SCSI hosts (common on ESXi)

for h in /sys/class/scsi_host/host*; do echo "- - -" | sudo tee "$h/scan"; done

Option 2: Rescan a specific disk (example: sda)

echo 1 | sudo tee /sys/class/block/sda/device/rescan

Then re-check: 

lsblk
sudo fdisk -l

If the disk still does not reflect the new size, a reboot may be required.

C) Linux Expansion Procedure (Works for BOTH EC2 and ESXi)

This section is the main runbook once the guest sees the new disk size.

C1 — Identify your root disk/partition and filesystem

From:

lsblk -f
df -h /

Example outcomes: - Root ext4 on /dev/nvme0n1p1 (EC2 NVMe) - Root ext4 on /dev/sda1 (ESXi SCSI) - Root LV like /dev/mapper/vg-root (LVM)

Check: 

sudo pvs
sudo vgs
sudo lvs

Typical flow: 1) Expand the partition that backs the PV (or the whole disk if PV is on disk) 2) Resize PV: 

sudo pvresize /dev/<disk>p1   # example: /dev/nvme0n1p1 or /dev/sda1
3) Extend the LV and filesystem together: 
sudo lvextend -r -l +100%FREE /dev/<vgname>/<lvname>

Verify: 

df -h /
lsblk

If you do not use LVM, continue to C3.

C3 — Plain partition + ext4/xfs (no LVM)

C3.1 If a partition AFTER root blocks expansion (swap/extended)

This is the case you hit previously. If fdisk -l shows something like: - p1 root partition - p2 extended (and sometimes p5 swap) after it

Then root cannot grow until those are removed.

Disable swap and remove swap entry from fstab

sudo swapoff -a
sudo nano /etc/fstab

Comment out any swap line referencing UUID or /dev/<disk>p5.

Verify: 

swapon --show

Delete the blocking partition(s)

Example (delete p2 extended): 

sudo fdisk /dev/<disk>

Inside fdisk: 1. p 2. d → enter partition number for the blocker (commonly 2, and if p5 exists, delete 5 first) 3. p 4. w

Note: Logical swap partitions (p5) may require deleting p5 before p2 depending on layout.

C3.2 Recreate the root partition to use the full disk (KEEP SAME START SECTOR)

⚠️ Critical Safety Rule: Recreate the root partition with the exact same start sector (commonly 2048). Do NOT remove the filesystem signature when prompted.

Run: 

sudo fdisk /dev/<disk>

Inside fdisk (example for partition 1): 1. p (note start sector for p1, e.g., 2048) 2. d → 1 (delete p1) 3. n → p → 1 4. First sector: type the exact start sector you noted (e.g., 2048) 5. Last sector: press Enter to use maximum (end of disk) 6. a → 1 (set boot flag if it was bootable) 7. When asked to remove signature: answer N 8. p (p1 should now match disk size) 9. w

Re-read partition table: 

sudo partprobe /dev/<disk> || true

If the system says the device is busy / table not re-read cleanly, reboot: 

sudo reboot

C3.3 Expand filesystem

ext4

sudo resize2fs /dev/<disk>p1

xfs (if root is xfs)

sudo xfs_growfs -d /

Verify: 

df -h /
lsblk

If you removed a swap partition, restore swap via swapfile to avoid future partition complications.

Create a 1G swapfile (adjust size as needed)

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Persist across reboot: 

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verify: 

swapon --show
free -h

Optional: reduce swap aggressiveness: 

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl -p /etc/sysctl.d/99-swappiness.conf

Final Validation Checklist (Both EC2 and ESXi)

Run: 

df -h /
lsblk
swapon --show

Expected: - Root / reflects the expanded size (e.g., ~50G) - Root partition/LV matches new disk layout - Swap present (via /swapfile if you switched to swapfile)

Notes and Troubleshooting

  • If fdisk offered a limited “last sector” range, it means another partition was still blocking the end of disk.
  • If partprobe does not update the in-use root partition, a reboot is normal and expected.
  • If your disk uses GPT (common on newer installs and large disks), you may prefer parted over fdisk.
  • For ESXi, always ensure the guest sees the new disk size after VMDK resize (rescan/reboot) before modifying partitions.