Database Users

New Info about Clockwork Brickings

Hi devs,
Strictly speaking, this is not a development issue, but I thought it warranted some special attention as it sheds a little bit of new light on the "bricking" caused by Clockwork (version unknown).
A new XDA member, SoSickWiTiT, brought back an Eris from the grave. The phone he started with could only be put into RUU mode - initially it would not even start correctly in Hboot or Fastboot mode (weird, right?), and is now fully functional. The long and tortuous thread is here in the Q&A forum.
The essential finding was that the "bricking" was apparently caused by enormous numbers of pages in the flash memory device being marked as bad pages, and that this was correctable by using the "flash_erase" tool of the mtd-util project. (This tool allows you to reclaim flash pages marked as bad if they erase successfully.) I built some of the tools for ARM/Android and posted them up here.. As long as you can get Amon_RA to come up, you can run this tool from Amon_RA (using adb) and erase/reclaim partitions on a partition-by-partition basis.
Also SoSickWiTiT found a useful hack that I hadn't seen before: because he could only get his phone to start in RUU mode, he started the "Official RUU", ran it to the point where it unpacks all files, and then replaced the "rom.zip" file (in the Temp folder the RUU utility unpacks) with the HTC Root-ROM (renaming it to "rom.zip", of course). Because it signed by HTC, it got the 1.49.2000 S-OFF bootloader installed (but the rest of the install failed). SoSickWiTiT was then able to flash Amon_RA via fastboot and continue gaining traction from there. Note that just flashing a ROM from this point would not work - his mtd3 (system) partition appeared as if over 60% of the pages were marked as bad, and I think his boot partition was similarly affected. "flash_erase" was able to reclaim these pages using the "-N" command line option.
Anyway, the behavior of his phone (excluding the RUU-only behavior) was consistent with prior bricking reports of how filesystems appear to be "corrupted", and this causes difficulties flashing new ROMs (largely due to lack of free space). SoSickWiTiT reports that the phone he obtained from a friend had been bricked by "a failed ROM flash in Clockwork/ROM Manager followed up with an attempt to use the RUU" - there have been at least one other report of this exact same scenario causing the "bricking".
So now I am wondering - are there a few "bricks" laying around that might be rescued?
bftb0

Very interesting and good to know, thanks! And thank you for the tool, great work.

Think this could be applied to deleting the NRAM flash on a router? =p

WAIT wait wait!!!
He changed the bootloader from S-On to S-off??? Was it on 1.49? If so couldnt that have been used to root our phones, A LONGGG time ago? lol

Nikolai2.1 said:
WAIT wait wait!!!
He changed the bootloader from S-On to S-off??? Was it on 1.49? If so couldnt that have been used to root our phones, A LONGGG time ago? lol
Click to expand...
Click to collapse
A looooooong time ago - December '09 (circa "MR1") iirc, someone attempted to stuff a different - and unsigned - "rom.zip" file into the running (MR1) RUU.
Naturally, that didn't work, 'cuz it wasn't a HTC-signed PB00IMG.zip file. To my knowledge, this is the first time anybody tried doing things this way (swapping in the validly-signed HTC Root-ROM into the RUU's "rom.zip" location)... maybe it would have worked for the "leakers". I suppose that someone could roll back their phone and give it a shot to see it if works, but that seems sort of academic at this point - hence your "LOL".
There is evidence that both the RUU- and Hboot- based update processes actually end up checking the contents of the "misc" partition for version information TWICE - first before any flashing occurs, and second, only after the bootloader has been flashed and reloaded, but before the remainder of the PB00IMG.zip/rom.zip file has been flashed. I don't think that even at this point in time this behavior is well understood: it is possible that the hboot flash of the bootloader can occur, but then the subsequent flashing of the rest of the PB00IMG.zip file fails due to a "Main Version is Older" error. Sort of hard to understand why that would ever occur (it happened to me once, so I know it occurs).
For anybody that has a brick, but can get RUU mode running, it is certainly worth a try to see if they can replace the bootloader with the S-OFF bootloader - what do they have to lose? In this particular case, it is hard to know what the state of the misc partition was; after all, it was a phone that was previously rooted. The result obtained using the RUU utility likely depends on what was going on in the misc partition on that phone, so it is not obvious that this (RUU utility) "trick" is universal. It might have been that the same phone would have been happy to accept the Root PB00IMG.zip file - but SickWiTiT couldn't get the phone into Hboot mode initially, so that wasn't tried.
cheers
bftb0

So if I have been using Clockwork to flash a few roms do you think I would have any bad pages in my flash memory? Is there an easy way to check this?

xtreme3737 said:
So if I have been using Clockwork to flash a few roms do you think I would have any bad pages in my flash memory? Is there an easy way to check this?
Click to expand...
Click to collapse
I don't think that using Clockwork causes slow growth in bad pages; afaik, when the problem occurs - whatever causes it - only then do you see a catastrophic number of pages marked this way. I mentioned it only in case someone bricks their phone and then asks for advice here - they can check to see if this repair works for them at that time - after they have determined that this is the nature of their problem. In the meantime, there is not much need to worry about it.
Short of actually performing a flash_erase with the "-N" option turned on, I don't know off the top of my head a way to determine the number of bad blocks easily, and there are good reasons why you should not be doing that unless you absolutely have to.
The tool "nanddump" that I compiled actually reports the number of bad blocks - but it also wedges the Amon_RA kernel when you run it. Rats.
bftb0

I just wanted to add my thanks for this very informative and interesting information and tool in case it becomes necessary. I do use Clockwork (loaded from Amon RA), BTW.

Thanks for the useful info as always.
It really seems like a bad idea to use clockwork
Sent from my nonsensikal froyo

SikYou said:
Thanks for the useful info as always.
It really seems like a bad idea to use clockwork
Sent from my nonsensikal froyo
Click to expand...
Click to collapse
bftb0 said:
I don't think that using Clockwork causes slow growth in bad pages; afaik, when the problem occurs - whatever causes it...
Click to expand...
Click to collapse
I haven't once had an issue with Clockwork Mod through ROM Manager, and have been using it for 3+ months now.

thanks for this thread i sort of helped one person put their phone into the grave by telling them to flash an ruu (still feel bad about it)

jamezelle said:
thanks for this thread i sort of helped one person put their phone into the grave by telling them to flash an ruu (still feel bad about it)
Click to expand...
Click to collapse
That cus you are a baddie jamezelle xD

Very informative read, thanks bftb0!

