My girlfriend managed to fill 100% of her / partition on Ubuntu, and now it won’t boot.

I can get into recovery mode and get a root console, and I’ve already used rm to delete several large files from her downloads directory, but the problem persists, even after several reboot attempts. ls no longer shows those files in the directory, and it should have freed up plenty of space to at least boot, but it’s still not booting, and when I try to use the recovery mode option of ‘fix broken packages’, dpkg tells me it can’t complete the action because it doesn’t have the required ~250MB of free disk space. But, again, I just used rm to delete several hundred GB of files. That should be more than enough, but it’s like the space isn’t being freed up somehow. And, to be clear, I’ve done several hard reboots after deleting these files, still getting the same results. du -h does show her / partition at 100% usage, even after these deletions. (And the /boot partition is only at 49% full, so that shouldn’t be an issue.)

Is there some command I need to use to get it to rescan and realize that it actually has free space now?

How much free disk space should Ubuntu actually need in order to boot, anyway?

Am I barking up the wrong tree entirely somehow? Booting always proceeds as normal right up until the moment the GUI desktop should load, and then it’s replaced by a single blinking underscore in the top left corner – it briefly shows any text typed in, not long enough to actually enter any command, but otherwise doesn’t respond to anything I’ve tried other than Ctrl+Alt+Del, which reboots it. I’ve been pursuing this free disk space problem because the only unusual thing she did before this problem started is that she downloaded a lot of videos and filled the disk completely.

Edit:

No, the /home and / directories were on the same partition, so that wasn’t the issue.

Okay, so I managed to get it to boot, I guess? For the possible reference of others, here’s what I did:

1: Used rm to delete even more things from her download folder. Deleted a lot of stuff. The ls -lS | less command helped here, to quickly identify the biggest, most space-hogging files. I basically just deleted the 10 biggest files before trying again. (After already having deleted some of the other big files in there.)

2: I used exit to go back to the recovery mode menu, then chose the option to resume normal boot. That once again brought me to the dreaded blinking underscore and nothing else.

3: As some here suggested, I then used the Ctrl + Alt +F3 key combination … and that just magically fixed everything. As soon as I hit that key combo, the screen flickered for a bit with weird graphical glitches straight out of a Cyberpunk hacking scene, and a moment later, it was suddenly fully booted into the normal desktop GUI.

At this point, I think I’m going to declare it ‘fixed’ and not fuck around with it any further – I don’t want to risk making things worse and losing this progress. Still not sure what actually happened, but it’s working for now, and I’m a big believer in “If it ain’t broke, don’t fix it.” Now that she has a GUI to work with, I’ll ask her to move more of her downloaded files to an external drive, and I’ll work on it further if and when something goes wrong again.

Thank you to everyone who offered suggestions and tried to help!

  • Coffee Junky ❤️ ( coffeejunky@beehaw.org ) English
    1·
    24 hours ago

    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 -hT shows actual filesystem capacity, available space, and filesystem types.

    • df -i / checks whether the root filesystem has exhausted its inodes.

    • lsblk -f shows 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.