Database Users

Symlinking the CACHE partition for extra space.

FAO stratosk and others.
I was not permitted to reply in the main dev thread, but I thought I'd share what I found that works for my Galaxy S.
Your original script worked perfectly apart from the changing ownership / group. For some reason on my rom, system.cache does not resolve into the correct UID / GID - which makes /cache eventually have a 'root' ownership and thus the market cannot access it.
The solution is to use
chown 1000:2001 /cache
chown -h 1000:2001 /cache
The second one changes the symlink as well as the target.
This has already been pointed out in a reply but it may have got lost amongst the others!
Will.
original thread - http://forum.xda-developers.com/showthread.php?t=1188972

torrentship said:
FAO stratosk and others.
I was not permitted to reply in the main dev thread, but I thought I'd share what I found that works for my Galaxy S.
Your original script worked perfectly apart from the changing ownership / group. For some reason on my rom, system.cache does not resolve into the correct UID / GID - which makes /cache eventually have a 'root' ownership and thus the market cannot access it.
The solution is to use
chown 1000:2001 /cache
chown -h 1000:2001 /cache
The second one changes the symlink as well as the target.
This has already been pointed out in a reply but it may have got lost amongst the others!
Will.
original thread - http://forum.xda-developers.com/showthread.php?t=1188972
Click to expand...
Click to collapse
Yeah, I had the same issue. Was surprised how it worked for others without changing the ownership.. I guess you were referring to my reply? ..
Btw, may I know why you can't post in the dev thread?

Hi,
I had seen someone make the same observation I did but I wondered if people had noticed because they were still saying the same thing; I thought it'd help saying it again but I get a feeling a lot of people probably don't know what symlinking is!
I'm surprised though as more and more games are over 30mb now. maybe done custom roms do this automatically?
I can't post in the dev forum because I would guess I don't have a high enough overall post-count.
will.
Sent from my GT-I9000 using XDA Premium App

I wonder how the "old" Market can download files larger then /cache partition, but the new one doesn't (version 3.0.27)? So Google could fix this using some other download location, if cache is small.

[Q] `repartitioning` or setting directories

Hiya.
I got used to SDMaid on my old Xperia Ray and I also use it on my N7 for cleaning cache of apps etc.
I recently noticed that there are some unused `partitions` on my device (see attachment)
Is it possible to shrink the size of those directories to make more space usable for the user, or do something like re-routing the .thumbnail directory to /dev or /cache ?

Don't think repartitioning (layouts - SYSTEM size/DATA size, to put it simply) can be done without nvFlash in APX mode... and nobody has figured a way of doing that yet... but it's a theoretical possibility.
----
I have an Advent Vega (shuttle based), and when devs. release a new ROM, more often than not, it's a CWM .zip flashable.... BUT if a developer needs to ENLARGE the SYSTEM partition (for example, such that the ROM will 'fit'), the ROM has to be nvFlashed.
Rgrds,
Ged.

[Q] "Not enough free space" while still 10GB available.

Hi guys,
I'm having a bit of an issue with my Nexus 4.
I'm on AOKP + Franco-kernel and everything was working great.
Today I've tried to install a game (Jetpack joyride) from the Play Store but the install failed, "not enough free space" error.
I've cleared the cache,dalvik cache and fixed permissions in TWRP but it didn't help.
Here's the output of the df command.
Code:
Filesystem Size Used Free Blksize
/dev 936.2M 32K 936.2M 4096
/mnt/secure 936.2M 0K 936.2M 4096
/mnt/asec 936.2M 0K 936.2M 4096
/mnt/obb 936.2M 0K 936.2M 4096
/system 827.8M 374.4M 453.4M 4096
/cache 551.7M 10.2M 541.6M 4096
/data 12.9G 2.2G 10.8G 4096
/persist 15.8M 4.2M 11.6M 4096
/firmware 64M 53.3M 10.7M 16384
/mnt/shell/emulated 12.9G 2.2G 10.8G 4096
/storage/emulated 936.2M 0K 936.2M 4096
/storage/emulated/0 12.9G 2.2G 10.8G 4096
/storage/emulated/0/Android/obb 12.9G 2.2G 10.8G 4096
/storage/emulated/legacy 12.9G 2.2G 10.8G 4096
/storage/emulated/legacy/Android/obb 12.9G 2.2G 10.8G 4096
I don't really see anything wrong so now I'm asking the experts.
Any ideas?
Thank you very much in advance.
Regards

