[AMR-1]

Even if we can get a GUI utility (or pluggin to an already existing one) that shows us the 100% Full Filesystems and lets us poke around in them, that would make it easier to determine what is wrong.

[jblather]

They definitely added the new error box "...not enough space..." in 3.04.

Yes, I noticed that. I'm glad they did that. The issue is telling users how to fix it. Normal users have no idea how to fix it nor do they know what files are important and which are not.

[jblather]

Well, once you start doing that (give them a GUI), then pretty soon, you have a thing called the shell or something that looks like a file explorer. Might as well just point them to Internalz or Xecutah/Xterm.

Again, this poses problems for normal users. How do they know which files are important and which they can safely delete?

Yes, we can tell users something filled up, but then what is the normal user to do about this? You show them a carrot, but then you make it impossible for them to reach it because they don't know how...

[leobloom]

HP have released an update to the App Catalog its now version 5.02.2210 and also a 2nd HP Catalog App shows up in the Software Manager as a Payment Service. Still having issued downloading/updating certain Apps.

[jblather]

The number of positive and negative reviews is back.

[ChemEngr]

Same issue here! Yes, I have MaptoolPro. i actually deleted a maptool directory (6 GB) to see if it resolves the issue. I gave up and about to doctor but decided to look it up here as I always do. So the question is now do I wait for a layman's resolution to this issue (are the updates worth it right now?) or do I bite the bullet and doctor? I have the doctor ready...

[jblather]

ChemEngr,

Do a 'df -h' and see which filesystems are full. You might find that /var/file-cache is 100%.

If it is, take a look under /var/file-cache/attachment. Mine was gigantic and I removed that entire directory (and then recreated an empty one).

[Stamponephoto]

OK, so I am getting the "No space left" error when I try to install uberkernal. I have 21GB available, I am running 3.0.4 and I have not installed CM on my Touchpad, and I don't have maptoolspro. On the advice of another thread, I checked the available space on my partitions (see attached) Now I am in no way a programer, It sounds like, based on this thread, I have somehow filled up some backend folder with unnecessary files, and I just have to clear it out. The problem is, if that is the case, I have no idea how to do this or what I am looking for. Any help would be greatly appreciated

[jblather]

I don't know how that got filled up, but take a look inside /dev/.static/dev. Issue the command "ls -aF | more" and see if there are any regular files or directories.

I think the only things you should see in there are block and character device files. Those are identified with a "b" or a "c" as the very first character. I don't think you should see any directories or regular files in there other than "." and "..".

[alex80386]

OK, so I am getting the "No space left" error when I try to install uberkernal. I have 21GB available, I am running 3.0.4 and I have not installed CM on my Touchpad, and I don't have maptoolspro. On the advice of another thread, I checked the available space on my partitions (see attached) Now I am in no way a programer, It sounds like, based on this thread, I have somehow filled up some backend folder with unnecessary files, and I just have to clear it out. The problem is, if that is the case, I have no idea how to do this or what I am looking for. Any help would be greatly appreciated

Your root filesystem / is 100% full.
Here is mine for the boot and root filesystems:

# df -h
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                31728     22816      8912  72% /boot
/dev/mapper/store-root
                        572468    454784    117684  79% /

Not sure how it happened, but you might have to doctor... at least it could be easier than going through all the directories in / and finding what is eating the extra space.

Perhaps this helps (mine after 3.0.4 and UberKernel):

# du -xsh /* | grep -v media
8.0K    /Settings
1.3M    /bin
18.3M   /boot
208.0K  /dev
6.0M    /etc
4.0K    /home
13.2M   /lib
16.0K   /lost+found
444.0K  /md5sums.gz
4.0K    /mnt
17.9M   /opt
0       /proc
4.5M    /sbin
0       /sys
428.0K  /tmp
402.2M  /usr
5.1M    /var

But if that doesn't immediately help find where the space is being used, then time for webOS doctor.
How To Recover - WebOS Internals

Edit: Perhaps there will be a few small differences as mine has some extra fonts in /opt and a few other minor patches.