I spent some time tonight fooling around with RomManager (v3.0.0.7) and ClockworkMod (v2.5.0.1 for the Eris). Sort of an eye-opener, actually.
The way it works is that it is actually NEVER "FLASHES" ANYTHING TO THE RECOVERY PARTITION. Instead, when you first tap on the menu item to "flash the recovery", what ROM Manager does is identify your handset type, and then downloads some files to
/sdcard/clockworkmod, e.g.:
/sdcard/clockworkmod:
----rwxr-x 1 system sdcard_r 829658 Jan 17 02:23 recovery-update.zip
/sdcard/clockworkmod/download/koush.tandtgaming.com/recoveries:
----rwxr-x 1 system sdcard_r 829658 Jan 17 00:56 recovery-clockwork-2.5.0.1-desirec.zip
/sdcard/clockworkmod/download/rommanager.appspot.com:
d---rwxr-x 2 system sdcard_r 4096 Jan 17 02:23 manifests
/sdcard/clockworkmod/download/rommanager.appspot.com/manifests:
----rwxr-x 1 system sdcard_r 11492 Jan 17 02:23 devices.js
Note that "recovery-update.zip" and "recovery-clockwork-2.5.0.1-desirec.zip" are the same size - less than 1 MB. In fact, they are identical. It is a signed update package - but too small to even contain an Android kernel.
Here's how ROM Manager works: when you press the button "Reboot into Recovery", what actually takes place is this:
- Rom Manager copies "recovery-update.zip" into /cache/update.zip, and then places the following command into /cache/recovery/command
Code:
"/sbin/recovery" "--update_package=CACHE:update.zip"
and then executes a "reboot recovery" command.
The next thing that happens is that whatever Custom Recovery that IS ALREADY FLASHED to your recovery partition on the phone boots up, and immediately begins to process the /cache/update.zip file
Here's the $64,000 observation:
This update.zip modifies NOTHING IN FLASH MEMORY - IT ONLY MODIFIES THE RAMDISK OF THE BOOTED RECOVERY ALREADY PRESENT.
Towards the end of the updater-script, it kills off the old /sbin/recovery and /sbin/adbd processes; but since these processes are defined as services, they get restarted automatically, using the new "ClockworkMod" version of these program files. Voila! The ClockworkMod recovery menus pop up.
There are two important observations that arise from this analysis:
- It does not have it's own kernel - it uses the kernel of whatever was already present in the recovery partition boot
- To get ClockworkMod to be cold-bootable, you need to COMBINE IT WITH A KERNEL AND BOOTSCRIPTS FROM SOMEPLACE ELSE - but WHERE exactly?
Now, I don't know if ROM Manager formerly worked in a different fashion - but the point is fairly obvious: if you wanted to provide a rooting method which installs "ClockworkMod" as a recovery - well then, you would need to combine the minimal components of "ClockworkMod" (mostly just the /sbin/recovery program !) with someone else's bootable recovery. And you could not use an HTC stock recovery - because then koush's "update.zip" files would have needed to be signed by HTC in order to get processed.
If you accept the hypothesis that the so-called "Clockwork" brickings have been due to a bug in the kernel MTD driver - and nobody ever seems to see those bugs happening with Amon_RA v1.6.2 - then the real problem comes from a kernel which is was kanged into a flashable "Clockwork Mod" recovery by a third party - not koush.
Who is it then - the unrevoked team? Someone else? What kernel is it?
As I recall, nearly every one of the brickings that have been reported here have been folks that got their rooting instructions from outside the XDA Eris community.
Bottom line - it's starting to look like the problem is not really due to Clockwork - its a problem kernel from unknown origins.
Perhaps Rom Manager did not always work this way on the Eris - but the way it works now is that if you install it after already having Amon_RA in the recovery partition, if you cold-boot (Vol-up+End or via HBOOT), what will come up is Amon_RA, not Clockwork.
So - if you can cold-start your phone into recovery, and up pops a ClockworkMod menu instead of a Amon_RA menu - how did you root your phone originally?
bftb0
(sorry if this post is a bit of a ramble - it's pretty late/early)

When I 'cold boot' I get the Clockwork V2.5.0.1 screen.
I rooted originally the day root was discovered here at XDA. I originally loaded Amon. Somewhere in the last year, I may have clicked the 'install Clockwork mod' at the top of ROM Manager, but I don't think I did.
I don't know if this helps, but I found your post interesting.

meanm50 said:
When I 'cold boot' I get the Clockwork V2.5.0.1 screen.
I rooted originally the day root was discovered here at XDA. I originally loaded Amon. Somewhere in the last year, I may have clicked the 'install Clockwork mod' at the top of ROM Manager, but I don't think I did.
I don't know if this helps, but I found your post interesting.
Click to expand...
Click to collapse
Huh.
If you do that, and then fire up an adb session, what kernel string does
Code:
adb shell uname -a
report?
When I click "Flash ClockworkMod Recovery", all it does is ask me to verify the phone model ("Droid Eris (CDMA)"), requests root (SuperUser), goes to the Internet and downloads stuff, and then pops up a message on the screen saying "Successfully downloaded Clockworkmod Recovery!" If I shut down the phone normally and then cold-boot the recovery afterward, what is there is Amon_RA - not clockwork.
Hmmm. Just used it to perform a ROM backup**. For this operation, the same thing happens - Amon_RA comes up first, followed by chaining to ClockworkMod and then the backup starts happening. I note that it also backs up the recovery partition - maybe it only modifies the recovery partition when it is installing a new ROM?
Hmmm (part 2). Just wiped and flashed a clean ROM using Clockwork. Cold start into recovery afterward gives me Amon_RA, not Clockwork.
Maybe koush has changed the basic methodology somehow. I have to say, the way I currently am experiencing it makes a great deal of sense - it means that koush does not need to be in the kernel-making/kernel-collecting business in order to support ROM Manager on a new handset.
Can anyone with a more long-term exposure to Rom Manager/ClockworkMod (on the Eris) shed some light on this?
bftb0
** Interesting side note: CWM backup now backs up (and I presume restores) /sdcard/.android_secure; also, a "wipe" operation will attempt to wipe any SD card ext partition if it is found.

I will adb when I get home...my work comp doesn't have the required programs installed...

bftb0 said:
** Interesting side note: CWM backup now backs up (and I presume restores) /sdcard/.android_secure; also, a "wipe" operation will attempt to wipe any SD card ext partition if it is found.
Click to expand...
Click to collapse
Also the /cache partition.

bftb0 said:
Huh.
If you do that, and then fire up an adb session, what kernel string does
Code:
adb shell uname -a
report?
Click to expand...
Click to collapse
Linux localhost 2.6.29-DecaFuctCFS-dirty-c6271491

meanm50 said:
Linux localhost 2.6.29-DecaFuctCFS-dirty-c6271491
Click to expand...
Click to collapse
Sorry - I meant adb with your recovery booted, not the normal OS. (The above must be from your regular OS right?)

[GUIDE] Backup of your BCT AND Partition with NVFLASH on the gtab

** UPDATED WITH .BCT saving, include USB as well as NVFLASH just copy in
** 1 dir, run the batch and keep those you may need them one day
** Read the batch file for more info
It is clear for me is that it is not a perfect solution to use nvflash with images that you do not know the source.
The tegra S.O.C. use the information from a file stored in partition#2 to configure some low level setting like flash memory chip speed, total memory installed, video memory installed, flash type etc. As an example, if for some reason a batch of tablet is built with more memory then the .bct files will need to be changed accordingly
It is already confirmed that there's at least 2 different type of hardware. (2 different images by bekit do not use the same .bct configuration)
When flashing after a full wipe after using the create command, nvflash read the .bct configuration files and store it in the partition #2 on the tablet, bct files are created by the manufacturer using a tool from nvdia called buildbct. They are not writen during regular nvflash (where the partition are not re-created)
This also mean it is MUCH safer to NOT replace the partition 2 when nvflashing a device... (the hardware configuration would not be touched).
This batch files will work under windows and will not modify your tablet in anyway
please make sure you use the nvflash tools that is 151K there's an older and smaller one in some package, it will output binary inside the partition.txt instead of plain text. The version 2 include everything you need to backup the device under windows
Thanks to the various poster of thread about nvflash for the correct command THEY did the hard work not me !
To Restore individual partition the command is
"nvflash.exe" --bl bootloader.bin --download X partX.img
where X is the partition number you wish to flash, as stated you can also use your backup from clockwork mod for partition 11 restore.
this will not work for partition below 4
P.S.
I am not trying to start a debate on the validity of the current recovery (thumb-up to the guy who offered those!) They are valid for MOST device however
if you do have a different device this will alleviate any issue that may happen with nvflash restore.
see 2 post below for full restore info

Hi,
I know that the partitiontable shows a partition named "BCT", but is there also something else, perhaps flashed into the SOC itself that is referred to as "the BCT"?
The reason for the question is that nvflash has a setbct and a getbct command, separate from the read and download commands, which work with the partitions.
Jim

Reserved
(will be completed a bit later)

so, we possibly share more internals with the 10s than previously expected? maybe... can we get this thing to dual boot in the future??

10roller said:
so, we possibly share more internals with the 10s than previously expected? maybe... can we get this thing to dual boot in the future??
Click to expand...
Click to collapse
My guess is yes, the platform of the ac100 laptop by toshiba is tegra based and they do it!

P00r said:
The set bct command probably write the 4080 byte to the partition named bct in the cfg, I have yet to test flashing a dummy FF filled partition with the command to confirm the flash.bct get writen there
So in fact when you restore with the nvflash restore images from bekit I think you are actually writing it twice... (it is in the image and you telling the nvflash to create it) but I have not confirmed this yet
Once the bct info is there, the SOC read his configuration there, as well as the ODM info, I have not found a way to use --getbct that reads back the BCT from mass storage yet...
I am not sure either why there's so many section being flashed it should work with only a few of those (I plan to test this) since nvflash is simply puting those one after the other. It make sense only sense for a dual booting unit
Click to expand...
Click to collapse
Hi,
I was able to get --getbct to output a 2048 byte file awhile ago. I think I had posted about it, but, sorry, I don't remember which thread. The only thing I vaguely remember was that I had to use some unobvious combination of parameters. Also, I think that it only worked right after pushing the bootloader.bin. If I find my post, I'll provide a link.
Jim

Thanks OP, I like the idea of being able to back up the partitions directly from my tablet so I know I'm restoring the proper thing should I ever have to resort to that.
Just starting to get into modding this thing after it showed up from Woot yesterday, been planning on buying one for quite some time to compliment my Epic 4g and when the woot sale dropped I had to jump on it. So far all I have done is flash clockwork, and make a nandroid backup with that. Also doing this backup method now.
So have you actually done a successful restore using this method?

so is it possible to back up your original hardware configuration and restore it when you got problems???

Yes and NO, I have error reading partition #11 (system) on my tablet (bad block)
if I use it as is for restore, it doesn't restore and boot, however replacing this partition with clockwork system.img backup give me back a full working tablet.
I can also reboot into recovery and restore from there.

Letters and numbers oh my
I ran the backup on my new replacement GTab yesterday. I had a size mismatch on partition 5, everything else backed up properly. Also, my partition 7 is BLO and partition 6 is MSC. Thanks for the script and capability.
Mike

P00r said:
This also mean it is MUCH safer to NOT replace the partition 2 when nvflashing a device... (the hardware configuration would not be touched). I will post later on how to flash back those if someone request it...
Click to expand...
Click to collapse
Instructions on how to flash back using this would be great. I'd like to have the option to do so if I need to, but haven't gotten familiar enough with nvflash yet to figure it out on my own.

iamchocho said:
Instructions on how to flash back using this would be great. I'd like to have the option to do so if I need to, but haven't gotten familiar enough with nvflash yet to figure it out on my own.
Click to expand...
Click to collapse
You can flash back the partition using
"nvflash.exe" --bl bootloader.bin --download X partX.img
where X is the partition number you wish to flash, as stated you can also use your backup from clockwork mod for partition 11 restore.
If needed you can use the nvflash format kit prior to restoring however it would be better to use your own .bct with that option

Getting stuck at partition 7.

xkwwwx said:
Getting stuck at partition 7.
Click to expand...
Click to collapse
What is the error you are getting ?

stock recovery image
Thank you very much for the sharing this.
Now I have 10 img files (part-2 to part-11)... wich one is the stock recovery image? I did this before installing clockwork mod...
Thanks!

I think this is fantastic. Gives us a chance to backup our gtab before deciding to try a new rom. I tried this today in the hopes to backup and then install the flashback HC rom. But unfortuntaly it stopped on image 7, as xkwwwx has also mentioned. The message seemed to be a issue with the size expected of the image as to what was received. Ill try and copy the message.
"nvflash.exe" -r --read 7 part-7.img
nvflash started
[resume mode]
receiving file: part-7.img, expected size: 16777216 bytes
/ 131072/16777216 bytes received
At that point it stops, and i have to control c to exit the batch file. Id love to be able to backup with this pls, so i can try another rom, and know i can use this to return to this rom if i dont like the new one, any chance this can be resolved pls ?
Was also wondering if some form of GUI maybe of benifit, i know alot of people feel wary of NVFlash, perhaps with a GUI people would feel more comfortable using it. Maybe a simple screen with a backup and restore set of buttons ?

P00r, any chance you can help mate ? Cant use this unfortunatly because of the image size issue.

Icedvoco said:
P00r, any chance you can help mate ? Cant use this unfortunatly because of the image size issue.
Click to expand...
Click to collapse
This mean you probably have a bad block in this section, try skipping it to get the other parts first. this is not a major issue, you may also encounter one in the last data section (my tablet has a few byte less than the regular one)
For the data partition you can substitute the cwm images
Also try using a different bootloader and nvflash this can help even shorter usb cable or a different one can help
The part that you can read is probably usable for a restore anyway
Bad block are not unusual in flash and I have seen a few with this, ideally and usually it's located at the end, you could try using the format image a few time it could be a stuck byte and writing different data can revive it (format write FF all over)

P00r said:
This mean you probably have a bad block in this section, try skipping it to get the other parts first. this is not a major issue, you may also encounter one in the last data section (my tablet has a few byte less than the regular one)
For the data partition you can substitute the cwm images
Also try using a different bootloader and nvflash this can help even shorter usb cable or a different one can help
The part that you can read is probably usable for a restore anyway
Bad block are not unusual in flash and I have seen a few with this, ideally and usually it's located at the end, you could try using the format image a few time it could be a stuck byte and writing different data can revive it (format write FF all over)
Click to expand...
Click to collapse
Bad blocks may be common, but bad blocks in the exact same spot probably not. I get the exact same thing:
"nvflash.exe" -r --read 7 part-7.img
Nvflash started
[resume mode]
receiving file: part-7.img, expected size: 16777216 bytes
/ 131072/16777216 bytes received
Any other thoughts on this?

Maybe someone here knows,
So with NVflashing, I've found only one file that has the alternative BCT (it's a tnt1.0 rom on BL1.1) and no other NVflash file sets work without causing a APX bootloop.
This is the NVflash file set that works for me http://db.tt/FvSeAZj
Ive read it was made when someone was trying to configure for the hardware variations.
Now is it possible to take my backup and insert just the files needed into another NVflash file set?