I had this issue too on my old phone but with another app, poweramp.
The fix for me was:
Navigate to /Data/App folder
Search the app's .odex file and delete it
Try to install the app again
Dont know if this applies for this app too, but it helped me fix that same error.
Hope it helps you!

Worked like a charm!
Thank you!
Can you please explain why this works?
I more or less know what odex-files are but fail to see the relation between the odex file and the error I was getting.
Regards

Pihkal said:
Worked like a charm!
Thank you!
Can you please explain why this works?
I more or less know what odex-files are but fail to see the relation between the odex file and the error I was getting.
Regards
Click to expand...
Click to collapse
I had the same problem and im still not sure why an odex file prevent the app from installing...maybe it sees the odex file like folder like something...who knows...the problem is what you can do when this happents and you dont root your phone!!

pikachukaki said:
I had the same problem and im still not sure why an odex file prevent the app from installing...maybe it sees the odex file like folder like something...who knows...the problem is what you can do when this happents and you dont root your phone!!
Click to expand...
Click to collapse
I'm no expert but I think it's possible to gain root access with adb shell in an unrooted phone or you can try to temp-root your phone with some app, remove the odex file, reboot and continue unrooted.
But I can be wrong, I'm no expert.
Regards

Glad its working again! And i have no idea why those two things produce the error, sorry ^^.

It doesn't really matter, I'm just curious.
You've solved my issue so I'm happy. :good:
Thanks again.
Regards

I'm no expert, but i'd like to say YOU ARE AWESOME. Giving needed information and asking what you actually did and asking for explanation. We need more people like you. KUDOS.

