Results 1 to 14 of 14
Like Tree2Likes
  • 1 Post By ArchonAdvisors
  • 1 Post By Jay Patel15
  1.    #1  
    I'd been having the Doctor 12% error for the last few days and followed OneBadTaz thread http://forums.precentral.net/webos-i...sue-fixed.html to try to fix it. Unfortunately none of the info in that thread helped me. I first noticed something was wrong when Icouldn't write anything to /media/internal and it would stay. Finally last night I noticed something odd. I typed a pvscan in novaterm and it returned something like 14.19GB of space... This is a 32GB TP with a 32GB model #. I confirmed in system info this thing says it has 16GB of memory.

    I did have two TP's I gave the other which was a 16GB to a friend.. Any chance that hp backup stuff could have pulled in her info into mine (both are still in my name)?

    HP is already sending a box, but was just putting this out there because I've talked to other folks who have the 12% failure and the other fixes aren't working for them.
  2. #2  
    Did you have any success with this?
    You said that pvscan found a smaller size than expected (close to 16GB).

    In mine I get:

    Code:
    # pvscan
      PV /dev/mmcblk0p14   VG store   lvm2 [29.07 GB / 0    free]
      Total: 1 [29.07 GB] / in use: 1 [29.07 GB] / in no VG: 0 [0   ]
    It appears that /dev/mmcblk0p14 is just part of the block device /dev/mmcblk0 (flash or similar) which has a number of different partitions, and partition p14 is the part that is used as the main physical volume seen in pvscan.

    What do you get from /proc/partitions like this...

    Code:
    # cat /proc/partitions
    major minor  #blocks  name
    
     179        0   31160320 mmcblk0
     179        1     102400 mmcblk0p1
     179        2        500 mmcblk0p2
     179        3       1500 mmcblk0p3
     179        4          1 mmcblk0p4
     179        5        500 mmcblk0p5
     179        6        750 mmcblk0p6
     179        7       2500 mmcblk0p7
     179        8      10240 mmcblk0p8
     179        9       1500 mmcblk0p9
     179       10       3072 mmcblk0p10
     179       11       3072 mmcblk0p11
     179       12       4096 mmcblk0p12
     179       13      32768 mmcblk0p13
     179       14   30504960 mmcblk0p14
     254        0     581632 dm-0
     254        1      65536 dm-1
     ......
     ......
    What size is that first mmcblk0 partition?
    Is it close to 32GB as in the listing above, or is it closer to 16GB?
  3. #3  
    Sorry for reviving an old thread, but after searching the forums, this thread appears to be the only thing actually on point with the issue I have come across.

    I am investigating a 32GB HP Touchpad that will not go past 12% in any version of the webos doctor. All attempts to follow the webOS internals procedures for manually rebuilding the filesystem have been completed but yield no better result when running the doctor.

    Current observations:
    -Looking at /proc/partitions, the main block device mmcblk0 reports as 32GB, but mmcblk0p14 only reports as around only 16GB, instead of the expected ~30GB.

    -The touchpad DOES allow me to write to and otherwise manipulate the filesystem (file additions, changes, and deletions stick across reboots just fine as well, so it does not appear to be a read-only failsafe mode hardware failure some people have encountered with their flash memory controller)

    ----------------------

    Here are the contents of /proc/partitions:

    Code:
    major minor  #blocks  name                                                      
                                                                                    
     179        0   31160320 mmcblk0                                                
     179        1     102400 mmcblk0p1                                              
     179        2        500 mmcblk0p2                                              
     179        3       1500 mmcblk0p3                                              
     179        4          1 mmcblk0p4                                              
     179        5        500 mmcblk0p5                                              
     179        6        750 mmcblk0p6                                              
     179        7       2500 mmcblk0p7                                              
     179        8      10240 mmcblk0p8                                              
     179        9       1500 mmcblk0p9                                              
     179       10       3072 mmcblk0p10                                             
     179       11       3072 mmcblk0p11                                             
     179       12       4096 mmcblk0p12                                             
     179       13      32768 mmcblk0p13                                             
     179       14   14895104 mmcblk0p14
    Notice that mmcblk0p14 strangely reports a size of 14895104 (instead of 30504960 as expected), although the main block device (mmcblk0) still reports a proper size of 31160320. Running pvscan also shows mmcblk0p14 as only around 16GB.

    I have tried deleting the partition and recreating it by writing it with dd. I have also tried to use pvcreate with the --setphysicalvolumesize parameter, but the resulting volume throws an error from mkdosfs when attempting to format it.

    Even if I ultimately cannot correct the space problem, I'd hope to at least get the doctor to simply ignore it and treat the tablet as though it is only 16GB and proceed installing.
    Last edited by ArchonAdvisors; 08/23/2013 at 12:09 PM.
  4. #4  
    Did you try the 3.0.0 Doctor? It seems to have some more magical skills compared to later versions :-)

    -- Sent from my TouchPad using Communities
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  5. #5  
    Quote Originally Posted by Herrie View Post
    Did you try the 3.0.0 Doctor? It seems to have some more magical skills compared to later versions :-)

    -- Sent from my TouchPad using Communities
    Yup, tried every version of the doctor...this goes beyond that. Even the 3.0.0 doctor throws a fit if most things don't appear just the way it wants them. Thanks though, I wish that was the answer.
  6. #6  
    There's a way to completely dump the partitions and rebuild them, would neee to look through my scripts. Used this for restoring the 2.2.4 Veer backup before the Doctor method was available. With some changed settings that should work for the TP too.

    -- Sent from my TouchPad using Communities
    Last edited by Herrie; 08/24/2013 at 02:18 PM.
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  7. #7  
    Sounds interesting! I'd be grateful to have a look at those scripts if you can find them. I figure the block device partitions need to be dumped at a lower level than what the various LVM commands do.
  8. #8  
    Quote Originally Posted by ArchonAdvisors View Post
    Sounds interesting! I'd be grateful to have a look at those scripts if you can find them. I figure the block device partitions need to be dumped at a lower level than what the various LVM commands do.
    I'll contact you by PM, too risky to post out here
  9. #9  
    Quote Originally Posted by ArchonAdvisors View Post
    Sounds interesting! I'd be grateful to have a look at those scripts if you can find them. I figure the block device partitions need to be dumped at a lower level than what the various LVM commands do.
    (Just to follow up on this part of the discussion, the scripts provided were running the LVM functions of the touchpad which unfortunately I had already tried without success.)
  10. #10  
    [SOLVED!]

    The following is the process I performed to bring this touchpad to full working order. Please FULLY charge your touchpad before proceeding:

    Checking /proc/partitions showed that although this was a 32GB touchpad, the /dev/mmcblk0p14 partition was only set to 14.9GB, around the appropriate size for a 16GB touchpad. All versions of webOS doctor would fail at 12%. The LVM based commands for on How To Recover - WebOS Internals and elsewhere on the web would only rebuild the filesystem within the current constraints of the block device partitions.

    Unable to otherwise modify the block device scheme. I decided to try the "nuclear option" and wipe the partition table of the entire flash memory block device, /dev/mmcblk0. (WARNING- THIS IS A LAST RESORT AND YOU ARE ESSENTIALLY "BRICKING" YOUR TOUCHPAD INTENTIONALLY, POTENTIALLY PERMANENTLY) This was done by getting to a novaterm shell and running the command :

    Code:
    dd if=/dev/zero of=/dev/mmcblk0 bs=512 count=1
    As mentioned, this puts the touchpad into a totally bare and "bricked" state. After rebooting you will see absolutely nothing on the screen and you will not even be able to boot into webOS recovery ("bootie") mode. The touchpad will appear powered off.

    The next step is to download several files and follow a debricking procedure. First you will want to download any files and follow the instructions of the TPDebrick v0.4 utility available at http://rootzwiki.com/topic/38786-tpdebrick-v004/ . You will also want to have the webOS 3.0.0 doctor in addition to the 3.0.5 doctor for later from http://www.webos-internals.org/wiki/...ions#Wifi_Only . Return here to finish when done with the TPDebrick utility.

    NOTE: The TPDebrick utility runs on Ubuntu 12.04, but you will likely have trouble with the utility if you are it running it on Ubuntu in a virtual machine (virtualbox, vmware, etc.) because of the low level hardware access that takes place. It is HIGHLY recommended to create a live CD or live USB stick with Ubuntu to boot it up natively instead.

    Once the TPDebrick utility has successfully completed, reboot your touchpad by holding power+volumeup+home, and enter "bootie" recovery mode by continuing to hold volume-up until you see the USB symbol. At this point you should run the webOS 3.0.0 doctor, and when it completes, reboot your touchpad with the keys again and get to bootie once more. Now run the webOS 3.0.5 doctor and let it complete. If all goes well, your touchpad will be operational like normal at this point. Go ahead and create sign-in with your webOS profile.

    Once booted into webOS, go to device info and check available space. If "Memory" says 32GB, but "Available" only shows something less than 16GB, then there is still more to do if you want to have all of your storage on your now working touchpad. (In theory however, you could stop here and still use the touchpad like a 16GB model.)

    First, enable developer mode on your touchpad. Then run novaterm and connect to open a root shell.

    Check /proc/partitions to confirm that at least the block device partitions are now correct.

    Code:
    cat /proc/partitions
    Take a look at the last line below for mmcblk0p14. If your output looks about the same then you are still on track to finish. Make a note of the large number next to mmcblk0p14 (usually 30504960) since you will use this in a command soon.

    major minor #blocks name

    179 0 31160320 mmcblk0
    179 1 102400 mmcblk0p1
    179 2 500 mmcblk0p2
    179 3 1500 mmcblk0p3
    179 4 1 mmcblk0p4
    179 5 500 mmcblk0p5
    179 6 750 mmcblk0p6
    179 7 2500 mmcblk0p7
    179 8 10240 mmcblk0p8
    179 9 1500 mmcblk0p9
    179 10 3072 mmcblk0p10
    179 11 3072 mmcblk0p11
    179 12 4096 mmcblk0p12
    179 13 32768 mmcblk0p13
    179 14 30504960 mmcblk0p14
    Run the following commands to temporarily disable and unmount the part of the filesystem that is being adjusted (the "mount | grep" commands on the 3rd and 5th line should produce no output)

    Code:
    pkill -SIGUSR1 cryptofs
    umount /media/cryptofs
    mount | grep cryptofs
    umount /media/internal
    mount | grep internal
    Now run the following command to manually set the size of the physical volume to use the whole block device partition. In this case it is 30504960k (don't forget the k) but if the number you noted from /proc/partitions is slightly different, then use that

    Code:
    lvm.static pvresize /dev/mmcblk0p14 --setphysicalvolumesize 30504960k
    Next, run the following command to set the logical volume to in turn make use of all free space on the now enlarged physical volume.

    Code:
    lvm.static lvresize -l +100%FREE /dev/mapper/store-media
    Run this command to get a new readout of the current logical volume sizes.

    Code:
    lvm.static lvscan
    Look for the line that references /dev/store/media and note the size (in this case it is 27.55GB)

    ACTIVE '/dev/store/media' [27.55 GB] inherit
    Now, run this command to resize the filesystem so that it uses all of the now enlarged logical volume (in this case 27.55G)

    Code:
    resizefat /dev/mapper/store-media 27.55G
    Lastly, run this command to check and fix the filesystem for any errors

    Code:
    dosfsck -a -v /dev/mapper/store-media
    Now reboot your touchpad one last time and enjoy!

    _
    Last edited by ArchonAdvisors; 11/06/2013 at 03:54 PM.
    MartinH@webos likes this.
  11. #11  
    cat /proc/partitions
    gives me this
    179 0 31160320 mmcblk0
    179 1 102400 mmcblk0p1
    179 2 500 mmcblk0p2
    179 3 1500 mmcblk0p3
    179 4 1 mmcblk0p4
    179 5 500 mmcblk0p5
    179 6 750 mmcblk0p6
    179 7 2500 mmcblk0p7
    179 8 10240 mmcblk0p8
    179 9 1500 mmcblk0p9
    179 10 3072 mmcblk0p10
    179 11 3072 mmcblk0p11
    179 12 4096 mmcblk0p12
    179 13 32768 mmcblk0p13
    179 14 30504960 mmcblk0p14
    254 0 581632 dm -0
    254 1 65536 dm -1
    254 2 16384 dm -2
    254 3 24576dm -3
    254 4 262144dm -4
    254 5 139264dm -5
    254 6 11075584dm -6
    254 7 524288dm -7
    254 8 409600dm -8
    254 9 204800dm -9
    254 10 1572864 dm -10
    254 11 262144 dm -11
    254 12 139264 dm -12


    pkill -SIGUSR1 cryptofs

    worked

    but at
    lvm.static pvresize /dev/mmcblk0p14 -setphysicalvolumesize 30504960k

    give error
    invalid option -- "s"
    error during parsing of command line

    ???
  12. #12  
    Quote Originally Posted by Jay Patel15 View Post
    cat /proc/partitions
    gives me this...

    ...pkill -SIGUSR1 cryptofs

    worked

    but at
    lvm.static pvresize /dev/mmcblk0p14 -setphysicalvolumesize 30504960k

    give error
    invalid option -- "s"
    error during parsing of command line

    ???
    I think I made a small typo in my instructions then, which I have now adjusted. Try that command with 2 dashes so it looks like this:

    lvm.static pvresize /dev/mmcblk0p14 --setphysicalvolumesize 30504960k

    It looks from your /proc/partitions that your mmcblk0p14 is already 30504960k, but you can go ahead and run the command anyway if you like.
  13. #13  
    it worked...thanks a lot
    ArchonAdvisors likes this.
  14. #14  
    Quote Originally Posted by Jay Patel15 View Post
    it worked...thanks a lot
    Glad to help.

Posting Permissions