Page 1 of 3 123 LastLast
Results 1 to 20 of 48
Like Tree28Likes
  1.    #1  
    I'm a regular at the Chicago webOS meetups, and one of the things we do there is help each other with issues we are having with our webOS devices. It can be software-related, like bypassing activation on a newly-acquired phone or tablet, getting Preware setup for a new user, or updating root certificates.

    Sometimes we try to deal with issues people have with hardware, although we can't do anything too involved at the Moretti's restaurant in Schaumburg, IL that we usually meet at, we do what we can. If we have to, one of us who has the expertise will offer to take a device home to work on over the coming days and weeks, so that disassembly can take place. I once took home a fellow member's TouchPad Go to remove a SIM card that had somehow slipped inside the case, in order to disassemble it and rescue the card, and put it back together. creepingmee, who organizes the Chicago webOS meetups, sometimes does the same with other people's phones. We usually meet in-person with the owner after we have fixed whatever problem was encountered with the device, and return their device to them, hopefully in working order.

    At the most recent meetup we had on April 17th, 2016, one of the folks who comes occasionally was there, and brought his 64GB TouchPad that he had bought a while ago off eBay, as an "as-is/broken" purchase.

    He had brought it a few months earlier, and at that time, creepingmee had tried a couple of things with it, but had no luck. It was at this point that I got interested and asked creepingmee what he had done so far, and he then suggested that I try membooting it. I said, "memboot, what's that?" So creepingmee showed me how to memboot webOS, and how you could proceed to use novaterm to log in to the device, and you had access to the underlying Linux command prompt in webOS to take a look around and see what's wrong. (For more information on how to memboot, see Memboot - WebOS Internals).

    Well, during that first encounter late last year with that 64GB TouchPad, we didn't have much time to diagnose what was wrong, much less try to fix it, so it went home with its owner. But at this more recent meetup, the non-working 64GB TouchPad was back, and I offered to take it home and take a look at it over the next few nights and see if I could fix it. So the owner and I exchanged e-mail addresses and phone numbers, so we could keep in touch. There is an element of trust in these meetups that gets built up after seeing the same folks at several of these meetups, that allows for one of us to take anothers precious webOS device home and work on it. You probably wouldn't do that with a perfect stranger. Also, those of us that take devices home to try to fix them know to take a bit more care - we don't own the devices, and at least when do this, I communicate with the owner as to what exactly I will do ahead of time, so there are no surprises.

    Well, I know that was a bit long-winded, but in the end, I was actually able to get that 64GB TouchPad working again no problem, right back to stock webOS 3.0.5. Now because I ran into some things that weren't well documented anywhere I could find on the Internet, and would probably be useful to other folks who are trying to revive a 64GB TouchPad in the future, I thought I would document the steps I took to revive it in this thread.

    I run Fedora Linux on my machines at home, so this will be documented from that standpoint. Also, I will skip over details on some things, like how to extract a webOS boot image from a doctor file. But otherwise, I think this should be useful no matter what operating system you're running on your desktop.
  2.    #2  
    The TouchPad would turn on and show the HP logo on the screen, but would never go beyond that. It never even got to the pulsating HP logo, where it changes from bluish to whitish and back again.

    It could be hard-reset by holding down the power button and center button at the same time for a few seconds, until the screen went blank.

    After a reset, it could be put into recovery mode, or bootie mode, by holding the power button and volume-up button until the big white USB logo appeared.

    Investigation

    Running the webOS Doctor at this point always resulted in a failure, somewhere around 4% or 8% or 9% - I forgot exactly where, and didn't document this, unfortunately.

    So, the next thing I did was memboot it. This is equivalent to booting a PC from a USB stick or CD-ROM when the hard drive is broken. When you memboot, you send a boot image from your desktop PC/Mac/Linux box to your ailing webOS device over the connected USB cable. After the memboot is complete, you can then run the novaterm command from your PC/Mac/Linux machine to connect to the environment that you just started (via memboot) on your webOS device.

    (Novaterm comes with the webOS SDK. If you don't already have the webOS SDK installed, I suggest reading this article on pivotce.com: https://pivotce.com/2015/12/20/legac...and-emulators/)
    (More details on memboot - Memboot - WebOS Internals)

    So, just like booting a PC from a USB flash disk when you have trouble with your hard drive, it was time to see if something was wrong with this TouchPad's "hard drive" (flash storage).

    webOS uses a linux storage concept called logical volumes (https://en.wikipedia.org/wiki/Logica...er_%28Linux%29) so the way I started is by checking the logical volume group:

    Code:
    root@webos-device:/# lvm.static vgscan --ignorelockingfailure
      Reading all physical volumes.  This may take a while...
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
      Volume group "store" inconsistent
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
      WARNING: Inconsistent metadata found for VG store - updating to use version 9
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
      Automatic metadata correction failed
    Right off the bat, just trying to examine the volume groups in the system results in error messages, so that's not good.

    I noticed the familiar linux device notation mentioned - "/dev/mmcblk0p14". It turns out that this is the linux block device that the volume group is built on. It turns out that all TouchPads build the one storage group they use on this same device - /dev/mmcblk0p14. (webOS phones, running webOS 2.x, seem to use /dev/mmcblk0p3 for this.)

    I googled, and found a command that would check the integrity of the physical volume that the volume group was based on more thoroughly, kind of like the old CHKDSK on DOS, or fsck for a linux file-system:

    Code:
    root@webos-device:/# lvm.static pvck -v /dev/mmcblk0p14
        Scanning /dev/mmcblk0p14
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
      Found label on /dev/mmcblk0p14, sector 1, type=LVM2 001^A
      Found text metadata area: offset=4096, size=8450048
        Found LVM2 metadata record at offset=16896, size=3072, offset2=0 size2=0
        Found LVM2 metadata record at offset=14336, size=2560, offset2=0 size2=0
        Found LVM2 metadata record at offset=11776, size=2560, offset2=0 size2=0
        Found LVM2 metadata record at offset=9728, size=2048, offset2=0 size2=0
        Found LVM2 metadata record at offset=8192, size=1536, offset2=0 size2=0
        Found LVM2 metadata record at offset=6656, size=1536, offset2=0 size2=0
        Found LVM2 metadata record at offset=5632, size=1024, offset2=0 size2=0
      Found text metadata area: offset=63447236608, size=8388608
      /dev/mmcblk0p14: lseek 63447236608 failed: Invalid argument
    Well, that didn't seem to help.

    At this point, it didn't seem likely that the corrupt volume group could be saved, so I decided it was time to remove it and recreate it.
  3.    #3  
    Fortunately, webOS Internals has exactly the infomation we need to remove and re-create the volume group and all the logical volumes within it that webOS uses, here: How To Recover - WebOS Internals

    BUT...if you read the fine print, it says, "The following is for a 32GB TouchPad." What if I have a 64GB TouchPad? The numbers can't all be the same, can they? Each of the logical volumes listed at that link to webOS Internals has a size, and the one used for the media partition:

    Code:
    lvm.static lvcreate -l 3523 -i 1 -M y --major 254 --minor 6 -n media store
    ...would create a logical volume of about 28GB. What's the right number for a 64GB TouchPad? I couldn't find this anywhere, and didn't have another 64GB TouchPad handy to find the right value, so by some other means, I settled on the following value appropriate for a 64GB TouchPad:

    Code:
    
    lvm.static lvcreate -l 7332 -i 1 -M y --major 254 --minor 6 -n media store
    
    This results in about a 59GB media partition.

    OK, so let's give it a go:

    Code:
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static vgremove store
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static vgcreate -s 8M store /dev/mmcblk0p14
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static lvcreate -l 71 -i 1 -M y --major 254 --minor 0 -n root store
    lvm.static lvcreate -l 8 -i 1 -M y --major 254 --minor 1 -n var store
    lvm.static lvcreate -l 2 -i 1 -M y --major 254 --minor 2 -n update store
    lvm.static lvcreate -l 3 -i 1 -M y --major 254 --minor 3 -n log store
    lvm.static lvcreate -l 32 -i 1 -M y --major 254 --minor 4 -n mojodb store
    lvm.static lvcreate -l 17 -i 1 -M y --major 254 --minor 5 -n filecache store
    Up to here, all the commands seemed to work just fine. But then...

    Code:
    lvm.static lvcreate -l 7332-i 1 -M y --major 254 --minor 6 -n media store
    
    Redundant stripes argument: default is 1
      Insufficient free extents (3590) in volume group store: 7332 required
    Uhh...Ok. So the volume group is too small? I don't remember specifying how big it should be when I created it, so how big is it? Well, it turns out it's as big as the lvm physical volume it lives in:

    Code:
    lvm.static pvdisplay
      "/dev/mmcblk0p14" is a new physical volume of "29.09 GB"
      --- NEW Physical volume ---
      PV Name               /dev/mmcblk0p14
      VG Name               
      PV Size               29.09 GB
      Allocatable           NO
      PE Size (KByte)       0
      Total PE              0
      Free PE               0
      Allocated PE          0
      PV UUID               Z6gIBe-gEay-G58w-AUOR-171t-X1A6-OUhCys
    Hmmm...there's probably a lvm command to resize or re-create the physical volume:

    Code:
    vm.static help
    
    Available lvm commands:
      Use 'lvm help <command>' for more information
       
      dumpconfig      Dump active configuration
      formats         List available metadata formats
      help            Display help for commands
      lvchange        Change the attributes of logical volume(s)
      lvconvert       Change logical volume layout
      lvcreate        Create a logical volume
      lvdisplay       Display information about a logical volume
      lvextend        Add space to a logical volume
      lvmchange       With the device mapper, this is obsolete and does nothing.
      lvmdiskscan     List devices that may be used as physical volumes
      lvmsadc         Collect activity data
      lvmsar          Create activity report
      lvreduce        Reduce the size of a logical volume
      lvremove        Remove logical volume(s) from the system
      lvrename        Rename a logical volume
      lvresize        Resize a logical volume
      lvs             Display information about logical volumes
      lvscan          List all logical volumes in all volume groups
      pvchange        Change attributes of physical volume(s)
      pvresize        Resize physical volume(s)
      pvck            Check the consistency of physical volume(s)
      pvcreate        Initialize physical volume(s) for use by LVM
      pvdata          Display the on-disk metadata for physical volume(s)
      pvdisplay       Display various attributes of physical volume(s)
      pvmove          Move extents from one physical volume to another
      pvremove        Remove LVM label(s) from physical volume(s)
      pvs             Display information about physical volumes
      pvscan          List all physical volumes
      segtypes        List available segment types
      vgcfgbackup     Backup volume group configuration(s)
      vgcfgrestore    Restore volume group configuration
      vgchange        Change volume group attributes
      vgck            Check the consistency of volume group(s)
      vgconvert       Change volume group metadata format
      vgcreate        Create a volume group
      vgdisplay       Display volume group information
    vgexport        Unregister volume group(s) from the system
      vgextend        Add physical volumes to a volume group
      vgimport        Register exported volume group with system
      vgmerge         Merge volume groups
      vgmknodes       Create the special files for volume group devices in /dev
      vgreduce        Remove physical volume(s) from a volume group
      vgremove        Remove volume group(s)
      vgrename        Rename a volume group
      vgs             Display information about volume groups
      vgscan          Search for all volume groups
      vgsplit         Move physical volumes into a new or existing volume group
      version         Display software and driver version information
    pvresize looks promising, but turns out not to be. Let's remove and re-create the whole physical volume:

    Code:
    lvm.static pvremove  /dev/mmcblk0p14
      Labels on physical volume "/dev/mmcblk0p14" successfully wiped
    
    lvm.static pvcreate --verbose --zero y /dev/mmcblk0p14
    lvm.static pvdisplay
      "/dev/mmcblk0p14" is a new physical volume of "29.09 GB"
      --- NEW Physical volume ---
      PV Name               /dev/mmcblk0p14
      VG Name               
      PV Size               29.09 GB
      Allocatable           NO
      PE Size (KByte)       0
      Total PE              0
      Free PE               0
      Allocated PE          0
      PV UUID               J2H1WK-N3KV-eEjK-mmH3-kqTT-cOcz-C0kbq5
    Wow, why is it STILL only 29GB intead of closer to 64GB?
    Last edited by George Mari; 05/02/2016 at 06:49 AM. Reason: Fixed typo.
  4.    #4  
    At this point, I did a little more Googling about logical volumes and physical volumes, and realized I could list out what the linux kernel thinks is the size of each disk partition on the TouchPad. It turns out that lvm physical volumes in turn are built on top of disk partitions, so it seemed like it would be a good idea to see how big all the partitions were.

    Code:
    root@webos-device:/# cat /proc/partitions
    major minor  #blocks  name
    
     179        0   62623744 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
    Some explanation - mmcblk0 represents the entire flash storage of the TouchPad - 62 million 1-kilobyte blocks is about 64GB, so that makes sense.

    All the other entries (p1 through p14) represent partitions of that larger storage/block device. mmcblk0p14 is the one that has showed up in all of the error messages so far, and you would expect it's size to be close to 64GB, but a little bit less because a small amount is used for the other partions (p1 through p13) that are used in different ways by webOS.

    What are all the other partitions? I found that mmcblk0p13 is used for the boot partition, but the others I really don't know for sure. I think one may hold the webOS tokens, but again, I'm not sure.

    But on this TouchPad, p14 is only around 30 milling 1-kilobyte blocks, or 30GB.

    If I saw this on a linux PC, I would start up the fdisk program, and use it to re-partition the mmcblk0 device, or just re-size mmcblk0p14 to the right size. But alas, the webOS memboot environment doesn't provide the fdisk program.

    I did find the parted program, but that seems to be broken:

    Code:
    root@webos-device:/# parted
    GNU Parted 1.8.9
    Using /dev/mmcblk0
    Welcome to GNU Parted! Type 'help' to view a list of commands.
    (parted) print devices
    print devices
    Error: Unable to satisfy all constraints on the partition.
    (parted) quit
    quit
    Ok, so if I can't manipulate the partitions directly from the device, what am I going to do?
  5.    #5  
    Note: current location of tpdebrick v004:
    Dev-Host - tpdebrick-v004.zip - The Ultimate Free File Hosting / File Sharing Service
    tpdebrick-v004.zip - alternate location
    tpdebrick-v004.zip - another alternate location

    (Thanks to middle_road for the alternate download locations for tpdebrick-v004.zip)

    At this point, I remembered the tpdebrick utility developed by jcsullins from the TouchPad Android community. I had used it once before to resurrect a non-working TouchPad I bought from eBay, and I remembered that it claimed it could re-write corrupt partitions, or something like that. From the README file:

    Code:
    tpdebrick v004 by jcsullins
    ===========================
    TPDebrick is a suite of programs and files used to "debrick"
    HP Touchpads. This process should allow the revival of Touchpads
    that cannot boot due to corrupted raw partitions, corrupted bootloaders
    or corrupted A6 firmware. Note that this should allow you to get
    into bootie (webOS) recovery mode. Additional steps may be needed
    after to restore the bootie configuration or OS (i.e. webOS doctor).
    In the past, I ignored the strict instructions to run tpdebrick from an Ubuntu 11.04 LiveCD, and tried running it directly from my Fedora Linux environment. It wouldn't run correctly - some dependencies are missing. So I learned my lesson and setup a USB flash drive to run Ubuntu 11.04 live on a spare netbook I have laying around. In that environment, and following the instructions exactly, the tpdebrick utlity runs correctly.

    So I started up my Ubuntu environment on my netbook, followed the directions and entered:

    Code:
    sudo ./tpdebrick 64
    ...with the 64 signifying that it should re-create all the partitions for a 64GB TouchPad. After it said it completed successfully, I proceeded to memboot the TouchPad to confirm it had corrected the wrongly-sized partition:

    Code:
    root@webos-device:/# cat /proc/partitions
    major minor  #blocks  name
    
     179        0   62623744 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
    ...wait, that's not right - the mmcblk0p14 partition is still only around 30GB, not 64GB or so. What happened? Maybe tpdebrick doesn't support 64GB TouchPads? But the README file specifically states you should enter 16, 32 or 64, depending on the size of the TouchPad you have. So what's going on?

    I dug into the tpdebrick shell script, and saw that it uses different configuration files, using .cfg extension, depending on the size of the TouchPad it's trying to debrick:

    Code:
    [george@poseidon tpdebrick-v004]$ ls -alh *.cfg
    -rw-r--r-- 1 george adm 597 Jan 30  2013 tp16.cfg
    -rw-r--r-- 1 george adm 514 Jan 30  2013 tp16nobootie.cfg
    -rw-r--r-- 1 george adm 597 Jan 30  2013 tp32.cfg
    -rw-r--r-- 1 george adm 339 Jan 30  2013 tp32nobootie.cfg
    -rw-r--r-- 1 george adm 597 Jan 30  2013 tp64.cfg
    -rw-r--r-- 1 george adm 339 Jan 30  2013 tp64nobootie.cfg
    [george@poseidon tpdebrick-v004]$
    Looking at the content of these files, they contained names of binary files to be copied to the TouchPad during the de-brick process. Here is the one used for 16GB TouchPad:

    Code:
    # HP Touchpad 16GB Wifi Bootloader Restore Configuration for TPDebrick
    # NOTE: Most of these files should be obtained from webOS 3.0.5 doctor
    tz.mbn 786432 1d54ad8f441f4a6f5c87ad973fef61b3
    appsboot-moboot.mbn 524288 nocheck
    sbl3.mbn 393216 cc7d2a040bb992aaa975735e55d09cea
    rpm.mbn 262144 5593bf7a15916c51fe5e07c86c7083d9
    ebr16.bin 208801 e12f1a5bba43b96b8391a2f54981daf7
    sbl2.mbn 205801 3664a3928ac3dd19b99d0a8188d1f713
    sbl1.mbn 204801 46c39e7485f9e903a117690db88622af
    mbr16.bin 0 2eaaf24a518cc8e1df127f43f6a0ccce
    Here is the one used for a 32GB TouchPad:

    Code:
    [george@poseidon tpdebrick-v004]$ cat tp32nobootie.cfg 
    # HP Touchpad 32GB Wifi Bootloader Restore Configuration for TPDebrick
    # NOTE: Most of these files should be obtained from webOS 3.0.5 doctor
    tz.mbn 786432 nocheck
    appsboot-moboot.mbn 524288 nocheck
    sbl3.mbn 393216 nocheck
    rpm.mbn 262144 nocheck
    ebr32.bin 208801 nocheck
    sbl2.mbn 205801 nocheck
    sbl1.mbn 204801 nocheck
    mbr32.bin 0 nocheck
    ...and here is the one used for a 64GB TouchPad:

    Code:
    [george@poseidon tpdebrick-v004]$ cat tp64nobootie.cfg 
    # HP Touchpad 32GB Wifi Bootloader Restore Configuration for TPDebrick
    # NOTE: Most of these files should be obtained from webOS 3.0.5 doctor
    tz.mbn 786432 nocheck
    appsboot-moboot.mbn 524288 nocheck
    sbl3.mbn 393216 nocheck
    rpm.mbn 262144 nocheck
    ebr32.bin 208801 nocheck
    sbl2.mbn 205801 nocheck
    sbl1.mbn 204801 nocheck
    mbr32.bin 0 nocheck
    [george@poseidon tpdebrick-v004]$
    Notice how the config file for 16GB contains files like ebr16.bin, and mbr16.bin? And the config file for 32GB TouchPads contains f
    iles like ebr32.bin, and mbr32.bin?

    But in the config file for a 64G TouchPad, it contains the same files as for a 32GB TouchPad - even the comment says it's for the 32GB TouchPad! Luckily, there are files you would think would be for a 64GB TouchPad, like ebr64.bin, and mbr64.bin in the tpdebrick zip file, so I just edited the tp64nobootie.cfg file like this:

    Code:
    # HP Touchpad 64GB Wifi Bootloader Restore Configuration for TPDebrick
    # NOTE: Most of these files should be obtained from webOS 3.0.5 doctor
    tz.mbn 786432 nocheck
    appsboot-moboot.mbn 524288 nocheck
    sbl3.mbn 393216 nocheck
    rpm.mbn 262144 nocheck
    ebr64.bin 208801 nocheck
    sbl2.mbn 205801 nocheck
    sbl1.mbn 204801 nocheck
    mbr64.bin 0 nocheck
    ...re-ran tpdebrick, then membooted the TouchPad to examine the partition size:

    Code:
    root@webos-device:/# cat /proc/partitions
    major minor  #blocks  name
    
     179        0   62623744 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   61759535 mmcblk0p14
    Now that looks A LOT better! About 61GB for the media partition sounds more like it.
    Last edited by George Mari; 09/16/2016 at 08:56 PM. Reason: Alternate links for tpdebrick-v004.zip
  6.    #6  
    Now that the partitions were all the right size, it was time to run the commands to re-create the lvm volume group, and logical volumes:

    Code:
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static vgremove store
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static vgcreate -s 8M store /dev/mmcblk0p14
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    lvm.static lvcreate -l 71 -i 1 -M y --major 254 --minor 0 -n root store
    lvm.static lvcreate -l 8 -i 1 -M y --major 254 --minor 1 -n var store
    lvm.static lvcreate -l 2 -i 1 -M y --major 254 --minor 2 -n update store
    lvm.static lvcreate -l 3 -i 1 -M y --major 254 --minor 3 -n log store
    lvm.static lvcreate -l 64 -i 1 -M y --major 254 --minor 4 -n mojodb store
    lvm.static lvcreate -l 17 -i 1 -M y --major 254 --minor 5 -n filecache store
    lvm.static lvcreate -l 7332 -i 1 -M y --major 254 --minor 6 -n media store
    lvm.static lvcreate -l 64 -i 1 -M y --major 254 --minor 7 -n swap store
    lvm.static vgscan --ignorelockingfailure
    lvm.static vgchange -ay --ignorelockingfailure
    mkdosfs -f 1 -s 64 /dev/store/media
    mkfs.ext3 /dev/mapper/store-var
    mkfs.ext3 /dev/mapper/store-log
    I'm not completely sure if those last two commands to format the var and log filesystems were necessary, but I saw someone did it on some other thread, and I thought it wouldn't hurt. Maybe the webOS doctor will do that, anyway?

    Now it was time to run the Doctor.

    But, which Doctor? I've read that after a tpdebrick session, you should run the webOS 3.0.0 Doctor, as it does something related to re-creating the partitions that the later doctors do not. I had my mis-givings, as honestly, I wasn't sure the 64GB TouchPad even existed before webOS 3.0.0 was replaced by 3.0.2. And didn't tpdebrick just re-create the partitions, anyway?

    As a first try, I ran the webOS 3.0.0 doctor, and of course, nothing is easy. I got the following error message, after the webOS Doctor progress bar got up to 8%:

    Code:
    Apr 22, 2016 9:32:17 PM com.palm.nova.installer.recoverytool.CardController logPrint
    INFO: Trenchcoat: Device repartition was forced.  Media cannot be preserved in this case.  Uncheck "Skip Format of Media Partition" and try again.
    I tried to run the webOS 3.0.5 Doctor, but got the same results - and error.

    I searched the Internet for this message, but didn't find much that was helpful. It seemed like I had come so far, and now I was unable to get over the final hurdle.
  7.    #7  
    After giving up for a few hours, I remembered I had a copy of the Nova Device Installer, a utility which supposedly does what webOS Doctor does, but offers a little more flexibility in it's options. I say supposedly, because I only saw it in action one time before, and I really had no idea how to make it work. I had also searched online and saw that as input, it expected the webOS.tar file, and hp.tar file extracted from the relevant webOS Doctor file.

    So after I start it from the command line, like this: java -jar NovaInstaller_92.jar

    I get this screen: (First attachment)

    So what field should I put webOS.tar and hp.tar in? It's not obvious, so here is the answer I found:

    webOS.tar goes in the Local Base Image field.
    hp.tar goes in the Local Customization field.

    It should look like this: (second attachment)

    I also saw the checkbox in NDI for, "Skip Format of Media Partition". This is exactly what the webOS Doctor mentioned in its error message, so un-checking this before starting the flashing process made sense.

    Then I just pressed the big "Flash Device" button on the bottom of the screen, and off it went. In about the same amount of time it takes to run the webOS Doctor, it was done, and I had a working 64GB TouchPad!!!
    Attached Images Attached Images
  8.    #8  
    Seeing that this was a TouchPad bought from eBay in non-working condition, I thought it would be a good idea to do two things.

    1. Test the media partition. Now that the TouchPad was working, I connected it via USB cable to my desktop, put the TouchPad in USB drive mode, and copied over enough files to fill up its storage. I wanted to make sure I didn't get any errors writing or reading files from that flash storage. It took a while, but it was all working.

    2. Run the built-in webOS Diagnostics. Nobody mentions this too much, but every webOS phone and tablet has a nice, thorough Diagnostics utility, but it's buried in the menu of the Device Info app. On this particular TouchPad, everything worked except the vibrate function. I told the owner about it, but he didn't want to pursue opening up the device to investigate it further, so we left it at that.

    It took a lot of doing, but I learned A LOT about how to resurrect a non-working webOS device. I hope that by sharing it all with you, it might be useful to someone else who finds them self in the same situation.

    If anyone has any more infomrmation on some of the steps I took, sees anything needing correcting, just let me know.
  9. #9  
    Is there something missing between the last line of post 3 and the first line of post 4? It reads like you fixed the partition size.
  10.    #10  
    Quote Originally Posted by Preemptive View Post
    Is there something missing between the last line of post 3 and the first line of post 4? It reads like you fixed the partition size.
    There were a couple of posts that didn't appear at first, waiting for moderator approval.

    It's all there now.
    Preemptive likes this.
  11. #11  
    Is nova device installer available on the HP servers (assuming an altered HOSTS file)?

    It would be nice if there were links to as comprehensive a tool kit as possible. Over time, more people will appear here asking how to revive old devices.
  12. #12  
    George,

    Thank you so much for your excellent documentation on reviving a touchapad. Information like this becomes invaluable to those of us that like to keep these devices going for the foreseeable future. Excellent documentation! See you at the next meetup!

    -Marc
  13. squall77's Avatar
    Posts
    28 Posts
    Global Posts
    30 Global Posts
    #13  
    Hi George,

    That is a very good helping in helping out the webOS community and the documentation you did was fantastic..
  14. #14  
    That guide was awesome. Well done!

    - Thomas

    Sent from my OnePlus One awaiting a LuneOS port
    This space for rent or lease. Inquire within.
  15.    #15  
    Quote Originally Posted by Preemptive View Post
    Is nova device installer available on the HP servers (assuming an altered HOSTS file)?

    It would be nice if there were links to as comprehensive a tool kit as possible. Over time, more people will appear here asking how to revive old devices.
    I don't remember ever seeing Nova Device Installer available on any public Palm or HP web site.

    I don't even remember it even being mentioned in the community until the TouchPad Go started to become a collector's item.

    I don't see any copyright notices on the main screen or any of the menus. I searched for strings in the java jar file and don't seen any instances of "copyright", "rights", "reseved", etc.

    There are some readable text configuration files in the JAR that seem to reference servers that were at one point in the past, internal servers on the Palm network, I think, so it's pretty clear that it's a tool used internally at Palm / HP in the past.

    But if there is no copyright notice in the file itself, maybe re-distributing it would be OK?
  16. #16  
    Quote Originally Posted by George Mari View Post
    I don't remember ever seeing Nova Device Installer available on any public Palm or HP web site.

    I don't even remember it even being mentioned in the community until the TouchPad Go started to become a collector's item.

    I don't see any copyright notices on the main screen or any of the menus. I searched for strings in the java jar file and don't seen any instances of "copyright", "rights", "reseved", etc.

    There are some readable text configuration files in the JAR that seem to reference servers that were at one point in the past, internal servers on the Palm network, I think, so it's pretty clear that it's a tool used internally at Palm / HP in the past.

    But if there is no copyright notice in the file itself, maybe re-distributing it would be OK?
    NDI is an internal Palm/HP tool. Very useful and powerful though Beats having to use Devicetool.jar for example
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  17. #17  
    NDI_91 seems to be around 11Mb to download..
    NDI_92 is presumably very similar in size?

    Good to know we have 'access' anyway.

    TP 32Gb 4G. 3.0.5 / CM10. ~ Pre3 16Gb GSM. 2.2.4. ~ TS2 BT Audio-Dock ~ HP iPaq. hx-2790b.
    TP 32Gb Wifi. 3.0.5 / CM10. ~ Veer (Wht.) 8Gb GSM. 2.2.4. ~ HP Omen-15-5206tx. 256Gb SSD. i7-O/C@3.39Ghz. Win10.
  18. #18  
    But where did you all get this 'internal tool'?
  19. #19  
    Quote Originally Posted by Preemptive View Post
    But where did you all get this 'internal tool'?
    In my case, from an 'External Friend'!

    However, no one seems to have quite answered George Mari's reasonable query as to whether we could make it available here - or 'near' here anyway?

    @ 11Mb it would hardly hog bandwidth.


    TP 32Gb 4G. 3.0.5 / CM10. ~ Pre3 16Gb GSM. 2.2.4. ~ TS2 BT Audio-Dock ~ HP iPaq. hx-2790b.
    TP 32Gb Wifi. 3.0.5 / CM10. ~ Veer (Wht.) 8Gb GSM. 2.2.4. ~ HP Omen-15-5206tx. 256Gb SSD. i7-O/C@3.39Ghz. Win10.
  20. #20  
    In my case, from an 'External Friend'!

    However, no one seems to have quite answered George Mari's reasonable query as to whether we could make it available here - or 'near' here anyway?

    @ 11Mb it would hardly hog bandwidth.

    Some "friends" indeed, the Go users have it. Lemanho sometime shared it here as well via a Chinese site.


    -- 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
Page 1 of 3 123 LastLast

Similar Threads

  1. Replies: 5
    Last Post: 09/11/2014, 03:44 AM
  2. TouchPad Bootloop After Memboot
    By Vistaus in forum WebOS Internals
    Replies: 28
    Last Post: 08/13/2013, 04:55 PM
  3. Replies: 18
    Last Post: 10/29/2011, 07:34 AM
  4. On device ipk installer??
    By phil.hsr in forum webOS Development
    Replies: 3
    Last Post: 03/28/2010, 09:47 AM
  5. Installer is not compatible with this device
    By The Knowledge T in forum Palm OS Devices & Apps
    Replies: 0
    Last Post: 01/05/2005, 02:26 PM

Posting Permissions