:laugh:
Thank you!
I know how it feels when people expect you to solve their issues without them giving you any useful information, I work as a End User Computing and Infrastructure Support guy in large multinational, sometimes it's very frustrating.
And some of the posts you guys get here on XDA (please help me, it doesn't work!!!!! PLEASE!) annoy the sh*t out of me.
Can you by any chance explain way the above mentioned fix works?
Because I still don't get it and Google isn't really helping...
Regards

The most logical assumption I could come up with is that because the odex file is still there it doesn't know what to do.
Here is an example
You already have testapp.apk installed
You update test app
It knows testapp.apk is already there so The new version is created as testapp-1.apk
Odexed system creates testapp-1.odex
Example 2 - your issue
You are fresh installing testapp
It checks for testapp.apk
Its not there
App is installed as testapp.apk
Odexed system creates testapp.odex
Installer fails as testapp.odex already exists
System reports as out of space because it couldn't create testapp.odex
This is the way I would see it happening.
The installer won't be able to handle an already existing file because the file shouldn't exist. So it will report it as the only thing it knows how.
If it can't create the file then the memory must be full
Sent from my Nexus 4 using xda app-developers app

Thank you for explaining it in a way that even an idiot (me) can understand.
That actually makes sense to me.
But why doesn't it delete the odex file when you uninstall the apk?
I've also noticed that only a few of my installed apps have an odex file, generally speaking only the larger apps (games) have them.
If I understand correctly odex files allow apps to launch faster and consume less space, so what decides when an odex file should be created?
Sorry for going offtopic,

The odex file should be deleted when the app was uninstalled. I have had this issue a few times on 2 different devices so I can only assume it's an android bug.
About the odex files. usually you will only get them on an odexed ROM. Like stock
I only use deodexed so I'm not sure if you can run a deodexed file on an odexed ROM.
But here is the theory anyway.
Having odex is apparently slightly faster than not.
But having deodex is much better for modifications.
Odex = .odex files with apps
Deodex = recompiled into classes.dex which is then merged into the apk itself.
The most likely thing that I can think of that would cause this behavior is if when you had the app installed previously.
You used an app like luckypatcher to make modifications to the app.
So say the app was deodexed (there was originally no .odex file)
You make a change with lucky patcher.
The changes are stored in a .odex file
You then decide you don't want the app and uninstall it.
As that odex file was not created by the app it will not be removed. And such when you try to reinstall it it fails.
Sent from my Nexus 4 using xda app-developers app

It all makes sense to me now.
I probably shouldn't say this but I actually did mess around with lucky patcher on 2 FREE games just to see what would happen.
Nothing really happened so I uninstalled it, I didn't know it created the odex files.
So now everythings falls in to place and I've learned my issue was caused by my own stupidity.
Thank you very much for solving my issue,answering my questions and making me a little less dumb.
Regards
PS: I don't condone piracy.

Pihkal said:
It all makes sense to me now.
I probably shouldn't say this but I actually did mess around with lucky patcher on 2 FREE games just to see what would happen.
Nothing really happened so I uninstalled it, I didn't know it created the odex files.
So now everythings falls in to place and I've learned my issue was caused by my own stupidity.
Thank you very much for solving my issue,answering my questions and making me a little less dumb.
Regards
PS: I don't condone piracy.
Click to expand...
Click to collapse
I flashed the stock deodexed 4.3 yesterday and power amp started behaving weird as it didn't allow me to view my library - all songs etc but only showed the folder view. So I uninstalled power amp and tried to reinstall but I am getting the same error as OP although I have around 7 GB memory free. I tried the above solutions too but nothing seems to work.
Any thoughts? Should I post this issue on power amp on play store?

siddroid said:
I flashed the stock deodexed 4.3 yesterday and power amp started behaving weird as it didn't allow me to view my library - all songs etc but only showed the folder view. So I uninstalled power amp and tried to reinstall but I am getting the same error as OP although I have around 7 GB memory free. I tried the above solutions too but nothing seems to work.
Any thoughts? Should I post this issue on power amp on play store?
Click to expand...
Click to collapse
Poweramp is still not stable on 4.3
Sent from my Nexus 4 using xda premium

[HELP] mmcblk0p7 flashed with recovery.img

Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!

What exactly lies in the mmcblk0p7 partition?

MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.

@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.

@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.

@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.

bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.

@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.

I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet

[TOOLS] Touchpad Toolbox (updated 2015-02-25)

Touchpad Toolbox (aka tptoolbox) is a completely self-contained and user-friendly system for the low-level management of the HP Touchpad.
TPToolbox replaces:
ACMEInstallers
ACMEUninstallers
Various methods of resizing volumes (erroneously called partitions)
Various methods of reflashing the A6 battery monitoring chip
Various methods of completely wiping/recreating volumes
TPToolbox adds:
A straightforward, reliable and easy-to-use method of installing all versions (ICS to LP) of Android on the Touchpad.
The ability to completely remove webOS.
User Interface
As the toolbox name implies, there are several tools in tptoolbox. These tools are accessible via a menu-driven interface:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The interface consists of three primary panes: menu, help and output. The menu pane is toward the top left. The help pane is toward the top right. The output pane is at the bottom.
When a tool runs, output (and possible error messages) will appear in the output pane (doh!). Also, the very bottom of the menu pane will have a "WORKING" status indicator. When a tool fails to complete successfully, the status indicator will change to "FAILED." When a tool completes successfully, the status indicator will change to "DONE." The DONE/FAILED status indicator will remain until the next user input (i.e. VolUp/VolDn/Home is pressed).
Most tools, however, are not simple one-step operations. They may require additional confirmation or input during the process. In those cases, the "WORKING" indicator will disappear (without a DONE/FAILED) after part of the process completes and a new menu will appear. You will be guided through these processes with appropriate information in the help pane. Also, if an operation is cancelled (i.e. you say 'no' to a confirmation, etc.), the status indicator will be reset (be blank).
The VolumeUp, VolumeDown and Home buttons are used to select menu items.
The screen will automatically blank if there is no user input for 20 mins. The Power button can be used to blank/unblank the screen.
Installing Android
Although the on-screen help will guide you through the process when you select "Install Android", I'll give an overview of the process here and how it differs from previous methods. Unlike previous methods of installing Android, you do not need to copy any files onto the Touchpad prior to running TPToolbox. After you select "Intstall Android" it will do some basic checks on the volumes and filesystems on the device. Then, it will share the "media" volume to your PC allowing you to copy the installation files (ROM, Recovery and GApps) to the Touchpad. It will then check these install files to make sure they are compatible and have no obvious errors (i.e. basic zip integrity check). Assuming those tests pass, it will create a set of volume resizing criteria based on the type of Android being installed (i.e. DataMedia vs Non-DataMedia) and confirm that you have availablespace on the device. Next, you will be presented a menu allowing you to confirm to proceed with the installation. It will then install moboot (which is included in TPToolbox) and recovery and resize the volumes. Then it will generate an "install script" for recovery and boot into recovery to complete the installation of the ROM and GApps. After recovery completes it's installation of the ROM and GApps, the Touchpad should boot into the newly installed ROM.
TL;DR: Select "Install Android," Copy files when it asks, Confirm when it asks
For more information on compatible ROM/Recovery/Gapps, etc., see post #3.
Complete Data Reset, webOS Removal and Android Uninstall
One of the tools available is "Complete Data Reset". This will completely wipe all OSes and Data from the Touchpad and rebuild the volumes fresh (actually, there will only be one volume after this, 'media') and rebuild /boot with a minimal set of programs (provided by tptoolbox) that are required by Android to boot. After doing a "Complete Data Reset," you can then "Install Android" (i.e. without webOS). Or, you can re-install webOS (see "Create webOS Volumes" in post #4) and then (optionally) "Install Android." Note that there are no separate "remove webOS" or "remove Android" (This is by design!).
See Also
Post #2 - Loading TPToolbox
Post #3 - Installing Android via TPToolbox
Post #4 - Other TPToolbox Tools
Post #5 - TPToolbox Limitations/FAQs/etc.

Loading TPToolbox
The latest version of TPToolbox is v42 released on 2015-01-08.
It can be downloaded from:
http://downloads.codefi.re/jcsullins/cmtouchpad/tptoolbox/TPToolbox-2015-01-08-v42.zip or
http://www.mediafire.com/download/kuz6e3itpudl9q2/TPToolbox-2015-01-08-v42.zip or
https://www.androidfilehost.com/?fid=95887005526788942
Loading TPToolbox is as simple as A, B, C
A) Have novacom installed
To load TPToolbox, you will need novacom to be installed on your PC.
You can download novacom drivers from: http://downloads.codefi.re/jcsullins/webos/novacom
Or, you can download and run a java-based "universal installer" from http://123haynes.github.io/universal-novacom-installer
B) Put the Touchpad into webOS recovery mode and connect via USB cable to PC
NOTE: Even if webOS is removed, webOS recovery will still exist as it's built into the bootloader.
If you have moboot already installed, just select "webOS recovery" there.
Or, power the Touchpad off via webOS, then with the Touchpad is off, hold VolumeUp (closest to Power) and Power until you see the USB symbol.
Or, hold Power+Home until the screen changes (about 10 secs) and then start holding the VolumeUp button until you see the big USB symbol.
C) Run the script provided with TPToolbox
Extract the contents of the TPToolbox zip file from above.
Navigate to the tptoolbox_v42 directory that was extracted from the zip.
On Windows, run the batch file named tptb_v42_win.bat
On Linux, run the script named tptb_v42_nix.sh
On Mac, run the script named tptb_v42_mac.command

