Due to Android 10 the new TWRP uses a different file/partition structure than in the past where backups generally included just the Boot, System & Data partitions. Which of the many new partitions are needed for a full, restorable backup?
Related
Having trouble finding a firm answer on this. I have read that encryption has NO effect on Recovery mods since it only encrypts apps, data, and a few other pieces of info. (I thought that there was full disk encryption, but I guess not). So I would like to verify the following questions regarding the use of custom ROMs and Android encryption and I would like to do both, back them up, and maybe even change ROMs without issue.
I am fairly certain I can boot into a recovery mod (CWM or Twerp) without any problems while encrypted. Is this true? (I have seen conflicting answers here and on the interwebs).
If I back up a ROM and data (assuming this is done together in one backup), will I be able to recovery the backup properly and use it even when it was encrypted?
Thanks in advance.
Bakura
You can boot into recovery and flash zips but you will not be able to access your /data partition since that's what's encrypted. For flashing ROMs this doesn't matter since those don't touch /data. However if you have to wipe your user data you will have to set up the encryption all over again.
What this also means is you cannot store your zips on the internal memory of your phone because those will not be accessible to the recovery. You will have to store them on either an unencrypted microSD or sideload them with adb (easy enough to do on CWM, not sure about other recoveries).
Backing up should be fine as long as you backup to somewhere other than the internal memory for the reasons I stated above.
Will the wipe and restore options work?
Hexgore said:
You can boot into recovery and flash zips but you will not be able to access your /data partition since that's what's encrypted. For flashing ROMs this doesn't matter since those don't touch /data. However if you have to wipe your user data you will have to set up the encryption all over again.
What this also means is you cannot store your zips on the internal memory of your phone because those will not be accessible to the recovery. You will have to store them on either an unencrypted microSD or sideload them with adb (easy enough to do on CWM, not sure about other recoveries).
Backing up should be fine as long as you backup to somewhere other than the internal memory for the reasons I stated above.
Click to expand...
Click to collapse
I have a full Nandroid Backup of my phone with 4ext Revovery Touch. So if I encrypt Internal Storage only and if it's screwed up, will I be able to restore the Nandroid backup from recovery (I mean, is it possible to modify (rwx) the encrypted partition from recovery?
Far_SighT said:
I have a full Nandroid Backup of my phone with 4ext Revovery Touch. So if I encrypt Internal Storage only and if it's screwed up, will I be able to restore the Nandroid backup from recovery (I mean, is it possible to modify (rwx) the encrypted partition from recovery?
Click to expand...
Click to collapse
If the Nandroid backup is stored on your SD card, I think so, but you might have to wipe the partition first. As far as I know (someone please correct me if I'm wrong) you can still wipe the encrypted partition, you just can't access any of the encrypted data from recovery.
Yeah, the recovery works just fine!
Hexgore said:
If the Nandroid backup is stored on your SD card, I think so, but you might have to wipe the partition first. As far as I know (someone please correct me if I'm wrong) you can still wipe the encrypted partition, you just can't access any of the encrypted data from recovery.
Click to expand...
Click to collapse
^+1. So I went ahead and encrypted the internal storage. The process was fairly fast (took me under 10 mins).
But entering a password was too much of a hassle. So I performed a full system wipe and restored the backup. No problems.
That actually didn't work for me on the Nexus 7.
I tried to wipe the tablet from recovery but it couldn't mount the /data partition.
I tried to wipe the tablet from the OS but it didn't like the custom recovery so it just rebooted without changing anything.
In the end I had to run "fastboot erase userdata" to wipe it. That worked.
I have now installed CM 10.1 and can report that the encryption process seems to be working fine on the N7. It's taking a while but it is the 32GB model.
Encryption on Android is very temperamental. The general pattern seems to be that if the ROM you're using is based on the stock OS for your device (as AOSP is for Nexus devices) encryption will work fine, but due to the way the memory is mounted on modern Nexus devices, recoveries may be unable to mount the /data partition at all.
However if you are using a ROM based on a non-stock OS for your device (e.g. AOSP on an HTC Sensation) encryption may not even be able to turn on, and sadly fixing this problem when it arises is not high on the list of priorities for most developers, especially if your device isn't popular.
We are lucky that CyanogenMod seems to care a lot about privacy and security recently however. That may mean they focus more on encryption compatibility in the future, and most AOSP ROMs are based on CM, so fingers crossed for that.
But basically be aware YMMV when it comes to encryption on custom ROMs.
I tried to encrypt two Moto G's with the new official CM11, but after reboot and enter pin to unlock, the devices crashes with a black screen.
Encryption with stock firmware works fine.
[Caveat emptor: adopt/follow this guide at your own risk].
Rooting and especially running a custom firmware (commonly referred to as “ROM”) on an NT unlock the NT’s full potential as a Android tablet. However these undertakings entail a significant risk: accidents or errors in the Rooting or Custom ROM Flashing process can render the NT unusable (aka “bricked”), potentially permanently. This risk can be mitigated by:
developing a basic understanding of the essence of the Rooting and ROM Flashing processes – in particular which parts of the NT storage/content get modified or replaced, and which parts do not
choosing an effective yet low risk rooting/flashing process, and most importantly,
making preparation in advance for a recovery process in the event something goes wrong: by far the most common cause of permanent bricking is not the initial bad rooting/flashing process but rather the subsequent use of unsuitable recovery (“unbrick”) procedures/tools.
NT Internal Storage (EMMC) Partitions and Associated Content (approximated partition sizes on a 16GB NT w/ 8GB allocated for user media)
/xloader (128KB, /dev/block/mmcblk0p1): first stage bootloader (MLO)
/bootloader (256KB, /dev/block/mmcblk0p2): second stage bootloader (u-boot.bin)
/recovery (15.3MB, /dev/block/mmcblk0p3): recovery process (recovery.img)
/boot (16.3MB, /dev/block/mmcblk0p4): boot process (boot.img)
/rom (49.1MB, /dev/block/mmcblk0p5): a set of 15 files containing factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.)
/bootdata (49.1MB, /dev/block/mmcblk0p6): boot control and status data (BCB, BootCnt, max17042.bin)
/factory (378.8MB, /dev/block/mmcblk0p7): backup copy of stock ROM as well as backup copy of device data in /rom partition (romdata.zip)
/system (628.6MB, /dev/block/mmcblk0p8): running copy of ROM (system and base apps)
/cache (436.2MB, /dev/block/mmcblk0p9): storage area for temporary data by system/user apps
/media (7.8GB, /dev/block/mmcblk0p10): user media content
/userdata (often referred to as /data, 5.8GB, /dev/block/mmcblk0p11): user-installed apps
For information on the roles of some of these partitions in the NT boot process: see http://omappedia.org/wiki/Bootloader_Project and http://forum.xda-developers.com/showthread.php?t=1444630.
Rooting
Rooting essentially adds a number of system files and apps to the stock ROM on the /system and /data partitions. The simplest routing method which uses CWM recovery running on bootable SDcard and which contains relatively the most current rooting content package can be found at http://forum.xda-developers.com/showpost.php?p=31271965&postcount=240. To get a sense of what get installed into /system and other changes to the stock ROM file-system, take a peek at the two folders “data” and “system” and the "updater-script" file in the folder "META-INF\com\google\android" inside the rooting content package "update.zip" referenced in that post.
Custom-ROM Flashing
Flashing custom ROM replaces the boot.img in /boot with a copy of boot.img from custom ROM zip file and the stock ROM in /system with the custom ROM and Gapps from the custom ROM and Gapps zip files, and wipes out /data (where user-downloaded apps from Google Play store will be installed) as well as /cache. Some custom ROM builds, such as Succulent’s CM10.x or 11.x builds (which are posted on his Blog http://iamafanof.wordpress.com/) also include copy of CWM or TWRP recovery.img which replaces the stock recovery.img in the /recovery partition. To get a sense of what get installed onto the NT and where, take a peek at the folders (except for "META-INF") and the "updater-script" file in the folder "META-INF\com\google\android" inside the ROM and Gapps zip files.
A method for flashing CyanogenMod (CM) ROM using CWM or TWRP recovery running on bootable SDcard is outlined at http://forum.xda-developers.com/showpost.php?p=51377882&postcount=163 (CM10.x ROM) and http://forum.xda-developers.com/showthread.php?t=2692403 (CM11 ROM).
An alternative to installing CyanogenMod (CM) ROM intenally on emmc is to install and run it off an SDcard, leaving the NT entirely unmodified. See http://forum.xda-developers.com/showthread.php?t=2098419 for info on how to create CM10.x SDcard images using Succulent's CM10.x builds.
Recovery from a Bad Rooting and ROM Flashing
It should be clear from the above discussion that the Rooting and custom ROM Flashing processes only involve /system, /data, (and in the case of ROM Flashing) /boot and /recovery. Thus, a logical approach for recovery is to make a backup copy of these affected partitions prior to Rooting and ROM Flashing. This approach makes even more sense since the very same CWM or TWRP recovery tool used to install the content of the Rooting/ROM/Gapps zip packages can also be used to make a backup copy of the affected partitions’ content and subsequently restoring these partitions using the content backup copy if needed. For this reason, while there are various approaches to Rooting and ROM Flashing, the most pragmatic and prudent one is to use CWM or TWRP Recovery tool running off a bootable SDcard, as this enables using the SDcard for content backup and, more importantly, using the SDcard to boot the NT and restore the backup content even when the NT becomes un-bootable on its own.
The remaining partitions of the NT – namely: /xloader, /bootloader, /rom, /factory, and /media – are not involved and should not be affected at all by Rooting and ROM Flashing. Hence there is absolutely no reason to use any “unbrick” process/tool that would flash/reformat/repartition/wipe/zero-out any one of these partitions – unless it has been determined with certainty that these partitions have been irreversibly corrupted. In particular the two partitions /rom and /factory which contain factory-installed individual device data must never be reformatted/wiped/zeroed-out without first backing up their content in a restorable form -- therefore refrain from using any “unbrick” tool that reformat/overwrite/wipe these two partitions without first backing up and subsequently restoring their content.
Making a Bootable Recovery SDcard
There are two approaches to making a bootable SDcard with Recovery tool for Rooting and ROM Flashing: using a pre-made SDcard image (download, unzip and write the image to the SDcard using a disk-image writer program), and creating the SDcard from scratch. The first approach is convenient, while the second although a bit more time-consuming (and potentially frustrating) provides the flexibility in customizing the card: e.g., selecting particular version of Recovery tool (i.e., for its features, or its compatibility with the particular ROM release), sizing the SDcard boot partition to provide adequate space for backing up current ROM).
The TI OMAP processor used by the NT is very fussy about the cylinder/head/sector geometry of its “boot disk” (i.e., the SDcard in this case) – see http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot for more info). Fortunately its requirements can be met using many disk-partition management tools such as MiniToolPartition or EASEUS Partition Master simply by selecting the approriate menu options in creating the boot partition: cylinder aligned, primary/FAT32 with partition ID type 0x0C and with LBA and Active flags set.
Next the boot partition needs to contain a specific set of boot files: MLO, u-boot.bin and boot.img and/or flashing_boot.img (aka Cyanoboot); these can be found in SD_boot.zip compiled by Succulent and posted at http://iamafanof.wordpress.com/2012/11/11/how-to-guide-bootable-cm7cm9cm10-sdcard-for-nook-tablet/). I have also found that it helps to first copy MLO (to the freshly made boot partition) before copying the other files, since it appears that the NT OMAP processor only scans the first couple of entries in the partition looking for this file (see http://www2.sakoman.com/OMAP/preparing-a-bootable-sd-card.html and http://permalink.gmane.org/gmane.comp.embedded.openbricks.scm/515).
In my experience, the two most common symptoms of failed SD boot and their likely causes are:
The NT boots straight to stock -- most likely the boot partition's type and/or flags are not correctly set, or the NT cannot find the MLO in the boot partition (see comment re: the ordering in file copying above).
The NT screen stays dark for several minutes then eventually boots to stock -- most likely the MLO or u-boot.bin are corrupted. Check the exact size of these two files in bytes, they should be respectively 38,356 and 179,812.
Also, it should be noted that many NTs will boot off a SD card only from the power-off state and upon insertion of a powered USB cable.
To complete the making of the Recovery SDcard, download a recovery program .img file for sdcard (such as cwm_6012_sd.img or twrp_2220_sd.img from http://forum.xda-developers.com/showthread.php?t=1640958), rename it to recovery.img, and copy it to the SDcard boot partition.
Info/Tools for Restoring to Stock
For situations with absence of a working DYI backup copy, attempts can still be made to restore the NT to stock.
Restore to Stock ROM from Rooted Stock ROM (NT with intact stock Recovery and /factory partition): consider using the “8 failed boots” method documented at http://nookdevs.com/NookColor/RestoreToStock (it was written for the Nook Color but should be applicable to the Nook Tablet as well).
Restore to Stock ROM from Custom ROM:
A good source for resource/tool for restoring to stock is Succulent's repository at https://github.com/succulent/acclaim_recovery_sdcard; see its README file for an annotated index/description of the resource/tools and usage instructions. Another potential recovery tool is the repart.img described at http://raywaldo.com/2012/06/how-to-un-brick-a-nook-tablet-8gb-or-16gb/.
HOW-TO Guides for Installing CyanogenMod on Nook Tablet
Installing CM11 Internally on Nook Tablet
Installing CM10.x Internally on Nook Tablet
Updating NT Internal Emmc to CM11 from CM10.x
Building a CM10.1 (JB 4.2.x) SD card for Nook Tablet
TWRP for the OPX brings up the partitions below:
System
Data
Cache
Persist
Boot
Recovery
EFS
I wondered which ones I should be backing up for standard nandroid backups? I used to do System, Data +/- Cache on my OnePlus One. I did EFS once and backed it up externally and on the SD card, but never restored it.
Do we need to backup all partitions every time?
More importantly, do we need to restore all partitions if restoring an older nandroid of the same ROM or one from a different ROM?
Many thanks
SORF said:
TWRP for the OPX brings up the partitions below:
System
Data
Cache
Persist
Boot
Recovery
EFS
I wondered which ones I should be backing up for standard nandroid backups? I used to do System, Data +/- Cache on my OnePlus One. I did EFS once and backed it up externally and on the SD card, but never restored it.
Do we need to backup all partitions every time?
More importantly, do we need to restore all partitions if restoring an older nandroid of the same ROM or one from a different ROM?
Many thanks
Click to expand...
Click to collapse
All recommended.
You can store your backups on SD card and forget to worry about the sizes.
Sent from my ONE E1003 using Tapatalk
I want to know how to make a complete backup of internal storage (ie. Sdcard0) without using a patched twrp or and apps. Is it as simple as zipping up a single directory?
Ideally I want this to complement my twrp backup of the system partitions.
I know this should be pretty basic, but I've found some conflicting information online. I'm running crDroid at the moment and I'd like to make a perfect backup that will restore the entire system, apps, and app data as it was at the time of backup.
TWRP offers me 14 partition options for backup:
Spoiler: Partitions
Data (excl. storage)
Cache
System
System Ext
Vendor
Boot
EFS
Android Secure
Modem
Persist
Recovery
Internal storage
System Image
Vendor Image
If I understand right based on the TWRP FAQ, then backing up "System Image" and "Vendor Image" should be what I need. Have I got that right?
You are right System Image and Vendor Image, but also add Data and for kernel add Boot and Dtbo.
Those partitions need to be recovered to get your old ROM back.
Once you should backup EFS which contains IMEI and also Persist if the recovery supports it.
EFS and Persist should only be recovered when you really need to.
Happy flashing.