[NEED HELP with e2fsck] Soft-Brick : corrupted /data/ & /sdcard/ partitions

----------- FIXED ----------
Hey guys,
I'm encountering a terrible problem with my P6810 tab. Here is the story :
At first, I just did format /system/ (and /data/, cache and dalvik) in CWM before flashing a new Rom.
After reboot, the tab just got stuck on the "Galaxy Tab 7.7" logo. no bootloop, just stuck on static logo.
At this stage i could go to download mode and recovery, which I did.
I tried to reflash the rom, no success so then i tried to flash stock ICS firmware through Odin 1.85 : Stuck on flashing Factoryfs.img for several hours, so i had no choice but to reboot the tab. (i had no kies-related software running, neither my antivirus)
There, the tab got stuck on the "Firmware upgrade encountered an issue. please select recovery in Kies" screen, no way to go to either recovery or download mode (not even worth saying Kies didn't recognize the tab).
I've been struggling a few hours with that brick and finally managed to get acces to download and recovery modes again by flashing CWM with Odin alongside a PIT file with "repartition" ticked in Odin.
So there I could access recovery, I flashed CM9, everything went smooth. The tab rebooted and got passed the Galaxy tab 7.7 logo and went to the cm9 bootscreen but got stuck there (big desillusion right there).
So now in recovery, i can mount every partition but those two : /data/ and /sdcard/
I figured out by reading similar threads that the solution to my issue might be e2fsck through adb. I'm a complete noob to adb.
I can acces the adb shell but here are what the commands i've been reading about return me : (mmcblk0p9 is /data/ partition on P6810)
# e2fsck -fDC0 /dev/block/mmcblk0p9 :
e2fsck : Superblock invalid, trying backup blocks...
The superblock could not be read or does not describe as a correct ext2 filesystem.
If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else),
then the superblock is corrupt and you might try running e2fsck with an alternate superblock : e2fsck -b 8193 <device>
also had this once with this command :
bad magic number in superblock while trying to open /dev/block/mmcblk0p9
# e2fsck -b 8193 /dev/block/mmcblk0p9 :
Attempt to read block from filesystem resulted in short read while trying to open /dev/block/mmcblk0p9
Could this be a zero-length partition ?
# e2fsck -c /dev/block/mmcblk0p9 :
same as above
can you guide me with e2fsck or give me a link to a specific tutorial related to android e2fsck?
is there not a way in adb to like replace the corrupt partitions with freshly created ones ? or any other workaround ?
Any help will be appreciated a lot, i'm willing to donate to whoever provides me with a solution to get my tab running again.
Thanks for reading.

check this thread, very informative, helped me before
http://forum.xda-developers.com/showthread.php?t=1625675&highlight=bootscreen

Thanks a lot, already checked that one though.
Everything that worked for the guys in that thread doesn't work for me, or I'm too ignorant to find out the right e2fsck command...

Still no one able to provide some help please ?
It's weird that so many people are having the same issue on 7.7 these days, could it be related to the EU ban of this tab ?^^
Anyway, last day before i send it to Samsung

check this thread here it may help you solve your issue. All problems are coming from a brick bug in the ICS Kernel thats trigerred by wiping.

Thanks a lot, trying this right now

Can someone please post a (parted) print of a safe and working Galaxy Tab 7.7 (either of the two models) ?
I need the exact size of the /data partition

ISSUE FIXED Thanks to Zorbakun's last post. A million thanks dude.
However, the actual internal storage of my tab is now 50mb :silly: anyway i'll find a way to fix that too.

the actual internal storage of my tab is now 50mb
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi

cakrabayu said:
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi
Click to expand...
Click to collapse
Well yeah, didn't recover the 16gb but you can try to earn yourself some extra gigs by doing this once you created a fresh /data partiton :
this is an example for p6810, replace resize 9 with resize 10 if on a p6800
Code:
adb shell
parted /dev/block/mmcblk0
print
resize 9
It will ask you for start/end values, keep the same start value otherwise it will give you an error. A good idea is to resize the partition like + 500mb at a time, to avoid i/o errors you might get when creating/resizing large file systems.
Hope it helps, good luck.

