When Ubuntu will not boot or reach the login screen because a filesystem is full, the safest response is not to start deleting random files. First identify which mounted filesystem has exhausted blocks or inodes, then inspect what is consuming space, remove only confirmed expendable data, and verify that the affected services can write again.
Ubuntu recovery mode provides a shell when normal startup cannot reach a usable desktop or TTY.
Diagnose the exact full mount before deleting anything. A full root filesystem, a full /var, a full /home, a full /boot, and inode exhaustion require different fixes.
Confirm that disk exhaustion is really the problem
A black screen, boot delay, failed graphical login, or service error can have many causes. Disk exhaustion is likely when the console reports “No space left on device,” package operations fail while writing, logs cannot be created, or the display manager repeatedly returns to the login screen.
Reach a shell using the least disruptive method available:
- Use a normal terminal if the desktop still opens.
- Switch to a text console with Ctrl+Alt+F3 when the graphical login is broken but the system is responsive.
- Use SSH if it was already enabled and the network is working.
- Use Ubuntu recovery mode when normal boot cannot reach a usable shell.
- Use a Live USB only when the installed system cannot provide a safe working shell.
A recovery-mode root shell may initially mount the root filesystem read-only. Only remount it read-write when a repair genuinely requires changes, and return to read-only or reboot after the cleanup.
Check blocks and inodes separately
Run these inspection commands before deleting anything:
df -i
The first reports filesystem space in human-readable units. The second reports inode usage. A filesystem can show free gigabytes but still reject new files when it has no free inodes, often because an application created a very large number of tiny files.
Look at the Mounted on column and identify the exact filesystem at or near 100%. Do not assume that / is the problem. A separate /var, /home, or /boot partition can fill while the others remain healthy.
Expected result: You should be able to name the affected mount and whether the shortage is blocks, inodes, or both.
Verification: Re-run df -h and df -i after every cleanup step rather than deleting several categories at once.
Find the real space consumer
Start with read-only inspection. On the full filesystem, examine top-level directory sizes without crossing into other mounted filesystems:
For a full /var, narrow the scan:
sudo du -xhd1 /var | sort -h
For a full home partition, inspect the relevant user directory rather than the entire computer:
sudo du -xhd1 /home/USERNAME | sort -h
Replace USERNAME with the actual account name. The -x option keeps the scan on one filesystem, which prevents mounted backups, network shares, and removable drives from distorting the result.
If inode exhaustion is the problem, count entries rather than only bytes. Inspect likely high-churn locations such as application caches, mail queues, container storage, temporary directories, and session data. Do not delete an unfamiliar directory merely because it contains many files.
Keep the investigation reversible. Record the output or take a phone photo of the console before changing anything, then remove one confirmed category and verify the result.
Use the safest cleanup options first
User caches and Trash
A user’s Trash or application cache can consume substantial space. When you can identify the affected account, inspect the directories before removing contents. Preserve documents, downloads, browser profiles, and application data unless the user has a backup and clearly intends to remove them.
APT package cache
Inspect the package cache first:
sudo du -sh /var/cache/apt/archives
When the cache is the confirmed problem, this command removes downloaded package files that can be fetched again:
Expected effect: Frees space used by cached package archives without uninstalling installed packages.
Verification: Run df -h again and confirm that package management can write normally.
Rollback consideration: Cached packages are deleted, so reinstalling them later requires network access or another package source.
Systemd journal archives
Check journal usage:
If archived journals are genuinely consuming the full filesystem, rotate active files and then apply a bounded vacuum:
sudo journalctl --rotate
sudo journalctl --vacuum-size=500M
The vacuum operation removes the oldest archived journal files until the archive is below the requested size. It does not delete active journal files, so the displayed total may remain above the target.
Verification: Re-run journalctl --disk-usage and df -h.
Rollback consideration: Removed historical logs cannot be restored unless they were backed up. Keep enough history for troubleshooting and compliance needs.
Old kernels and a full /boot
Do not manually delete random files from /boot. First confirm that /boot is the full filesystem with df -h, list installed kernels through the package manager, and keep the running kernel plus at least one known-good fallback.
When normal package management works, use supported package cleanup rather than rm. If package operations cannot complete because /boot has no working space, stop and document the exact installed and running kernel versions before removing anything. This is a higher-risk repair and should remain in recovery until a verified bootable kernel and initramfs are present.
Large deleted files still held open
Sometimes du shows less usage than df because a running process still holds a deleted file open. When lsof is installed, inspect deleted open files:
sudo lsof +L1
Restarting the responsible service normally releases the space. Do not kill an unfamiliar critical process without understanding the service impact.
Container and virtual-machine storage
Docker, Podman, Snap revisions, virtual-machine images, database files, and application-specific caches can become the largest consumers. Use each product’s own inventory and cleanup commands.
Never delete arbitrary files from /var/lib/docker, /var/lib/snapd, database directories, or package databases while their services are active.
Do not delete unknown files from /var/lib, /usr, /boot, /etc, package databases, active logs, or user data simply to make the percentage fall. A small amount of careless cleanup can turn a recoverable full disk into an unbootable or inconsistent system.
Why freeing space may not immediately restore Ubuntu
Ext2, ext3, and ext4 filesystems can reserve a percentage of blocks for privileged processes. This helps essential services continue writing when ordinary users are blocked and reduces fragmentation. A filesystem may therefore appear full to a normal user while root can still write a limited amount.
Do not change the reserved-block percentage as the first fix. On large non-system data volumes, an administrator may decide that the default reservation is excessive, but that is a filesystem-policy change, not a substitute for identifying uncontrolled growth. Record the current setting and have a tested rollback before using tune2fs.
Services may also need a restart after space is freed. Package management may require recovery from an interrupted transaction, a display manager may need to restart, and a database may need its own integrity checks. Free space first, then read the current boot logs and service status before making additional changes.
Verify recovery before normal use
After cleanup:
- Confirm meaningful free blocks and inodes with df -h and df -i.
- Confirm that the affected mount is writable.
- Check the failed service with systemctl status SERVICE.
- Review current-boot errors with journalctl -b -p warning.
- Complete any interrupted package transaction only after enough space exists.
- Reboot once and confirm that the system reaches the expected login or service state.
- Create a backup and set up monitoring or retention limits so the same growth pattern is detected earlier.
If the boot screen instead pauses on a `/dev/...: clean, ... files, ... blocks` line, use the Ubuntu “clean, files, blocks” boot guide to distinguish a routine filesystem status line from a genuine hang before assuming the disk is full.
This guide focuses specifically on capacity and inode exhaustion rather than general boot diagnosis.
