[Novalug] Still a Problem: re: full root partition problem
Roger W. Broseus
RogerB at bronord.com
Fri Oct 17 12:54:05 EDT 2008
First, thanks to Peter, Anthony and Joh, especially for the instructive
pointers about pointers in /proc.
Please bear with me in this "learning experience."
The backup was destined for an external drive so I don't think this was a
matter of the dragon eating it's own tail. And, the files never showed-up
on the external drive - not even in parts - I did periodic looks to see if
anything was growing there. I'm guessing that, as others pointed out,
there were tmp files in-process and that the backup job failed with space
disappared (this was a BIG backup).
I have not found any temp files that might have been left behind by an
incomplete backup. More . . .
On Thu, October 16, 2008 11:33 pm, Peter Larsen wrote:
> On Thu, 2008-10-16 at 23:07 -0400, Roger W. Broseus wrote:
>> I'm getting a report that / is nearly 100% full. It is on a separate
partition that is 19 GB. This occurred after I tried doing a backup with
>> Simple Backup under Ubuntu.
> First of - LVM would have made things a lot easier for you. There really
isn't a reason NOT to use it anymore.
There was for me: I did not understand usage enough (!) to feel
comfortable and I've got a lot of space on HDs. I did enjoy your talk on
LVM tho and studied on this quite a bit.
>> The combined size of
>> bin, dev, etc, initrd, lib, mnt, opt, proc, sbin, srv,
>> sys, tmp. usr,var, initrd.img, initrd.img.old,
>> vmlinuz and vmlinzu.old
>> is 4.5 GB.
> What does "du -sh /" report?
>> I have the following on separate partitions: /boot and /home.
> So /tmp is part of / - that's most likely where you're having issues.
I don't think so: as root using nautilus, looking at /tmp, after a reboot,
I see no files created before today. If I boot to command line, there's
not much in /tmp. /var looks "normal" too.
>> I can not find what is eating up all of that disk space on / but it
appears to have happened when I ran Simple Backup, which seems to be a gui
>> for gzip.
> du is your friend. du = disk usage. It will report where things are
allocated. There's actually a very cool gnome tool called Baobab - a disk
usage analyzer. It makes a very interesting layout of your data.
Interestingly, baobab crashes after initiating with an error message
(repeated 13 times):
Failed to contact configuration server; some possible causes are that you
need to enable TCP/IP networking for ORBit, or you have stale NFS locks
due to a system crash. See http://www.gnome.org/projects/gconf/ for
information. (Details - 2: IOR file '/tmp/gconfd-root/lock/ior' not
opened successfully, no gconfd located: No such file or directory)
I'm guessing this is a symptom, and not a cause, of a constipated /
> To see where data is allocated, you simply do: du -s /*
> It should list all directories/files in root and their summarized size.
as root in dir /, du -s /* reports, with my ##comments interspersed (## is
NOT output from du):
## this does not make sense to me becuse /home is on a SEPARATE
## but the size is about right. Is this just a "pointer"
## like in /proc?
0 /link to pics sda1
## again, not making sense: if, as root, I cd to /
## all I see is /"Desktop" which is empty
So, with the two exceptions mentioned, I still don't see an reason for /
to be reported as full.
>> I've searched for a large file or folder but am at a loss to find the
> You're most likely having "temporary" files all over the place. But it
really depends on what you asked the "simple backup" program to do. So
once you know where disk is allocated, you may still have to revisit your
As mentioned above, I'm sure this is related to the backup job but I'm
Thanks again, all who have taken a look at this.
More information about the Novalug