I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--

aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
Try the .PIT file for the P6800 located here. You will lose all data, and part of your internal SD space. Looks like the brick happens consistently at the same point of the memory chip, so the same .PIT works for most people. If that doesn't help, you will need parted.
How can you use parted? It's a Linux program that runs in your tablet. You will adb shell to it, then you will have a Linux shell. Everything you put down there will run in your tablet, as if you were typing on it (think ssh, or remote desktop). I can't help you much more, because (knocks on wood) my tablet is still very much alive, and I don't use ADB that much.
Now, I don't know how it works in your country, but here in Brazil the Samsung service accepts warranties issued anywhere. It may be worth a shot.

aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
I am working on writing a specific 7.7 guide to teach people the parted/e2fsck technique I use to revive my bricked p6810 everytime I want to flash a new rom or test my builds.
First, as pointed out, try to Odin the PIT file for your particular model (eg : P6800 16gb).
You got to know that the parted technique is a pain in the ass, that you'll have to do it quite often if you like flashing roms, and that your tab will have a much smaller internal storage.
I think the guide will be ready in a couple days but you can pm be if you need help before that, no problem.
Good luck with this superbrick curse

thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!

aletheus said:
thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!
Click to expand...
Click to collapse
I just finished writing the guide, it's here : forum.xda-developers.com/showthread.php?t=1862294

[UPDATED][INFO] ROM 101 + CWM Errors Solutions

Parts of a ROM
i. The kernel.
Android (like many other Smartphone operating systems) runs on the Linux kernel. The Linux kernel was created in the early 1990’s by a gentleman named Linus Torvalds in Helsinki, Finland. It’s incredibly stable, incredibly friendly, and incredibly difficult for the layman to understand and modify. Thankfully it’s also very popular so it has been ported on to a multitude of hardware, including our Android devices.
Think of the kernel as an interface layer between the hardware and software on your device. The kernel decides when things happen, such as the LED indicator gets lit or when the soft button's LED gets lit. An application sends a request to the operating system to blink the LED. The operating system then sends the request to the kernel, which makes the light flash for the amount of time requested by the OS.
What sounds like a round-about way to get things done is also what makes the system so scalable and robust. Application developers only have to code in a way the operating system understands and the kernel makes it work on the hardware. This also keeps the application running in it’s own user-space and separate from the kernel. That means when you run the latest uber-cool app that wasn’t designed for your particular OS version, or is still very beta and it crashes, the kernel gives you the option to Force Close the application and the kernel can run untouched.
In a standard Android ROM (we will leave developer images and the like for another discussion) the kernel is bundled along with a set of instructions that tell the device how to load the kernel and the OS during boot. This is the boot.img that you see inside a zipped ROM that your not able to easily open. The device knows to extract this image to internal memory (the ramdisk) and follow a series of scripts (init scripts) to load the kernel and then the other portions of the OS. That’s what’s happening while you’re watching the boot animation. Interestingly enough this is done the same way for a PC, your smartphone, an Android tablet, or even a smart Linux powered toaster. If you’re feeling exceptionally geeky, plug your Android phone into the USB port on your PC and let the PC boot from the USB device. No, it doesn’t actually load, but you can watch the animation while it tries to match up the hardware support with what’s inside your PC. As I said, Linux is amazingly scalable and as a result so is Android.
What is a kernel? If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
Click to expand...
Click to collapse
ii. The operating system.
Once the kernel is loaded, the init scripts tell the Operating System to load. Android is the user interface for a custom built Java virtual machine called Dalvik. Dalvik was written by Dan Bornstein, who named it after the fishing village of Dalvik in Iceland, where his family originated from. The debate of which Java VM is superior is best left for another discussion, so I’ll simply say that DalvikVM is a register-based machine versus true JavaVMs which are stack based.
The Dalvik machine creates executable files (.dex files) which can be interpreted by the OS and run by the end user. These .dex files are OS version dependant. That simply means that applications and core functions built to work with one version of Android may or may not work well with other versions. Google provides the tools through it’s Software Development Kit (SDK) for applications to communicate with the OS.
Click to expand...
Click to collapse
iii. Core functions.
No smartphone would be complete without a set of functions that allow the device to be used as intended. Things like the phone and dialer interface, the calendar, the messaging system are core functions of the Operating System. In Android, these are run on top of the kernel as separate applications. The merits (or lack of) of providing these needed functions as separate applications is once again best left for another discussion, but this is what allows developers like HTC or Motorola to replace the standard functions with alternatives that provide a different look and feel from stock. HTC’s onscreen keyboard or Motorola’s MotoBlur contact list are great examples of this. The “little guy” isn’t left out of the mix either. Handcent SMS or Chomp SMS can integrate into the OS very well, as most of us already know.
An additional set of Core Functions are provided by Google. Popularly called GoogleBits, things like Gmail, sync, Gtalk and the Android Market are applications written by Google that give an extra set of useful functions to the OS. You’ll find these on all smartphones, as well as many other Android devices.
Click to expand...
Click to collapse
iv. Optional applications.
These are applications provided by the manufacturer to give the device even more usability. Things like the Amazon MP3 store, PDF readers, Corporate Calendar etc. allow you to do even more with your device. Remember - Droid Does
Click to expand...
Click to collapse
B. How is a ROM packaged?
In most cases a ROM will come packaged in a .zip file. The recovery image’s kernel (yes, it has one too!) has the ability to unzip and copy the contents into the correct place. Inside this zip file is a folder (META-INF\com\google\android\) that contains a script prepared by the ROM “cooker” (another of those techie terms - it means the person(s) who developed the ROM) that tells the system what to format, what to copy and where, and any file operations that need to be done. Each device does things a bit differently, but this script is where it all gets done. More on this folder later.
You’ll also see a /system folder. This is the meat of the ROM. It has the necessary OS files, the Core functions, and any optional applications the cooker decided to include. The folder is structured the same way it is on your device - /system/app, /system/framework, etc. The whole tree is usually copied over and the existing /system folder is overwritten. The cooker uses the script to tell the kernel to erase the existing system folder, copy the new folder over, and set the file permissions.
Sometimes you will also see a data folder. This usually is space set up for optional applications, including optional system tools like busybox or SuperUser white list. These applications could be placed in the /system folder, but placing them in the data folder makes it easier for the end user (you and I) to remove or update them as needed.
You’ll also notice a META-INF folder. This contains the update script we talked about earlier, as well as secure keys that need to be provided so the device knows the update can be trusted. A special note needs made here. Trusted means that the update is trusted to be in the correct form to load the device. It in no way means the ROM is safe from malicious code. Anyone is able to use a set of test keys and create a ROM that will flash and run your device - even those people with bad intentions. Flashing and running a custom 3rd party ROM is putting faith in the cooker that he or she not only knows what they are doing, but are honest as well. Also, some Motorola custom ROMs will have a small update.zip stored inside this folder to be run on first boot of the device.
Finally we are left with the boot.img file. This is the kernel and ramdisk image we discussed earlier. Your phone copies this over to be decompressed and run when the device boots.
Click to expand...
Click to collapse
2. How do I install a ROM?
In this section we’re discussing how to install a custom 3rd party ROM. ROMs from the manufacturer usually have a utility that runs on your PC to flash and load the new image.
A. Got Root???
What is Root?
Android rooting is the process of allowing users of smartphones, tablets, and other devices running the Android mobile operating system to attain privileged control (known as "root access") within Android's subsystem.
Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices, resulting in the ability to alter or replace system applications and settings, run specialized apps that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system, usually with a more recent release of its current operating system.
As Android derives from the Linux kernel, rooting an Android device is similar to accessing administrative permissions on Linux or any other Unix-like operating system such as FreeBSD or OS X.
The process of rooting varies widely by device, but usually includes exploiting a security bug(s) in the firmware (i.e. in Android) of the device, and then copying the su binary to a location in the current process's PATH (e.g. /system/xbin/su) and granting it executable permissions with the chmod command. A supervisor application like SuperUser or SuperSU can regulate and log elevated permission requests from other applications. Many guides, tutorials, and automatic processes exist for popular Android devices facilitating a fast and easy rooting process.
For example, shortly after the HTC Dream was released, it was quickly discovered that anything typed using the keyboard was being interpreted as a command in a privileged (root) shell. Although Google quickly released a patch to fix this, a signed image of the old firmware leaked, which gave users the ability to downgrade and use the original exploit to gain root access. Once an exploit is discovered, a custom recovery image that skips the digital signature check of a firmware update package can be flashed. In turn, using the custom recovery, a modified firmware update can be installed that typically includes the utilities (for example the Superuser app) needed to run apps as root.
The Google-branded Android phones, the Nexus One, Nexus S, Galaxy Nexus and Nexus 4, as well as their tablet counterparts, the Nexus 7 and Nexus 10, can be boot-loader unlocked by simply connecting the device to a computer while in boot-loader mode and running the Fastboot program with the command "fastboot oem unlock".[9] After accepting a warning, the boot-loader is unlocked, so a new system image can be written directly to flash without the need for an exploit.
Recently, Motorola, LG Electronics and HTC added security features to their devices at the hardware level in an attempt to prevent users from rooting retail Android devices.[citation needed] For instance, the Motorola Droid X has a security boot-loader that puts the phone in "recovery mode" if a user loads unsigned firmware onto the device, and the Samsung Galaxy S II displays a yellow triangle indicator if the device firmware has been modified.
Click to expand...
Click to collapse
Yes ?:good:!!!
Custom ROM’s simply will not load on devices that aren’t rooted. In theory, it may be possible to sign a 3rd party ROM with the keys that the stock recovery image will flash, but for the most part you need to have flashed a custom recovery image before you can change your device’s ROM. Instructions and tutorials on how to root your device are all over the internet. Some are good, some are bad. The hacking forum is a great place to go and learn more about rooting and how to successfully get it done on your device.
Click to expand...
Click to collapse
B. Recovery
Most Android devices have had a custom recovery image written for them. This will overwrite the stock recovery image, allowing you to flash 3rd party ROMs as well as giving extra functionality. Help with finding and flashing the custom recovery image for your device can also be found in the hacking forum. The installation of a custom recovery image also allows for a very important function. Backup and restore.
Click to expand...
Click to collapse
.C. Nandroid
Nandroid is a set of bash scripts and code written by that copies the state of your system and stores it in a folder on your SD card. You can then use the restore function of Nandroid to restore to this point at any time. This is a priceless feature and reason enough to root your phone. It’s included by default in most custom recovery images, and the code is freely available to use if you’re inclined to write your own recovery image.
Click to expand...
Click to collapse
In most situations, using Nandroid to back everything up is easy:
1. Verify you have a memory card with enough free space (~300MB to backup, ~500MB to restore).
2. Reboot your device into recovery. It’s slightly different for each device, once again hacking forum FTW!
3. Navigate through the menu and select the Nandroid Backup function.
4. Apply your choice and wait for the device to tell you it’s finished.
It’s always good practice to copy the entire nandroid folder from your SD card to a safe place. You can then copy it back to the SD card if the card is ever damaged, lost or erased.
D. Copy and Flash
You’re rooted, have downloaded a custom ROM, have your system backed up and are now ready to flash your device. This is not nearly as scary as it sounds.
1. Mount your SD card to your PC, and copy the .zip file to the root folder of the card. Don’t unzip the file, and don’t look for a folder called root. The root folder in this case means the base folder, what you will see when you mount your card to a PC or the device.
2. Reboot your phone into recovery.
3. Navigate through the recovery menu and select the flash update option. Depending on your recovery image, the file may need to be named update.zip, or you may be able to select any zip file on your card as long as it’s the correct format. The cooker knows this as well and if the ROM needs to be named update.zip it will be.
4. Apply your choice and wait for your device to tell you it’s finished.
5. Reboot.
Click to expand...
Click to collapse
It’s worth noting that many times a new ROM will require that you wipe and factory reset your devices data. While inconvenient, it’s often necessary to get rid of the old data as it may be incompatible. As long as you’re using the cloud for calendar and contacts, they will be re- downloaded and stored back on your device automatically.
Dirty flash and Clean flash
A dirty flash is only wiping cache and davlik then flashing your ROM....
a Clean flash is at LEAST factory reset/data wipe + wiping davlik(factory wipe takes care of /cache also)... Maybe doing a format /system also.

