Root Eris half-brick

[scary alien]

Just a quick question. When I replace the RUU rom.zip file with the eris_rootrom.zip , does it matter what I name it? I'm just been naming it "rom", but I'm wondering if it shuold be named rom.zip?

Yes, "rom.zip"...that's the one that the RUU is expecting...try that and let us know.

edit: you might need / want to change Windows Explorer to not "hide extensions for known file types" (this can be done in Organize drop-down in the top-left of your Explorer window, then select "Folder and search options", then the View tab, then un-check the "Hide extensions for known file types"); that way, you can ensure that your file is really called what you think it should be.

 

[zloetakoe]

Here's what RUU brings up after I tell it I'm ready to procede
Current info about your Android phone:
Image version:
2.36.605.1
Select one below:
Update the current ROM version

====================================
I click UPDATE
====================================
Verify that you want to update the ROM version:

From:
Image version:
2.36.605.1

To:
Image version:
(for some reason it's blank this time????)
===================================
Usually it says 2.19.xxxxxxxxx, is the "update TO" blank because I named the .zip file "rom.zip"?

 

[scary alien]

I can't remember...(I'm trying to look up what I did in the other thread)...just give it a try....

 

[scary alien]

I can't remember...(I'm trying to look up what I did in the other thread)...just give it a try....

Ack...found it (http://androidforums.com/eris-all-things-root/371983-help-save-brick-3.html#post2932669)...

Yeah, this is what I saw when I tried it on my phone:

1. Main splash screen (i.e., "Welcome to the ROM Update Utility...")
2. Second screen ("Follow the instructions below to prepare the phone for the update:")
3. Current information about your Android phone: Image version 2.36.605.1, select "Update" (clicked "Update" button) to update the current ROM version
4. Fourth screen: "Verify that you want to update the ROM version:" (from Image version 2.36.605.1 to 2.19.605.1)...hit the "Next" button
5. Fifth screen: "You are now ready to update your ROM image..."...hit Next button...
6. Rebooting to Bootloader...Sending....
7. Finally comes back with the "ERROR [140]: BOOTLOADER VERSION ERROR"

I'm guessing that you had "show file extentsions" turn off before and when you renamed your file to "rom", it already had the .zip extension.

Be sure to double-check the whole filename like I described a post or two above.

 

[zloetakoe]

That's what it was, I was naming it rom.zip and it was adding .zip already because it was hiding the extensions.

Ok. Here we go again.

.....same result Error 140.

 

[zloetakoe]

Maybe if I just bang it against the wall really hard a couple times?

 

[scary alien]

That's what it was, I was naming it rom.zip and it was adding .zip already because it was hiding the extensions.

Ok. Here we go again.

.....same result Error 140.

Bummer dude...well, I do think you are in the same boat as 13kyl was, although your phone does boot in Android (although I think you reported some missing/broken functionality).

The fact that your recovery (Amon_RA's at that) is "gone" (or not responding properly) implies that something bad happened to your phone.

LOL, I just read your new response on Gmail...I wished that would fix it .

I'm tapped-out at the moment, idea-wise...at least your not any worse-off than you were before we started this little experiment, and you've got to use some new skillz, eh? [small consolation, right? ]

I'll keep thinking about this, but for now I don't quite know what to try next given what we've seen with other phones in similar states as yours.

 

[zloetakoe]

Just in case anyone is reading this in the future and wants some help finding the rom.zip file in the temp files. The easiest way I've found (I'm using vista) is to type in appdata in the start search menu. That will pull up the appdata. From there it's....

Appdata>Local>Temp>{yadda yadda yadda characters}

Then just use the date and time to easily find your ruu rom.zip file which will be in another {yadda yadda yadda characters} folder.

Hasn't got me anywhere so far, but it may help someone else.

 

[zloetakoe]

Bummer dude...well, I do think you are in the same boat as 13kyl was, although your phone does boot in Android (although I think you reported some missing/broken functionality).

The fact that your recovery (Amon_RA's at that) is "gone" (or not responding properly) implies that something bad happened to your phone.

LOL, I just read your new response on Gmail...I wished that would fix it .

I'm tapped-out at the moment, idea-wise...at least your not any worse-off than you were before we started this little experiment, and you've got to use some new skillz, eh? [small consolation, right? ]

I'll keep thinking about this, but for now I don't quite know what to try next given what we've seen with other phones in similar states as yours.

Very worthwhile undertaking.

Any ideas for a new phone? I may have to be text message free until January! Then I'll have a little cash to throw around.

If anyone has any ideas, let me know and I'll give it a shot. It's been great getting to know the phone a little better.

Are there any other RUUs out there that may work?

 

[scary alien]

Just in case anyone is reading this in the future and wants some help finding the rom.zip file in the temp files. The easiest way I've found (I'm using vista) is to type in appdata in the start search menu. That will pull up the appdata. From there it's....

Appdata>Local>Temp

Then just use the date and time to easily find your ruu rom.zip file.

Although that hasn't got me anywhere so far.

LOL, zloetakoe, you've been amazingly patient and helpful to yourself re. this...

This thread will help others down the road, even if its just to reinforce what they have experienced. Kudos to you for that.

I'll ping you back here on this thread or PM you if I hear of any new things to try.

Cheers, mate!

 

[scary alien]

Very worthwhile undertaking.

Any ideas for a new phone? I may have to be text message free until January! Then I'll have a little cash to throw around.

If anyone has any ideas, let me know and I'll give it a shot. It's been great getting to know the phone a little better.

Are there any other RUUs out there that may work?

Well, I've got my eye on the sexy, new Samsung Galaxy Nexus (VZW) that is supposed to be available on the 17th. Its a pure Google Nexus device and should be a beast of a phone and has a big 4.65 inch screen (shouldn't be too much bigger than my current Droid X).