Installing Android via TPToolbox
Installation Overview
For the most reliable install, it is suggested that you consider doing a "Complete Data Reset" (as mentioned in the OP) prior to doing the install as it's the best way to "start fresh."
The OP gave an overview of the process that TPToolbox uses to install Android.
From a user perspective, it's pretty simple: copy three files (ROM, Gapps and Recovery) when and where TPToolbox asks and then select "yes" when asked to confirm the install details.
Below is the list of Recoveries that you can use with TPToolbox. Those marked with "DM" are for data-media ROMs and those marked with "NODM" are for non-datamedia ROMs. Unless the developer has specified otherwise, you can assume that any KK or LP ROM is datamedia and ROMs previous to KK are non-datamedia. However, TPToolbox checks to make sure that the ROM and Recovery are compatible and will tell you if they are not.
Compatible DataMedia (DM) recoveries
Download traditional CWM (DM):
http://downloads.codefi.re/jcsullins/cmtouchpad/recovery/update-CWM-jcs-dm-tenderloin-20141231.zip or
https://www.androidfilehost.com/?fid=95887005526788938 or
http://www.mediafire.com/download/eyugz1w6twld313/update-CWM-jcs-dm-tenderloin-20141231.zip
Download Philz-CWM (DM):
http://downloads.codefi.re/jcsullin...date-PhilZ_CWM-jcs-dm-tenderloin-20140612.zip or
https://www.androidfilehost.com/?fid=23610159112654007 or
http://www.mediafire.com/download/vvldbc3380y4pl1/update-PhilZ_CWM-jcs-dm-tenderloin-20140612.zip
Download TWRP (DM):
http://downloads.codefi.re/jcsullins/cmtouchpad/recovery/update-TWRP-jcs-dm-tenderloin-20140612b.zip or
https://www.androidfilehost.com/?fid=95784891001615841 or
http://www.mediafire.com/download/d155um5531ymp3h/update-TWRP-jcs-dm-tenderloin-20140612b.zip
Download flintman's Dec. 23, 2014 build of TWRP (DM):
http://evervolv.com/get/FLINTMAN-TWRP-touch-data_media-SELINUX-2.8.3.0-12-23-14.zip
Compatible Non-DataMedia (NODM) recoveries
Download traditional CWM (NODM):
http://downloads.codefi.re/jcsullins/cmtouchpad/recovery/update-CWM-jcs-nodm-tenderloin-20141231.zip or
https://www.androidfilehost.com/?fid=95887005526788937 or
http://www.mediafire.com/download/y7xqj521a76z4ml/update-CWM-jcs-nodm-tenderloin-20141231.zip
Download Philz-CWM (NODM):
http://downloads.codefi.re/jcsullin...te-PhilZ_CWM-jcs-nodm-tenderloin-20140614.zip or
https://www.androidfilehost.com/?fid=23610159112654008 or
http://www.mediafire.com/download/eb602915di0gcuc/update-PhilZ_CWM-jcs-nodm-tenderloin-20140614.zip
Download TWRP (NODM):
http://downloads.codefi.re/jcsullin...update-TWRP-jcs-nodm-tenderloin-20140614b.zip or
https://www.androidfilehost.com/?fid=95784891001615842 or
http://www.mediafire.com/download/r4grp5bu6brsl6l/update-TWRP-jcs-nodm-tenderloin-20140614b.zip