ERRORS encountered in CWM Recovery
.
What is CWM Recovery ?
ClockworkMod Recovery is a custom recovery for many Android devices. It is considered to be the most popular recovery for Android due to its easily-ported nature, and integration with ClockworkMod ROM Manager by Koush(Koushik Dutta). The easiest way to recognize it is by the printed name when it first starts, and the background logo of a gear and hat.
Click to expand...
Click to collapse
ERROR STATUS 6
This is usually caused by CR/LF EOL(Windows style End Of Line) in updater-script. Change it to LF EOL(Unix Style EOL) using Linux command: dos2unix updater-script, then re-signing the ZIP, will usually fix this error.
Click to expand...
Click to collapse
ERROR STATUS 7
This is usually caused by a corrupt download, or bad file signature. Re-downloading (or re-signing) the ZIP will usually fix this.
Click to expand...
Click to collapse
We have been consistently seen and heard people facing error “Status 7″ error while trying to flash or install
custom ROMs or firmware packages on their Android smart phones or tablets with ClockworkMod Recovery. Many
of the users are nowadays facing this problem with CWM Recovery while flashing .zip files of modded or custom
Ice Cream Sandwich (ICS) or Jelly Bean (JB) ROMs on their devices. So, you have also downloaded a custom ROM,
placed its .zip file in your phone’s or tablet’s SD card, booted into ClockworkMod Recovery, selected – “install zip
from sdcard” and then chosen the .zip file of the ROM to get it installed on your device. But instead of getting
flashed successfully, if you are facing the issue mentioned below, then just keep reading this article to find out
what’s wrong and fix up the problem :
Finding update package…
Opening update package…
Installing update…
Error in /sdcard/custom-jelly-bean-rom.zip (Status 7)
Installation aborted
Click to expand...
Click to collapse
or the following error right after CWM recovery shows –
Installing update…
assert failed: getprop(“ro.product.device”) == “I9103″ || getprop(“ro.build.product”) == “I9103″ || getprop
(“ro.product.board”) == “I9103″
Error in /sdcard/android-4-1-1-ics-rom-latest.zip (status 7)
Click to expand...
Click to collapse
So, if you are facing any of these errors while trying to install the desired custom ROM package on your Android
phone or tab, then you may try a various things or steps which may turn out to be the workaround of this
problem. Here are a few tips to get this “Status 7” error fixed in ClockworkMod Recovery and flash the ROM
successfully on your device :
(1) First of all, make sure your device’s bootloader is unlocked. If it is already unlocked but you are still
not able to flash the ROM, then just extract the .zip file of the ROM into a new folder, find the boot.img file from
that directory and flash it up on your phone or tablet via fastboot on your PC.
(2) Make sure that you are having the appropriate Radio or Baseband version installed on your device which is
supported by the custom ROM you are trying to flash. Most of the ROMs requires the latest version of Baseband, so
just update or upgrade your device to the latest Baseband version and then try to install the ROM once again.
(3) Update your device to the supported / latest build of official firmware before trying to install the ROM. You can
do it from – Settings > About Phone / Device > Software Update.
(4) Make sure you are having the supported or required kernel installed on your phone or tab. If it’s not, then flash
a new kernel right away and try to install your custom ROM once again.
(5) Is the ROM which you are trying to flash really works ? Find out whether it is working for other users or not.
Click to expand...
Click to collapse
Error Status 0
Well sometimes while flashing some ROMs especially the cooked ones we get Error status 0 in the CWM Recovery
this error is an indicator of Wrong Update Binary.This is usually caused by an incompatible update-binary in edify ZIPs. Replacing it with a compatible one, then re-signing the ZIP, will usually fix this error.
Click to expand...
Click to collapse

