I feel I owe it to others who may have done likewise to set out a record of what I did, and how I fixed it. The notes that follow are VERY technical and arcane to the world of hacking one’s smartphone, and for most of my blog’s readership I’d suggest passing this one by, unless you are hip to this kind of stuff. If you want to read on from curiosity, well, good for you!

What this is NOT: This isn’t notes on how to successfully get Jelly Bean on your Dinc. It’s all about recovering from a phone that is trapped in a boot loop after attempting to get Jelly Bean, and is further incapable of loading and booting a nandroid recovery rom.

My phone is a Verizon ADR6300, ie, an original HTC Incredible, and pretty old as smartphones go. As soon as I obtained it, I rooted the device, and have from time to time done my own Android upgrades by cook-booking the process from information in the various forums.

It was running Cyanogenmod 7 and somebody’s stock rom of Gingerbread since last summer, and as I’d had good success a few days earlier updating my Toshiba Thrive tablet to Jelly Bean, I was looking to see if this was now possible for the “Dink”.

Notes on the phone, how it was rooted, etc, because I’m fairly certain that being non-specific about those details is what may have led to my problems:

ADR6300

Android v.2.3.7

Baseband 2.15.00.07.28

Kernel 2.6.37.6-cyanogenmod+jistone @folkvanger #6

CPU ARMv7 Processor rev2 (v7l)

Mod version: CyanogenMod-7.2.0-inc

Build: GWK74

The phone had been rooted using the techniques shown at unrevoked.com , but quite some time ago: more than two years, I think, and without any recent updates. THIS IS LIKELY WHY I RAN INTO TROUBLE.

Here’s the specifics on how my Dinc was set up as unrooted at the time of my near-bricking, using unrevoked-forever, with PB31IMG.zip, and S-OFF. The bootloader showed this:

HBOOT-0.79.0000

MICROP-0417

TOUCH PANEL-ATMEL224_16ab

RADIO-2.15-00.07.28

ClockworkMod Recovery v2.5.0.5

Setting out:

I read up on how to update the Dinc to Jelly Bean, made a nandroid backup of my current working installation, backed up my contacts, used TitaniumBackup for my apps, and downloaded a Jelly Bean rom, and the associated Gapps.

I booted the phone into ClockworkMod 2.5.0.5 (volume down + on to HBOOT, then select RECOVERY with vol up/down, then press ON). Once in the Clockwork menus, I used vol up/down to select wipe data/factory reset, committed to it, and executed it. Next, selected wipe cache partition, committed to it, and executed it. Next, went to the advanced menu, selected Wipe Dalvik Cache, committed to it, and executed it. Those three tasks done, navigated to the main ClockworkMod menu again (one press of on/off button), scrolled down to ‘Install Zip from sdcard’, and selected the CM-10 rom for installation. I used this one from http://goo.im/devs/tiny4579/inc/cm10 , cm-10-20130118-TINY-inc.zip . After that installation ran, I again chose ‘install zip from sdcard’, selected gapps-jb-20121011-signed.zip , and installed that.

Unfortunately, I didn’t closely note the messages generated by those two installs. Anyway, as I went to reboot the phone, it got as far as the white HTC Incredible screen, and got no further. It was hung up at that screen for longer than 30 minutes, and could not progress. In the next couple of hours, I tried a different Jelly Bean rom, with no better results. (the rom was this one: jellybean-inc-RC3.zip) .

At that point, I abandoned trying to make JB work.

Fortunately, I was still able to get into HBOOT and CWM, so I selected ‘backup and restore’ in CWM’s main menu, selected ‘restore’, pointed it at my nandroid backup of Gingerbread that I’d made that morning, and launched it. Alas, it reported a number of errors, and was unable to build a working android system in the phone. It got past the white HTC Incredible start up panel, but went dark beyond that, and wouldn’t boot. The best clue was an error resembling this one:

E: Can't mount /dev/block/mmcblk0p2 (File exists)

The next eight hours or so were spent in searching for a fix online. The most helpful post I found was this one: http://forum.cyanogenmod.org/topic/6433-solved-messed-up-partitions-on-internal-storage/

The thread concerned a guy who was getting pretty much the same errors I was experiencing on attempting the nandroid recovery. There were two partitions in the phone’s memory that were failing to mount. His errors (below) were almost identical to mine:

