Database Users

[HOWTO] "Partitioning" your Nexus S using LVM

Always wanted a larger /data partition? Want to add a swap partition or an extra partition for your Debian/Ubuntu/Fedora chroot? Want your ROM to have the combined /data and /sdcard of Honeycomb and ICS devices? Then this guide is for you.
Table of contents
This post: background information
(Advanced) users: modifying your phone to use LVM
Developers: adding LVM support to a ROM
Building LVM for Android
The Linux [URL="http://sourceware.org/lvm2/]Logical Volume Manager[/URL] (LVM) is a set of tools which allows you to create virtual disks ("logical volumes", "LVs") backed by a set of real storage devices ("physical volumes", "PVs") organized into "volume groups" ("VGs"). Using LVM, you can:
Create logical volumes which are larger than any of the individual physical volumes available on your device's real storage.
Create an arbitrary number of logical volumes of arbitrary size, regardless of the number of physical volumes or partitions available on your real storage devices. You could, for example, add a dedicated swap partition, or create a separate /system and /data for a dual-boot setup.
Take a snapshot of a logical volume -- a copy of the LV which only stores differences between it and the original (requires additional kernel support). You could, for example, take a snapshot of the external storage LV and export it via USB mass storage to a computer, without needing to unmount the LV from your device.
Grow or shrink logical volumes without unmounting the file system ("online resize", requires filesystem support).
LVM was developed to manage storage on Linux servers and workstations, but was also used by Palm/HP in WebOS devices. It uses the Linux device-mapper technology used in Android for apps installed on the SD card, so any Android kernel will work with LVM.
This guide was developed with the Nexus S in mind, but the technique described should be applicable to many other Android devices as well.

Modifying your phone to use LVM
WARNING WARNING WARNING
While unlikely, you could brick your phone if you do this incorrectly!!!
Read this guide completely before attempting. If you don't understand the procedure, read it again until you do. If you still don't understand, wait for someone else to make this easier. If you're not sure you understand, you probably don't.
BACK UP EVERYTHING ON YOUR PHONE, INCLUDING THE CONTENTS OF /sdcard, BEFORE ATTEMPTING THIS PROCEDURE! This will erase everything on your phone.
The preassembled images attached to this post are for Nexus S GT-i9020T running stock Android 4.0.4 IMM76D ONLY. They may or may not work with other phones and ROMs. (See the next post for how to modify any ROM to use LVM.)
You will need:
A Nexus S with unlocked bootloader
A computer with fastboot and adb installed and working
A USB cable
Factory images for your phone, in case something goes wrong
Procedure:
Take a nandroid backup of your phone and copy it to your computer. We'll use it to restore the ROM later. You MUST copy the backup to your computer! This procedure will erase EVERYTHING on your phone, including the contents of /sdcard.
Download the boot and recovery images attached to this post. Reboot your phone into the bootloader, then flash the recovery to your phone using fastboot:
Code:
fastboot flash recovery recovery-lvm-clockwork-5.0.2.0-crespo.img
(GPL information: this is the stock kernel image from ClockworkMod 5.0.2.0. For LVM source, see this post.)
Boot into recovery.
Enter the shell on the device:
Code:
adb shell
In the shell on the device, do the following (# is your prompt):
Code:
# /lvm/sbin/lvm pvcreate /dev/block/mmcblk0p1 /dev/block/mmcblk0p2 /dev/block/mmcblk0p3
# /lvm/sbin/lvm vgcreate lvpool /dev/block/mmcblk0p1 /dev/block/mmcblk0p2 /dev/block/mmcblk0p3
This marks the partitions normally used for /system, /data, and /sdcard for use with LVM, and creates an LVM volume group named "lvpool" using those devices.
In the shell on the device, set up your desired logical volumes (partitions).
Code:
# /lvm/sbin/lvm lvcreate -L 320M -n system lvpool
# /lvm/sbin/lvm lvcreate -L 1G -n userdata lvpool
# /lvm/sbin/lvm lvcreate -L 10G -n media lvpool
[...]
This creates the mandatory logical volumes named "system", "userdata", and "media", which will be mounted on /system, /data, and /sdcard, respectively. Replace the argument to -L with the desired size of each partition. (/system needs to be at least 300 MB to fit the stock ROM.) You can create additional volumes similarly:
Code:
# /lvm/sbin/lvm lvcreate -L [size] -n [name] lvpool
replacing [size] with the desired size and [name] with the desired name. You have a little less than 15 GB space in the volume group to work with; depending on how many partitions you want to create, you can adjust the size of the "media" and "userdata" logical volumes as required.
Reboot back into recovery. Mount the USB storage on your computer. On your computer, format your phone's USB storage as you would a USB flash drive.
Copy your nandroid backup from your computer onto your phone.
Reboot back into recovery. Restore the nandroid backup.
Reboot into the bootloader. Flash the boot image to your phone via fastboot:
Code:
fastboot flash boot boot-lvm-crespo-IMM76D.img
(GPL information: this is the stock kernel image for IMM76D. Source is available from AOSP git. For LVM source, see this post.)
Reboot. You should have a working device running on LVM.
Additional tips and hints
To see the logical volumes you've created, use
Code:
# /lvm/sbin/lvm lvs
and to see how much free space you have remaining in the volume group, use
Code:
# /lvm/sbin/lvm vgs
If you want to delete a logical volume (for example, if you screwed up), use
Code:
# /lvm/sbin/lvm lvremove /dev/lvpool/name
(replacing "name" with the name of the LV you want to delete).
It's often useful to leave a bit of free space in the volume group (512 MB to 1 GB or so). This gives you a bit more flexibility to modify the layout or grow partitions in the future, and allows you to take snapshots of logical volumes.
Removing LVM from your phone
Flash a standard recovery such as the regular ClockworkMod recovery to your phone.
Do a full wipe/factory reset.
Restore your phone from a backup.
If things go really wrong, flash the factory image to your phone via fastboot.

Modifying an existing ROM to use LVM
(This is a condensed version of the full guide: https://raw.github.com/steven676/android-lvm-mod/master/HOWTO-MOD)
You will first want to grab a copy of the binaries and config files by cloning my git repository: https://github.com/steven676/android-lvm-mod.
Unpack the ramdisks from your boot and recovery images. Make the following changes:
Copy the contents of lvm-bin/ in the git repository to lvm/ in the ramdisks.
Copy devices/crespo/lvm.conf to lvm/etc/lvm.conf in the ramdisks.
For the boot image, integrate the changes in devices/crespo/boot/init.herring.rc-changes.diff into your init.herring.rc.
For the recovery image, integrate the changes in devices/crespo/recovery/init.rc-changes.diff into your init.rc.
For the recovery image, copy devices/crespo/recovery/recovery.fstab to etc/recovery.fstab.
Repack the ramdisks and create new boot and recovery images with them (the original kernels are fine to use).
If creating a flashable zip to install your ROM, you will also want to modify the installer script to set up the LVM volume group and logical volumes (see the previous post).
If you're building your own kernel, consider enabling CONFIG_DM_SNAPSHOT in your kernel's build configuration, to allow taking snapshots of logical volumes.
Remember that LVM is released under the terms of the GPL v2 (same as the Linux kernel), so you are required to comply with the GPL's source distribution requirements with respect to LVM.
More extensive modifications (such as changing the devices used to form the volume group) are possible; see the full HOWTO guide for details.

Building LVM from source for Android
The LVM source was written for standard glibc-based GNU/Linux systems, and doesn't build agains Android libc. We could invest time and effort into porting it to Android, but it's easier to just statically link the LVM binary against glibc (we already have to use a statically linked binary, since the boot image doesn't ship shared libraries).
To build LVM with glibc, you will need either an actual GNU/Linux ARM system with a development environment (gcc, make, and glibc header files) set up, or a GNU/Linux ARM cross-compiler toolchain (more difficult to set up). The binaries in lvm-bin/ were compiled with an Emdebian squeeze/armel toolchain running on a Debian squeeze/amd64 machine; this procedure has also been tested with a Nexus S running a Debian squeeze chroot (though any recent Linux distribution and any device should do). The Linaro prebuilt GCC toolchain and the CodeSourcery CodeBench Lite toolchain for ARM GNU/Linux should work; the Android NDK toolchain will not.
Getting the source
Clone the lvm-mod git repository. Then, in the newly cloned repository, do
Code:
git submodule init
git submodule update
You will have a copy of the LVM source (as used to build the binaries in lvm-bin/) in lvm-src/.
(Alternately, clone https://github.com/steven676/lvm2 and checkout branch android-lvm-mod. You can also use upstream's git repository or source tarballs; see their website for details.)
Building the source
(This is a condensed version of the full guide: https://raw.github.com/steven676/android-lvm-mod/master/HOWTO-BUILD)
These instructions are written for a native build (building in a Debian/Ubuntu/Fedora chroot on an actual ARM device).
Configure the LVM source:
Code:
$ ./configure --prefix=/lvm --enable-static_link --disable-readline \
--disable-selinux --with-pool=none --with-cluster=none \
--with-confdir=/lvm/etc --with-default-run-dir=/data/lvm/run \
--with-default-system-dir=/lvm/etc \
--with-default-locking-dir=/data/lvm/lock \
--with-optimisation="-Os -march=armv5te -mtune=cortex-a8 -mthumb"
For a cross build, you need to set up the system to run ARM binaries using QEMU (see the full HOWTO for details). (For extra credit, fix the build so that it works with the configuration produced by running configure without qemu-arm enabled.) Then configure the source with:
Code:
$ export CC=arm-linux-gnueabi-gcc # replace with your cross compiler
$ ./configure --host=arm-linux-gnueabi \
--prefix=/lvm --enable-static_link --disable-readline \
--disable-selinux --with-pool=none --with-cluster=none \
--with-confdir=/lvm/etc --with-default-run-dir=/data/lvm/run \
--with-default-system-dir=/lvm/etc \
--with-default-locking-dir=/data/lvm/lock \
--with-optimisation="-Os -march=armv5te -mtune=cortex-a8 -mthumb"
Build the source:
Code:
$ make
Grab the pieces you need: the statically linked, unstripped lvm binary is located in tools/lvm.static, and a sample configuration file is in doc/example.conf.

(reserved)

Hello steven676,
This post is helpful to me!
But I have some questions on LVM as I am new to it.
1. Is it possible to use LVM only on one pv, say /sdcard?
2. If 1. yes, will lv's on a pv be linear mapped, that is, lv's in a pv are placed one after one?
3. now that removing lvm is possible, is it also possible to backup lvm setting, and switching between non-lvm and lvm environment?
Thanks

solarispika said:
1. Is it possible to use LVM only on one pv, say /sdcard?
Click to expand...
Click to collapse
Sure. Just modify the arguments to pvcreate and vgcreate accordingly:
Code:
# /lvm/sbin/lvm pvcreate /dev/block/mmcblk0p3
# /lvm/sbin/lvm vgcreate lvpool /dev/block/mmcblk0p3
solarispika said:
2. If 1. yes, will lv's on a pv be linear mapped, that is, lv's in a pv are placed one after one?
Click to expand...
Click to collapse
Probably, but in general it is not safe to assume this. Imagine the following sequence of commands:
Code:
# /lvm/sbin/lvm lvcreate -L 1G -n vola lvpool
# /lvm/sbin/lvm lvcreate -L 1G -n volb lvpool
# /lvm/sbin/lvm lvresize -L +1G /dev/lvpool/vola
What's likely to happen here is that vola is going to be split into two segments on disk, like this:
Code:
[ 1GB vola ][ 1 GB volb ][ 1 GB vola ][ remaining free space ]
There are ways in which you can give LVM hints as to what on-disk layout you want, and the LVM tools will generate information about the current layout in /data/lvm/backup if that directory's available (and mounted read-write) at the time, but in general, it's best to treat the on-disk layout of a logical volume as unknown. In practice, unless you have physical volumes with widely varying characteristics in the same volume group (say, an SSD and some spinning-platter hard disks), you shouldn't need to worry about the actual layout.
solarispika said:
3. now that removing lvm is possible, is it also possible to backup lvm setting, and switching between non-lvm and lvm environment?
Click to expand...
Click to collapse
If /data is mounted read-write, running
Code:
# /lvm/sbin/lvm vgcfgbackup
will create a human-readable backup of the current LVM volume group metadata in /data/lvm/backup (if that directory is available and mounted read-write).
I'm not sure what you mean by "switching" between non-LVM and LVM environments. If you mean going between an unmodified stock boot image and an LVM boot image, the answer is yes, but you won't have access to any of the data in your LVM logical volumes while running an image not configured for LVM, and you need to be careful not to accidentally format the LVM physical volume.
If you're asking about having two or more ROMs on the phone, one installed to the normal /data and /system eMMC partitions, and another on LVM logical volumes, the answer is also yes, but both ROMs will need modified ramdisks. The one for the eMMC-installed ROM should only mount /sdcard from LVM, while the others should be set up to mount /data and /system from LVM as well.

Good write up;-)
wonder if lvm swap could be connected as extra memory .
Sent from my Nexus S using XDA

wizardslovak said:
wonder if lvm swap could be connected as extra memory .
Click to expand...
Click to collapse
Sure, of course. From my phone:
Code:
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/lvpool-swap partition 65532 28196 -1
It works just fine, even if it's not a setup I'd use on a mission-critical server.

Hey Guys,
Thanks for this awesome guide.
I just have a quick question, what are the advantages of using LVM instead of the normal partitioning?
I just want to know cause i might added to my rom.
Thanks

mandaman2k said:
I just have a quick question, what are the advantages of using LVM instead of the normal partitioning?
Click to expand...
Click to collapse
Primarily flexibility in deciding the number and layout of partitions -- see the first post.

Sounds good . Ill try it once home ;-)
Sent from my Nexus S using XDA

I just pushed a couple of changes:
Updated prebuilt binaries and LVM source to 2.02.96.
Fixed the instructions for cross compiling LVM.
The boot and recovery images attached to the second post have been updated accordingly.

Is this the only way to make the device function like HC/ICS/JB devices that ship with combined storage?
Are the images from Google partitioned with internal/external storage or are the latest images partitioned with a layout similar to the Galaxy Nexus?

CocoCopernicus said:
Is this the only way to make the device function like HC/ICS/JB devices that ship with combined storage?
Click to expand...
Click to collapse
If you want a setup that's exactly as on a 3.0+ device with "SD card" data stored in /data, then yes, this is the only way I know of. If you just want MTP functionality, then no.
CocoCopernicus said:
Are the images from Google partitioned with internal/external storage or are the latest images partitioned with a layout similar to the Galaxy Nexus?
Click to expand...
Click to collapse
Official Google software builds use separate userdata and media partitions and continue to offer the 2.x-style USB mass storage access. I'm not sure the partition layout is adjustable in software -- the eMMC presents an EFI partition layout which no one seems to have figured out how to change.

Cool, thanks. Yea, I'm not too interested in the MTP functionality, I just don't want to deal with internal/external storage after using the Galaxy Nexus.

Swap partiton
Hi..
how i can to create a swap partition of 1G and added to system??
I had create a 1G partition "swap" but system no activated this partition.

xxmurdocxx said:
Hi..
how i can to create a swap partition of 1G and added to system??
I had create a 1G partition "swap" but system no activated this partition.
Click to expand...
Click to collapse
You'd need to format the swap partition:
Code:
# mkswap /dev/lvpool/swap
Also, you need to make sure that your kernel has swap support (CONFIG_SWAP=y -- the default kernel does not have this) and that your init scripts are enabling the swap partition (swapon /dev/lvpool/swap).
One other note: you might find lag to be somewhat severe with a 1 GB swap partition -- I'd suggest smaller.

I'm finally getting around to messing with my NS. From what I understand I can't just modify an existing rom(stock JB in this case) to use the larger partitions without compiling an entire new rom, right?
Which would mean I'd be at the mercy of whoever created the ROM to update when an OTA rolls around?

CocoCopernicus said:
I'm finally getting around to messing with my NS. From what I understand I can't just modify an existing rom(stock JB in this case) to use the larger partitions without compiling an entire new rom, right?
Which would mean I'd be at the mercy of whoever created the ROM to update when an OTA rolls around?
Click to expand...
Click to collapse
No, you can modify an existing ROM yourself. It's most definitely not the simplest process around, though -- see the documentation at the top of the thread for instructions. As I say there ... read thoroughly and understand before attempting.

PIT file method to revive your phone from a MMC_CAP_ERASE brick

Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.
Note: This thread is rather old now (2012).
Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
most important: an older emmc chip (or firmware).
All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
Some insights here (as part of this thread)
after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
In case only one of the conditions is not true, the brick should not happen.
So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.
So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.
Especially, all current roms or recoveries should be safe.
If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.
So in most cases, don't look here, unless you are using rather old devices and rather old software.
Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.
Note: You should generally post in the correct thread (please look in my signature)
Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).
It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
Please, please, please:
Read this multiple times and try to understand all aspects before using anything of this thread.
If you have questions, read it again!
If you have questions, read it again!
...
If you have questions, read it again!
If you have questions, read it again!
If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).
If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.
If you have questions, read first post again and again and also read the whole thread!
Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...
Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...
You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.
-------------------- manual method and tools for using adb
I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
Along the way our threads started to be companions to each other.
forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.
But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
However, the manual method can do more, especially if you have special cases.
-------------------- find begin and end of bricked area
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You should write down two numbers:
* where emmc_find_brick_start.zip freezes -> BRICK_START
* where emmc_find_brick_end.zip freezes -> BRICK_END
I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).
-------------------- patched pit files
I finally hacked a perl script, which generates a set of PIT files for me.
But because I cannot test the PITs on my phone (because I need it):
==> NO GUARANTY <==
Say you have a situation like this:
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
^ ^
| |
BRICK_START BRICK_END
(? = bad blocks)
The repartitioning should leave a hole in the partition table around the bricked area.
Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
(? = bad blocks)
The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:
Code:
16GB original (Q1_20110914_16GB.pit)
FACTORYFS 548864 ->Fo 1744896 ->Fs
DATAFS 2293760 ->Do 4194304 ->Ds
UMS 6488064 ->Uo 23232512 ->Us
HIDDEN 29720576 ->Ho 1048576 ->Hs
16GB MMC_CAP_ERASE patched
FACTORYFS FoX = Fo+X unchanged
DATAFS DoX = Do+X unchanged
UMS UoX = Uo+X UsX = Us-X
HIDDEN unchanged unchanged
The PITs are named like that:
N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB
This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.
Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.
So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB
Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB
In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
Therefore the following partitions (only HIDDEN in this case) remain unchanged.
All partitions before the first moved partition (FACTORYFS) remain also unchanged.
I recently added more starting partitions for the brick (XXX-moved-by-...).
As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.
Code:
case FACTORYFS-moved-by-...
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
case DATAFS-moved-by-...
before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
after: ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
\ /
-+-
|
HOLE
(? = bad blocks)
The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
For all other partitions, you have to format those partitions, before you can use them.
At least the data partition should be formatted
The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).
ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.
I also had the following problem:
I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
So, you may want to create a backup of your external sdcard first.
Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).
-------------------- backup
before messing with the partition table, everyone should make backups of all partitions that can be accessed.
-------------------- efs backup
The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.
For most supported phones, you can do this via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
please look at forrest1971's thread for details about using adb.
If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
Perhaps you have to mount your sdcard first, to be able to save it there.
Then you should copy the backup to your PC (the recovery should have the option to mount usb).
-------------------- backup files from internal sd before repartitioning
the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.
* you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).
For the following possibilities you should first ensure, you have a working recovery with working adb support.
Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.
* you can use QtAdb to copy files to your PC:
* you can use adb pull to copy any files or directory tree to your PC, e.g.:
adb pull /emmc/. emmc
* you can use tar from adb to archive files to a file on sdcard:
adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.
* you can use a copy command in adb shell to copy files to a folder in sdcard:
adb shell cp -ra /emmc/. /sdcard/emmc.backup
Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
This may matter for system and some app related files.
-------------------- recommended procedures for "standard" cases
"standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
All other partitions need special considerations and are not handled in this section!
Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
So be "careful with that axe, Eugene!"
Note, there are always multiple ways to reinstall the phone.
phase "find brick"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
* flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END
phase "flash pit and ROM"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)
phase "check partitions"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* check the partitions (see section "checking all partitions" below)
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format cache
* format data
* format internal SD (if it fails read below)
phase "start ROM"
...
After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).
A second method is via recovery using a custom kernel:
phase "find brick" like above
phase "flash pit and kernel"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)
phase "check partitions" like above
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format system
* format cache
* format data
* format internal SD
phase "install ROM"
* install the zip of the ROM
phase "start ROM"
...
So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
For some partitions this can be done by a simple format (cache, data, internal sd).
Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).
In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).
You may find other important information in the thread, please read it completely before asking the same things over and over again.
There may also be useful information and experiences from users.
I try to incorporate useful information in the thread starter, but my time is often very limited.
Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.
...suggestions or corrections welcome!...
-------------------- checking all partitions for bricked blocks
After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).
Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.
So you should check all your partitions after repartitioning to be sure.
With both methods below, you can check the partitions even before formatting any of them.
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You can also do it manual via dd commands in adb, but this is much slower.
Use commands like this, using the partition block device in the if=... argument:
adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
...
adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
etc.
If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.
-------------------- pit.str for DataWorkshop
For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
Please ask (PM), if you are interested in this.
-------------------- PITs for other devices
Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
Look at the attached files, which devices are currently available.
If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
I'll look what I can do...
I will add comments for special cases below.
-------------------- device i9250 - experimental PITs
I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
I added this especially for Shanava, who said to be able to recover even from a hard brick.
His brick is in userdata.
So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.
-------------------- devices not supported/supportable
i9000, i9300 (and similar):
These devices have a different PIT structure.
The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
Inserting an unused partition changes the partition numbers after it, which shouldn't work.
-------------------- FOR-EXPERTS-ONLY packages
DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
These packages contain files to be used by those who have special problems and want to take the risk to try them.
They are only documented by the corresponding discussion (somewhere in this thread).
note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.