The deal you are seeing with the RUU is some kind of bootloader version mismatch that you mostly likey experiencing (we've seen with other, different methods of trying to accomplish the same thing you were). I would think that an older RUU will also encounter this same type of mismatch.

Its fun trying stuff like this...am just sorry when we aren't able to get a positive resolution.

 

[zloetakoe]

Before I throw in the towel, I'm wondering if it would hurt anything if I reformated my SD card, or at the least got rid of any PB00IMG.zips that may be on there from when I was first trying to root the phone.

Good idea or bad idea?

 

[scary alien]

Before I throw in the towel, I'm wondering if it would hurt anything if I reformated my SD card, or at the least got rid of any PB00IMG.zips that may be on there from when I was first trying to root the phone.

Good idea or bad idea?

Well, the reason we were going through all of the previous work was to try to get you an S-OFF bootloader so we could flash or boot-up Amon_RA's custom recovery so that we could run the erismtdnuke.zip tool to fix your presumed bad memory blocks.

Actually, this just gave me an idea...its too complicated to articulate it here, but I'm going to research something that might allow us to boot into recovery like the Droid X does (we can't replace the recovery partition at all due to the locked bootloader, so the custom recovery hijacks part of the boot process).

I'll think about this and will certainly get back to you if it comes of something.

But yes, you can and probably should safely delete those files so that you don't have to wait for them to try to install if you ever entered HBOOT mode.

You don't have to reformat the SD card though...that shouldn't help or hurt your situation at this point.

Cheers!

 

[scary alien]

By the way, are you currently rooted or is the phone back to stock?

If you're not rooted, then my idea wouldn't work for you ...

 

[zloetakoe]

By the way, are you currently rooted or is the phone back to stock?

If you're not rooted, then my idea wouldn't work for you ...

Rooted with OMGB.

 

[scary alien]

Rooted with OMGB.

Ah, thanks!