E: Can't mount /dev/block/mmcblk0p2 (File exists)
E: Can't mount CACHE:recovery/log
E: Can't mount /dev/block/mmcblk0p2 (File exists)

Alas, I didn’t precisely record my error messages at the time, but they were VERY close to his, and centered on being unable to mount the /data and /cache partitions of the phone’s memory. The thread with these clues was very long, but the key help came from this section (#7) Here’s what he wrote:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here’s the solution.

The problem was that I managed to screw up the partitions on my internal storage card, so basically nothing would work properly.  I could still get into recovery, though.  That’s key.

Here’s what you’ll need:

• Working recovery, basic knowledge of adb & the shell
• Parted (download here)
• stock PB31IMG.zip

Note also that I had run unrevoked forever (so my phone was S-OFF) … I’m not sure if that’s required or not.

So, grab parted from the link above.  Now you need to extract the individual binaries from the .zip (the 6 files in the sdparted folder within the zip), ideally to your android-sdk\tools directory.  Now push all 6 files (adb push [file] /sbin/).  Next, we need to make them useable, so go into the shell (adb shell).  Change to your /sbin/ directory, and run: chmod 0755 <file> on each of the 6 files.

Now, we need to fix the partitions.  This is assuming that the partitions are there, just the wrong format (which is what happened to me .. I accidentally made them FAT32 instead of ext).  So, run the following: parted /dev/block/mmcblk0 mkfs ext2.  It will ask if you want to continue, hit yes.  When it asks for the partition number, enter 1.  Next, when it asks for the format, enter ext2.  Let it do its thing.  Now, once it’s done, run parted again.  This time, enter partition 2 (everything else is the same).

Once all that’s done, your recovery program should be able to mount both the /data and /cache partitions.  If that’s true, you’re pretty much done!  One thing I found was that I couldn’t directly install a new OS (I tried both Cyanogen and Ultimate).  In both cases, it would look for stuff in the davik-cache that it couldn’t find, so something wasn’t installing correctly I think.  So, if that happens, flash back to the stock PB31IMG.zip (put it in the root of your /sdcard/ and let hboot install it), and then root your phone anew.  That’s what I ended up doing.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now, there WERE differences between his situation and mine. Most of his problem seemed focused on the partitions having been somehow reset to the wrong filetypes. On my phone, the filetypes appeared to be ok, but I suspect that they had been resized somehow by the Jelly Bean installer rom. Nevertheless, the basic steps this guy had taken to recover his phone ARE WHAT WORKED for me.

If you’ve read this far, I’m guessing you have an almost dead Dinc, and are hoping for a precise guide of what to do next. Be warned! I’m only reconstructing the late hours of a very bad day from memory, so please take the following notes as an outline to guide you, but IT’S NOT A RECIPE you can completely trust. You’re going to need to read, and think, and proceed cautiously if this is going to work, maybe. If you don’t have command-line experience in linux, and a basic understanding of navigating through file structures and permissions, and using command line partitioning tools, well, go find someone who does, and ride shotgun as they try this out for you.

Here’s what I went and did:

1. I installed android sdk tools to my Windows desktop system. Google was helpful in locating a download for them: http://developer.android.com/tools/sdk/tools-notes.html
2. The main thing about step 1. is getting ADB working as a command you can access from the Windows Command box. I’d used ADB before, and there was a re-learning curve to get the hang of it again, but this guide was helpful getting started: http://droidlessons.com/how-to-install-adb-on-a-windows-7-pc/ The business about changing the path variable isn’t really necessary, because you can execute adb if you simply navigate to where you installed it. It’s less elegant, but I was in a hurry to fix my damned phone.
3. Follow the guy’s link (http://www.sendspace.com/file/w6hi6x), and download the sdparted-recovery.zip file. It’s a command set of partitioning tools. Unzip and put those executable files into the same place where adb.exe is, so it’s easy to move and use them where needed when you get to that part.Ok, those first three steps all took place on your desktop system. It’s time to connect your phone to the desktop and test adb’s ability to work within the phone.:
4. Connect the phone’s usb cable to the desktop system, and boot the phone with “vol down + on” to get to the HBOOT screen. Watch the messages there. After a few seconds you should see HBOOT USB PLUG. Then launch Recovery from the HBOOT menu. The phone is now tethered to the desktop.
5. Test adb, by running cmd to open a command line box on the desktop. (Win+R keys together, then type cmd in the Run Window). Then navigate using the cd command to the path where you installed sdk tools, and the parted tools. (For me the path I used was c:\program files\android\android-sdk\platform-tools). The dir command will show you if adb.exe is in there. If so, try typing:

 adb devices 

 If the desktop is connected to your phone, it will give you;

List of devices attached

HT00XX1234 …… recovery

…or something like that.

If you’ve unzipped the six sdparted files into the same directory as adb.exe, then you are ready to move those files into your phone using the command:

adb push <filename> /sbin/

Do this for each of the six files (e2fsck, mke2fs, parted, resize2fs, sdparted, tune2fs).

Next, make them useable by changing their permissions: Use:

adb shell

to start navigating the file structure within the phone. You will see:

~#_

Navigate using linux commands now, and enter the sbin directory by typing:

cd sbin

Use:

chmod 0755 <filename>

on each of the sdparted commands you pushed into that directory. Now the parted command will work when you go to run it on the phone within the adb shell environment.

This is a very good place to slow down and BE VERY CAREFUL! You are about to run commands that will alter the partioning of the phone’s internal memory. You might very well make things worse unintentionally if you get sloppy here. I cannot promise that what you are about to do won’t TOTALLY BRICK your phone. I got mine back again, but your milage may vary, and lead you down that highway to hell.

I knew at this point that the information I’d found and was working from didn’t precisely match what I had been seeing in my phone’s error messages, or in information I looked at within my phone. Mostly, the partition file names were a bit different, and as I’d said before, that guy was talking about have wrong filetypes specified in his structure, and that didn’t seem to be my exact problem.

At this point you need to be sure of the correct device block names of your /data and /cache partitions, and maybe your /sd-ext partition, too. You can find out by doing this:

cd /etc

cat fstab

This will print out the partition structure in your phone. The lines that matter are those referencing the suspected bad partitions. The suspect partitions are the ones you’ve been seeing in your error messages on failed nandroid recovery attempts. For me those were, I think:

/dev/block/mmcblk0p1 /data auto rw

/dev/block/mmcblk0p2 /cache auto rw

It’s possible that the /sd-ext partition needed the parted command, too, but my notes and memory are incomplete here and I’m not exactly sure what I changed. Too, I’m guessing that the structure of the memory in the phone was changed again when I succeeded in running nandroid recovery after these steps, so for your situation let the error messages you’ve been getting be your guide. Less is generally more, when it comes to tinkering with re-partitioning. BE THOUGHTFUL AND BE CAREFUL.

The main thing is, I wouldn’t re-partition anything that wasn’t reporting a mounting error or formatting error of some sort as you were trying to get nandroid to do its thing.

Take a deep breath, and run:

parted /dev/block/mmxblkx mkfs ext2

using the block identifier that you think needs fixing. Leave off the “p” part of it. It will ask if you want to continue, hit yes. Then it will ask for the partition number: For me, I entered: 1. Next it might ask for the format, and enter: ext2 . Just as the author of the thread did, I needed to repeat this sequence for the second partition on the same block, like so:

parted /dev/block/mmxblkx mkfs ext2

Do you want to continue? -Yes

It asked me what partion number, and I entered: 2 , and it asked for the format, and I again entered: ext2 .

Now, you type:

exit

and that takes you out of the adb shell.

8. At this point, you are ready to re-attempt the nandroid recovery of your previous working android version. Make sure the backup files are on the sd card in the phone. I disconnected my phone from the desktop system, and rebooted into HBOOT, and then clockworkmod recovery in the usual way. Then followed the menu to “backup/restore” , “restore”, and chose the image of the system I’d saved that morning: -2013-01-27.55/ I pressed the button, confirmed my choice, and set it in motion.

And it worked!

I sincerely hope these notes will help someone out of a frustrating situation. At this point, I have notions of what I might try if I re-attempt to install Jelly Bean, but I’m a little gun-shy, and in no hurry to waste an entire day again with a broken phone. From what I’ve read, I do think the old ADR6300 can be made to run Jelly Bean, but it would be very wise to update ClockworkMod Recovery to something more recent first. That’s my best guess.

If anyone reading this has any insight as to why my partitons got screwed up from what I did with Jelly Bean, I’d be really glad to know. Please leave comments.