I have a 5G partition with Ubuntu Feisty on it. /home is on a separate disk of 80G, so no user data is stored on /

For some reason I got the 99% full warning yet there is no reason why it has done it. By checking certain folders, I can see the bulk of stuff is in:

/usr - in excess of 1.8G (most is in /usr/share and usr/lib (about 900M each))

/proc - nearly 1G

Perhaps it is all the updates - but having said that, dapper went through far more updates and I had that on a smaller partition.

One point worth mentioning was that I kept getting a lock up when switching users and trying to log one of them out. At this point the keyboard became dead - and so the only remedy was to reboot (as in the button on the front of the case). So lots of not clean shutdowns. The latest kernel update to Feisty has solved this.

Any thoughts as to what I should check for?

Post the results of:
# du -hs /*

Likely culprits are /tmp and /var.

/var gets big real fast. If du shows /var getting to big it might be the apt cache. Delete all the .deb files manually or tell aptitude to do it automatically.

I make /var a seperate 3G or so partition so it doesn't effect the rest of the system when this happens.

Hi - /var isn't that big, but here's the dump.

4.8M /bin
27M /boot
0 /cdrom
164K /dev
9.8M /etc
17G /home (on separate drive....)
4.0K /initrd
0 /initrd.img
0 /initrd.img.old
253M /lib
16K /lost+found
690M /media
8.0K /mnt
6.8M /opt
0 /proc
7.7M /root
6.1M /sbin
4.0K /srv
0 /sys
3.3M /tmp
2.1G /usr
307M /var

/var/cache/apt only 107M

Try apt-get clean to clear the apt/dpkg packages cache and you might want to install localepurge and say yes to remove the man pages as well if asked.

Hi - yes I've cleared the apt cache, which has claimed me back just under 100M, but I'm still very puzzled as to why I have an almost full disk.... It's not quite 5G, it's 4.6G, but even so, I only have 102M free.

As you can see, it's all in /usr.

