Page 3 of 7 FirstFirst 1234567 LastLast
Results 41 to 60 of 130
Like Tree11Likes
  1. AMR-1's Avatar
    Posts
    258 Posts
    Global Posts
    261 Global Posts
    #41  
    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.
  2. #42  
    Quote Originally Posted by amrcc View Post
    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.
    Last edited by jblather; 10/20/2011 at 07:01 PM.
  3. #43  
    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 likes this.
  4. #44  
    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.

    Last edited by leobloom; 10/20/2011 at 06:52 PM. Reason: added a photo :)
  5. #45  
    The number of positive and negative reviews is back.
  6. #46  
    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...
    Palm III > Palm V > Palm Vx > (Sprint) Kyo 6035 > Handspring Treo 300
    > Handspring Treo 600 Oct.'03 > Palm Treo 700P May'06 > Treo 755P Aug.'07 > Pre(-) June'09 + TouchPad July'11 LONG LIVE webOS!!!
  7. #47  
    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).
  8. #48  
    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
    Attached Images Attached Images
  9. #49  
    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 "..".
  10. #50  
    Quote Originally Posted by Stamponephoto View Post
    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:

    Code:
    # 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):

    Code:
    # 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.
    Last edited by alex80386; 10/22/2011 at 06:18 PM. Reason: du command options
  11. #51  
    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?
  12. #52  
    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.
  13. #53  
    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.
  14. #54  
    Quote Originally Posted by alex80386 View Post
    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
    Attached Images Attached Images
  15. #55  
    Quote Originally Posted by Stamponephoto View Post
    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.
    Last edited by alex80386; 10/22/2011 at 08:10 PM.
  16. #56  
    Quote Originally Posted by Stamponephoto View Post
    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.
  17. #57  
    Quote Originally Posted by jblather View Post
    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
    Attached Images Attached Images
  18. #58  
    Ha, you forgot the "ls" command itself.
  19. #59  
    Quote Originally Posted by jblather View Post
    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
    Attached Images Attached Images
  20. #60  
    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.
Page 3 of 7 FirstFirst 1234567 LastLast

Tags for this Thread

Posting Permissions