Now it's time for the partitions :good:
Let’s start with a list of standard internal memory partitions on Android phones and tablets. These are:
/boot
/system
/recovery
/data
/cache
/misc
In addition, there are the SD card partitions.
/sdcard
/sd-ext
Note that only /sdcard is found in all Android devices and the rest are present only in select devices. Let’s now take a look at the purpose and contents of each of these partitions.
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the kernel and the ramdisk. Without this partition, the device will simply not be able to boot. Wiping this partition from recovery should only be done if absolutely required and once done, the device must NOT be rebooted before installing a new one, which can be done by installing a ROM that includes a /boot partition.
/system
This partition basically contains the entire operating system, other than the kernel and the ramdisk. This includes the Android user interface as well as all the system applications that come pre-installed on the device. Wiping this partition will remove Android from the device without rendering it unbootable, and you will still be able to put the phone into recovery or bootloader mode to install a new ROM.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it. To learn more about this partition and its contents, see the ‘About Android Recovery’ section of our guide to ClockworkMod recovery.
/data
Also called userdata, the data partition contains the user’s data – this is where your contacts, messages, settings and apps that you have installed go. Wiping this partition essentially performs a factory reset on your device, restoring it to the way it was when you first booted it, or the way it was after the last official or custom ROM installation. When you perform a wipe data/factory reset from recovery, it is this partition that you are wiping.
/cache
This is the partition where Android stores frequently accessed data and app components. Wiping the cache doesn’t effect your personal data but simply gets rid of the existing data there, which gets automatically rebuilt as you continue using the device.
/misc
This partition contains miscellaneous system settings in form of on/off switches. These settings may include CID (Carrier or Region ID), USB configuration and certain hardware settings etc. This is an important partition and if it is corrupt or missing, several of the device’s features will will not function normally.
/sdcard
This is not a partition on the internal memory of the device but rather the SD card. In terms of usage, this is your storage space to use as you see fit, to store your media, documents, ROMs etc. on it. Wiping it is perfectly safe as long as you backup all the data you require from it, to your computer first. Though several user-installed apps save their data and settings on the SD card and wiping this partition will make you lose all that data.
On devices with both an internal and an external SD card – devices like the Samsung Galaxy S and several tablets – the /sdcard partition is always used to refer to the internal SD card. For the external SD card – if present – an alternative partition is used, which differs from device to device. In case of Samsung Galaxy S series devices, it is /sdcard/sd while in many other devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored automatically on this external SD card and everything present on it has been added there by the user. You can safely wipe it after backing up any data from it that you need to save.
/sd-ext
This is not a standard Android partition, but has become popular in the custom ROM scene. It is basically an additional partition on your SD card that acts as the /data partition when used with certain ROMs that have special features called APP2SD+ or data2ext enabled. It is especially useful on devices with little internal memory allotted to the /data partition. Thus, users who want to install more programs than the internal memory allows can make this partition and use it with a custom ROM that supports this feature, to get additional storage for installing their apps. Wiping this partition is essentially the same as wiping the /data partition – you lose your contacts, SMS, market apps and settings.
With this, we conclude our tour of Android partitions. Now whenever you install a ROM or mod that requires you to wipe certain partitions before the installation, you should be in a better position to know what you’re losing and what not and thus, you’ll know what to backup and what not.
ADB-Android Debugging Bridge
Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
A daemon, which runs as a background process on each emulator or device instance.
You can find the adb tool in <sdk>/platform-tools/.
When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.
Click to expand...
Click to collapse
The server then sets up connections to all running emulator/device instances. It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices. Where the server finds an adb daemon, it sets up a connection to that port. Note that each emulator/device instance acquires a pair of sequential ports — an even-numbered port for console connections and an odd-numbered port for adb connections. For example:
Emulator 1, console: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557
and so on...
As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console listens on port 5554.
Once the server has set up connections to all emulator instances, you can use adb commands to access those instances. Because the server manages connections to emulator/device instances and handles commands from multiple adb clients, you can control any emulator/device instance from any client (or from a script).
Note: When you connect a device running Android 4.2.2 or higher to your computer, the system shows a dialog asking whether to accept an RSA key that allows debugging through this computer. This security mechanism protects user devices because it ensures that USB debugging and other adb commands cannot be executed unless you're able to unlock the device and acknowledge the dialog. This requires that you have adb version 1.0.31 (available with SDK Platform-tools r16.0.1 and higher) in order to debug on a device running Android 4.2.2 or higher.
Syntax
You can issue adb commands from a command line on your development machine or from a script. The usage is:
adb [-d|-e|-s <serialNumber>] <command>
If there's only one emulator running or only one device connected, the adb command is sent to that device by default. If multiple emulators are running and/or multiple devices are attached, you need to use the -d, -e, or -s option to specify the target device to which the command should be directed.
LOGCAT
The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command. You can use logcat from an ADB shell to view the log messages.
-b <buffer> Loads an alternate log buffer for viewing, such as event or radio. The main buffer is used by default. See Viewing Alternative Log Buffers.
-c Clears (flushes) the entire log and exits.
-d Dumps the log to the screen and exits.
-f <filename> Writes log message output to <filename>. The default is stdout.
-g Prints the size of the specified log buffer and exits.
-n <count> Sets the maximum number of rotated logs to <count>. The default value is 4. Requires the -r option.
-r <kbytes> Rotates the log file every <kbytes> of output. The default value is 16. Requires the -f option.
-s Sets the default filter spec to silent.
-v <format> Sets the output format for log messages. The default is brief format. For a list of supported formats, see Controlling Log Output Format.

awesome thread to learn everything in a quick while

Again.? :good:
But highlight the Status error with big & bold font.

Disturbed™ said:
Again.? :good:
But highlight the Status error with big & bold font.
Click to expand...
Click to collapse
I think he's trying to take over XDA
But just to keep this on topic, great thread for those who are learning and aren't sure what certain things are for.
I guess I'll have to make another thread in this forum just so other RCs don't take all the ideas
SGS2 FAQ | HTC One FAQ

KidCarter93 said:
I think he's trying to take over XDA
But just to keep this on topic, great thread for those who are learning and aren't sure what certain things are for.
I guess I'll have to make another thread in this forum just so other RCs don't take all the ideas
SGS2 FAQ | HTC One FAQ
Click to expand...
Click to collapse
Lolzzz.. Yes buddy. He is something else.
Collecting Informations & useful stuff for all users. May be in near future, he will take over XDA.

It's all your love guys. Sometimes even my guides correct my mistakes!
Started from the bottom

Guys if you like this thread please press the tip us button so that more and more people who are willing to learn about android phone and how they work can get help.
I will be grateful to you all.
Started from the bottom

Very nice write up TechnoCrat :good::good::good:
TEAM MiK
MikROMs Since 3/13/11

Long way to go mate!
Congo! This thread got featured on XDA Portal
http://www.xda-developers.com/android/android-101-how-it-all-fits-together/

Thank you very much. I needed this definition thread. I kinda understand but it'd nice to hear official language that's understandable.
Sent from that FBI van parked down the street.

Thanks for the CWM errors write up and another bookmark.

Tha TechnoCrat said:
i. The kernel.
If you’re feeling exceptionally geeky, plug your Android phone into the USB port on your PC and let the PC boot from the USB device. No, it doesn’t actually load, but you can watch the animation while it tries to match up the hardware support with what’s inside your PC
Click to expand...
Click to collapse
What. The. Hell. Are you talking about?
If you mean booting the device's kernel on the PC, unless the device uses an x86 processor, it flat out will not boot, let alone mount the device's system, to display the bootanimation.zip
/snarkieness
Sorry, I had to let that out.
Also, init is called/started after the kernel has started, and generally after it has setup most of the hardware.
so I’ll simply say that DalvikVM is a register-based machine versus true JavaVMs which are stack based.
Click to expand...
Click to collapse
I don't even truly understand that, so could add a little more detail, or remove it?
I'm speaking mostly from my implied knowledge, gained from tinkering with android/linux for a few years.

ADB and Logcat added

Hey, Thanks for the article. Can you talk about root? There is some mis-leading information and I really want to learn about it. Thanks again.

ak700 said:
Hey, Thanks for the article. Can you talk about root? There is some mis-leading information and I really want to learn about it. Thanks again.
Click to expand...
Click to collapse
Okay buddy
Editone! !!
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Bump to update newbies
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

QD 9008 FIX!! Tested on LG-V410(G Pad 7.0 US ATT)