Other TPToolbox Tools
Mount Media Volume allows you to access the 'media' volume from your PC
Reflash A6 Firmware allows you to reflash the A6 firmware.
Resize Android Volumes
This allows you to interactively resize the Android (and media) volumes.
This is not needed to "Install Android", but can be used at other times to 'tweak' the volume sizes as needed.
Repair Android Volumes
If a fsck (file system check) determines that there are non-trivial errors on a filesystem, then this can be used to attempt to fix those errors.
Create webOS Volumes
If you want to re-install webOS following a "Full Data Reset," you will need to run this prior to running webOS doctor.
At this time, re-installing webOS should only be done prior to installing Android. Tools to assist re-installing webOS after
Android has been installed (without detriment to the Android install) may be provided in the future.

TPToolbox Limitations/FAQs/etc.
Limitations
This thread
Re-install of webOS after Android installed is not supported yet. (i.e. after a "Complete Data Reset", you must re-install webOS before Android)
Method for permanently installing TPToolbox (always available via moboot) not available yet
Installation of a "3rd OS" (i.e. luneOS) not supported yet
Installation of Android without Gapps not supported yey

reserved

reserved too

Used toolbox to do a full reset , wipe webos and install cm 11.
Worked fast and easy.
27 gb free after install.
One question though, is it normal to have a internal storage and a sdcard partition (about 800 mb) after install ?

HP TouchPad Index
I've added this to the HP TouchPad Index
Great work JCS :good:

This is exactly the type of high quality, high functionality solutions that make this forum great. Thank you.
This just brought back my borked (yes, I did it) Touchpad to a fully functional tablet without resorting to WebOSDr. And in less time than it took me to download the required files and get novacom working!
Now to hit that Thank You button...

Brilliant, amazed by how much support the Touchpad has, it's embarrassing that as a none native android device it has better custom roms than my Sony Xperia U and Galaxy S3 (i9300).
Not a major issue, but I'd like to see ACMEUninstaller built in to remove just android and leave WebOS, not a major issue if not as I can just use ACMEUninstaller. *edit* Given the state of data media, this is probably useless anyway, unless it would reverse it all and redo the original partitions at the same time.
Soon as I get chance on Friday WebOS is getting nuked off my touchpad once and for all.
Thanks again for all the great work.
*edit* I'm running your 4.2.2 currently which is running great but will move to your 4.4.2 when I test this. If we've nuked webos does media still need to be kept at ~600mb, can it not be knocked down to a token size like 5-10mb or something?
Thanks.

Thanks for the work on the toolbox JcSullins. Looking forward to trying this out when I get home.
Sent from my "Up All Night Sleep All Day" Nexus 5!

One question: after resizing the volumes before installing Android I'm only seeing about 2.7GB in data and about 900MB in Media after Android install. I had sized data to about 12GB.
I have a 16GB Touchpad and its running your latest 4.4 Android snapshot.

phikal said:
Used toolbox to do a full reset , wipe webos and install cm 11.
Worked fast and easy.
27 gb free after install.
One question though, is it normal to have a internal storage and a sdcard partition (about 800 mb) after install ?
Click to expand...
Click to collapse
I think it is normal. I have it too.

All I can say is W O W. Thanks you so much jcsullins, you really out did yourself. The HP TouchPad Toolbox is a real blessing. We now have an official android device for our HP TouchPad. Your directions were easy to following, I including flashing the A6 Firmware. Android runns really smooth. Thanks again for all the work you put into the toolbox, it was worthwhile waiting for.

