[HACKS] Root Droid 1 - regardless of OS version

[furbearingmammal]

and when u transfer the update.zip file to your droid root DO NOT put.zip at the end because by nature the association is already built into the file.

This is not categorically true. By default Windows operates in what I call "dummy mode" and hides your file extensions from you. This is a horrible idea for more reasons than I care to type. To disable this bit of Windows idiocy, see this post. At least that's how you do it in XP. If Windows Vista/7, etc. is different I'm sure you can Google how to unhide file extensions.

I think I may make that Step #1 of every procedure that involves an update.zip file -- "be sure your Windows is not configured to hide file extensions".

And make the final step "Revert to your previous Windows settings to prevent damage to your computer if you are uncomfortable with the new way."

 

[MotoCache1]

And make the final step "Revert to your previous Windows settings to prevent damage to your computer if you are uncomfortable with the new way."

If anything I think you're more likely to prevent damage to your computer if you can see the file extensions. Otherwise you're just trusting the stupid icon to know what kind of file it is. It doesn't take a rocket scientist to make a trojan horse / virus / worm that's a .EXE but has a notepad icon so it looks like a text file when you're in dummy mode. I just don't know what Microsoft was thinking. I mean, it was already fairly idiot proof -- if you tried to change the extension of a file with a "known type" it would warn you that it might break the usability of the file. Did they really need to go further than that? If so, shouldn't the people who needed that change really rethink the idea of using complex technology?

 

[furbearingmammal]

I agree with you in theory, but having put computers back together after Redbull-fueled teenagers with more time then sense have deleted "all that junk I don't need"...

Of course, if people want it that way and can't figure out how to reverse it I imagine they're beyond help. Suggestion withdrawn.

 

[DarkFlow83]

well did everything with ADB also. Still says it can not mount SDcard. Very odd. it says something like E/:dev/something can not mount SD card.

 

[MotoCache1]

well did everything with ADB also. Still says it can not mount SDcard. Very odd. it says something like E/:dev/something can not mount SD card.

Can I get an exact error message?

 

[c64whiz]

Failed Flashing Process ; 0x703E

Tried the process at the start of the post and I get:

Failed Flashing Process; Did not re-enumerate after RAM-loader was sent...0x703E

Ideas?

I'm using RSDLite 4.6, with 4.6.5 USB drivers on XPsp3 (though my USB ports are only 1.1 )

--C64whiz

 

[MotoCache1]

Tried the process at the start of the post and I get:

Failed Flashing Process; Did not re-enumerate after RAM-loader was sent...0x703E

Ideas?

I'm using RSDLite 4.6, with 4.6.5 USB drivers on XPsp3 (though my USB ports are only 1.1 )

--C64whiz

I believe the 0x703E is almost always something wonky with your USB ports or your drivers.

The drivers you installed are actually the same version I'm running and the docs say XP SP3 is supported for those drivers, so no issue there.

Unfortunately that probably means it doesn't like your USB...

 

[jntdroid]

Tried the process at the start of the post and I get:

Failed Flashing Process; Did not re-enumerate after RAM-loader was sent...0x703E

Ideas?

I'm using RSDLite 4.6, with 4.6.5 USB drivers on XPsp3 (though my USB ports are only 1.1 )

--C64whiz

I believe the 0x703E is almost always something wonky with your USB ports or your drivers.

The drivers you installed are actually the same version I'm running and the docs say XP SP3 is supported for those drivers, so no issue there.

Unfortunately that probably means it doesn't like your USB...

yeah, gotta have usb 2+ - ran into that error once and simply switched usb ports and it worked fine - saw this with another guy as well

 

[log]

Backing up my recovery first?

I'm sorry if this is answered in another thread, but couldn't find the answer to this one can someone please clear this up for me or confirm I'm correct?

When you use this method, it is a one-time use only. That is, once you use this method, you will no longer be able to install OTA updates since you need the stock recovery installed. Once you install sprecovery as detailed here, furture OTA will be blocked.

If this is the case, is it possible to backup our current stock recovery first, to be able to restore after rooting? For example, for my scenario, I'm running a rooted FRG01B with a stock recovery, what I would like to be able to do --