I am beyond ecstatic, after 3 months of research, trial and error, I fixed my tablet!!
I am pleased to announce a fix to the dreaded QDLOAD 9008 brick! I've written this tutorial on the one tablet experimented on (LG-V410 aka Gpad 7.0 LTE US ATT), but I'm pretty certain others may find this helpful to other qualcomm msm based devices.
Background: I maintain that I can fix anything I break so I did the worst thing and corrupted the data on my LG GPAD LTE 7.0 (V410). As a result the tablet wouldn't go into any mode, no lights, even when charging, no screen image or light, nothing. When I plugged it into my computer, it wasn't even recognized, windows told me the device was having a problem. After a little experimentation I got it recognized (held power while connected to power cycle) by the computer as "QD BULK". Further research I found some drivers for Qualcomm devices and got the computer to recognize it as "QDLOADER 9008". I thought this was great news but from there got no where. I tried qpst, qfuse, hyperterminal, LG B2C, LG SUPPORT TOOL, EFS Professional, miflash, blankflash, etc... everything I tried got me nowhere. After 3 months, It is now fully operational and apparently CARRIER UNLOCKED, talk about a pot of gold at the end of a rainbow!!
WORD OF WARNING: This is not a simple matter, 9008 most likely means your Grand Partition Table is corrupted, and the poor thing doesn't have a clue how to function. My method is NOT GUARANTEED in any way, I will not be responsible if you turn your paper weight of a device into permanent paper weight or half functioning paper weight etc...PROCEED WITH CAUTION, this is not for the feint of heart nor a simple fix!! You've been warned!
PreRequisites:
-Windows (for expanding the KDZ) (there may be a linux alternative to LGFirmwareExtract)
-Linux and some basic experience with dd and navigating the terminal (I used ubuntu) --(again, nearly everything I'm about to explain can probaly be translated to another os.)
-KDZ for your device. http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
-Replacement aboot and boot (see attached)
-KDZ Extractor ---http://forum.xda-developers.com/showthread.php?t=2600575
-TWRP http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
-Fasboot and ADB http://forum.xda-developers.com/showthread.php?t=2588979
-A modified rom like Cyanogen mod etc... http://download.cyanogenmod.org/?device=v410
-16GB microsd card + a way of directly writing to it (i.e. usb card reader etc..) a second one is helpful but not required.
-Most important, Patience, beer, more patience, and more beer...
To teach a man to fish, some pertinent understanding: First thing to understand is how your main board works. Personally I disassembled my device and cross referenced every chip to do this, Good news is you don't have to. When power goes to the device, the SoC (system on a chip) looks to built in storage media for booting instructions (think low level here) and that in turn fires up everything else and then loads your kernel etc... You may be aware, there are two different types of computer systems out there, the old method used a BIOS, and the current uses UEFI. Older machines, when power was given to the system, the BIOS was responsible for firing up peripherals and finding the bootloader etc... UEFI (Unified Extended Firmware Instruction) however, relies on firmware on storage media to do all that.
For example, an x86 PC with a bios, when power is given to the board, the bios runs the show, testing equipment and waking up devices, then when it's ready, it looks to external media for a little magic byte at the end of the first sector of that media to indicate that it is bootable and in turn will boot (let those instructions take over). This style of booting media is called MBR or Master Boot Record.
Modern machines and most mobile devices use GPT or global partition table. There are quite a few advantages to GPT one primary being the possibility of many many more primary partitions, (MBR was very limited). The GPAD 7 LTE has 34 partitions to put things in perspective. When your device is stuck in 9008 mode, it is because it doesn't have a clue how to boot, most likely your GPT is corrupted. Fortunately, at least with the Gpad 7.0 this information does not have to be on the onboard internal memory chip. For this fix we will be constructing an sdcard to have all this info to get into a mode capable of writing to the emmc.
Without Further Ado, Here are the steps:
]PLUG THE TABLET INTO A CHARGER while you do the following (you may think it's been off and fully charged, but in reality it's probably been trying to boot over and over again while looking lifeless)
1.) Get the KDZ for your device (stock firmware)
2.) Extract the DZ using LGFirmwareExtractor
3.) Extract all the .bin files from the DZ using LGFirmwareExtractor
3b.) V410 US LTE ONLY - Replace aboot and boot with the files I attatched --I was fortunate enough to back them up before I hosed my tablet and they proved invaluable as the ones in the KDZ I linked to were causing strange graphic issues.
4.) open a terminal in linux and dd the sdcard with the file you extracted called "PrimaryGPT...."
I.E. "sudo dd if=/PATHTODZFILES/PrimaryGPT_0.bin of=/dev/sdx" (BE CERTAIN of the of= path, you can find yourself with more problems if you get that wrong) (run "sudo fdisk -l | less" first to verify what your sdcard's path is.)
This is where it gets tedious...:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
7.)Unmount your sdcard and put it in the tablet
8.) Press and hold power and volume up...If all went well, there is suddenly life to your paperweight!! Congratulate yourself and prepare for more fun... If nothing happened, revisit the above steps, more than likely something got flashed to the wrong partition.
9.)Now that you have fastboot, plug your tablet into the computer and use the following command: "fastboot boot TWRP.img" (or whatever the name or path is for your downloaded TWRP image.
10.) You should now be in TWRP and now your device is ADB ready, we are close to the home stretch...
11.) Now we need to load up an sdcard with all those dz files (except for laf and system images) and the custom rom like cyanogen mod. (if you only have the one sdcard you can unmount it and remove it while the table is in TWRP...crazy right?, if you opt for this, reformat the sdcard to ext or fat or whatever you please so the tablet can see all the bin files) Then put the sdcard into the tablet. You may need to remount the card in twrp before proceeding...
12.) Now from your computer type the following command "adb shell".
13.) now just like you did with the sd card dd PrimaryGPT_0.bin to the internal memory card, with the following command: dd if=/sdcard/PrimaryGPT_0.bin of=/dev/block/mmcblk0
14.) Grab the paper you wrote all the partitions down on and start doing the same thing you did to the sdcard to your tablet. You'll adjust the following command accordingly: "dd if=/sdcard/PARTITIONNAME.bin of=/dev/block/mmcblkpX (X being the partition number)
(again skip all system bin's and laf_xxxx.bin. Flashing laf disables fastboot on LG devices.)
15.) now time to install your custom rom, go through the prompts, clear your cache, and delvik cache and choose power off.
If all went well, you now have a tablet again, that's unlocked too!!!!! If not, don't lose faith, revisit the steps and ensure you didn't mistype or overlook something, this is so tedious it's easy to do. For instance, if you mistype your of=xxx it will create the file instead and give no error.
Post with your success stories, questions or difficulties and I'll try to help.
Yours Truly,
TheKiln
UPDATE/WARNING: Do not at any time under any circumstances dd directly from your host computer to the internal memory on your tablet, only do this via the asb shell. This may render a mode that I have not yet found a fix to, I will be working on it soon but from initial observation may be more complicated then the above instructions. With any invasive hacks like this tutorial there is always the possibility of making matters worse, so exercise caution and patience.

Quick Update/Revision : I am actively experimenting with this device and wanted to share that if your sbl1 and sbl1b partition is corrupt I have confirmed it will also cause 9008 mode. Therefore, it may be best to determine if the table is corrupt (try "parted /dev/block/mmcblk print"), and if not instead of wiping rewriting mmcblk0 try restoring sbl1 and sbl1b first. The V410 boots in the following order from what I can tell slb1->aboot->boot->system. So far I haven't found a downside to my prior instructions but to be less invasive just in case it might be wise to try this amendment.

I know my grand partition is corrupt, because after doing fastboot erase, basically everything, it came up as /dev/sdb. In a panic, I had deleted all the partitions, so now obviously my emmc storage is one big formated 16gb HD that cannot be seen in windows or linux no longer.
I just tried your method, found this post by doing a google search for:
sudo dd if=PrimaryGPT_0.bin
Had been doing just this, including the laf and many other ways. Am still getting the same thing though when putting the sdcard in the tablet, shows a 0% battery.
with the sdcard in the tablet I do get:
Bus 003 Device 063: ID 05c6:f006 Qualcomm, Inc.
Then after a few minutes, leaving it plugged into the USB I get:
Bus 003 Device 058: ID 1004:61a1 LG Electronics, Inc.
Also, with the sdcard in I do get KDZ_FW_UPD_EN to start updating but then get a perimeter error.

bethnesbitt said:
I know my grand partition is corrupt, because after doing fastboot erase, basically everything, it came up as /dev/sdb. In a panic, I had deleted all the partitions, so now obviously my emmc storage is one big formated 16gb HD that cannot be seen in windows or linux no longer.
I just tried your method, found this post by doing a google search for:
sudo dd if=PrimaryGPT_0.bin
Had been doing just this, including the laf and many other ways. Am still getting the same thing though when putting the sdcard in the tablet, shows a 0% battery.
with the sdcard in the tablet I do get:
Bus 003 Device 063: ID 05c6:f006 Qualcomm, Inc.
Then after a few minutes, leaving it plugged into the USB I get:
Bus 003 Device 058: ID 1004:61a1 LG Electronics, Inc.
Also, with the sdcard in I do get KDZ_FW_UPD_EN to start updating but then get a perimeter error.
Click to expand...
Click to collapse
Ive seen the exact mode you are referring to. Three possibilities:
1.) unplugged, hold down the power button for 30 seconds (or less if fastboot comes up)
2.) your sd card does not have all the necessary partitions to boot (which i just confirmed are specifically rpm, rpmb, tz, tzb, sbl1, sbl1b, PrimaryGpt(has to be done first), aboot and abootb)
3) They didn't dd quite right. from my active testing Ive found if you script the dd'ing it doesn't quite flash right, unless you add a delay after each step.
Its actually a very good sign you are seeing the 0% battery logo, sounds like you are almost there. Let me know what happens. Ill be happy to help guide you. Ive dedicated my v410 as a dev board so Im constantly running tests and reverse engineering it.