Let's hear it....

ok I wait. ..

Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S

RavenY2K3 said:
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
Click to expand...
Click to collapse
That's why I said "Let's hear it....". Like, I am very curious because I noticed the same thing you did. I hate doubting people, but sometimes you have to.

hg42 said:
go straight ahead to the final solution (see next post)...
Click to expand...
Click to collapse
andreww88 said:
Let's hear it....
Click to expand...
Click to collapse
errr

I very much doubt it. But lets hear your version of "The curious case of Benjamin eMMC bug"

panyan said:
errr
Click to expand...
Click to collapse
Why did you quote me?

Repartitioning around the bad blocks
This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.
-----------------------snip -------------------------------------
Hi everyone, especially those with an ICS brick,
last week I jumped straight into a MMC_CAP_ERASE brick.
Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".
Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.
But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.
So I got the BRICK!
After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...
(this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here sorry, my fault)
---- cut ----
This is a rewrite in english of my report at a german forum:
ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html
My brick created bad blocks in the phone's flash memory.
I got I/O-Errors when attempting to read or write those blocks.
My SGN was still able to boot into recovery and all kinds of kernels/recovery.
Odin was able to flash boot loaders, kernels, modems and CSCs.
But flashing a factory_fs stopped at the very beginning.
I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.
For all of the following I needed access to some tools (mainly e2fsck and parted).
As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
You may use the tools from forrest1971, see below under "manual method".
One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
Click to expand...
Click to collapse
This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.
At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:
Code:
before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
after: + ...-| ? ?? |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(? = bad blocks, + working, - = not working still bad blocks inside)
In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).
Here is a log of my steps (but see below in the blue sections for other probably easier procedures):
Code:
I managed to access the device via [I]adb shell[/I]...which is another story for itself...
Then I started [I]parted[/I] with the flash device:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
[QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? f
f
f
Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
continue with the current setting?
Fix/Ignore? f
f
f
this was the partition scheme before implementing the workaround:
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
then I deleted the partitions 9=FACTORYFS=/system, 10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
(parted) rm 11
(parted) rm 10
(parted) rm 9
(parted) mkpartfs primary ext2 3500 4400
(parted) mkpartfs primary ext2 4400 7000
(parted) mkpartfs primary fat32 7000 15.2G
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
now I upgraded both new ext2 partitions to ext4:
~ # tune2fs -j /dev/block/mmcblk0p9
tune2fs -j /dev/block/mmcblk0p9
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # tune2fs -j /dev/block/mmcblk0p10
tune2fs -j /dev/block/mmcblk0p10
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # e2fsck -fDp /dev/block/mmcblk0p9
e2fsck -fDp /dev/block/mmcblk0p9
/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
~ # e2fsck -fDp /dev/block/mmcblk0p10
e2fsck -fDp /dev/block/mmcblk0p10
/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
and this is the final partition layout:
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 3500MB 4400MB 900MB ext3 FACTORYFS
10 4400MB 7000MB 2600MB ext3 DATAFS
11 7000MB 15.2GB 8217MB fat32 UMS msftres
12 15.2GB 15.8GB 537MB ext4 HIDDEN
This configuration works so far (one complete day now).
I can install firmwares and restore backups via recoveries.
Also flashing via Odin should work (not tried yet).
I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
I think/hope this will not occur too often...

-- naturally, it's much faster to insert those short messages than rewriting a long german post in english.
Next time I should write the main text prior to posting anything, I think...
sorry...

WoooooooOOOOOOoooooooowwwww!!!!
YeeeeeeEEEEEEaaaaaAAAAAaaaahhhhhh!!!!!!
You are the man, bro.

man has a few posts but are worth a lot. .. thanks for share with us

And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Is the damage so serious? Is it physical??

Interesting Read, this should be of a great help to those bricked without warranty.

straycat said:
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Click to expand...
Click to collapse
you *can* indeed try to recreate the standard partition scheme (I did it very early with a PIT file in Odin and also tried formatting those partions etc.), but this doesn't work because *accessing* those blocks in any way is the *real* problem.
Is the damage so serious? Is it physical??
Click to expand...
Click to collapse
yes, you can't even fix the bad blocks with the usual JTAG equipment.
I was told by a technician from a good repair center that a fix could eventually be possible by directly reprogramming the flash chip in some way (JTAG again), but no one tried yet, because this would cause several hours of work...
usually they swap the whole motherboard instead (which is >250EUR)

Thanks, hg42.
I really apreciate your efforts and to share with us.
I'm not a superbriked note owner but I follow with great interest those posts.
Again, thank you, man.

Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Thanks anyway for your efforts!
Sent from my GT-N7000 using Tapatalk 2

Zamboney said:
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Click to expand...
Click to collapse
LOL, you're right, at the end I also thought, that's really simple
but, at least...I had several problems to solve before getting adb up and running properly with root permissions and having the necessary tools at hand (inside adb).
I think this was mainly because I wiped my /system before.
But, it's easy to be wise after the event.

hmm, I tried to export this partition scheme to a PIT file (using heimdall-frontend), but I got a file that is exactly equal to the one I flashed last via Odin, which was Q1_20110914_16GB.pit.
So I assume the PIT file is one way only?
A PIT file would probably allow even unexperienced users to unbrick their phones.

This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Although your post I found easier to read.

[DEV]How to compile TWRP touch recovery

All of TWRP 3.x source is public. You can compile it on your own. This guide isn't going to be a step-by-step, word-for-word type of guide. If you're not familiar with basic Linux commands and/or building in AOSP then you probably won't be able to do this.
You can currently use Omni 6.0, Omni 7.1, Omni 8.1, Omni 9.0, CM 13.0, CM 14.1, CM 15.1, LineageOS 16.0 source code. Omni 9.0 is recommended for now unless your device has a super partition.
If you are using CM/LineageOS, you'll need to place TWRP in the LineageOS/bootable/recovery-twrp folder and set RECOVERY_VARIANT := twrp in your BoardConfig.mk file. TWRP source code can be found here:
https://github.com/TeamWin/android_bootable_recovery (NOTE: The location for the latest TWRP source code has changed!)
Select the newest branch available. This step is not necessary with Omni because Omni already includes TWRP source by default, however, if you are using an older version of Omni, you will probably want to pull from the latest branch (the latest branch will compile successfully in older build trees)
If you are only interested in building TWRP, you may want to try working with a smaller tree. You can try using this manifest. It should work in most cases but there may be some situations where you will need more repos in your tree than this manifest provides:
https://github.com/minimal-manifest-twrp
*BEFORE YOU COMPILE*
Note: If you add or change any flags, you will need to make clean or make clobber before recompiling or your flag changes will not be picked up.
Now that you have the source code, you'll need to set or change a few build flags for your device(s). Find the BoardConfig.mk for your device. The BoardConfig.mk is in your devices/manufacturer/codename folder (e.g. devices/lge/hammerhead/BoardConfig.mk).
Your board config will need to include architecture and platform settings. Usually these are already included if you're using device configs that someone else created, but if you created your own, you may need to add them. Without them, recovery may seg fault during startup and you'll just see the teamwin curtain flash on the screen over and over.
We usually put all of our flags at the bottom of the BoardConfig.mk under a heading of #twrp For all devices you'll need to tell TWRP what theme to use. This TW_THEME flag replaces the older DEVICE_RESOLUTION flag. TWRP now uses scaling to stretch any theme to fit the screen resolution. There are currently 5 settings which are: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi, and watch_mdpi. For portrait, you should probably select the hdpi theme for resolutions of 720x1280 and higher. For landscape devices, use the hdpi theme for 1280x720 or higher.
TW_THEME := portrait_hdpi
Note that themes do not rotate 90 degrees and there currently is no option to rotate a theme. If you find that the touchscreen is rotated relative to the screen, then you can use some flags (discussed later in this guide) to rotate the touch input to match the screen's orientation.
In addition to the resolution, we have the following build flags:
RECOVERY_SDCARD_ON_DATA := true -- this enables proper handling of /data/media on devices that have this folder for storage (most Honeycomb and devices that originally shipped with ICS like Galaxy Nexus) This flag is not required for these types of devices though. If you do not define this flag and also do not include any references to /sdcard, /internal_sd, /internal_sdcard, or /emmc in your fstab, then we will automatically assume that the device is using emulated storage.
BOARD_HAS_NO_REAL_SDCARD := true -- disables things like sdcard partitioning and may save you some space if TWRP isn't fitting in your recovery patition
TW_NO_BATT_PERCENT := true -- disables the display of the battery percentage for devices that don't support it properly
TW_CUSTOM_POWER_BUTTON := 107 -- custom maps the power button for the lockscreen
TW_NO_REBOOT_BOOTLOADER := true -- removes the reboot bootloader button from the reboot menu
TW_NO_REBOOT_RECOVERY := true -- removes the reboot recovery button from the reboot menu
RECOVERY_TOUCHSCREEN_SWAP_XY := true -- swaps the mapping of touches between the X and Y axis
RECOVERY_TOUCHSCREEN_FLIP_Y := true -- flips y axis touchscreen values
RECOVERY_TOUCHSCREEN_FLIP_X := true -- flips x axis touchscreen values
TWRP_EVENT_LOGGING := true -- enables touch event logging to help debug touchscreen issues (don't leave this on for a release - it will fill up your logfile very quickly)
BOARD_HAS_FLIPPED_SCREEN := true -- flips the screen upside down for screens that were mounted upside-down
There are other build flags which you can locate by scanning the Android.mk files in the recovery source. Most of the other build flags are not often used and thus I won't document them all here.
*RECOVERY.FSTAB*
TWRP 2.5 and higher supports some new recovery.fstab features that you can use to extend TWRP's backup/restore capabilities. You do not have to add fstab flags as most partitions are handled automatically.
Note that TWRP only supports v2 fstabs in version 3.2.0 and higher. You will still need to use the "old" format of fstab for older TWRP (example of that format is below), and even TWRP 3.2.0 still supports the v1 format in addition to the v2 format. To maximize TWRP's compatibility with your build tree, you can create a twrp.fstab and use PRODUCT_COPY_FILES to place the file in /etc/twrp.fstab When TWRP boots, if it finds a twrp.fstab in the ramdisk it will rename /etc/recovery.fstab to /etc/recovery.fstab.bak and then rename /etc/twrp.fstab to /etc/recovery.fstab. Effectively this will "replace" the fstab 2 file that your device files are providing with the TWRP fstab allowing you to maintain compatibility within your device files and with other recoveries.
Code:
PRODUCT_COPY_FILES += device/lge/hammerhead/twrp.fstab:recovery/root/etc/twrp.fstab
The fstab in TWRP can contain some "flags" for each partition listed in the fstab.
Here's a sample TWRP fstab for the Galaxy S4 that we will use for reference:
Code:
/boot emmc /dev/block/platform/msm_sdcc.1/by-name/boot
/system ext4 /dev/block/platform/msm_sdcc.1/by-name/system
/data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
/cache ext4 /dev/block/platform/msm_sdcc.1/by-name/cache
/recovery emmc /dev/block/platform/msm_sdcc.1/by-name/recovery
/efs ext4 /dev/block/platform/msm_sdcc.1/by-name/efs flags=display="EFS";backup=1
/external_sd vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 flags=display="Micro SDcard";storage;wipeingui;removable
/usb-otg vfat /dev/block/sda1 /dev/block/sda flags=display="USB-OTG";storage;wipeingui;removable
/preload ext4 /dev/block/platform/msm_sdcc.1/by-name/hidden flags=display="Preload";wipeingui;backup=1
/modem ext4 /dev/block/platform/msm_sdcc.1/by-name/apnhlos
/mdm emmc /dev/block/platform/msm_sdcc.1/by-name/mdm
Flags are added to the end of the partition listing in the fstab separated by white space (spaces or tabs are fine). The flags affect only that partition but not any of the others. Flags are separated by semicolons. If your display name is going to have a space, you must surround the display name with quotes.
Code:
/external_sd vfat /dev/block/mmcblk1p1 flags=display="Micro SDcard";storage;wipeingui;removable
The flags for this partition give it a display name of "Micro SDcard" which is displayed to the user. wipeingui makes this partition available for wiping in the advanced wipe menu. The removable flag indicates that sometimes this partition may not be present preventing mounting errors from being displayed during startup. Here is a full list of flags:
removable -- indicates that the partition may not be present preventing mounting errors from being displayed during boot
storage -- indicates that the partition can be used as storage which makes the partition available as storage for backup, restore, zip installs, etc.
settingsstorage -- only one partition should be set as settings storage, this partition is used as the location for storing TWRP's settings file
canbewiped -- indicates that the partition can be wiped by the back-end system, but may not be listed in the GUI for wiping by the user
userrmrf -- overrides the normal format type of wiping and only allows the partition to be wiped using the rm -rf command
backup= -- must be succeeded by the equals sign, so backup=1 or backup=0, 1 indicates that the partition can be listed in the backup/restore list while 0 ensures that this partition will not show up in the backup list.
wipeingui -- makes the partition show up in the GUI to allow the user to select it for wiping in the advanced wipe menu
wipeduringfactoryreset -- the partition will be wiped during a factory reset
ignoreblkid -- blkid is used to determine what file system is in use by TWRP, this flag will cause TWRP to skip/ignore the results of blkid and use the file system specified in the fstab only
retainlayoutversion -- causes TWRP to retain the .layoutversion file in /data on devices like Sony Xperia S which sort of uses /data/media but still has a separate /sdcard partition
symlink= -- causes TWRP to run an additional mount command when mounting the partition, generally used with /data/media to create /sdcard
display= -- sets a display name for the partition for listing in the GUI
storagename= -- sets a storage name for the partition for listing in the GUI storage list
backupname= -- sets a backup name for the partition for listing in the GUI backup/restore list
length= -- usually used to reserve empty space at the end of the /data partition for storing the decryption key when Android's full device encryption is present, not setting this may lead to the inability to encrypt the device
canencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt the backup of this partition if the user chooses encryption (only applies to tar backups, not images)
userdataencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt only the userdata portion of this partition, certain subfuldes like /data/app would not be encrypted to save time
subpartitionof= -- must be succeeded by the equals sign and the path of the partition it is a subpartition of. A subpartition is treated as "part" of the main partition so for instance, TWRP automatically makes /datadata a subpartition of /data. This means that /datadata will not show up in the GUI listings, but /datadata would be wiped, backed up, restored, mounted, and unmounted anytime those operations are performed on /data. A good example of the use of subpartitions is the 3x efs partitions on the LG Optimus G:
Code:
/efs1 emmc /dev/block/mmcblk0p12 flags=backup=1;display=EFS
/efs2 emmc /dev/block/mmcblk0p13 flags=backup=1;subpartitionof=/efs1
/efs3 emmc /dev/block/mmcblk0p14 flags=backup=1;subpartitionof=/efs1
This lumps all 3 partitions into a single "EFS" entry in the TWRP GUI allowing all three to be backed up and restored together under a single entry.
As of TWRP 3.2.0, TWRP now supports a version 2 fstab like those that have been found in Android devices for years. Yes, I know we're really slow to adopt this one, but I also saw no major advantage to v2 and the v2 fstab was being used in regular Android as well as recovery and I didn't want full ROM builds crashing or doing other weird things because of TWRP flags being present in the fstab. Version 2 fstab support is automatic. You don’t need to add any build flags. The regular version 1 fstab format is also still valid and it’s possible to use both v1 and v2 types in the same fstab. TWRP 3.2.0 also supports using wildcards via the asterisk in v1 format which can be useful for USB OTG and micro SD cards with multiple partitions. Note also that v2 fstab formats haven’t been extensively tested so developers should test their v2 fstabs before shipping to users (you should always be testing anyway!).
This is a v1 fstab line with a wildcard intended for a USB OTG drive. All partitions should show up in the list of available storage devices when the user plugs in a drive:
Code:
/usb-otg vfat /dev/block/sda* flags=removable;storage;display=USB-OTG
This line is straight from the v2 fstab for the same device and also should work. In this case the kernel will notify us that new devices have been added or removed via uevents:
Code:
/devices/soc.0/f9200000.ssusb/f9200000.dwc3/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usb:auto
In addition to the v2 fstab, you can include /etc/twrp.flags which uses the v1 fstab format. The twrp.flags file can be used to supplement the v2 fstab with TWRP flags, additional partitions not included in the v2 fstab, and to override settings in the v2 fstab. For example, I have a Huawei device with the following stock v2 fstab present as /etc/recovery.fstab
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,verify
/dev/block/bootdevice/by-name/cust /cust ext4 ro,barrier=1 wait,verify
/devices/hi_mci.1/mmc_host/mmc1/* auto auto defaults voldmanaged=sdcard:auto,noemulatedsd
/devices/hisi-usb-otg/usb1/* auto auto defaults voldmanaged=usbotg:auto
/dev/block/bootdevice/by-name/userdata /data f2fs nosuid,nodev,noatime,discard,inline_data,inline_xattr wait,forceencrypt=footer,check
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,data=ordered wait,check
/dev/block/bootdevice/by-name/splash2 /splash2 ext4 rw,nosuid,nodev,noatime,data=ordered,context=u:object_r:splash2_data_file:s0 wait,check
/dev/block/bootdevice/by-name/secure_storage /sec_storage ext4 rw,nosuid,nodev,noatime,discard,auto_da_alloc,mblk_io_submit,data=journal,context=u:object_r:teecd_data_file:s0 wait,check
In addition I have also included this in /etc/twrp.flags:
Code:
/boot emmc /dev/block/platform/hi_mci.0/by-name/boot
/recovery emmc /dev/block/platform/hi_mci.0/by-name/recovery flags=backup=1
/cust ext4 /dev/block/platform/hi_mci.0/by-name/cust flags=display="Cust";backup=1
/misc emmc /dev/block/platform/hi_mci.0/by-name/misc
/oeminfo emmc /dev/block/platform/hi_mci.0/by-name/oeminfo flags=display="OEMinfo";backup=1
/data f2fs /dev/block/dm-0
/system_image emmc /dev/block/platform/hi_mci.0/by-name/system
The first 2 lines in twrp.flags adds the boot and recovery partitions which were not present at all in the v2 fstab. The /cust line in the twrp.flags file is added to tell TWRP to allow users to back up the cust partition and to give it a slightly better display name. The /misc partition is also only present in the twrp.flags file. Much like the /cust partition, the /oeminfo partition is in the twrp.flags file to tell TWRP to allow users to back it up and give a display name. The /data line is needed because this Huawei device, like many Huawei devices, is encrypted but the encryption uses some special Huawei binaries and is encrypted with some sort of default password that the user cannot change. We use the Huawei binaries to decrypt the device automatically in recovery. The /data line here tells TWRP to use /dev/block/dm-0 instead of /dev/block/bootdevice/by-name/userdata which is required for proper mounting, etc. Lastly we have the /system_image line so that TWRP will add a system image option for backup and restore.
As we add more new devices, we’ll add more example device trees to https://github.com/TeamWin/ which should help you find more ways to use this new fstab support. Please note that using the v2 fstab format at this point is completely optional, so feel free to continue using v1 if that is what is more comfortable or if you have trouble with the v2 format support.
If you have questions, feel free to stop by #twrp on Freenode. If you post here I may not see it for a while as I have lots of threads out there and there's no way for me to keep track of them all. If you successfully port TWRP to a new device, please let us know! We love to hear success stories!
If you have code changes that you'd like to submit, please submit them through the Omni Gerrit server. Guide is here.
Once you get Omni or CM sync'ed and your TWRP flags set, you should do a source ./build/envsetup.sh We usually lunch for the device in question, so something like "lunch omni_hammerhead-eng".
After you lunch successfully for your device this is the command used for most devices:
Code:
make clean && make -j# recoveryimage
Replace the # with the core count +1, so if you have a dual core it's -j3 and a quad core becomes -j5, etc. If you're dealing with a "typical" Samsung device, then you'll need to
Code:
make -j# bootimage
Most Samsung devices have the recovery included as an extra ramdisk in the boot image instead of a separate recovery partition as found on most other devices.
Old guide here: http://forum.xda-developers.com/showpost.php?p=65482905&postcount=1471

So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with the TWRP app. In order for us to add "official support" for your device we'll need the following:
1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
2) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to the official TWRP app.
Note that we won't take credit for your port. You'll still get to post it on XDA to collect all the credit that goes with releasing something new for your device along with having your name listed on our website as the maintainer for the device. Also note that it's not always possible to provide automated installs for all devices.
You can now boot TWRP in an emulator. If you're trying to help develop TWRP, this can be a huge help as you don't have to risk your device and you can do everything directly on your computer.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Download this set of device configuration files.
Compile a recoveryimage using those device files. In the Android SDK, click on Tools -> Manage AVDs. Click New. Set it up as the following:
AVD Name: TWRP
Device: Galaxy Nexus
Target: ICS or newer though anything will probably work here
CPU: ARM (armeabi-v7a)
Check the box for hardware keyboard (your computer's keyboard will work in TWRP)
Up to you if you want to have the skin with controls present
Front Camera: None
Back Camera: None
RAM: 1024 VM Heap: 64
Internal Storage: 200
SD Card: Size: 500 MiB
Then click OK.
Once you have your AVD and your recoveryimage, you can boot TWRP in the emulator by browsing to your android-sdk/tools folder and run this command:
./emulator -avd TWRP -ramdisk CMFOLDER/out/target/product/twrp/ramdisk-recovery.img
Note that ADB doesn't work right away. About 10 to 15 seconds after TWRP finishes booting, ADB will come online. We start ADB via init.rc so even if TWRP fails to boot due to some kind of code error that you may have made, ADB should still work. Enjoy!

TWRP and A/B devices:
From a TWRP standpoint, A/B devices aren't a whole lot different from regular devices, but developers seem to be shy about working on these devices. I'm going to try to shed some light on this subject and hopefully this will serve as a guide for porting TWRP to A/B devices.
Firstly, let's understand what is an A/B device and how it's different. A/B devices have duplicates of many partitions on the device. An A/B device has 2x system partitions, 2x boot partitions, 2x vendor partitions, 2x modem / firmware partitions, etc. Only one slot is in use at a time. During early boot, the first stages of the bootloader read some small amount of data called the BCB or Bootloader Control Block and decide whether to boot the A partitions or the B partitions. When an OTA update is available, the data from the active slot is copied from the inactive slot and patched / updated. For example, if you're currently on slot A, your device would download the update and copy the existing system partition from slot A and patch / update it with the new updates into slot B. Once the copying and updating is complete, the BCB is updated and the device reboots using slot B. Next time an update is available, the system partition in slot B is copied to slot A and updated, the BCB gets updated, and we reboot to slot A. When viewing partitions on the device, you'll see something like this:
Code:
/dev/block/bootdevice/by-name/boot_a
/dev/block/bootdevice/by-name/boot_b
/dev/block/bootdevice/by-name/system_a
/dev/block/bootdevice/by-name/system_b
/dev/block/bootdevice/by-name/userdata
/dev/block/bootdevice/by-name/vendor_a
/dev/block/bootdevice/by-name/vendor_b
Note the dual boot, system and vendor partitions in the list above, but only one userdata partition.
While there is technically no requirement that I am aware of, all A/B devices shipped thus far have no separate recovery partition. Instead, the boot image contains the recovery in its ramdisk. The important thing is knowing that the boot image now also contains the recovery. For completeness, the system partition is a full root file system. During boot, if the kernel is told to boot to recovery, it will extract the ramdisk in the boot partition. If the kernel is not told by the bootloader to boot to recovery, then the kernel will mount the appropriate system partition (A or B) because the system partition is a full root file system. This means that the system partition on these devices is mounted to / instead of to /system and the system partition contains all of the files that would have normally been in the boot image ramdisk and a /system subfolder.
From a TWRP standpoint, there are 3 things that you have to do for an A/B device. First, you need to set
Code:
AB_OTA_UPDATER := true
in your BoardConfig.mk. Secondly, for any partition that has an A/B option, you need to add
Code:
flags=slotselect
in your fstab so something like this:
Code:
/boot emmc /dev/block/bootdevice/by-name/boot flags=slotselect
/system ext4 /dev/block/bootdevice/by-name/system flags=slotselect
/system_image emmc /dev/block/bootdevice/by-name/system flags=slotselect
/vendor ext4 /dev/block/bootdevice/by-name/vendor flags=slotselect;display="Vendor";backup=1
/vendor_image emmc /dev/block/bootdevice/by-name/vendor flags=slotselect
Lastly, once you get into TWRP, you will probably want to make sure that bootctl hal-info responds correctly with no errors. Usually the bootctl binary requires a proprietary library or even a couple of services to work correctly. If bootctl does not work correctly, then you will not be able to switch slots within TWRP correctly either.
In addition to setting
Code:
AB_OTA_UPDATER := true
you may also want to set:
Code:
BOARD_USES_RECOVERY_AS_BOOT := true
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
If you set
Code:
BOARD_USES_RECOVERY_AS_BOOT := true
then make recoveryimage will no longer work and instead you will have to make bootimage. I don't recommend setting either of these flags for TWRP-only build trees. These flags will probably be required for developers building full ROMs for A/B devices.
Installing / Flashing TWRP on A/B devices:
Since all known A/B devices do not have a separate recovery partition, you will eventually have to flash TWRP to the boot partition. On the Pixel 1 and 2, we use fastboot boot to temporarily boot TWRP without flashing TWRP. We are then supplying a zip to allow users to flash TWRP to both slots. You can download one of these zips from our website and update the zip as needed to support your devices. Eventually we will add tools to TWRP to allow users to flash recoveries on these devices without needing to use zips.
Recently, I worked on the Razer Phone. The Razer Phone unfortunately does not support fastboot boot. Instead, users have to determine their currently active boot slot using
Code:
adb shell getprop ro.boot.slot_suffix
then use
Code:
fastboot --set-active=_a
to switch slots to the inactive slot. From here, the user can
Code:
fastboot flash boot twrp.img && fastboot reboot
to get into TWRP. Once in TWRP they can then go to the reboot page and change back to their originally active slot, make a backup, then install TWRP. Using the inactive slot allows users to get a good, unmodified backup of their device before installing TWRP.
Hopefully this helps!
Debugging with gdb in TWRP guide can be found here!

Beep boop zee doop

I know I've PM'ed you but I would like to ask you again. What should I do after compiling the TWRP recovery binary? What files have to be copied and where? I'm trying to integrate it with an ICS kernel.

Dees_Troy said:
Once you get CM sync'ed, I suggest that you go ahead and compile a build of ClockworkMod (ClockworkMod source is included in the CM repos). We usually lunch for the device in question, so something like "lunch full_tenderloin-eng".
After you lunch successfully for your device this is the command used for most devices:
Code:
make clean && make -j# recoveryimage
Click to expand...
Click to collapse
I don't get this part. What is lunch supposed to be? is it supposed to be a individual command for a device or can I do "lunch full_tenderloin-eng" for all devices? Because I am building for a device that doesn't run Android natively (at least out of-the-box) so cyanogenmod doesn't support it on any way...
Also, can I use this for resistive screens? Just to make sure.
Thanks for the guide, I have been looking for this for a long time

thanks for the guide, well structured and not so complicated
i have only a question: i'm trying to build it for galaxy 5, the problem is that the resolution is 320x240, so can you tip me on modify the sources? (i've done this some days ago, but images were too large)

manuel100 said:
thanks for the guide, well structured and not so complicated
i have only a question: i'm trying to build it for galaxy 5, the problem is that the resolution is 320x240, so can you tip me on modify the sources? (i've done this some days ago, but images were too large)
Click to expand...
Click to collapse
Set the device resolution to 320x240...I'm pretty sure they have support for that resolution...and if they don't then you can copy one of there's except resize it all to 320x240
Edit-they only have 320x480 https://github.com/TeamWin/Team-Win-Recovery-Project/
My question: I built twrp from source a while ago using smasher's Samsung inject twrp zip...that worked fine for a while...but recently we switched to mtd format so that inject twrp zip doesn't work...neither does the inhect twrp button within twrp anymore...I've seen that the galaxy s has the same problem as well...just wondering if you know of a work around...
Sent from my SGH-I997 using Tapatalk 2

mg2195 said:
Set the device resolution to 320x240...I'm pretty sure they have support for that resolution...and if they don't then you can copy one of there's except resize it all to 320x240
Edit-they only have 320x480 https://github.com/TeamWin/Team-Win-Recovery-Project/
My question: I built twrp from source a while ago using smasher's Samsung inject twrp zip...that worked fine for a while...but recently we switched to mtd format so that inject twrp zip doesn't work...neither does the inhect twrp button within twrp anymore...I've seen that the galaxy s has the same problem as well...just wondering if you know of a work around...
Sent from my SGH-I997 using Tapatalk 2
Click to expand...
Click to collapse
thanks for respond, however i've tried resizing images to 320x240 but i don't know what should be the size of bottoms, because they are alway out-of-screen
what is smasher's Samsung inject twrp zip? but i think that the recovery doesn't work because you have to built it with mtd support (for ex. on madteam they are trying to build a mtd kernel, but for install that testing rom they built a special cwm with mtd support)

manuel100 said:
thanks for respond, however i've tried resizing images to 320x240 but i don't know what should be the size of bottoms, because they are alway out-of-screen
what is smasher's Samsung inject twrp zip? but i think that the recovery doesn't work because you have to built it with mtd support (for ex. on madteam they are trying to build a mtd kernel, but for install that testing rom they built a special cwm with mtd support)
Click to expand...
Click to collapse
Smashers inject twrp zip is a tool for Samsung devices that let's you get the recovery without flashing the whole kernel. You basically put the ramdisk-recovery.img in the zip and then flash. During the flash process it pulls the boot.img, replaces the current ramdisk-recovery.img with the new one that contains twrp. It then deletes the old boot.img and flashes the new one...not affecting the actual kernel...
The recovery itself has mtd support...I can use it if I flash the whole boot.img, but I don't want to release the recovery within a whole kernel...because then I have to keep it up to date with both twrp and kernel sources, not to mention the different kernels available for my device....I can't make a recovery for each kernel...don't have the time for that...that's where the inject came in handy....the user could use any kernel he wanted while still using twrp
Recovery logs say it fails to find the ramdisk inside the boot.img and then in parenthesis something about may not be using gzip compression...which it is....
Sent from my SGH-I997 using Tapatalk 2
---------- Post added at 07:21 AM ---------- Previous post was at 07:19 AM ----------
Deestroy did this same tutorial on rootzwiki...if you look at the second post you'll see info about the smasher inject twrp I was referring to...http://rootzwiki.com/index.php?/topic/23903-How-to-Compile-TWRP-from-Source
Sent from my SGH-I997 using Tapatalk 2

mfsr98 said:
I don't get this part. What is lunch supposed to be? is it supposed to be a individual command for a device or can I do "lunch full_tenderloin-eng" for all devices? Because I am building for a device that doesn't run Android natively (at least out of-the-box) so cyanogenmod doesn't support it on any way...
Also, can I use this for resistive screens? Just to make sure.
Thanks for the guide, I have been looking for this for a long time
Click to expand...
Click to collapse
can I get help here please?

mfsr98 said:
can I get help here please?
Click to expand...
Click to collapse
Its a single command...it opens up the menu for devices...just type lunch into the terminal and hit enter...you'll see what I mean. You will probably have to add your device to the menu by creating a vendorsetup.sh in your device repo if it doesn't already exist....
Sent from my SGH-I997 using Tapatalk 2

Thank you for the quick answer. Yes, I already have vendorsetup.sh on the boot.img. Sorry for the noob question

What about for android beginners???

Devarishi said:
What about for android beginners???
Click to expand...
Click to collapse
There's only so much that you can dumb it down and simplify it. There's lots of other guides out there for getting started. Compiling a recovery is not a super simple task that anyone and everyone can do and there's plenty of potential pitfalls including the possibility of bricking your device. If none or very little of this guide makes sense, then you might see if a developer for your device is interested in working on it instead.

how would you compile this for a device without an official cm9 build?

azoller1 said:
how would you compile this for a device without an official cm9 build?
Click to expand...
Click to collapse
Well, you don't need official cm9 if you can find any working device tree for you phone you are good to go.. For lg spectrum 4g, this could be useful.

Hey guys I'm trying to compile this for my phone the problem I'm running into is I need the root.ts I've searched and it doesn't come up with anything any help would be appreciated thanks
Sent from my SAMSUNG-SGH-I577 using xda premium

I have a mtk6577 device which is not in de device tree of CM9.
I can compile CWM for my device with CM9. Because I was only making recovery, there was no need for setting up boardconfig.
In this guide there is a part starting with TARGET_RECOVERY_INITRC which is not there in my boardconfig.
Also is stated:
"Your board config also needs to include architecture and platform settings. Usually these are already included if you're using device configs that someone else created, but if you created your own, you may need to add them. Without them, recovery will often seg fault during startup and you'll just see the teamwin curtain flash on the screen over and over."
Does this mean that I cannot build TWRP without it, even I can build CWM ?

gls9 said:
I have a mtk6577 device which is not in de device tree of CM9.
I can compile CWM for my device with CM9. Because I was only making recovery, there was no need for setting up boardconfig.
In this guide there is a part starting with TARGET_RECOVERY_INITRC which is not there in my boardconfig.
Also is stated:
"Your board config also needs to include architecture and platform settings. Usually these are already included if you're using device configs that someone else created, but if you created your own, you may need to add them. Without them, recovery will often seg fault during startup and you'll just see the teamwin curtain flash on the screen over and over."
Does this mean that I cannot build TWRP without it, even I can build CWM ?
Click to expand...
Click to collapse
Look for another mtk6577 device that has CM & copy the arch flags from it.

[GUIDE]How to extract /system from Samsung S7 OTA/FW in Windows without a Phone

This is a complete working guide on how to extract the /system partition from a Samsung S7 FW/OTA package using Windows (This is the same package one might flash to their phone with ODIN.) You can get this FW/OTA package from sites like Samsung-Firmware.org & SamMobile.com. It is very likely this works (or parts of it duct-taped together ) on other Phone models,etc, but I vouch that this guide works on the Samsung S7. Please chime in if it works on other models & brands!
Intro:
I found a LOT of guides similar to this, but couldn't get any to work with the Samsung S7 packages! And there are MANY different versions of the tools I mention below, many not working! So be sure to use the tool versions I post below. Over much time, it was a tiny step with each new attempt until I finally got it...& wanted to share!
Purpose:
Why would anyone want to do this? If you're reading this thread and don't know the answer to that, then I'm confused But I'll answer anyway - What is the purpose of this thread?
You would want to do this because you're a ROM Developer and don't want to have to go through the time & trouble of installing an OTA, then do a dd/cat to get the system image, etc. (With this method you don't even need a phone, just a PC!)
You are using a custom ROM, but want a stock app; for example the custom ROM you're using has the Google Dialer/Phone app builtin, but you prefer the stock Samsung Phone. Doing the steps outlined here will yield a "system" folder in Windows that you can simply navigate to /system/app or /system/priv-app and copy over the apk to your phone and install it! (via ADB or phone File manager app, etc). Obviously not all apks will work. Or maybe you want the libraries from another phone OTA package in order for an apk to work, and so on...
You are just curious what's in the /system partition for an OTA package!
Tools:
7-Zip
LZ4
simg2img: "Clone or download"->Download ZIP
Ext2Explore (Same as Ext2Read)
Guide:
Download FW/OTA (TMB-G930TUVU4CRI2.zip) from SamMobile website (or whereever)
Use 7zip to extract TMB-G930TUVU4CRI2.zip to a folder
Use 7zip to extract AP_G930TUVU4CRI2*.tar.md5 to a folder (ignore "There is no correct record at end of archive" error)
Use lz4 to extract system.img.ext4.lz4 -> system.img.ext4
lz4 system.img.ext4.lz4​
Extract simg2img_win-master.zip -> \simg2img_win-master\
Copy system.img.ext4 to \simg2img_win-master\ folder
Rename system.img.ext4 -> system.img
Use simg2img_win-master to convert system.img -> system.ext4.img
Double-click convert.bat (or run in cmd prmpt) (This will take a few minutes)​
Create new folder to save contents in, eg: "C:\System"
Use ext2explore to mount system.ext4.img: Open ext2explore->File->Open Image->Select system.ext4.img
Click Save icon->Save to your new folder, eg: "C:\System"
Wait for it to extract. Once complete, enjoy!
Links & Useful Resources:
Tmobile Versions: https://support.t-mobile.com/docs/DOC-30276
Search Keywords:
(This section is here so this thread comes up in searches for the many errors I came across while trying to get this to work in both Windows & Linux. That's right! I tried in both OSs and actually got it to work first in Windows... & yet to get it to work in Linux!)
- losetup /dev/loop2 /media/sf_Share/system.img.ext4 ->warning file does not fit into 512-byte sector; the end of the file will be ignored
- mount /dev/loop2 /mnt/mysystem2 -> mount: /mnt/mysystem2: cant read superblock on /dev/loop2
- mount -t ext4 /media/system.img /mnt/mysystem6 -> wrong fs type, bad option, bad superblock on /dev/loop6, missing codepage or helper program, or other error
fsck /media/system.img -> ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open ...
The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate suberblock: ...

Reserved

Just happened to see this thread.
Dropping in the let you know for linux just do this
Code:
simg2img system.img.ext4 system.img
mkdir system
sudo mount -t ext4 system.img system/
Of course all work is done in the current working directory.
You can just copy whatever you want from this mounted loop device of the system.img or whatever.
This is what i do because it seems to be the fastest in terms of work.
Hope it helps. I prefer all android work on linux

kevin71246 said:
Reserved
Click to expand...
Click to collapse
oh man you saved my day thanks man none of the old method worked but this did wonders

[SOLVED] Restore decrypted nandroid backup of FBE

Tried restoring a nandroid backup of the data partition with twrp.
also copied the /data/media partition back from an external copy.
when booting up the phone immediately reboots back into twrp with an error message:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/vendor'
the vendor partition seems to be intact and i do have a backup of it taken at the same time as the data backup, restoring it doesn't yield results..
i'm wondering if FBE is throwing it off, as the backup was taken when the phone was decrypted (within twrp) however the data on the partitions is referencing some sort of encryption key?

you may also exhibit the following error upon bootup of a restored nandroid backup.
immediately after booting, the phone reboots back into recovery.
viewing the log in twrp will show:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/bootchart'
1. the solution to this is editing fstab.​​under twrp or other recovery​mount /vendor from the mount icon.​​in twrp: Advanced > File Manager > /vendor/etc/fstab.qcom​select edit file under userdata, find where it says fileencryption=ice​rename fileencryption to encryptable.​​Original​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,fileencryption=ice,quota,reservedsize=512M
​​Modified​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=ice,quota,reservedsize=512M
​save file.​
2. next delete the following directories:​
/data/unencrypted
/data/misc/vold/user_keys
3. Lastly delete any of the existing files from /data/system/ :​
locksettings.db
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db-shm
locksettings.db-wal
recoverablekeystore.db
password.key
pattern.key
4. Reboot and re-encrypt​​
At this point rebooting from recovery will result in a running and successfully recovery backup.
one thing to note is the data and data/media partitions are at this point unencrypted
TRYING TO REINCRYPT NOW WILL FAIL to reencrypt got to settings > security > re set your pin or password for the phone
(optional) then select encryption and there will be an orange button to encrypt device.
the encryption process will take quite a while as it will reencrypt your entire phone.
The above doesn't work as it's trying to accomplish FDE, and the fstab line for encryptable=ice, isn't compatible with this.
i could not find an fstab string to follow the same option but for FBE.
​

Thanks for sharing, nice guide to disable forced FBE encryption! I think this applies to Android 12+ in general, not just OnePlus devices.
I ended up with the same problem on my Mi 10 Ultra with MIUI 13 after a /data partition restore and it was a real pain to solve ("set_policy_failed:..." rescue party error for different directories). It's strange though why it fails to set the fscrypt policy for existing directories with no policy, correct permissions and SELinux context...
(Btw: whether a fscrypt policy is applied to a directory ("is this directory encrypted?") can be checked with fscryptpolicyget in terminal.)
Unfortunately, this didn't directly solve my TWRP backup restore problem and I still had to do a manual restore, but now I can at least disable FBE and it's always nice to have actual control over the device you paid money for (you should really have control by default, but oh well...)
(Some of) the troubleshooting I did:
Like I mentioned, I first thought the issue might be with the SE linux context, so I tried running restorecon, but this didn't help - I eventually found that in init.rc, restorecon is usually already automatically run during each boot for directories under /data/... so running it manually makes no difference.
To edit /vendor/etc/fstab.qcom (or /system) on my device, I had to first disable the shared blocks EXT4 optional feature. I followed this nice guide to unpack/repack super.img. But this is missing the step for disabling shared blocks: when I tried to mount any of the unpacked images (e.g. vendor.img) as R/W, it failed with the useless generic error:
wrong fs type, bad option, bad superblock on ...
Click to expand...
Click to collapse
Then dmesg gave me another clue, but at the same time was still cryptic and not immediately helpful:
EXT4-fs (loop*): couldn't mount RDWR because of unsupported optional features (4000)`.
Click to expand...
Click to collapse
So I guess 4000 is the code for shared blocks and you can disable these with e2fsck -E unshare_blocks <your .img file or loop device> (and probably need a filesystem check with e2fsck -yf <file>). Again very annoying that these numerical feature codes are not mentioned anywhere in the e2fsck manual pages for example.
Anyway, I was finally able to either:
1. mount vendor.img on my PC (mount -o loop vendor.img /mnt/vendor) and edit the /mnt/vendor/etc/fstab.qcom right there before repacking the .img and flashing the new edited super.img to my device
or
2. just repacking the vendor.img with shared blocks disabled and size increased (resize2fs vendor.img <new size>) and flashing the new super.img without other modifications - this way /vendor can also be mounted as r/w in Android and changes made later (mount -o remount,rw /vendor).
The worst part is that in the end, even with decryption disabled and the keys deleted, the device still wouldn't boot after a /data restore from TWRP (and after multiple days spent on debugging )... I still had to manually extract the TWRP backup and move directories/files individually - thankfully no issues with app/ or data/ - I think the problem was with some files in either system/ or misc/, but idk for sure. I just manually went through and kept only what seemed important (saved wifi APs, BT devices, SMSs etc, but not saved accounts). And after this it finally booted with all my apps and (most of) my settings!
(Btw2: a TWRP/nandroid backup is apparently just a bunch of separate tar.gz files, not a split archive, so you can just extract them with for file in ../data.f2fs.win*; do echo "extracting $file..."; busybox tar -xzf $file; done)