1) Install OTA update to FRG22D (as part of process, lose root access)
2) Backup stock recovery for FRG22D (it installs a new recovery image as part of the OTA)
3) Use MotoCache1 method to obtain root (by flashing a custom recovery)
4) Restore stock recovery for FRG22D
5) Be able to install future OTA updates

 

[MotoCache1]

I'm sorry if this is answered in another thread, but couldn't find the answer to this one can someone please clear this up for me or confirm I'm correct?

When you use this method, it is a one-time use only. That is, once you use this method, you will no longer be able to install OTA updates since you need the stock recovery installed. Once you install sprecovery as detailed here, furture OTA will be blocked.

True and not true. OTA will be blocked from installing automatically. If however you grab the OTA file out of your /cache directory, rename it update.zip, and put it in /sdcard, then you can "allow" update.zip and apply update.zip just like any other update.zip. If you're already in SPRecovery and SPRecovery has blocked the install, you must grab the file from /cache and put it somewhere else (using ADB) before rebooting out of SPRecovery as it will delete the file when you reboot.

If this is the case, is it possible to backup our current stock recovery first, to be able to restore after rooting?

Yes, but not necessary.

For example, for my scenario, I'm running a rooted FRG01B with a stock recovery, what I would like to be able to do --

1) Install OTA update to FRG22D (as part of process, lose root access)
2) Backup stock recovery for FRG22D (it installs a new recovery image as part of the OTA)
3) Use MotoCache1 method to obtain root (by flashing a custom recovery)
4) Restore stock recovery for FRG22D
5) Be able to install future OTA updates

If you want to be rooted but keep the stock recovery, the solution is simple:

1. Install your FRG22D OTA update.
2. Flash my "recovery only" SBF.
3. Install my update.zip.
4. Reboot the phone.
5. With your new root powers, rename /system/recovery-from-boot.p.not back to "recovery-from-boot.p".
6. Reboot the phone.

Step #5 re-enables the Flash Recovery Service and when you do step #6 your recovery partition will get put back to stock.

 

[furbearingmammal]

Not true in an absolute sense, just not the FRG22D update -- and any other official ones will break your root as well as replace your custom recovery image. So, while you technically can use them, there's very little incentive to do so unless you have to run stock.

You can't "back up" stock recovery. The fastest and easiest way to get it back -- at present -- is to install the 79MB FRG01B update patch. Then you install whatever update you crave and re-root using this method. Or you could just install a rooted version of the OTA update, which generally hits within 24 hours of an update rolling out.

 

[MotoCache1]

You can't "back up" stock recovery. The fastest and easiest way to get it back -- at present -- is to install the 79MB FRG01B update patch. Then you install whatever update you crave and re-root using this method. Or you could just install a rooted version of the OTA update, which generally hits within 24 hours of an update rolling out.

Actually, you can backup the stock recovery. And even without a backup, getting it back is easy if your phone had FRS and you are still running the original boot image (haven't replaced your kernel), as detailed in my prior post.

If there is any useful purpose for knowing how to back up and restore the recovery partition I could do a separate topic on it, but honestly, I can't see a purpose. Heck, I could make an SBF of just the stock recovery for that matter.

 

[log]

Thanks guys for the response, especially for the very clear method for achieving what I was looking for

Now that I think it through from your explanation it probably makes the most sense to leave sprecovery flashed, and if a new "official" google update.zip becomes available, I can simply remove the recovery check/flash commands from updater-script since the zip file no longer needs to be signed to execute in sprecovery! Is this correct?

With this I can can still get the benefits of a custom recovery (such as full nandroid backup) but stay on the "stock" version of Android.

 

[MotoCache1]

Now that I think it through from your explanation it probably makes the most sense to leave sprecovery flashed, and if a new "official" google update.zip becomes available, I can simply remove the recovery check/flash commands from updater-script since the zip file no longer needs to be signed to execute in sprecovery! Is this correct?

Yep.

With this I can can still get the benefits of a custom recovery (such as full nandroid backup) but stay on the "stock" version of Android.

That's what I do.

 

[log]

Thanks again will probably give it a shot tomorrow and report in