• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Life Saver!

andrizoid

andrizoid

Android Expert
So as some of you know, last night i totally wrecked my phone. Bricked to the point that NAND restore wouldnt even help.
after searching around for a long time, i finally decided to put together a new boot image and see if that worked (at this point i figured i couldnt mess it up any worse haha).
this is the fruits of my labor. i can honestly say that this is one thing ive put together that i hope non of you will ever have to use, but its good to have just in case

ONLY USE THIS IN EMERGENCIES. IM NOT RESPONSIBLE IF 1. YOU RUN THIS WITHOUT NEEDING IT AND IT BRICKS YOUR PHONE, 2. YOU RUN THIS IN AN EMERGENCY SITUATION AND IT DOES MESS YOUR PHONE UP EVEN MORE.

I only take responsibility for it if it works out just right ;)

this is based off the EE2 boot image.
not sure if that makes a difference.


again i will repeat, do not use this unless your nand restores are not working and you have no other choice.


when_the_shit_hits_the_fan.zip - download now for free. File sharing. Software file sharing. Free file hosting. File upload. FileFactory.com
 
Just curious... was the initial hint that something was going south occur when you were flashing (via fastboot) a system image?

I had something similar happen some time ago - fastboot reported a write error part way through flashing a system image; after that happened, when booting to recovery, nandroid would fault out when trying to perform a recovery of saved ROMs. It struck me as rather odd, almost as if the recovery code was getting tripped up by corrupted file system(s). (If that is the case, it means that Amon_RA's recovery does not create new filesystems in preparation for recovery, and can be tripped up this way by activities that happen outside of the recovery boot).

At first, I was convinced that I had a "partially bricked" phone.

The important thing to remember is that the S-OFF bootloader will allow you to write ANYTHING to the phone - including replacing the bootloader itself.

If you poke through some of the strings contained in the bootloader, there are some clues which suggest that the bootloader is capable of resizing the flash memory partitions. If it decides to do this, then it also must re-create the file systems, which garuantees that they are in pristine shape. I think that the (root) PB00IMG.ZIP process on the phone does just this.

What I know that I did was to re-run the "root PB00IMG.ZIP" process all the way through - this means that I had to re-install the recovery partition (using fastboot) - but at least at that point /system, /data, and /cache had coherent file systems, and then the recovery console worked flawlessly.

(The only thing I can't seem to remember is if I needed to over-write the bootloader using fastboot to one of the older S-OFF bootloaders from the 1.16.605.1 or 1.17.605.1 releases in order to re-root the phone - I honestly can't remember if the S-OFF bootloader will let you re-run the (root) PBOOIMG.ZIP install with the same version of the bootloader inside. Probably it will - I suppose that's what S-OFF gets you!)

eu1
 
Details on your attempted brick? So others, including myself, can learn from your experience.
 
hattrick said:
Details on your attempted brick? So others, including myself, can learn from your experience.
Click to expand...

sorry, i would but i cant.
i can guarantee that none of you will try what i tried.

if i told you, men in black suits would carry me away to a secret office somewhere off the coast of a third-world country and thats the last anyone will see of andrizoid.
at least...thats what i have been made to believe
 
erisuser1 said:
Just curious... was the initial hint that something was going south occur when you were flashing (via fastboot) a system image?

I had something similar happen some time ago - fastboot reported a write error part way through flashing a system image; after that happened, when booting to recovery, nandroid would fault out when trying to perform a recovery of saved ROMs. It struck me as rather odd, almost as if the recovery code was getting tripped up by corrupted file system(s). (If that is the case, it means that Amon_RA's recovery does not create new filesystems in preparation for recovery, and can be tripped up this way by activities that happen outside of the recovery boot).

At first, I was convinced that I had a "partially bricked" phone.

The important thing to remember is that the S-OFF bootloader will allow you to write ANYTHING to the phone - including replacing the bootloader itself.

If you poke through some of the strings contained in the bootloader, there are some clues which suggest that the bootloader is capable of resizing the flash memory partitions. If it decides to do this, then it also must re-create the file systems, which garuantees that they are in pristine shape. I think that the (root) PB00IMG.ZIP process on the phone does just this.

What I know that I did was to re-run the "root PB00IMG.ZIP" process all the way through - this means that I had to re-install the recovery partition (using fastboot) - but at least at that point /system, /data, and /cache had coherent file systems, and then the recovery console worked flawlessly.

(The only thing I can't seem to remember is if I needed to over-write the bootloader using fastboot to one of the older S-OFF bootloaders from the 1.16.605.1 or 1.17.605.1 releases in order to re-root the phone - I honestly can't remember if the S-OFF bootloader will let you re-run the (root) PBOOIMG.ZIP install with the same version of the bootloader inside. Probably it will - I suppose that's what S-OFF gets you!)

eu1
Click to expand...


Very good information.

+1
 
You must log in or register to reply here.
Back
Top Bottom