Root I Messed Up..???

[scary alien]

All,

Just to put a cap on the nandroid-mobile.sh script from before...

I booted my Eris into custom recovery and pulled the /sbin/nandroid-mobile.sh script: View attachment nandroid-mobile.zip

Interestingly enough, this file is not present while the phone is booted normally...(I'm assuming that the act of booting into custom recovery must place this file in /sbin temporarily, but I couldn't find such a reference in Amon_RA's recovery source code).

Anyway, this version is different (but very similar) to the pastebin version I posted earlier.

It just nice to have this for future reference. Cheers!

 

[Podivin]

mhotovec, thanks for the fast reply.

Perhaps it is prudent to leave the ext partion in place just in case, as you suggested.

Now in this case when I restore the apps with the Ti backup, will they go automatically to this ext partition (where they were saved from)?
Peter

Peter
I can't say for SURE, but I'd bet a fair amount of money (50 cents) that the apps will be saved in the phone rather than on the card. While TI remembers your apps and their data, I believe it's the phone setting that will control where the apps are actually restored to.

 

[doogald]

Perhaps it is prudent to leave the ext partion in place just in case, as you suggested.

Now in this case when I restore the apps with the Ti backup, will they go automatically to this ext partition (where they were saved from)?
Peter

Assuming that you have installed xtrROM (or xtrSENSE) and have not activated apps2sd, TI will restore to internal - not to the ext partition.

 

[erisuser1]

Interestingly enough, this file is not present while the phone is booted normally...(I'm assuming that the act of booting into custom recovery must place this file in /sbin temporarily, but I couldn't find such a reference in Amon_RA's recovery source code).

There are two bootable linux/android "images" on the phone: boot.img, and recovery.img (held in raw format in the boot and recovery flash memory (MTD) partitions). Never the twain shall they meet - by design.

The Android bootable images contain both a compressed linux kernel and a ramdisk, and anything may be placed in a ramdisk.

For stock releases, the compressed kernel is identical between the "boot" and "recovery" images, but is duplicated between the two partitions for rather obvious reasons - you don't want corruption of the OS boot to kill off the recovery boot as well.

Think of it this way: the kernel creates a "virtual" file system in system RAM that starts at "/", and has a bunch of folders and files which are also virtual (in the sense that they reside only in RAM); these files and folders get populated by the kernel from the contents of the ramdisk. When the regular OS starts up, it creates this virtual file system, and then "mounts" a bunch of file systems on top of it - some of which are "real", (as in "backed up by non-volatile flash memory") such as /system, /data, and /cache, and some of which are also virtual, but use different memory-based storage formats, such as /proc, /sys, /tmp, et cetera. Note that one of the folders, namely: /sbin is not a mount point, so everything that you find in /sbin in either the recovery boot or the regular OS boot comes with the ramdisk that is part of the (respective) bootable image file.

When Amon_RA starts up, it is more or less self-contained - the only "real" file system that it mounts by default is /cache, and the reason that it does so is for compatibility with the stock Android recovery boot (the OS or the bootloader can place commands that the recovery binary /sbin/recovery interprets that are stored in /cache/recovery/command - that is one way that the different boots can "communicate" with each other across a reboot cycle).

Hope that explanation helps,

eu1


PS There is one other thing about Amon_RA which is a little bit interesting. You will note that you can use commands such as "ls" and "grep" from within the (adb) shell with Amon_RA recovery booted - but if you examine the "PATH" variable, you will find that

PATH = /sbin

and while you will find things in there such as "nandroid-mobile.sh", you won't find "ls" or "grep"... they are all "built-in" to the adb shell. Sort of like a combination of "sh" and "busybox", where "sh" understands a bunch of "built-in" commands which are not usually part of a bash, (ash, or bourne) shell.

 

[scary alien]

eu1,

Thank you very much, that was/is very helpful!

I tried finding the nandroid-mobile.sh referencs in init.rc and other various places since I didn't know about the compressed mini-kernel. This must also explain why you would want to do it this way--i.e., you don't want a "live" filesystem mounted that Nandroid would backup due to wanting to preserve the integrity of the files and filesystems being saved.

I didn't look at the PATH variable or explore too deeply ...this was really only my second time exploring via adb while booted into recovery (thanks for that, too!).

Thanks again and we missed your presence around here for the past couple of days...hope all is okay.

 

[scary alien]

All,

I posted this http://androidforums.com/eris-all-t...please-cant-nandroid-restore.html#post1604509 earlier this evening and wanted to re-post here so that this additional Nandroid backup and restore information was all linked together in one thread. The post had to do with listing most all of the exit status values from the Eris' nandroid-mobile.sh script.

Anyway, I could copy/paste that information again here if anyone thinks it would be helpful. Let me know.

Thanks.