Actually, if you add up the contents above (excluding the CDROM that's listed in /media) you get about 2.7G - so where's all the rest????

Do you have a large core dump in /? I've seen X dump core in root before and fill the whole thing. Or some other large files in /?

Alas, no. I can't "find" any large files (in / or anywhere for that matter). Could ext3 get messed up by hard reboots?

Unless my math is way off that doesn't look like it should be talking up 4.6G it should be closer to about 3G.

du -hx --max-depth=1
will give you a better idea of how space is being used on that partition (it excludes other devices)

also check
df -h
take make sure the partition is really that full.

In my experience its very easy to go over 5G for a root partition once you start installing a lot of extra programs. The only way to reduce the size of /usr is to uninstall programs that you are not using. You can also cut down the size of /lib by uninstalling extra kernels and modules.

Thanks for help. All my original figures I got from df -h, but I am going to remove some of the useless fonts that I don't need and some other redundant modules.

I have a feeling this is a misreporting issue. As I said above, I made it about 2.7G, so something is reporting it incorrectly.

I'm going to boot up with a live CD (Puppy) and examine the disk from that.

----------------
mazzo,

I don't think /usr is abnormal.

I had an almost identical problem yesterday.

couldn't find an LARGE files anywhere. I finally
used 'find / -xdev -size +10000 -exec ls -l {} \; | sort > filename.txt'

And I noticed about 1.3 gb was shown from
/media/stg1 which is a memorystick but was
being reported as part of / partition.

I went to /media and deleted the stg1 and all
is well. But I see this thread is 5 days old so
maybe you have it solved by now.

Larry

Since this thread is already here and frob23's suggestion about core dumps helped me, I'll just tack my problem onto it.

I have started having problems with OpenOffice. Namely, <soffice> gets me to the blank OpenOffice screen, but when I attempt to open a file, it gives this error message:

“OpenOffice.org could not save important internal information due to insufficient free disk space at the following location:
/home/castanea/.openoffice.org2/user/backup
You will not be able to continue working with OpenOffice.org without allocating more free space at that location. Press the 'Retry' button after you have allocated more free disk space to retry saving the data.”

Then, with the OpenOffice window still open, I run another <xterm>, and within it try to run <mc>, it gives the message:

“Cannot create temporary directory /tmp/mc-castanea: No space left on device (28). Temporary files will be created in /tmp. Press any key to continue.” When you do so, it works fine. I went to the space indicated in the OpenOffice error message, and .../user/backup was empty.

I eventually got out of X, and moved about 500MB of things out of /home/castanea. I tried <startx> and <soffice> again, and had the same problem, likewise with <mc> while in <xterm> (mc gives no error message outside of X)

<df> returns that /dev/hdb1 which is /mnt/home is only 5% full. That is fine, but I see that /dev/hda1 is 100% full: 1K blocks = 9345096, Used = 9344140. This is mounted as /, and being virtually full is not fine, I suspect.

For what it is worth, /dev/hda is a 10 GB drive, with 9.722 GB as /, 263 MB as swap, and 247 MB as /tmp. /dev/hdb is a 30 GB drive; about 10 GB as /home and 20 GB as /usr.

And likewise for what it is worth, my operating system, grml, is a version of Debian, running the kernel version 2.6.18

As frob23 suggested in this thread, I thought that X might be filling the root up with core dumps, and indeed there was a core dump there of approx. 169 MB. I moved it to a temporary location in /usr, where there is plenty of room.

<du -hs /*> (as a response to a suggestion in another thread) returns a normal-looking list (this is after doing the file-moves mentioned above). Highlights:

844 M /backup
11 M /bin
12 M /boot
34 M /etc
527 M /home (this is /dev/hdb1, which is 10GB)
75 M /lib
130 M /proc
5.2 M /root
24 K /tmp
7.1 G /usr (this is /dev/hdb2, which is 20 GB)
233 M /var
(nothing else is as large as 1 MB).

I rebooted with a live CD and ran <e2fsck> on /dev/hda1 (while it was unmounted), and it reported that it was clean, but confirmed that it was almost full. I ran it on /hdb1 and /hdb2 as well; likewise clean, with plenty of space.

OpenOffice still behaves the same way, running it as castanea. I can, however, run it as root with no difficulties – but I don't like to do that.

Anyway....

I strongly suspect that my OpenOffice problems are related to /hda1 being almost full. But I don't see what could be filling it up, nor do I see what else I might try to fix it.

Any ideas?

Did you run e2fsck with the -f option? By default fsck only checks that the partition was cleanly unmounted and how many times its been mounted since the last time it was checked. With the -f option it forces it to actually check all the information in the partition.

Scribles, thanks for the suggestion. No, I didn't try that (I have now – thanks).

It turns out the answer was much simpler, and just one of my New User Dumb Moves.

I got to wondering why I moved things out of /home into /usr because /usr was on /hdb2 and had plenty of room – yet, the usage of /hda1 remained unchanged, even after I moved gigabytes worth of files.

Simple. /usr is still on /hda1, not /hdb2 as I thought. So is /home, and everything else. I thought I had edited /etc/fstab in such a way that /usr and /home were on /hdb. Indeed, <mount> showed /mnt/home=/hdb1 and /mnt/usr=/hdb2.

Silly me; I thought that /mnt/home was equal to /home, and the same for /usr. Not so. When I started poking around with <mc> on /hda1, after mounting it from a live CD boot (and not mounting /hdb1 or /hdb2), I saw that /home and /usr were, indeed, still on /hda1, and pretty much nothing was on /hdb1 or /hdb2. What WAS there were the directories /mnt/home and /mnt/usr, not that they were doing me any good.

I have moved lots of things over to /hdb1 and /hdb2, my /hda1 is down to 52% usage, and the computer works fine once again. In the process, I learned about some of the neat tools for disk management in Linux. Live and learn!