The 0% only shows up with the sdcard in, after I remove it, nothing. Tried wall charging it all night, that did nothing.
My theory is that if there was some way to mount the raw emmc and dd the primarygpt.bin to the raw emmc hd then the rest would be not problem.
I deleted the original EMMC partitions in gparted under linux after doing an erase fastboot -w laf, system, etc... something like that. After that the tablet did not show up again in gparted as soon as I unplugged it.
Right now I'm zero dd'ing my 16gb sd card, dang dd'ing seems to glue the partitions to the sdcard, If I try to fdisk the sdcard or delete the partitions using gparted, as soon as I dd the primarygpt.bin the old files reappear. Need to start fresh with 0s to the card.
In windows I can actually install specific lg drivers while in qualcomm hs_usb 9008 mode. The interesting thing with the sdcard in I can install the LG Android Net USB serial driver, which will not work while in 9008 mode.

bethnesbitt said:
The 0% only shows up with the sdcard in, after I remove it, nothing. Tried wall charging it all night, that did nothing.
My theory is that if there was some way to mount the raw emmc and dd the primarygpt.bin to the raw emmc hd then the rest would be not problem.
I deleted the original EMMC partitions in gparted under linux after doing an erase fastboot -w laf, system, etc... something like that. After that the tablet did not show up again in gparted as soon as I unplugged it.
Right now I'm zero dd'ing my 16gb sd card, dang dd'ing seems to glue the partitions to the sdcard, If I try to fdisk the sdcard or delete the partitions using gparted, as soon as I dd the primarygpt.bin the old files reappear. Need to start fresh with 0s to the card.
In windows I can actually install specific lg drivers while in qualcomm hs_usb 9008 mode. The interesting thing with the sdcard in I can install the LG Android Net USB serial driver, which will not work while in 9008 mode.
Click to expand...
Click to collapse
The 0% comes up when your sdcard is inserted because you are close to getting it done. You're going to have your computer running all night on the zero'ing but I can assure you that will be in vein. The whole point of this tutorial is so you can get into a mode in which you can flash the emmc. I can tell you are a little lost in the steps so pm me and I'll help you out. Also a word to the wise, you can try all you want with windows and the 9008 drivers, but seriously there is nothing out there specific to the v410 thats going to help you "engage" the 9008 mode. Not being stubborn I've just literally tried it all. If it's any credit I am clinically OCD. I can't sleep till I figure things out.

Finally, I see a hope is shining here!
I bricked my LG VK810, when I was trying to flash twrp, I refered to v500 pad instead and I flashed wrong img files (aboot, boot, sb1, sb2, sb3, tz & twrp.img) "only those 6 files" so I only need to replace those with the correct files, which I downloaded now.
I do not have Ubuntu, however I have CentOS, which i have not used for couple of years, so I forgot how to use it. also do I still need to use the LG Firmware Extractor?
please help

thekiln said:
This is where it gets tedious...:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
Click to expand...
Click to collapse
Please please please help, how to do those steps!

nmnm4alll said:
Please please please help, how to do those steps!
Click to expand...
Click to collapse
I am not certain exactly which partitions have to be flashed, the attached note I made was from what I can tell so far. I was simply noting that it may be best to try one partition at a time vs doing them all at once, it is at your own descretion. So as far as listing the partitions, I'm not familuar with the centos distro but in Ubuntu it is something to the effect of fdisk /dev/sdb -l or gdisk /dev/sda then p. I hope that answers your question, If not please be more specific to your exact question.

thekiln said:
I am not certain exactly which partitions have to be flashed, the attached note I made was from what I can tell so far. I was simply noting that it may be best to try one partition at a time vs doing them all at once, it is at your own descretion. So as far as listing the partitions, I'm not familuar with the centos distro but in Ubuntu it is something to the effect of fdisk /dev/sdb -l or gdisk /dev/sda then p. I hope that answers your question, If not please be more specific to your exact question.
Click to expand...
Click to collapse
Thank you very much for your response, I am sorry I have never flashed partitions before, sbut I noticed gparted is not on CentOS, so I downloaded Puppy precise Linux as I was able to find gparted and I tried using it as shown in this video, https://www.youtube.com/watch?v=6z1Tu9l8WNc
But I am confused now about how big and what are the formats for the 34 partitions which need to be created?

nmnm4alll said:
Thank you very much for your response, I am sorry I have never flashed partitions before, sbut I noticed gparted is not on CentOS, so I downloaded Puppy precise Linux as I was able to find gparted and I tried using it as shown in this video, https://www.youtube.com/watch?v=6z1Tu9l8WNc
But I am confused now about how big and what are the formats for the 34 partitions which need to be created?
Click to expand...
Click to collapse
Flashing PrimaryGPT_0.bin will automatically create the partitions. Flashing the individual partitions will give each partition the data needed. There should be no need to manually create partitions, if no partitions show up in gparted, the problem goes back to primarygpt, as that is the partition table.

I am not quite sure what you mean by:
thekiln said:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
Click to expand...
Click to collapse
how to can I get the Partition names?
Edit: I finally was able to get Ubuntu installed on my computer, so please instruct accordingly, sorry I have been googling everything you have mentioned in your OP with no luck!
Thanks in advance.

nmnm4alll said:
I am not quite sure what you mean by:
how to can I get the Partition names?
Edit: I finally was able to get Ubuntu installed on my computer, so please instruct accordingly, sorry I have been googling everything you have mentioned in your OP with no luck!
Thanks in advance.
Click to expand...
Click to collapse
For the names I like to use "parted /dev/sdb" then "print" (sdb being the location of the sd card, might be sdc, sdd, etc..)

thekiln said:
For the names I like to use "parted /dev/sdb" then "print" (sdb being the location of the sd card, might be sdc, sdd, etc..)
Click to expand...
Click to collapse
Thanks for the command line, I came up with this 36 partitions
https://www.dropbox.com/s/bw8nj317y3v7pw6/VirtualBox_Ubunto_05_01_2016_08_59_03.png?dl=0
now how do I know each partition's path?
you have mentioned "I.e. ("Partition name: LAF Located at /dev/sdXx")"
so do I type for example: "modem: LAF located at /dev/sdb1" (sdb1 is my sdcard's path)?
thekiln said:
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
Click to expand...
Click to collapse
Those are the files got extracted from the DZ file
https://www.dropbox.com/s/z3ebiy4vvnsy9oo/Untitled.png?dl=0
and this is a screenshot in Ubuntu after copying the file on a 64 memory stick and mounting it
https://www.dropbox.com/s/gqn35n1npklq8ld/VirtualBox_Ubunto_05_01_2016_09_30_15.png?dl=0
Do I just type: "sudo dd if=/media/mike/MEMORY/aboot_153600.bin of=/dev/sdb1" and so on for all .bin files?
Please try to write command lines as I do not have experience with Linux

I'll be honest and blunt, if you do not have experience with linux, a simple keystroke mistake could wipe your entire computer. I can't in good conscience recommend touching dd if you're not familiar with it. Not trying to be condescending or anything just really dangerous tools we are working with here.

it have problem
wow !!! i can see the LG logo in my tablet !!!
but i can't run next step !!!
pushed power + volume up button but i never changed screen !!
This is written on the screen.
"boot certification verify"

please help me i copy 34 partition on SDcard after that what can i do? please answer , this does not work (( 8.) Press and hold power and volume up...If all went well, there is suddenly life to your paperweight!! Congratulate yourself and prepare for more fun... If nothing happened, revisit the above steps, more than likely something got flashed to the wrong partition.

Issue
Hello, I've successfully followed the tutorial until step 9. When i flash TWRP it reboots and comes back to the fastboot screen.
If I hold the vol+ button when it is booting, the download mode screen flashes for a second and then it comes back to the fastboot.
I haven't been able to to anything else and would be very grateful if someone could help me with this.
Apparently there is no bootloader so it is stuck
I attached a picture of my screen

LG G Pad 7.0 V400
Is there a way to unlock Qualcomm 9008 from LG V400?

Finally my dead tablet went into fastboot mode.
Except windows cannot find a fastboot driver and fastboot command can't locate the device either. Any suggestions?