I've been researching the idea... The source code is published and open-source, but the hijack itself is a binary , so I'll have to look elsewhere for the key part (I think the 2nd init method that the DX uses might tell me more).

My idea is that you just need to boot into custom recovery and the methods that the Droid X uses might enable us to cobble together a hack to get custom recovery able to boot (indirectly from Android).

I'll let you know if anything comes to fruition .

Cheers!

 

[zloetakoe]

Ah, thanks!

I've been researching the idea... The source code is published and open-source, but the hijack itself is a binary , so I'll have to look elsewhere for the key part (I think the 2nd init method that the DX uses might tell me more).

My idea is that you just need to boot into custom recovery and the methods that the Droid X uses might enable us to cobble together a hack to get custom recovery able to boot (indirectly from Android).

I'll let you know if anything comes to fruition .

Cheers!

Hey, sounds good. Just don't text me any ideas. (cause I won't get em)

Thanks for everyone's time. It's been a pleasure. I'm open to try anything at this point if someone has any inspiration.

Best,
Zloe

 

[erisuser1]

Pardon me for butting in - and also for not going over this thread with a fine toothed comb - but if there is a rooted ROM on the phone, has flashing the recovery from a shell with flash_image been attempted? It can be done from adb, or from a terminal emulator, or from gscript...

Apologies in advance if this has been tried already.

eu1

PS

Note that the things that ErisMTDNuke does are performed on a partition by partition basis, using binaries which will certainly also run correctly under the normal OS (again, from adb, or a root shelll in a terminal emulator, etc). If the recovery partition was in fact borked that particular way (you would know cuz flash_image would fail), you could certainly attempt to repair *just the recovery partition* using that method.

Food for thought, anyway.

 

[scary alien]

Pardon me for butting in - and also for not going over this thread with a fine toothed comb - but if there is a rooted ROM on the phone, has flashing the recovery from a shell with flash_image been attempted? It can be done from adb, or from a terminal emulator, or from gscript...

Apologies in advance if this has been tried already.

eu1

PS

Note that the things that ErisMTDNuke does are performed on a partition by partition basis, using binaries which will certainly also run correctly under the normal OS (again, from adb, or a root shelll in a terminal emulator, etc). If the recovery partition was in fact borked that particular way (you would know cuz flash_image would fail), you could certainly attempt to repair *just the recovery partition* using that method.

Food for thought, anyway.

eu1,

I don't think Zloe did this directly via adb, but he (pardon if I've gotten the gender incorrect) did try the 1-click rooting apps (original and trackball-optional versions) again, to no avail.

I hadn't recently looked in detail at the contents of the ErisMTDNuke.zip file to try to grok that about its ability to be run from a root shell--that is indeed great information.

I'm guessing that we would first attempt to just flash_erase mtd1 (recovery) and then re-flash Amon_RA?