JCS, I normally run the a6 firmware once a month. To do this monthly, please correct me if I am wrong, I would need to go into WebOS recovery and run the TPToolbox script to flash the A6 firmware? Is this correct?

phikal said:
Used toolbox to do a full reset , wipe webos and install cm 11.
Worked fast and easy.
27 gb free after install.
One question though, is it normal to have a internal storage and a sdcard partition (about 800 mb) after install ?
Click to expand...
Click to collapse
Looking at the way it re-sizes the volumes you should end up with a media volume of at least 600M
KitKat/DataMedia Volume (re)sizing criteria
system: MIN_SIZE: 704M
cache: MIN_SIZE: 200M
data: MIN_SIZE: 1500M
data: also takes any free-space "media" has over 600M
This would be where the installation files are stored while the TPToolbox re-sizes and creates the necessary volumes for Android to install.

donslade said:
One question: after resizing the volumes before installing Android I'm only seeing about 2.7GB in data and about 900MB in Media after Android install. I had sized data to about 12GB.
I have a 16GB Touchpad and its running your latest 4.4 Android snapshot.
Click to expand...
Click to collapse
Please see info from df command:
[email protected]:/ $ df
Filesystem Size Used Free Blksize
/dev 403.3M 136.0K 403.2M 4096
/sys/fs/cgroup 403.3M 0.0K 403.3M 4096
/sys/fs/cgroup/memory: Permission denied
/mnt/asec 403.3M 0.0K 403.3M 4096
/mnt/asec/com.speedsoftware.rootexplorer-1 4.0M 3.0M 1.0M 4096
/mnt/obb 403.3M 0.0K 403.3M 4096
/mnt/fuse 403.3M 0.0K 403.3M 4096
/boot 32.0M 13.0M 19.0M 1024
/system 755.9M 490.9M 265.0M 4096
/data 2.9G 517.1M 2.4G 4096
/cache 315.0M 5.3M 309.6M 4096
/mnt/shell/emulated: Permission denied
/storage/sdcard1 903.1M 208.0K 902.9M 8192
/storage/emulated 403.3M 0.0K 403.3M 4096
/mnt/media_rw/sdcard1: Permission denied
/mnt/secure/asec: Permission denied
/storage/emulated/0 2.9G 517.1M 2.4G 4096
/storage/emulated/legacy 2.9G 517.1M 2.4G 4096
As shown it looks to me like I have no permission to access sdcard1. How can I correct this so that the sdcard1 is mounted and becomes accessible?
Thanks in advance.

I hope just a quick question so I understand.
If I already have 4.3 running, the procedure I follow is the same as not having Android previously?
I can not seem to download the rom and gapps from:
http://forum.xda-developers.com/showthread.php?t=2712680
Are there other links?
Edit: nevermind, appears I grabbed the correct files from goo.im

donslade said:
Please see info from df command:
[email protected]:/ $ df
Filesystem Size Used Free Blksize
/dev 403.3M 136.0K 403.2M 4096
/sys/fs/cgroup 403.3M 0.0K 403.3M 4096
/sys/fs/cgroup/memory: Permission denied
/mnt/asec 403.3M 0.0K 403.3M 4096
/mnt/asec/com.speedsoftware.rootexplorer-1 4.0M 3.0M 1.0M 4096
/mnt/obb 403.3M 0.0K 403.3M 4096
/mnt/fuse 403.3M 0.0K 403.3M 4096
/boot 32.0M 13.0M 19.0M 1024
/system 755.9M 490.9M 265.0M 4096
/data 2.9G 517.1M 2.4G 4096
/cache 315.0M 5.3M 309.6M 4096
/mnt/shell/emulated: Permission denied
/storage/sdcard1 903.1M 208.0K 902.9M 8192
/storage/emulated 403.3M 0.0K 403.3M 4096
/mnt/media_rw/sdcard1: Permission denied
/mnt/secure/asec: Permission denied
/storage/emulated/0 2.9G 517.1M 2.4G 4096
/storage/emulated/legacy 2.9G 517.1M 2.4G 4096
As shown it looks to me like I have no permission to access sdcard1. How can I correct this so that the sdcard1 is mounted and becomes accessible?
Thanks in advance.
Click to expand...
Click to collapse
Since Touchpad Toolbox makes it so easy I just wiped and started fresh. This time everything worked as expected!! Thanks for a great application!