During an upgrade I received an error message stating that I had less 1 GB left on root partition... unfortunately I had to shutdown my machine before I could investigate.

Now, I received this error message from the rescue command line: enter image description here

After some reading, I deleted all of my old kernels and large files found in "/" . However, no matter how much I delete I still get the same error above.

Why isn't Ubuntu recognizing the additional freed space that I created? I easily freed 2 gigs of space, but I get this constant request for 529M

I even ran:

No luck

Additional Info I am on Ubuntu 20.04, Acer Aspire 5 55g machine, and per the comments below: enter image description here

  • Could you boot your system with a Live USB and edit your question to include the terminal output of df -h and maybe lsblk? This will provide some specific information that may make it easier to answer your question 👍🏻
    – matigo
    Oct 26 at 5:13
  • @guiverc my apologies, was supposed to have a productive day today, instead, I can't boot... frustrated... adding info now
    – yupthatguy
    Oct 26 at 5:47
  • 5% of your partition space is reserved for root user. 5% of 92G are round about 5G, which can't be used by normal users. So either you delete more old files, or you remove/reduce the reserved space via tune2fs -m (works only for ext2/ext3/ext4 filesystems).
    – paladin
    Oct 26 at 7:14

Well there's your problem:

Filesystem       Size  Used Avail Use% Mounted on
/dev/nvme0n1p5    92G   87G     0 100% /

Your / location is full. The 5G of storage that appears unused is reserved by the system for logging and other core functions, meaning that you cannot use it without changing the reserve space for the filesystem ... which I strongly discourage when talking about /.

You will need to find out where all your storage space is being used and move/delete files accordingly. The typical place to start looking is /var/log. In here you can (probably) move/delete some of the archived .gz files. That could free up a good bit of space.

Alternatively, you can use du to identify where you are using the most storage:

sudo du / -h --max-depth=1

This will give you something that looks like:

8.0K    /media
84K     /root
4.0K    /mnt
1.7M    /run
16K     /lost+found
300K    /home
201M    /boot
17G     /var
8.1M    /etc
16K     /dev
22M     /opt
4.0K    /cdrom
0       /sys
4.0K    /srv
76K     /tmp
2.2G    /snap
0       /proc
65G     /data
3.5G    /usr
123G    /

From here, you can edit the / part of the du command to identify specific directories that may be using far more storage than you would like.

  • 1
    a fast way to remove old log in /var/log is by issuing the command sudo find /var/log -type f -iname "*.[0-9]*" -exec rm -rf {} + &> /dev/null. If the OP uses snapd, another idea is to follow this askubuntu.com/questions/1345456/do-snap-files-get-larger and related links. Oct 26 at 7:30
  • @matigo You missed the point of this post. No matter how much I delete... Ubuntu does not recognized that I created free space. Since posting this, I have deleted 20GB of iso files, but the results of #df -h above... has not changed... That is why I am posting here
    – yupthatguy
    Oct 26 at 9:00
  • 1
    Where were the .iso files that you deleted? If they were somewhere in /home, then that would not affect / as your /home is on /dev/sda2. Same with the other delete attempts. If they were on a different partition than /, removing those files would have no effect. Without knowing more about what you're deleting and how, I can only guess based on 20+ years of helping people with their Linux problems 😕
    – matigo
    Oct 26 at 9:50
  • @matigo On the "/" alone I have deleted over 2 gigs of data in the form old kernels and /var/www/html ... the system is only requesting 529M of space
    – yupthatguy
    Oct 26 at 10:01
  • Does lsof | grep DEL reveal anything of note? This will show a list of processes holding deleted files 🤔
    – matigo
    Oct 26 at 10:14

I solved the problem, but I did not answer the question, and created a new mystery.

  1. How I solved the problem: From the rescue shell of my ubuntu default kernel 5.11~~ I ran:

     # du / -h --max-depth=1

    I noticed that my /media folder weighed in at 36GB, which should be impossible as I had no external devices (usb) connected. First, I thought they were old mounts somehow locked in place and I tried umount /media/USB, but was told that they were not mounted.. since these are external devices and my data is safe, I went ahead and removed them.

     # rm -r /media/usb

    Now machine is happy. I was able to boot and complete my update/upgrades.

  2. But my original question remains. Even with the "ghost" mounted usb present, I still deleted over 2 gigs of data, while ubuntu only wanted 529 mb, what I deleted should have been more than enough to complete the update and boot my system? Why wasn't Ubuntu recognizing that I was deleting items?

    I used lsof | grep DEL and it returned no value... so I still don't have an explanation for why the space I deleted wasn't recognized.

  3. And the new mystery that I seem to have created is "Why were 'ghost' mounts of my USB's eating 36GB of space under "/"? I really would like to know this. Could my use of TimeShift somehow created the "ghost" mounts?

In any case @matigo's answer was partially useful, although it doesn't answer the question.

  • Processes running as root can use the reserved space, so it's possible that logging and such could have used up some of that, and your deleting 2GB only served to free up reserved space.
    – muru
    Oct 26 at 11:15
  • 6
    More probably, what was in /media/usb was not ghost mounts, but files that due to a user error got copied there instead of to the removable media that was supposed to be mounted there.
    – Edheldil
    Oct 26 at 15:26
  • @Edheldil 2 of the USB's were iso files from when I created 2 bootable usb sticks. Both sticks (win10 and ubuntu) both work perfectly
    – yupthatguy
    Oct 26 at 15:58
  • 3
    I strongly suspect you did something along the lines of cp ubuntu.iso /media/usb instead of cp ubuntu.iso /dev/sdb :) Oct 26 at 16:00
  • @soxwithMonica Nope.. I used unetbootin-linux64-702.bin to create my bootable usb's, but it also had ghost usb of my external storage drive (though not full size) so I don't think unetbootin-linux64-702.bin is the culprit
    – yupthatguy
    Oct 26 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.