Then, we could just re-boot into Amon_RA and flash the whole of the ErisMTDNuke script? (or hold-off on this until it became apparent that repairing the other partitions was necessary? -- I'm just thinking that if the recovery partition got borked, it might be likely that others have, too (i.e., leading to some of the wonky behavior he first reported that led him to try to re-enter recovery to try to correct things).

Thank you again for your insight re. this...sometimes its hard to see the forest for the trees, eh?

 

[erisuser1]

I'm guessing that we would first attempt to just flash_erase mtd1 (recovery) and then re-flash Amon_RA?

Then, we could just re-boot into Amon_RA and flash the whole of the ErisMTDNuke script? (or hold-off on this until it became apparent that repairing the other partitions was necessary? -- I'm just thinking that if the recovery partition got borked, it might be likely that others have, too (i.e., leading to some of the wonky behavior he first reported that led him to try to re-enter recovery to try to correct things).

I think you are a little bit early in your diagnoses.

[ I will also point out (in my usual cryptic fashion) that flash_image (with a rooted OS running, as suggested above for the recovery partition) can also be used to install Jcase's "Flash any RUU" misc partition image. In principle, this will allow a PB00IMG.zip (bootloader) install of the old "Root PB00IMG.zip" ROM - which will install the S-OFF bootloader. Combined with the "battery pull trick", I suppose it is possible that this could be done without overwriting the current ROM. ]

The failure of the OneClick app means nothing really - the ROM that was on the phone when it was attempted probably didn't even have the symlink that allows the rooting exploit to occur. The OneClick app works for STOCK phones, right?

So, zloe (or somebody else) should manually attempt to perform an overwrite of the recovery using flash_image to see if they get a failure. Then, and only then would I proceed with the flash_erase procedure.

A little off-topic, but I think it is important to repeat this point: the Rooted ROM on the phone is currently the ONLY lifeline left to recovering the phone's full function (as neither the recovery boot nor a S-OFF bootloader is presently available). So, whatever steps are taken, that consideration should be kept in mind. Flashing any STOCK RUU (without the Root-PB00IMG.zip hack) should be avoided.

eu1

 

[scary alien]

I think you are a little bit early in your diagnoses.

[ I will also point out (in my usual cryptic fashion) that flash_image (with a rooted OS running, as suggested above for the recovery partition) can also be used to install Jcase's "Flash any RUU" misc partition image. In principle, this will allow a PB00IMG.zip (bootloader) install of the old "Root PB00IMG.zip" ROM - which will install the S-OFF bootloader. Combined with the "battery pull trick, I suppose it is possible that this could be done without overwriting the current ROM. ]

Yeah, I'm guessing you might have had the OP do the MTD_Inspect thing to verify the bad block counts (manually, at this point)? Not saying that this is necessary at this point...

I also do see that the ErisMTDNuke package also does flash jcase's misc partition fix, which is cool . Nice to have that syntax handily available.

The failure of the OneClick app means nothing really - the ROM that was on the phone when it was attempted probably didn't even have the symlink that allows the rooting exploit to occur. the OneClick app works for STOCK phones, right?

As always, yes sir!

So, zoe (or somebody else) should manually attempt to perform an overwrite of the recovery using flash_image to see if they get a failure. Then, and only then would I proceed with the flash_erase procedure.

And/or try to flash the misc image fix, too (so we might attempt the base root ROM installed to get S-OFF)?

A little off-topic, but I think it is important to repeat this point: the Rooted ROM on the phone is currently the ONLY lifeline left to recovering the phone's full function (as neither the recovery boot nor a S-OFF bootloader is presently available). So, whatever steps are taken, that consideration should be kept in mind. Flashing any STOCK RUU (without the Root-PB00IMG.zip hack) should be avoided.

eu1

Thank you again, eu1.

So, when Zloe is back on and available, we'll have him try to manually do a flash_image of (the trackball-optional) recovery (I know he flashed that a while back, so I'm guessing he did have trackball issues).

Optionally, we could also try flashing jcase's misc partition fix in hopes of getting the base root ROM installed (if needed).

Failing the above, we can try the flash_erase on the mtd1 recovery partition and then re-try flashing the recovery again (rinse and repeat, so-to-speak).

Failing that, we'd try installing the base root ROM (directly this time) to see if the misc partition fixed worked and hopefully get us S-OFF, which opens the doors for fastboot.

 

[erisuser1]

Yeah, I'm guessing you might have had the OP do the MTD_Inspect thing to verify the bad block counts (manually, at this point)?

As that operation is non-destructive, it is certainly the least risky of all possibilities, and can feasibly pin-point where the trouble lies (i.e., which partition). Note that there is a small risk that writing to the misc partition (if it really does have bad blocks in it) could actually brick the phone, so it would be nice to know (with a non-destructive procedure) where the problem lies before writing stuff to misc willy-nilly.

Also I suppose we should ask zloe if his phone is "flashed" to a different carrier than Verizon, as flashing the misc partition will reset the carrier back to Verizon.

And/or try to flash the misc image fix, too (so we might attempt the base root ROM installed to get S-OFF)?

Yes. But I would try overflashing just the recovery, and seeing if it is bootable first before mucking with "misc". See comment above about risks.

So, when Zloe is back on and available, we'll have him try to manually do a flash_image of (the trackball-optional) recovery (I know he flashed that a while back, so I'm guessing he did have trackball issues).

Optionally, we could also try flashing jcase's misc partition fix in hopes of getting the base root ROM installed (if needed).

Failing the above, we can try the flash_erase on the mtd1 recovery partition and then re-try flashing the recovery again (rinse and repeat, so-to-speak).

Failing that, we'd try installing the base root ROM (directly this time) to see if the misc partition fixed worked and hopefully get us S-OFF, which opens the doors for fastboot.

That priority ordering seems reasonable. Make sure to pay attention to the command-line switches to flash_erase if it is needed.

If the phone were in my hands, I would be inclined to get the S-OFF bootloader on the phone, even if a simple re-flash of the recovery seems to do get the recovery working. If something in the misc or recovery partition went wrong - it will probably happen again.

eu1

 

[zloetakoe]

WHOA!!! All of that stuff sounds fun, but you'll have to be patient with me a little. I don't understand most of what was said in the past 5-6 posts. But definitely willing to give it a shot. I THINK the phone is still a verizon phone. BUT I'm using page plus as my provider (which works on the verizon network). Any additional info that I need to provide?

 

[scary alien]

WHOA!!! All of that stuff sounds fun, but you'll have to be patient with me a little. I don't understand most of what was said in the past 5-6 posts. But definitely willing to give it a shot. I THINK the phone is still a verizon phone. BUT I'm using page plus as my provider (which works on the verizon network). Any additional info that I need to provide?

LOL, hey Zloe, good to see you again .

Yeah, erisuser1 swooped-in to pull the covers back on what we really needed to do .

So, I think you said you got the Android SDK install re. getting setup for adb (I posted a link to this guide that I wrote (and just updated yesterday with some pictures, to boot): http://androidforums.com/faqs/443072-adb-guide.html) to get adb installed.

I'll write-up some notes and instructions for you about doing the starter steps for what erisuser1 prescribed, so, let's proceed carefully, okay?

Why don't you let me know about if/when you get adb setup okay and when you'll have time to work on this? (its 9:02 PM right now for me so we can coordinate times, whether its tonight, tomorrow, etc.).

When you get adb setup, you can simply test that you've got good access to your phone by this:

- connect the phone to your computer via the USB cable
- on your PC, start-up a Window Command Prompt (old DOS window)

c:\> cd c:\android-sdk-windows
c:\android-sdk-windows> cd platform-tools
c:\android-sdk-windows\platform-tools> adb devices
HTxxxxxxxxx device
c:\android-sdk-windows\platform-tools> adb shell
# pwd
/
# exit
c:\android-sdk-windows\platform-tools>

If you get something similar to the above, then adb is working .

Let me know and I'll get started writing-up the notes for you.

Cheers!

 

[zloetakoe]

It works!

Except I had a
*Daemon not running. starting it now on port H5037 *
*daemon started successfully *

List of devices attached
HT************* device

c:\android>adb shell
#pwd
pwd
/
#exit
exit

c:\android>

===================================
Only difference, as you can probably tell is that I didn't name my folder android-sdk-windows. Maybe I should clean that up to avoid some confusion? I also think that the adb shell is in the same folder so I didn't have to use the platform-tools command.

Anyway, I'm probably going to bed tonight. I've got to get up really early tomorrow. (Should probably be in bed already). Thanks a ton for the help. Tomorrow I've got most of my evening that I could try some stuff with the phone if you have time scary. Let me know what time works for you. Anything after about 7:30pm would be perfect.

Thanks again, see you tomorrow!