My Linux Root Partition Was Full at 98%, Here’s How I Fixed It Without Reinstalling

The Problem

So there I was, trying to install a simple package, and BAM — “No space left on device.” not something you would expect anytime with 500GB disk space.

33/100

So I ran df -h and saw this nightmare:

/dev/nvme0n1p3   21G   19G  556M  98% /     
# shows that my root is just 21GB and i knew soemthing is off right away

My root partition was choking at 98% usage. But wait — I had a massive 448GB partition sitting right there (/dev/nvme0n1p2), just collecting dust at 37% usage.

The problem? My system’s disk space was booting from the wrong partition. All my new installations, downloads, and even system updates were trying to squeeze into that tiny 21GB partition.

The Solution: Make the Big Partition My New Root

I needed to clone my entire system to the big partition and tell my computer to boot from it instead of the 21GB space.

Step 1: Mount the Big Partition

# Create a mount point and mount the large partition
sudo mkdir -p /mnt/data
sudo mount /dev/nvme0n1p2 /mnt/data
# /dev/nvme0n1p2 is my 448GB partition : make sure you have the naming right
# don't copy paste blindly
# /mnt/data is just a temporary meeting point

Step 2: Copy Everything Over

# The magic rsync command - copies everything while preserving permissions
sudo rsync -avxHAX --progress / /mnt/data/
# Flags explained:
# -a: archive mode (preserves everything)
# -v: verbose (show me what's happening)
# -x: stay on one filesystem (don't go into /proc, /sys, etc.)
# -H: preserve hard links
# -A: preserve ACLs (access control lists)
# -X: preserve extended attributes
# --progress: show me the progress

Step 3: Prepare the New System’s Boot Configuration

I needed to tell the new system where to look for its boot files so that it should map the root to right mounting position.

# Create necessary directories in the new root
sudo mkdir -p /mnt/data/{dev,proc,sys,boot/efi}

# Mount system directories so we can configure from inside
sudo mount --bind /dev /mnt/data/dev
sudo mount --bind /proc /mnt/data/proc
sudo mount --bind /sys /mnt/data/sys

# Mount the EFI partition (this is where UEFI boot files live)
sudo mount /dev/nvme0n1p1 /mnt/data/boot/efi

Step 4: Create the New fstab

The fstab file tells Linux which partitions to mount where. I needed one that points to my big partition as root.

# Create a new fstab file on the big partition
sudo nano /mnt/data/etc/fstab

Here’s what I put in it:

# My big 448GB partition becomes the new root (/)
UUID=<your partition uuid> / ext4 defaults,noatime 0 1
# EFI partition for booting
UUID=<your partition uuid> /boot/efi vfat defaults 0 1

Pro tip: Get your partition UUIDs with sudo blkid

Step 5: Step Inside and Install the Bootloader

This is the critical part — I had to “become” the new system and install GRUB from inside it.

# Jump into the new system (like Inception for Linux)
sudo chroot /mnt/data

# Now I'm "inside" my new system on the big partition
# Install GRUB for UEFI systems
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu --recheck

# Update GRUB configuration
update-grub

# Get out of the chroot
exit

Note: You might see warnings about EFI variables — that’s normal from inside a chroot.

Step 6: Reboot and Pray (But It Worked)

sudo reboot

After reboot, I ran df -h again and saw:

/dev/nvme0n1p2  448G  351G   74G  83% /

BOOM. My root was now on the 448GB partition, so now my disk is routing to correct partition.

Key Takeaways

1. Always check your partition layout — You might have free space you’re not using
2. rsync is your best friend for copying entire systems.
3. chroot lets you work on another Linux system like you're inside it
4. The problem wasn’t lack of space — it was booting from the wrong partition.