Expanding the Root Partition Manually on MTN Cloud

Service Name:
Root Partition & Storage Expansion
Service Category:
Compute, Storage Management
Document Version:
v1.0

Overview

The MTN Cloud compute infrastructure requires manual storage tuning on specific Linux distribution images. Currently, Debian environments do not automatically scale the root partition layout to fill the entirety of a newly provisioned block storage volume. For example, a virtual machine initialized with a 50 GB root disk only allocates a default 10 GB to the root path (/), leaving the remaining storage footprint unassigned and unusable until an administrator manually reorganizes the underlying disk geometry.

Prerequisites

Before executing raw disk manipulation commands, ensure your workspace meets the following administrative criteria:

  • An active MTN Cloud Console login provisioned with the Customer Admin User role or explicit permissions to view the Provisioning suite.
  • A live, deployed virtual machine instance utilizing either the Debian 12 or Debian 13 operating system type.
  • A verified external backup of all business-critical production data pools before adjusting partition tables.

Part 1 – Storage Geometry Reorganization

Disabling Active Partition Swap

To safely drop, modify, or extend active partition boundaries without triggering kernel resource blocks or data corruption, you must completely stop all swap-backed virtual memory subsystems. This clears active memory paging and unlocks the physical disk sectors.

Execute the global swap deactivation utility in the terminal:

sudo swapoff -a

Modifying Partition Tables via fdisk

Launch the scriptable interactive partition utility targeting the primary virtual disk block device:

sudo fdisk /dev/vda

Inside the active fdisk prompt utility loop, input the following operational command sequence exactly as documented, pressing Enter after each parameter to adjust the layout geometry:

  • d → 5: Deletes partition vda5 (the legacy dedicated swap space partition).
  • d → 2: Deletes partition vda2 (the extended layout container partition).
  • d → 1: Deletes partition vda1 (the original root volume partition). Note: The raw data blocks remain safely intact in memory sectors and are immediately reallocated below.
  • n: Initializes the creation wizard for a brand new partition block.
  • p: Defines the target allocation as a standard Primary partition type.
  • 1: Registers the configuration block under index identifier Partition Number 1.
  • [Enter]: Accepts the default starting sector location. Critical Safety Rule: This value must match the original partition start point exactly (which is standardly sector 2048).
  • [Enter]: Accepts the default final sector value, expanding the partition envelope to encompass all remaining free space.
  • N: Explicitly rejects signature removal when prompted with “Do you want to remove the signature? [Y]es/[N]o”. This preserves the underlying ext4 structure.
  • a: Enables the system bootable flag on Partition 1 to preserve system boot mechanics. (Note: If fdisk does not auto-select partition 1, explicitly pass 1).
  • w: Writes the newly compiled partition table changes down to persistent disk storage and exits the interactive session.

Part 2 – Kernel Synchronization & Filesystem Growth

System Reboot Integration

Although the structural disk parameters have been written down to storage, the active Linux kernel continues tracking the older, smaller partition architecture. A hard system restart is mandatory to force the kernel subsystem to completely flush and reload the updated disk table maps.

Issue the hardware cycle prompt via your console shell:

sudo reboot

Note: Wait a few moments for background compute components to initialize, then reconnect your cloud terminal session.

Online Filesystem Scaling

Following the system reboot, the virtual partition container (/dev/vda1) correctly reflects the expanded hardware capacity, but the internal tracking file engine remains restricted to its original footprint size. Run the online extension tool to stretch the filesystem to fill the expanded partition space:

sudo resize2fs /dev/vda1

Verification: Audit the storage layer matrix by executing the human-readable disk utility:

df -h

Verify that the root path filesystem entry (/dev/vda1) shows the updated, enlarged volume allocations within its available capacity column.

Part 3 – File-Based Swap Deployment

Recreating and Securing Swap Allocation

Because the legacy dedicated raw swap disk partition was dropped during the partition table remapping phase, you must restore swap capacity. Implementing a file-based swap rather than formatting an isolated raw disk partition provides significantly higher operational flexibility, making it vastly simpler to resize, maintain, and migrate across cloud environments.

Run the following block of terminal commands in order to provision, secure, and activate a replacement 583 MB file-based swap space:

# 1. Allocate a 583MB block on the root filesystem space
sudo fallocate -l 583M /swapfile

# 2. Tighten file permissions to ensure only the root user can read/write paging memory
sudo chmod 600 /swapfile

# 3. Format the unallocated space with an active Linux swap signature
sudo mkswap /swapfile

# 4. Turn on the swap file system subsystem interface
sudo swapon /swapfile

Persistence & Critical Safety Validations

To guarantee that the newly initialized swap allocation remounts automatically during subsequent host initialization or power cycles, permanently append the configuration metrics to your file systems table:

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

Post-Configuration Validation: To ensure there are no formatting syntax mistakes or invalid mount parameters inside your updated storage mapping records that could freeze future system boot sequences, run a comprehensive dry-run mount verification test:

sudo mount -a