Clockwork Recovery?

---

Hi,

I was curious if there is any way to replace the recovery with CWR (or something similar)? I would like to tinker, but i always feel better about having a backup in case something goes wrong.

Thanks,
Rich

while it is quite impressive that we have things such as angry birds and launcherpro, we dont seem to even have a system dump. i would think that a system dump would be required in order to better understand the rest of the system, including the nook launcher itself. then we could go after a recovery and custom roms. but i think it wont be long. like a week or two, it didnt take long to root it from initial release.

I would assume someone has noticed this, since it seems obvious, but I'll point it out just in case.

Partition 3 is an ext2 partition, which I mounted temporarily. On there are a few recovery files, including factory.zip, which appears to be a full firmware backup. What's puzzling is that factory.zip does NOT seem to be applied when I do a factory reset via Home+Vol Up, as my installed apps on /system are still there (and factory.zip has a script to format and rewrite the system partition).

So....anyone have ideas for how to trigger an update from this zip? It's not as nice as clockwork recovery, but at least we would be able to mess around and restore to factory easily.

Originally Posted by clockworx

I would assume someone has noticed this, since it seems obvious, but I'll point it out just in case.

Partition 3 is an ext2 partition, which I mounted temporarily. On there are a few recovery files, including factory.zip, which appears to be a full firmware backup. What's puzzling is that factory.zip does NOT seem to be applied when I do a factory reset via Home+Vol Up, as my installed apps on /system are still there (and factory.zip has a script to format and rewrite the system partition).

So....anyone have ideas for how to trigger an update from this zip? It's not as nice as clockwork recovery, but at least we would be able to mess around and restore to factory easily.

try to strings the u-boot.bin that's in that partition (or in p1). The u-boot environment variables are in there. When one of the recovery modes are triggered, a file called BCB is written with a string presumably instructing recovery on what to do. It's a little hard to follow since the envs have to write the string into memory and call fatsave to save the string into the file.

Here's what I can see is happening:

-up+home recovery writes "boot-recovery recovery --wipe-data-ui"

-some condition (dead battery + charger just plugged in?) writes "boot-recovery --update-package=BOOT:charging.zip"

-too many reboots (looks like >7) without devconf/BootCnt being written with 0 (don't know where this happens) writes "boot-recovery recovery --update_package=MISC:factory.zip"

If you were daring you could probably mount partition 2 and echo 8>devconf/BootCnt and I'd imagine it would force a complete factory.zip install.

edit: BootCnt seems to be binary valued, though ASCII '8' should still trigger it.

-if devconf/DeviceID doesn't exist (this is a copy of the serial number file) then it writes "boot-recovery recovery --update-package=BOOT:romrestore.zip". No ideas about this one.

-finally, if a plain FAT microSD is found with the file "encore_update.zip" then it writes "boot-recovery recovery --update_package=SDCARD:encore_update.zip". Guess how we'll get non-OTA upgrades?

Haha, I was just searching for the string .zip in the recovery binary. I found that, and googled "encore_binary.zip", and here I am again, full circle.

I'm guessing encore_binary.zip only gets flashed from VolUp+Home recovery, right?

I copied factory.zip to my SD and renamed it encore_binary.zip, just to try...Couldn't get it to activate, unfortunately.

Originally Posted by clockworx

Haha, I was just searching for the string .zip in the recovery binary. I found that, and googled "encore_binary.zip", and here I am again, full circle.

I'm guessing encore_binary.zip only gets flashed from VolUp+Home recovery, right?

I copied factory.zip to my SD and renamed it encore_binary.zip, just to try...Couldn't get it to activate, unfortunately.

I've got one better for you:

I tried what I recommended about /rom/devconf/BootCnt and got the "Installing..." screen. Then a boot loop running through the installer over and over.

Then I broke in by putting a Nooter card in the slot. It seems that u-boot uses itest.l to test the boot count, where .l is for long and we wrote just one byte leaving whatever was in the remaining 3 bytes of ram to stick around. Why it bootloops I don't know. So in Nooter I mounted /dev/mmcblk1p2 /mnt then "echo -n -e "\000\000\000\000" > /mnt/devconf/BootCnt", removed the card, and rebooted. No more boot loop!

Then for the lulz: On my PC I did "echo -n -e "\008\000\000\000 > /tmp/foo" and "adb push /tmp/foo /rom/devconf/BootCnt; adb reboot". This (writing a (long)8 ) forced the reboot into recovery and then booted normally when done. After doing this, I noticed that adb is enabled (/data left alone), my user partition untouched, but my root is gone (ramdisk overwritten) and /system was wiped.

So if you wanted to remove all traces of your rooting, use the above to force recovery, then use up+home to force factory reset. The next question (which I'm too much of a wuss to explore) is if the recovery or factory reset will rebuild trashed /system or /data filesystems.

Originally Posted by pokey9000

I've got one better for you:

I tried what I recommended about /rom/devconf/BootCnt and got the "Installing..." screen. Then a boot loop running through the installer over and over.

Then I broke in by putting a Nooter card in the slot. It seems that u-boot uses itest.l to test the boot count, where .l is for long and we wrote just one byte leaving whatever was in the remaining 3 bytes of ram to stick around. Why it bootloops I don't know. So in Nooter I mounted /dev/mmcblk1p2 /mnt then "echo -n -e "\000\000\000\000" > /mnt/devconf/BootCnt", removed the card, and rebooted. No more boot loop!

Then for the lulz: On my PC I did "echo -n -e "\008\000\000\000 > /tmp/foo" and "adb push /tmp/foo /rom/devconf/BootCnt; adb reboot". This (writing a (long)8 ) forced the reboot into recovery and then booted normally when done. After doing this, I noticed that adb is enabled (/data left alone), my user partition untouched, but my root is gone (ramdisk overwritten) and /system was wiped.

So if you wanted to remove all traces of your rooting, use the above to force recovery, then use up+home to force factory reset. The next question (which I'm too much of a wuss to explore) is if the recovery or factory reset will rebuild trashed /system or /data filesystems.

Actually, factory.zip touches data, but all it does is kill packages.xml and wipe the dalvike cache.

Also, the factory.zip script will reformat mmcblk0p5, so it fixes it in that sense, but I doubt it could recover if you started killing partition layouts and stuff like that.

I was just looking through the updater-script in factory.zip and I noticed this:

mount("vfat", "/dev/block/mmcblk0p1", "/boot");

I just thought it was interesting that mmcblk0p1 is type vfat.

Originally Posted by staulkor

I was just looking through the updater-script in factory.zip and I noticed this:

mount("vfat", "/dev/block/mmcblk0p1", "/boot");

I just thought it was interesting that mmcblk0p1 is type vfat.

It has to be, otherwise the OMAP won't find the bootloader.

Originally Posted by clockworx

Actually, factory.zip touches data, but all it does is kill packages.xml and wipe the dalvike cache.

Also, the factory.zip script will reformat mmcblk0p5, so it fixes it in that sense, but I doubt it could recover if you started killing partition layouts and stuff like that.

I've been messing around with the monster root pack, and can confirm that doing a "Erase and Deregister" doesn't clean out the system; I was still at least half-rooted and nearly unusable. I wiped the transient partitions from CWR and then the eight-boots reset got me back to (what I think is) stock.

I re-applied the monster pack and am having stability issues, but that's another thread, somewhere, I hope...

Dennis