[Stamponephoto]

So, I looked at this and quickly realized that I was in over my head. I am just going to try and doctor it, which I have not done yet. One quick question: Do I have to do a full erase before I doctor for a problem like this, or can I just doctor it as is?

[alex80386]

I'd be interested to know the results of the following commands (for those people that have the full root filesystem problem).

# df -h /

# du -xsh /

# du -xsh /* | grep -v -e media -e boot -e var -e tmp

I'm getting about 428MB for the second one.

To answer the question, you shouldn't need to do full erase... most people doctor because they have a complete lock up and of course for them, there is no way they can erase.

[jblather]

I agree. Doctoring it is probably unnecessary and overkill for what could be a simple problem.

Execute the commands that alex80386 has presented and report back here. There could be a simple solution to this.

[Stamponephoto]

I'd be interested to know the results of the following commands (for those people that have the full root filesystem problem).

# df -h /

# du -xsh /

# du -xsh /* | grep -v -e media -e boot -e var -e tmp

I'm getting about 428MB for the second one.

To answer the question, you shouldn't need to do full erase... most people doctor because they have a complete lock up and of course for them, there is no way they can erase.

Well I hope this means something to you, cause it Greek to me

I can hold off on doctoring, if you think you can help. I really wasn't looking forward to it anyway. I just didn't know how else to get uberkernal back on. Thanks for your help

[alex80386]

I can hold off on doctoring, if you think you can help. I really wasn't looking forward to it anyway. I just didn't know how else to get uberkernal back on. Thanks for your help

Comparing your results and mine for a reference.

# df -h /

559.1M 557.9M 1.1M 100%
559.1M 444.1M 114.9M 79% <--- mine

# du -xsh /

425.9M /
427.6M / <---- mine

So while we have almost the same output from the 'du' command, there is a big difference between that and the output of 'df'. It is normal for there to be some difference, due to:

1. file system metadata not counted in the du command.
2. sometimes different block size used with different commands.
3. perhaps something cached and not written to a file (so not reported in 'du').
4. other(?)

But I don't think the difference should be that large (more than 20% in your case). So assuming you have tried a shutdown and restart and we can eliminate #3, then I'm guessing your file system metadata might be screwed up and I don't think there is any way to fix that other than using the doctor.

[jblather]

Well I hope this means something to you, cause it Greek to me

I can hold off on doctoring, if you think you can help. I really wasn't looking forward to it anyway. I just didn't know how else to get uberkernal back on. Thanks for your help

oops..you gave the "ls -aF..." command in the wrong directory.

Do this:

cd /dev/.static/dev
ls -alF | more << --- note the command changed a little bit.

What I'm looking for here is what file(s) are filling up your /dev/.static/dev directory. Mlaybe a simple "rm..." will take care of it.

[Stamponephoto]

oops..you gave the "ls -aF..." command in the wrong directory.

Do this:

cd /dev/.static/dev
ls -alF | more << --- note the command changed a little bit.

What I'm looking for here is what file(s) are filling up your /dev/.static/dev directory. Mlaybe a simple "rm..." will take care of it.

Here you go

[jblather]

Ha, you forgot the "ls" command itself.

[Stamponephoto]

oops..you gave the "ls -aF..." command in the wrong directory.

Do this:

cd /dev/.static/dev
ls -alF | more << --- note the command changed a little bit.

What I'm looking for here is what file(s) are filling up your /dev/.static/dev directory. Mlaybe a simple "rm..." will take care of it.

Ignore the last post (I mistook the l for a | [how could I have been so stupid] )

I think this is what you asked for

[jblather]

I had expected to find some regular files in there, filling up the filesystem. I don't see anything out of the ordinary in that directory that 'df' thinks is 100% full.

There's something taking up a crap load of space...

I went back to post #54 of this thread and just noticed that /usr has 400+ meg. Sorry, I didn't catch this earlier!

Dive into /usr and see if you can find and giant files or directories in there.
Doing a "du -sh /usr/*" would help.