

Maybe its actually /boot that is full? You could try to remove some old kernels https://linuxconfig.org/how-to-remove-old-kernels-on-ubuntu
sudo apt autoremove --purge
Sorry it’s not boot commented too soon.
Maybe this is useful sometimes these AI answer’s can send you in the correct direction
Nagedacht gedurende 1m 19s
He’s probably on the right track: a completely full root partition can prevent Ubuntu’s graphical desktop from loading. The blinking underscore is consistent with that problem, although it can also indicate a display manager or graphics driver failure.
However, there’s something unusual about his situation: deleting hundreds of gigabytes of files should have freed space immediately. Linux doesn’t need a special command to rescan the disk after rm.
There are several possible explanations:
-
The files he deleted were on a different partition from
/. -
The files were still held open by running processes, although rebooting should have resolved that.
-
The filesystem uses snapshots, which may retain deleted data.
-
Filesystem corruption or another storage issue is preventing space from being reclaimed.
-
The root partition now has free space, but the GUI is failing for a different reason.
Here’s how I’d troubleshoot it from the recovery root shell.
1. Check the actual filesystem usage
Run these commands in the recovery shell:
df -hT
df -i /
lsblk -f
The first command is particularly important.
-
df -hTshows actual filesystem capacity, available space, and filesystem types. -
df -i /checks whether the root filesystem has exhausted its inodes. -
lsblk -fshows the partitions and their filesystems.
du is different: it calculates the space consumed by files and directories, not the filesystem’s percentage of available space.
He should pay special attention to whether /home and / are on separate partitions.
For example:
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 50G 50G 0 100% /
/dev/sda3 ext4 900G 300G 600G 34% /home
In this situation, deleting hundreds of gigabytes from /home would do absolutely nothing to free up space on /.
He should also check where the Downloads directory is actually mounted:
findmnt -T /home/USERNAME/Downloads
Replace USERNAME with her username.
Recovery mode doesn’t necessarily mount all separate partitions automatically, so he should verify that he’s actually examining the intended filesystem.
2. Find out what’s filling the root partition
Run:
du -xhd1 / 2>/dev/null | sort -h
The -x option is important because it restricts the search to the root filesystem rather than counting separate mounted partitions.
Example:
4.0K /media
120M /etc
2.8G /usr
8.5G /home
36G /var
48G /
In this example, /var is the main culprit.
He can investigate further:
du -xhd1 /var | sort -h
This helps identify whether the problem is log files, caches, package downloads, or something else.
3. Free some space safely
Ubuntu’s recovery shell commonly mounts / read-only. To make changes, first run:
mount -o remount,rw /
This is documented in Ubuntu’s recovery instructions.
If the remount succeeds, he can clean the package cache:
apt-get clean
And reduce old system logs:
journalctl --vacuum-size=100M
The second command removes older archived journal files while retaining newer entries.
Then check again:
df -h /
If he has regained sufficient space, he can retry:
dpkg --configure -a
However, he shouldn’t randomly delete files from /usr, /lib, or other system directories.
4. If df and du disagree
If df still reports the filesystem as full, but du shows much less data, that is an important diagnostic clue.
A common cause is deleted files that are still open by a process. He can check with:
lsof +L1
Normally, the filesystem cannot reclaim their space until the process closes those files.
But since he’s rebooted several times, this explanation is much less likely.
Other possibilities include snapshots retaining deleted data, files hidden beneath mount points, or filesystem inconsistencies.
If the discrepancy remains unexplained, he should consider checking the filesystem for errors, preferably using the Ubuntu recovery filesystem-check option or a live USB. He should not run a repairing fsck on the mounted root filesystem.
5. How much free space does Ubuntu need to boot?
There’s no universal minimum because it depends on the installed software and what services need to write during startup.
As a practical guideline:
| Available root space | Assessment |
|---|---|
| 0 MB | Very likely to cause failures |
| 250 MB | May be insufficient for repairs and updates |
| 1–2 GB | Often enough to restore basic operation |
| 5–10 GB | More comfortable for normal use and updates |
I’d aim to free at least 5 GB, preferably more, before attempting package repairs and another graphical boot.
6. If space is available but the GUI still won’t start
The original problem may have caused a secondary issue, or the graphical failure might have a different cause.
He can try switching to a terminal with Ctrl+Alt+F3 during the failed boot.
If that doesn’t work, return to recovery mode and check the display manager’s previous-boot logs:
journalctl -b -1 -u display-manager --no-pager
And general system errors:
journalctl -b -1 -p err --no-pager
These can reveal why the graphical login screen is failing.
My main recommendation: Before deleting anything else, he should post the output of these three commands:
df -hT
df -i /
du -xhd1 / 2>/dev/null | sort -h
They will establish whether / really is still full, whether inode exhaustion is involved, and where its allocated space is going.
There’s no reason to reinstall Ubuntu yet. The fact that recovery mode works is encouraging, and this is very likely diagnosable without losing her files.




A couple of years ago they changed the phone policy, you can only read work email on your phone when you install Microsoft intune and basically give the company admin access. We all use personal phones (company doesn’t provide them), so basically my entire team decided to just not get work emails on our phones. Most of my team is self employed (freelance). Now sometimes I get complaints I don’t respond to emails quickly… Yeah what on earth could be the reason for that…