[OFFICIAL][TWRP][shamrock] TWRP for Android One Third Gen - General Mobile GM 5 Plus ROMs, Kernels, Recoveries

SEE POST 2 FOR ROOT GUIDE​
TRY TO FORMAT YOUR SUPPORTED PARTITIONS IN EXT4 USING TWRP THAT MAKE EXPLOREABLE​
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
{
"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"
}
CHANGELOG for 3.0.2-0:
-Fix a bug with the input box that affected masked inputs (passwords). This fixes decrypt of full device encryption on devices that support decrypt. This bug also impacts encrypted backups. Users are highly encouraged to stop using 3.0.1 if you use encrypted backups or if you need decrypt of data in TWRP.
-Add Greek translation to some builds.
CHANGELOG for 3.0.1-0:
-support new CM 13.0 pattern encryption (sultanqasim)
-fix slow flashing issue due to modprobe (present on only some devices) (#twrp)
-libtar updated to latest upstream and fixes (jcadduono)
-fixes for loading custom themes (_that)
-TWRP will now detect and install TWRP themes automatically through the normal zip install process (Dees_Troy)
-translation updates - added Italian, Czech and Polish and significant updates to Dutch
-progress bar improvements - progress bar updates during image flashing and better tracks progress during file system backups (tar) (Dees_Troy)
-fix input box text display (Dees_Troy)
-reboot option after zip install complete (bigbiff)
-other mostly invisible bug fixes and improvements
CHANGELOG for 3.0.0-0:
-Completely new theme - Much more modern and much nicer looking (by z31s1g)
-True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
-Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
-Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
-Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
-Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
-SuperSU prompt will no longer display if a Marshmallow ROM is installed
-Update exfat, exfat fuse, dosfstools (by mdmower)
-Update AOSP base to 6.0
-A huge laundry list of other minor fixes and tweaks
WARNING: This is our first release in a long time. We have a lot of new and somewhat aggressive changes in this new release. The changes to the graphics back-end may cause some devices to not boot up properly or have other display-related issues. If you are not in a position to reflash an older build of TWRP, then wait until you are or at least wait until others have tried the new version for your specific device. You don’t want to end up with a non-working recovery and have to wait several hours or days to get to a computer to be able to fix it.
Notes for themers: In addition to the udpated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
CHANGELOG for 2.8.7.0:
-Initial ground work for software drawn keyboard (_that)
-Fix handling of wiping internal storage on datamedia devices (xuefer)
-Allow DataManager to set and read values from the system properties (xuefer)
-Fix crash when taking screenshots on arm64 devices (xuefer)
-Fix error message after an ORS script completes (Dees_Troy)
-Fix crashes / error when creating encrypted backups (_that, Dees_Troy)
-Add system read only option – more details below (Dees_Troy)
-Add resize2fs and GUI option to run resize2fs (Dees_Troy)
-Fix crash loop caused by empty lines in AOSP recovery command file (_that)
-Prevent duplicate page overlays such as multiple lock screens (mdmower)
Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
This new version also marks our first set of full builds using our new jenkins build server. You can track the progress of builds at https://jenkins.twrp.me and we have taken additional steps to make it easier for device maintainers to step up and submit patches to our gerrit server at https://gerrit.twrp.me to help us keep devices up to date and working.
DOWNLOAD:
Most devices can be updated quickly and easily within TWRP if you already have version 2.8.4.0 or higher installed
1) Download the latest version from our website on your device
2) Reboot to TWRP
3) Hit Install and tap the "Images..." button in the lower right
4) Browse to the location of the TWRP image on your device and select it
5) Select recovery from the partition list and swipe to flash
OR:
You can find more information and download links on our website.
OR:
BUGS:
If you have found a bug, please consider posting it to our [URL="https://github.com/TeamWin/Team-Win-Recovery-Project/issues"]github issues log. It's pretty much impossible for us to keep up with the more than 40 threads that we have for the devices that we "directly" support. If you have a significant problem that cannot be answered in this thread, your best bet is to PM me directly, contact us via our website, or find us in our IRC channel below. If you see someone that's struggling, feel free to point it out to us. We need your help to help us keep track of all of our devices! Thanks!
SUPPORT:
Live support is available via #twrp on Freenode with your IRC client or just click this link.
Credits:
@Equal1zer
XDA:DevDB Information
[OFFICIAL][TWRP][shamrock] TWRP for Android One Third Gen, Tool/Utility for the General Mobile GM 5 Plus
Contributors
HostZero
Source Code: https://github.com/TeamWin/android_device_google_shamrock/tree/android-6.0
Version Information
Status: Testing
Created 2016-06-23
Last Updated 2016-08-04

Reserved
UNLOCK BOOTLOADER and Flash SuperSU
1. Setup ADB and Fastboot.
2. Install UNIVERSAL ADB drivers:
3. Connect your device and authorize it.
4.
Code:
adb reboot bootloader
fastboot oem unlock
fastboot erase userdata
fastboot reboot
5. Install TWRP as explained on #1st Post
6. Download supersu.zip and Copy the zip file to SDCARD.
supersu.zip
7.
Code:
adb reboot recovery
8. Go to Install>>Select SDCARD>>Select download SuperSU.zip
9. Select FLASH (If TWRP Asks for Flash SuperSU Select No)
10. Done! Reboot System Now.

Reserved

Managed to get root!

Equal1zer said:
Managed to get root!
Click to expand...
Click to collapse
Great Hope you enjoy it!

Equal1zer said:
Managed to get root!
Click to expand...
Click to collapse
As you have got the root. can you provide me the System and Boot partition backup.
The STOCK ROM by other person is unpackable its corrupted sparse format. Please if possible provide me it. And upload on a good server like AFH or DropBox.

HostZero said:
As you have got the root. can you provide me the System and Boot partition backup.
The STOCK ROM by other person is unpackable its corrupted sparse format. Please if possible provide me it. And upload on a good server like AFH or DropBox.
Click to expand...
Click to collapse
This is the boot partition. Dumped using dd
https://www.dropbox.com/s/88iqg3haa1rjgkq/boot.img?dl=0
Uploading system.img at the moment, will add the link once upload is done.
Edit: System.img. dumped using dd again.
https://www.dropbox.com/s/x6nrjs11cz6018r/system.img?dl=0
This is the partition table in case anyone need it. (i.e. you can backup your recovery, boot or system partition )
Code:
DDR -> /dev/block/mmcblk0p10
aboot -> /dev/block/mmcblk0p14
abootbak -> /dev/block/mmcblk0p15
apdp -> /dev/block/mmcblk0p44
boot -> /dev/block/mmcblk0p16
cache -> /dev/block/mmcblk0p33
cmnlib -> /dev/block/mmcblk0p23
cmnlibbak -> /dev/block/mmcblk0p25
devcfg -> /dev/block/mmcblk0p39
devinfo -> /dev/block/mmcblk0p17
dip -> /dev/block/mmcblk0p40
dpo -> /dev/block/mmcblk0p46
dsp -> /dev/block/mmcblk0p30
frp -> /dev/block/mmcblk0p37
fsc -> /dev/block/mmcblk0p28
fsg -> /dev/block/mmcblk0p11
hyp -> /dev/block/mmcblk0p8
hypbak -> /dev/block/mmcblk0p9
keymaster -> /dev/block/mmcblk0p24
keymasterbak -> /dev/block/mmcblk0p26
keystore -> /dev/block/mmcblk0p36
limits -> /dev/block/mmcblk0p22
mcfg -> /dev/block/mmcblk0p43
mdtp -> /dev/block/mmcblk0p41
metadata -> /dev/block/mmcblk0p47
misc -> /dev/block/mmcblk0p35
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p31
modemst2 -> /dev/block/mmcblk0p32
mota -> /dev/block/mmcblk0p38
msadp -> /dev/block/mmcblk0p45
odm -> /dev/block/mmcblk0p20
oem -> /dev/block/mmcblk0p19
persist -> /dev/block/mmcblk0p34
recovery -> /dev/block/mmcblk0p27
rpm -> /dev/block/mmcblk0p4
rpmbak -> /dev/block/mmcblk0p5
sbl1 -> /dev/block/mmcblk0p2
sbl1bak -> /dev/block/mmcblk0p3
sec -> /dev/block/mmcblk0p12
splash -> /dev/block/mmcblk0p13
ssd -> /dev/block/mmcblk0p29
syscfg -> /dev/block/mmcblk0p42
system -> /dev/block/mmcblk0p18
tz -> /dev/block/mmcblk0p6
tzbak -> /dev/block/mmcblk0p7
userdata -> /dev/block/mmcblk0p48
vendor -> /dev/block/mmcblk0p21

Equal1zer said:
This is the boot partition. Dumped using dd
https://www.dropbox.com/s/88iqg3haa1rjgkq/boot.img?dl=0
Uploading system.img at the moment, will add the link once upload is done.
This is the partition table in case anyone need it. (i.e. you can backup your recovery, boot or system partition )
Code:
DDR -> /dev/block/mmcblk0p10
aboot -> /dev/block/mmcblk0p14
abootbak -> /dev/block/mmcblk0p15
apdp -> /dev/block/mmcblk0p44
boot -> /dev/block/mmcblk0p16
cache -> /dev/block/mmcblk0p33
cmnlib -> /dev/block/mmcblk0p23
cmnlibbak -> /dev/block/mmcblk0p25
devcfg -> /dev/block/mmcblk0p39
devinfo -> /dev/block/mmcblk0p17
dip -> /dev/block/mmcblk0p40
dpo -> /dev/block/mmcblk0p46
dsp -> /dev/block/mmcblk0p30
frp -> /dev/block/mmcblk0p37
fsc -> /dev/block/mmcblk0p28
fsg -> /dev/block/mmcblk0p11
hyp -> /dev/block/mmcblk0p8
hypbak -> /dev/block/mmcblk0p9
keymaster -> /dev/block/mmcblk0p24
keymasterbak -> /dev/block/mmcblk0p26
keystore -> /dev/block/mmcblk0p36
limits -> /dev/block/mmcblk0p22
mcfg -> /dev/block/mmcblk0p43
mdtp -> /dev/block/mmcblk0p41
metadata -> /dev/block/mmcblk0p47
misc -> /dev/block/mmcblk0p35
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p31
modemst2 -> /dev/block/mmcblk0p32
mota -> /dev/block/mmcblk0p38
msadp -> /dev/block/mmcblk0p45
odm -> /dev/block/mmcblk0p20
oem -> /dev/block/mmcblk0p19
persist -> /dev/block/mmcblk0p34
recovery -> /dev/block/mmcblk0p27
rpm -> /dev/block/mmcblk0p4
rpmbak -> /dev/block/mmcblk0p5
sbl1 -> /dev/block/mmcblk0p2
sbl1bak -> /dev/block/mmcblk0p3
sec -> /dev/block/mmcblk0p12
splash -> /dev/block/mmcblk0p13
ssd -> /dev/block/mmcblk0p29
syscfg -> /dev/block/mmcblk0p42
system -> /dev/block/mmcblk0p18
tz -> /dev/block/mmcblk0p6
tzbak -> /dev/block/mmcblk0p7
userdata -> /dev/block/mmcblk0p48
vendor -> /dev/block/mmcblk0p21
Click to expand...
Click to collapse
Can I Salute You? Once I receive system.img I will make device and vendor blobs.

HostZero said:
Can I Salute You? Once I receive system.img I will make device and vendor blobs.
Click to expand...
Click to collapse
I edited my post and added system.img. Have fun! Thanks for your efforts btw!

Equal1zer said:
I edited my post and added system.img. Have fun! Thanks for your efforts btw!
Click to expand...
Click to collapse
Worst Senerios.
Instead can you provide TWRP backup as i have request in #4 post.
please take a complete TWRP backup and provide. That will even help in getting noticed of blocks.

HostZero said:
Worst Senerios.
Instead can you provide TWRP backup as i have request in #4 post.
please take a complete TWRP backup and provide. That will even help in getting noticed of blocks.
Click to expand...
Click to collapse
Ok did it, uploading now.
@HostZero here you go: https://www.dropbox.com/sh/dre5a88hwmwxd3a/AADz1krTHRZP0VI1mlpZOIVya?dl=0

Equal1zer said:
Ok did it, uploading now.
Click to expand...
Click to collapse
Thx.

Good work bro, will you buy gm 5 plus?

Thank you @HostZero. I am glad that prepare device and twrp source . But are you ask a question ?. How do you not vendor with compile twrp ?. I want compiled from source. Is there a manifest file from source ?

kaankulahli said:
Thank you @HostZero. I am glad that prepare device and twrp source . But are you ask a question ?. How do you not vendor with compile twrp ?. I want compiled from source. Is there a manifest file from source ?
Click to expand...
Click to collapse
Sir,
For Compiling TWRP we don't need source.
Where as We need to prepare a device tree with prebuilt kernel for that. I have mentioned source link in main OP.
I going to bring even CM13.0 for your device. no issues.

RealSchule said:
Good work bro, will you buy gm 5 plus?
Click to expand...
Click to collapse
Not sure. But I love Android One. I would better bring some development.
Anyways,
We are step behind for OFFICIAL for A1-3rd Gen.
build.twrp.me/twrp/twrp-3.0.2-0-shamrock.img
Source has been forked to TeamWin
github.com/TeamWin/android_device_google_shamrock/tree/android-6.0

Equal1zer said:
Ok did it, uploading now.
@HostZero here you go: https://www.dropbox.com/sh/dre5a88hwmwxd3a/AADz1krTHRZP0VI1mlpZOIVya?dl=0
Click to expand...
Click to collapse
NOW MY DATA IS DONE! Lol Not able to download.
Anyways i will download the file on July1

phone diag port code ?

AmedLatent said:
phone diag port code ?
Click to expand...
Click to collapse
Diag Port Code?
I didn't get you. Please explain properly what you want to.

modemst1 -> /dev/block/mmcblk0p31
modemst2 -> /dev/block/mmcblk0p32
fsg -> /dev/block/mmcblk0p11
reset imei repair

Related

[CLOSED][APP][2.1+] DiskInfo

DiskInfo lists all partitions and all mount points on you device showing disk usage and very detailed partition information. It can also display total and available memory (RAM) and Swap (e.g. zRam).
It supports:
mounted and unmounted partitions,
device-mapper / loop partitions,
LVM partitions (DiskInfo PRO)
temporary mount points
* UBIFS (beta)
For each partition, you can display the following information:
total size, used and free space
partition name, partition alias, partition type, partition number
device name and type
block size
mounted file system type (also for FUSE in DiskInfo PRO), mount paths, mount type (ro/rw)
logical volume group and attributes (DiskInfo PRO)
All shown in clean, human readable format.
Root access is NOT required.
Download:
https://play.google.com/store/apps/details?id=me.kuder.diskinfo&hl=en
Screenshots:
Change log:
Code:
4.5.3 (11/09/2014)
+ Initial UBIFS support
* Bug fixes
4.5.2 (07/28/2014)
* Bug fixes
4.5.1 (07/26/2014)
* Fixed bug with sd cards on some kitkat devices
* Other small bug fixes
4.5 (05/26/2014)
+ Italian translation (credits: bovirus)
4.4.2 (05/12/2014)
* Bug fixes
4.4.1 (05/07/2014)
* Bug fixes
4.4 (04/22/2014)
+ Details for SWAP - swappiness, dirty ratios, etc.
* Fixed issue with missing internal partitions on some devices
* Other small fixes
4.3.4 (24/1/2014)
* PRO: Fixed issue with SDcard missing in widget config (xperia z)
* Fixed issue with 'unkown size' on some devices
* Other small fixes
4.3.3 (17/10/2013)
* Small optimizations for tablets (e.g. added size in bytes)
4.3.2 (14/10/2013)
* Small bug fixes
4.3.1 (10/4/2013)
* Fix FC
4.3 (10/3/2013)
+ PRO: Support for root mounts (i.e. StickMount USB devices)
+ PRO: Swap can now be displayed in a widget
+ Better handling of partition nicknames and labels (aka aliases)
* PRO: Fixed issue with widget size on some devices
* Several small fixes
4.2 (9/2/2013)
+ PRO: Added more details (vendor, model for USB devices; manf. date, CSD, CID, OEM ID, manf. ID, revisions and serial numbers for SD cards)
* Fixed issue with duplicated settings
* Fixed issue with partition labels not showing on some devices (thanks sordna!)
* Fixed issue with duplicated device names
* Partition labels are now case sensitive
* Compact Mode: Free percentage now better visible
* Small tweaks here and there...
4.1 (8/22/2013)
+ Better support for partition labels (thanks sordna!)
+ Multiple swap partitions are now supported and marked in the list view
* Performance tweaks
4.0 (8/4/2013)
+ DiskInfo PRO now available (home screen widgets, compact mode, LVM support)
+ MicroSD/USB/ExternalSD support (Asus Inifinity)
* Performance tweaks
* UI tweaks (new pie chart, new font, new animations, etc.)
* Many small enhancements
3.1
+ Added ability to show device type (NAND, SD, MMC. etc..)
* Fixed issue with missing partitions on LG and Samsung devices
* Fixed issue with boot0 and boot1 partitions
* Better support for partition aliases
3.0.2
* Fixed issue with ExtSdCard on some devices
3.0.1
* Reduced apk size
3.0
+ Rewritten mechanism to get list of partitions and mount points:
+ Partitions categorized by device (Internal, SD card, etc.)
+ List both mounted and unmounted partitions
+ List multiple mounts per single partition - no more duplicated entries
+ List device-mapper / loop partitions
+ List temporary file systems
+ New, more accurate mechanism to get available memory
+ New UI
+ Tablet mode
+ New details view with pie chart
+ many, many more...
2.2 08/27/2012
+ Amount of Swap memory is now displayed in the memory section (only if it is present)
2.1.3 08/17/2012
+ Size is displayed using floating-point numbers
2.1.2: 7/31/2012
* Fixed issue with free RAM calculation
2.1.1: 7/31/2012
* Fixed issue with Gingerbread devices
2.1: 7/30/2012
+ More details for each partition (file system type, mount type)
+ New window for details
* Fixed issue with SD-ext partition not displaying on some devices.
* Fixed issue with mount points not displaying on some devices.
XDA:DevDB Information
DiskInfo, App for the Apps & Games
Contributors
M.Q.
Version Information
Status: Stable
Current Stable Version: 4.9.1
Stable Release Date: 2015-10-05
Created 2014-11-09
Last Updated 2015-10-09
Hey i tesred the app.. some info what it gave me were not correct like the sd card free space left and ram used.
Sent from my LG-E730 using Tapatalk 2
.xxx. said:
Hey i tesred the app.. some info what it gave me were not correct like the sd card free space left and ram used.
Sent from my LG-E730 using Tapatalk 2
Click to expand...
Click to collapse
Thanks for testing it!
Can you please provide me more details so that I can investigate the issue? What does DiskInfo show for your SD-card and what is the real free space? How did you measured your real free space?
Sqter said:
Thanks for testing it!
Can you please provide me more details so that I can investigate the issue? What does DiskInfo show for your SD-card and what is the real free space? How did you measured your real free space?
Click to expand...
Click to collapse
My real free space was 2.9 gb amd it showed 2 gb free.. about ram at first it showed 2mb used xD dunno why then i restarted the app and it corrextly showed that arpund 100mbs were used.
Sent from my LG-E730 using Tapatalk 2
I have downloaded and tested it
Simple and light app, nice!
All infos are similiar to link2sd
But I don't understand about RAM indicator, it showed 54mb
Is it right?
Sent from hell using Tapatalk 2
.xxx. said:
My real free space was 2.9 gb amd it showed 2 gb free.. about ram at first it showed 2mb used xD dunno why then i restarted the app and it corrextly showed that arpund 100mbs were used.
Click to expand...
Click to collapse
You are right, there was a problem with my free RAM calculation - I have fixed it already and republished the app (it may take up to few hours to update it on Play store).
Regarding 2.9 gb vs. 2 gb, it may be because currently the app displays only integer numbers - I will look into this.
.xxx. said:
My real free space was 2.9 gb amd it showed 2 gb free..
Click to expand...
Click to collapse
It has been fixed in newest version (2.1.3). Now you shall see 2.9 GB.
New version is available - amount of total and used Swap memory is now displayed in the memory section (only if it is present). It has been tested with HD2 zRam enabled but it should work on other devices as well.
Major update available. See first post for change log.
Please report if you find any issues.
Sent from my Nexus 7 using Tapatalk HD
I liked the new update.. kinda shows quite a lot of info.. thanks..
Sent from my GT-I9300 using Tapatalk 2
I have some problem after update.. My primary partition external sd (storage/ExtSdCard) don't detected after second partition (data/sdext2) mounted.. Only second partition listed..
Sent from my GT-I9070 (Galaxy S Advance) using xda premium
mawahib.anang said:
I have some problem after update.. My primary partition external sd (storage/ExtSdCard) don't detected after second partition (data/sdext2) mounted.. Only second partition listed..
Sent from my GT-I9070 (Galaxy S Advance) using xda premium
Click to expand...
Click to collapse
New update is available. Please let me know if the problem is fixed.
version 4.0.1
New update is available - https://play.google.com/store/apps/details?id=me.kuder.diskinfo
I hope you like it and find it useful.
Changelog for version 4.0:
Code:
+ DiskInfo PRO now available (home screen widgets, compact mode, LVM support)
+ MicroSD/USB/ExternalSD support (Asus Inifinity)
* Performance tweaks
* UI tweaks (new pie chart, new font, new animations, etc.)
* Many small enhancements
identify boot, recovery, bootloader, etc partitions
M.Q. said:
New update is available - https://play.google.com/store/apps/details?id=me.kuder.diskinfo
I hope you like it and find it useful.
Click to expand...
Click to collapse
Hi, nice app! However I noticed it doesn't identify partitions such as boot and recovery partitions. It shows mmcblk0p6 and mmcblk0p7 if I choose to display unmounted partitions but without any label or indication that they are boot and recovery... such partitions are pretty important, and other apps like .img flashers, and recoveries like CWM, TWRP, identify them just fine.
Your app should be able to find such partitions by looking at "by-name" directory, for example on my Nexus 4 I can do this:
ls -l /dev/block/platform/msm_sdcc.1/by-name/boot
lrwxrwxrwx root root 2013-08-17 22:50 boot -> /dev/block/mmcblk0p6
ls -l /dev/block/platform/msm_sdcc.1/by-name/recovery
lrwxrwxrwx root root 2013-08-17 22:50 recovery -> /dev/block/mmcblk0p7
There are other noteworthy partitions, for bootloader, etc, here is the full list, can your app be enhanced to identify and display the important ones with their appropriate designation ?
thanks in advance!
Code:
lrwxrwxrwx root root 2013-08-17 22:50 DDR -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2013-08-17 22:50 aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2013-08-17 22:50 abootb -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2013-08-17 22:50 boot -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-08-17 22:50 cache -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2013-08-17 22:50 grow -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2013-08-17 22:50 m9kefs1 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-08-17 22:50 m9kefs2 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-08-17 22:50 m9kefs3 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2013-08-17 22:50 metadata -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2013-08-17 22:50 misc -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2013-08-17 22:50 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-08-17 22:50 persist -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2013-08-17 22:50 recovery -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2013-08-17 22:50 rpm -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2013-08-17 22:50 rpmb -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2013-08-17 22:50 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-08-17 22:50 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-08-17 22:50 sbl2b -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2013-08-17 22:50 sbl3 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-08-17 22:50 sbl3b -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2013-08-17 22:50 system -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2013-08-17 22:50 tz -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-08-17 22:50 tzb -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2013-08-17 22:50 userdata -> /dev/block/mmcblk0p23
Thanks for the useful tip. I will add ability to read the "by-name" directory. Stay tuned!
Sent from my Nexus 7 using Tapatalk 4
M.Q. said:
Thanks for the useful tip. I will add ability to read the "by-name" directory. Stay tuned!
Sent from my Nexus 7 using Tapatalk 4
Click to expand...
Click to collapse
thanks! Only problem is that the platform driver has different name from device to device, not sure what is the best way to determine it, but from what I have seen from the different android devices I have, they only have 1 entry in /dev/block/platform/ so I can:
cd /dev/block/platform/*/by-name
when I'm poking around, but I'm not sure if there might exist any devices with more than 1 entry.
Some related info here:
https://git.linaro.org/gitweb?p=and...it;h=b0ab94b7d5a888f0b6920b156e5c6a075fa0741a
sordna said:
thanks! Only problem is that the platform driver has different name from device to device, not sure what is the best way to determine it, but from what I have seen from the different android devices I have, they only have 1 entry in /dev/block/platform/ so I can:
cd /dev/block/platform/*/by-name
when I'm poking around, but I'm not sure if there might exist any devices with more than 1 entry.
Some related info here:
https://git.linaro.org/gitweb?p=and...it;h=b0ab94b7d5a888f0b6920b156e5c6a075fa0741a
Click to expand...
Click to collapse
Yes. I'm aware of the different directories on different devices. Some of them even have the labels symlinks directly in the /dev/block directory. And some (e.g. CyanogenMod) do not have by-name directory at all.
Anyway, thanks for the information.
I have published a new version to the Play store. It shall be available in few hours. It has the by-name labels implemented, so please report if it works on your device.
Thanks!
M.Q. said:
Yes. I'm aware of the different directories on different devices. Some of them even have the labels symlinks directly in the /dev/block directory. And some (e.g. CyanogenMod) do not have by-name directory at all.
Anyway, thanks for the information.
I have published a new version to the Play store. It shall be available in few hours. It has the by-name labels implemented, so please report if it works on your device.
Click to expand...
Click to collapse
I'm out of THANKS presses for the day, will push the button tomorrow, but thank you, it works! Your app has now multiplied it's usefuleness! I really like the fact you separately list aliases from mount points, since they can be different, like the "modem" alias of my partition is mounted as /firmware
I noticed one peculiar thing though, the cache, system, and data aliases are displayed capitalized (Cache, System, Data) why is that?
Shouldn't the alias be displayed in the same name and case as the symlink file in the by-name directory ?
All I can say is wow. I love this little app.
Nice and useful. I went ahead and made a modification to your icon
NEW Icon: https://docs.google.com/file/d/0Byxlw5J4qbOvRmJiLUtaaFRFb2s/edit?usp=sharing
Let me know if you like it. keep up the good work! :good:
SystemErrorOne said:
All I can say is wow. I love this little app.
Nice and useful. I went ahead and made a modification to your icon
NEW Icon: https://docs.google.com/file/d/0Byxlw5J4qbOvRmJiLUtaaFRFb2s/edit?usp=sharing
Let me know if you like it. keep up the good work! :good:
Click to expand...
Click to collapse
Thanks for the icon! I like it. I'll consider changing it in future but for now I'll stick to the current one.

[Q] Recovery can't properly access /data - WTF?

Hi all,
I don't remember when it started, but recently my Photon's recovery has been acting strange when accessing /data partition. I'm now using official TWRP 2.7.0.1, and the recovery "hot reboots" itself when wiping /data, effectively making it unable to restore backups (because to restore the /data partition it has to be wiped first). I tried an older version of CWM (6.0.1.2), and it "wipes" /data in a blink of an eye, which only means it didn't wipe successfully at all.
For reference sake, I can still use my phone normally. I can install apps, restore app backups, or even directly create/delete files in /data partition once I'm booted into Android, so the problem is only limited to recovery. I even tried RSD-ing back to stock and then start all over, but still no dice.
Any ideas would be welcome. If I need to grab any logs, please tell me which and how.
AndyYan said:
Hi all,
I don't remember when it started, but recently my Photon's recovery has been acting strange when accessing /data partition. I'm now using official TWRP 2.7.0.1, and the recovery "hot reboots" itself when wiping /data, effectively making it unable to restore backups (because to restore the /data partition it has to be wiped first). I tried an older version of CWM (6.0.1.2), and it "wipes" /data in a blink of an eye, which only means it didn't wipe successfully at all.
For reference sake, I can still use my phone normally. I can install apps, restore app backups, or even directly create/delete files in /data partition once I'm booted into Android, so the problem is only limited to recovery. I even tried RSD-ing back to stock and then start all over, but still no dice.
Any ideas would be welcome. If I need to grab any logs, please tell me which and how.
Click to expand...
Click to collapse
Recovery logs are stored in /cache/recovery .
kabaldan said:
Recovery logs are stored in /cache/recovery .
Click to expand...
Click to collapse
For TWRP, I thought it was just /tmp/recovery.log...
But either way, can you post a log from recovery after attempting to wipe?
I had something similiar when I wanted to restore a nandroid from my sdcard with TWRP (earlier, about a year ago).
At the end I chose to backup and restore on the internal sd (/data/media) instead of the external sd.
I am not sure if it was the sdcard but this solved my backup problems with TWRP.
Since then I always first backup to internal sd and then copy it to the external one.
I could not read if the problem comes by just wiping /data or while restoring a backup (which should first wipe a backup).
kabaldan said:
Recovery logs are stored in /cache/recovery .
Click to expand...
Click to collapse
Here is the last_log from TWRP 2.7.0.1: http://d-h.st/TKb . These 2 parts grabbed my attention:
Code:
I:Mount: Unable to find partition for path '/data'
and
Code:
I:wipe list '/data;'
I:wipe_path '/data'
Wiping data without wiping /data/media ...
[STRIKE]I:Unable to unlink '/data/bugreports'[/STRIKE]
I:Fixing /data/media/0 contexts
...What's that "/data/bugreports" all about?
And here's the last_log from CWM 6.0.4.8 (I built it via ClockworkMod Builder myself): http://d-h.st/zvK . These:
Code:
-- Wiping data...
Formatting /data...
I:Formatting unknown device.
rm: can't remove '.' or '..'
rm: can't remove '.' or '..'
Something even more strange is, although TWRP "hot reboots" / CWM "fast skips" when wiping /data, /data gets wiped anyways.
Loader009 said:
I could not read if the problem comes by just wiping /data or while restoring a backup (which should first wipe a backup).
Click to expand...
Click to collapse
Hmm, my problem can be triggered simply by attempting to wipe /data, so I'm pretty sure this is not relevant to my SD. For verification, I ejected my SD before booting into recovery, and attempted another /data wipe, which still "hot rebooted" my recovery.
AndyYan said:
Hmm, my problem can be triggered simply by attempting to wipe /data, so I'm pretty sure this is not relevant to my SD. For verification, I ejected my SD before booting into recovery, and attempted another /data wipe, which still "hot rebooted" my recovery.
Click to expand...
Click to collapse
Probably I'm talking about another problem.
Sorry, I was not sure and noticed my problem to be on the safe side.
Loader009 said:
Probably I'm talking about another problem.
Sorry, I was not sure and noticed my problem to be on the safe side.
Click to expand...
Click to collapse
I'm not sure if you're familiar with linux at all. But there's a simple fix to this solution. I had the same problem when I was using CM7 with my second OG Droid. But basically you use the following commands. If it's a problem with wiping the /Data clean out, and then rebuilding from a previous backup where the /Data directory is in tact, this is what you do. (WARNING! IF YOU ARE NOT COMFORTABLE ISSUING THESE COMMANDS, THEN DON'T.)
open up cmd prompt
Click to expand...
Click to collapse
navigate to your adb folder where the actual adb.exe file is located. Then make sure your phone is booted into recovery.
adb shell
Click to expand...
Click to collapse
that will put you in a linux environment while your phone is in recovery
ls
Click to expand...
Click to collapse
that will list all directories and files in the root of your phone make sure there is a directory called data. as long as there is, do the following.
rmdir data
Click to expand...
Click to collapse
that will delete the entire current /data structure on your phone. If you don't feel safe doing this, then don't. From there just do the recovery again.
ENJOY!
dslinfreak said:
I'm not sure if you're familiar with linux at all. But there's a simple fix to this solution. I had the same problem when I was using CM7 with my second OG Droid. But basically you use the following commands. If it's a problem with wiping the /Data clean out, and then rebuilding from a previous backup where the /Data directory is in tact, this is what you do. (WARNING! IF YOU ARE NOT COMFORTABLE ISSUING THESE COMMANDS, THEN DON'T.)
navigate to your adb folder where the actual adb.exe file is located. Then make sure your phone is booted into recovery.
that will put you in a linux environment while your phone is in recovery
that will list all directories and files in the root of your phone make sure there is a directory called data. as long as there is, do the following.
that will delete the entire current /data structure on your phone. If you don't feel safe doing this, then don't. From there just do the recovery again.
ENJOY!
Click to expand...
Click to collapse
You really sure this could deal with my issue, since you're replying to HIM instead of ME in MY question post?
EDIT: I actually risked my phone and attempted this - I think I already know ADB commands pretty well - and although /data is totally deleted, after a reboot to recovery, wiping /data still causes "hot reboot".
AND the actions also totally wiped my internal storage (because internal storage is /data/media and deleting /data also deleted it)! Thank god I don't have anything important in there...
Sent from Google Nexus 4 @ CM11
Yes, that's what I was thinking after reading his post.
It is also a little bit different problem than the one discussed here.
In your case AndyYan I simply would flash a stock ROM with RSDLite and then redo the flash recovery and ROM steps.
Because your data is already lost, this might be the fastest way.
But this way we wouldn't figure out what the current problem is. It's your choice since I don't know how fast you need the phone. I don't know if you are able to get a shell (with OpenRecovery you surely are) but what do you get if you enter "mount"? (Search for a line with /data)
With "mount" you'll get plenty of lines so it might be better to do it on the PC with "adb shell mount".
edit: With mount you get only the mounted partitions. I forgot that nothing of that is mounted. Theoretically we should be able to mount the data partition manually and format it with the right filesystem...
But I really don't know what might break, what happens to the media folder and other soft-/hardlinks.
Loader009 said:
flash a stock ROM with RSDLite and then redo the flash recovery and ROM steps.
Because your data is already lost, this might be the fastest way.
But this way we wouldn't figure out what the current problem is. It's your choice since I don't know how fast you need the phone. I don't know if you are able to get a shell (with OpenRecovery you surely are) but what do you get if you enter "mount"? (Search for a line with /data)
With "mount" you'll get plenty of lines so it might be better to do it on the PC with "adb shell mount".
edit: With mount you get only the mounted partitions. I forgot that nothing of that is mounted. Theoretically we should be able to mount the data partition manually and format it with the right filesystem...
But I really don't know what might break, what happens to the media folder and other soft-/hardlinks.
Click to expand...
Click to collapse
As said in the OP, RSD'd already but problem remains. As for mounting problems, I assume I can attempt to manually mount it, but I don't know the right command (Linux n00b).
I don't have any important data on the phone (it's not my primary device, as my signature says), everything's on the SD card, so feel free to throw suggestions/commands at me, as long as it doesn't have the risk of hard-bricking!
Sent from Google Nexus 4 @ CM11
AndyYan said:
You really sure this could deal with my issue, since you're replying to HIM instead of ME in MY question post?
EDIT: I actually risked my phone and attempted this - I think I already know ADB commands pretty well - and although /data is totally deleted, after a reboot to recovery, wiping /data still causes "hot reboot".
AND the actions also totally wiped my internal storage (because internal storage is /data/media and deleting /data also deleted it)! Thank god I don't have anything important in there...
Sent from Google Nexus 4 @ CM11
Click to expand...
Click to collapse
I appoligize that you did this. i really was just talking to him. as for the fix, was there a stock rom already on the phone? or had you put cm10 or 11 on there? i know for a fact that their internal storage for files, pictures, music, and dowloads are stored in /sdcard on the photon q. i did enough digging on adb for the past week to memorize that file structure.
Edit: Now that /data is gone, do an advanced recovery, don't wipe data, just flash it on. this might avoid the 'hot reboot' issue. i'm about to attempt to replicate this problem on my emulator.
dslinfreak said:
I appoligize that you did this. i really was just talking to him. as for the fix, was there a stock rom already on the phone? or had you put cm10 or 11 on there? i know for a fact that their internal storage for files, pictures, music, and dowloads are stored in /sdcard on the photon q. i did enough digging on adb for the past week to memorize that file structure.
Click to expand...
Click to collapse
/sdcard is just a symlink to /data/media...
I read the thread from the beginning to be sure what has already been tried.
It looks like the /data partition is corrupted, probably even more, the partition table (which we cannot rewrite afaik).
But I give my best suggestions I have to help.
As you might imagine, I won't be able to solve your problem but I can try to search where the actual problem is.
Please correct me if I am saying something wrong!
The following commands should be entered inside "adb shell" and the output should be posted here:
mount
ls -al /dev/block/platform/msm_sdcc.1/by-name
ls -al /dev/block/mmcblk0p39
The first command tells us what has been mounted within the recovery. /data should be there somewhere.
The second command tells us what partitions are available. userdata is the /data partition and should be listed.
The third command is actually a confirmation. If userdata is not in the output of the second command, then this command tells us if the actual partition exists.
In the last case (userdata is not shown in the second command but the partition exists), there might be a naming issue. Theoretically a format of this partition and give it the name "userdata" should solve it.
How? Actually I know on linux the command "mkfs.ext4 /path/to/partition" with which it is possible to format a partition into the ext4 filesystem.
But how do we give it a name? I don't know. Actually this is done in the partition table and not in the partition itself.
arrrghhh said:
/sdcard is just a symlink to /data/media...
Click to expand...
Click to collapse
well, color me purple now. Not a great thing for me and now I look like an absolute retard. I think I'm gonna go back to hs now and retake linux OS.
dslinfreak said:
I appoligize that you did this. i really was just talking to him. as for the fix, was there a stock rom already on the phone? or had you put cm10 or 11 on there? i know for a fact that their internal storage for files, pictures, music, and dowloads are stored in /sdcard on the photon q. i did enough digging on adb for the past week to memorize that file structure.
Edit: Now that /data is gone, do an advanced recovery, don't wipe data, just flash it on. this might avoid the 'hot reboot' issue. i'm about to attempt to replicate this problem on my emulator.
Click to expand...
Click to collapse
It's okay, if there were any important data there I would have backed it up before you say it. And yes, /sdcard simply symlinks to /data/media.
As I described, I can flash ROMs all I want, yet I can't backup or wipe my /data, which is needed for backup ops.
Loader009 said:
I read the thread from the beginning to be sure what has already been tried.
It looks like the /data partition is corrupted, probably even more, the partition table (which we cannot rewrite afaik).
But I give my best suggestions I have to help.
As you might imagine, I won't be able to solve your problem but I can try to search where the actual problem is.
Please correct me if I am saying something wrong!
The following commands should be entered inside "adb shell" and the output should be posted here:
mount
ls -al /dev/block/platform/msm_sdcc.1/by-name
ls -al /dev/block/mmcblk0p39
The first command tells us what has been mounted within the recovery. /data should be there somewhere.
The second command tells us what partitions are available. userdata is the /data partition and should be listed.
The third command is actually a confirmation. If userdata is not in the output of the second command, then this command tells us if the actual partition exists.
In the last case (userdata is not shown in the second command but the partition exists), there might be a naming issue. Theoretically a format of this partition and give it the name "userdata" should solve it.
How? Actually I know on linux the command "mkfs.ext4 /path/to/partition" with which it is possible to format a partition into the ext4 filesystem.
But how do we give it a name? I don't know. Actually this is done in the partition table and not in the partition itself.
Click to expand...
Click to collapse
Here's the full output:
Code:
~ # mount
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mmcblk0p36 on /cache type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
[B]/dev/block/mmcblk0p39 on /data type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)[/B]
/dev/block/mmcblk0p39 on /sdcard type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/mmcblk1p1 on /external_sdcard type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
~ # ls -al /dev/block/platform/msm_sdcc.1/by-name
ls -al /dev/block/platform/msm_sdcc.1/by-name
lrwxrwxrwx root root 2014-05-18 00:52 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2014-05-18 00:52 abootBackup -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2014-05-18 00:52 boot -> /dev/block/mmcblk0p31
lrwxrwxrwx root root 2014-05-18 00:52 cache -> /dev/block/mmcblk0p36
lrwxrwxrwx root root 2014-05-18 00:52 carriercust -> /dev/block/mmcblk0p35
lrwxrwxrwx root root 2014-05-18 00:52 cdrom -> /dev/block/mmcblk0p38
lrwxrwxrwx root root 2014-05-18 00:52 cid -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 2014-05-18 00:52 devtree -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 2014-05-18 00:52 dhob -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2014-05-18 00:52 fsg -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2014-05-18 00:52 hob -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2014-05-18 00:52 kpan -> /dev/block/mmcblk0p33
lrwxrwxrwx root root 2014-05-18 00:52 logo -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 2014-05-18 00:52 mbl -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2014-05-18 00:52 misc -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 2014-05-18 00:52 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2014-05-18 00:52 modemst1 -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2014-05-18 00:52 modemst2 -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2014-05-18 00:52 padA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2014-05-18 00:52 padB -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2014-05-18 00:52 pds -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 2014-05-18 00:52 persist -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2014-05-18 00:52 recovery -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 2014-05-18 00:52 rpm -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2014-05-18 00:52 rpmBackup -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2014-05-18 00:52 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2014-05-18 00:52 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2014-05-18 00:52 sbl2Backup -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2014-05-18 00:52 sbl3 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2014-05-18 00:52 sbl3Backup -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2014-05-18 00:52 sp -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2014-05-18 00:52 ssd -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 2014-05-18 00:52 system -> /dev/block/mmcblk0p37
lrwxrwxrwx root root 2014-05-18 00:52 tombstones -> /dev/block/mmcblk0p34
lrwxrwxrwx root root 2014-05-18 00:52 tz -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2014-05-18 00:52 tzBackup -> /dev/block/mmcblk0p14
[B]lrwxrwxrwx root root 2014-05-18 00:52 userdata -> /dev/block/mmcblk0p39[/B]
lrwxrwxrwx root root 2014-05-18 00:52 utags -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2014-05-18 00:52 utagsBackup -> /dev/block/mmcblk0p15
~ # ls -al /dev/block/mmcblk0p39
ls -al /dev/block/mmcblk0p39
brw------- root root 259, 7 2014-05-18 00:52 mmcblk0p39
As you can see, /data and userdata both exists.
Furthermore, using TWRP, I can even use its file manager to delete files, modify permissions, etc. in /data, just can't wipe it or back it up (backing up /data usually takes 20+ seconds, but now it's completed in a flash).
For me everything looks ok.
The partition is mounted and the recovery can access the partition.
It should work but it doesn't.
I am kind of clueless.
If I remember correctly, there was in TWRP an option to wipe data/internal storage (or something like that).
Could you try this one? (And post the last_log again.)
I think that it wipes in a blink of an eye because there is nothing to delete.
With the wipe data/internal storage I think it formats the partition instead of doing a "rm -R" (wipe data) on several folders. (I think it is rm -R, I don't actually know it.)
I have problems if I backup data from (external) sdcard. I have to move my backup to the internal storage (not in a recovery!) to successfully restore my backup.
It is annoying, but I haven't found a solution to be 100% sure that the recovery reads the backup correctly from the (external) sdcard.
What about a recovery.log after the failed attempt?
He already has:
AndyYan said:
Here is the last_log from TWRP 2.7.0.1: http://d-h.st/TKb.
[...]
And here's the last_log from CWM 6.0.4.8 (I built it via ClockworkMod Builder myself): http://d-h.st/zvK.
[...]
Something even more strange is, although TWRP "hot reboots" / CWM "fast skips" when wiping /data, /data gets wiped anyways.
Click to expand...
Click to collapse
Loader009 said:
If I remember correctly, there was in TWRP an option to wipe data/internal storage (or something like that).
Could you try this one? (And post the last_log again.)
I think that it wipes in a blink of an eye because there is nothing to delete.
With the wipe data/internal storage I think it formats the partition instead of doing a "rm -R" (wipe data) on several folders. (I think it is rm -R, I don't actually know it.)
I have problems if I backup data from (external) sdcard. I have to move my backup to the internal storage (not in a recovery!) to successfully restore my backup.
It is annoying, but I haven't found a solution to be 100% sure that the recovery reads the backup correctly from the (external) sdcard.
Click to expand...
Click to collapse
I tried the "format data" option like you said, and it seems to go nicely - the log says it recreated filesystem properly - until it "hot reboots" again. Bang it. Log attached: http://d-h.st/chh
I have always been backing up to/restoring from external SD card without any flaws. Now I can't restore my backup, but only because restoring backup involves wiping /data...
Loader009 said:
He already has:
Click to expand...
Click to collapse
I kept looking for recovery.log... haha.
Nothing brilliant is coming to me at the moment, I will ask some people (much) smarter than I...

[ROOT] [REF] LG K7 install SuperSU without Kingroot (lgms330 and lgk330)

***It worked for me, but I make no guarantee of invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***
MetroPCS (lgms330) and the T-Mobile (lgk330) models.​
The TWRP method: It's easier than the old method in post 3 which did mess up a couple of peoples phones for some reason. The method in post 3 is still relevant for those who don't want to use TWRP for whatever reason.
You will need:
computer, usb cord, and *adb/fastboot installed
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Part 1: enable developer mode / unlock boot loader
Developer options
On your phone, open settings do the following
Enable Developer mode
{
"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"
}
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Part 2: installing the Team Win Recovery Project.
I can confirm that the following technique works for the T-Mobile k330 too.
Abridged quoted instructions from this thread / partial copy from post #42 Senior Member: starkly_raving
Prerequisites:
1. unlocked bootloader
2. knowledge of fastboot commands.
First, connect your phone to the computer and run
Code:
adb reboot bootloader
Next, if you want to test but not replace your recovery
Code:
fastboot boot Twrp_m1_v2.img
Instead, if you want to replace your recovery partition with TWRP
Code:
fastboot flash recovery twrp-image-3.img
DOWNLOADS:
New forum has a version of TWRP with a button combination to boot into recovery.
Beta1:
twrp-image-3.img I hope you don't mind me mirroring [MENTION=805681]reemobeens19
Part 3: Installing SuperSu, Xposed framework, and Xposed installer
At the time of this writing these are the latest versions:
Xposed framework: sdk22/arm/xposed-v86-sdk22-arm.zip
Xposed installer: XposedInstaller_3.0-alpha4.apk
SuperSU: Version 2.76
Xposed uninstaller <- You need to flash this in order to completely uninstall the Xposed framework if you don't want it anymore or you want to upgrade with a newer version.
On our phone booting into TWRP can be done with the physical button combinations. If you don't feel like doing finger gymnastics you can use
Code:
adb reboot recovery
Tap install, choose the zip file(s) you downloaded, and the rest is fairly self explanatory.
If I made any errors or omissions feel free to mention it. I really hope this helps.
Xposed Follow up
Now that you have the Xposed Framework installed, you need to install the "Xposed installer" app in order to use it.
You need to go into settings -> security -> and check the box that says "Unknown sources"
If you have downloaded the XposedInstaller_3.0_alpha4.apk onto you phone, then you can use the "File Manager" app already installed on the phone; navigate to the XposedInstaller_3.0_alpha4.apk (probably in your "Download" folder); and tap on it. It will ask if you want to install it so tap install.
Xposed installer needs root access so grant it when prompted. The first time I ran the actual app it threw an error message. Either restart your phone or restart the app (I cannot remember which I did) then it should work.
OBSOLETE
Here are the old instructions for postarity. It worked for quite a few people
***I have followed this exact procedure with a 100% success rate in linux; however, I make no guarantee invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***​
These custom system images come with SuperSu and the appropriate Xposed framework (sdk22/arm/xposed-v86-sdk22-arm.zip) baked right in.
So many people have bricked their LG K7's trying to replace kingroot with the superb SuperSu by chainfire. I have seen many that have bricked their phones trying to flash the latest Xposed framework as well. This method will hopefully be easy enough to deter people relying on kingroot all together. (Feel free to leave feedback in the comments if there is a step that need further elaboration or isn't working)
This tutorial will work for both the MetroPCS (lgms330) and the T-Mobile (lgk330) models.​***This will wipe your device***
​You will need:
computer, usb cord, *adb/fastboot installed, the appropriate system image, and serious patience.
MetroPCS Download:
ms330_root_system.img
T-Mobile Download:
k330_root_system.img
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Developer options
On your phone, open settings do the following
Enable Developer mode
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Someone who is proficient in Windows please verify that fastboot "sees" the device. I was having trouble getting my Windows 7 64bit machine to recognize it. It worked every time in linux though. Thanks.
ADB/Fastboot commnads
On the computer (in windows you may have to replace adb with adb.exe and fastboot with fastboot.exe)
Code:
adb reboot bootloader
Code:
fastboot oem unlock
Don’t worry about the message it returns:
Code:
FAILED (remote: Already unlocked)
or
Code:
OKAY [ 0.040s]
Let's be OCD and make certain the bootloader is unlock.
Code:
fastboot getvar unlocked
The result should be
Code:
unlocked: yes
finished. total time: 0.001s
Get ready to wait a loooooong time. Flash the correct system image for your device carrier.
DON’T PANIC!!! When you run the fastboot command to flash the system image, it will return something like “Invalid sparse file format at header magi” and hangs for what seems like an eternity. This is normal. The next message it returns is “erasing 'system'...” and then you wait another eternity for the system to be overwritten. Mine took over 6 minutes to complete.
MetroPCS
Code:
fastboot flash system ms330_root_system.img
T-Mobile
Code:
fastboot flash system k330_root_system.img
​
Wait forever for it to get to the “Android is starting…” screen by running
Code:
fastboot reboot
I have no problem with kingroot as a concept. I just want to help people avoid bricking their phones.
It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"
IEatFood said:
It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"
Click to expand...
Click to collapse
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img
ledzepman71 said:
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img
Click to expand...
Click to collapse
Alright, 'I got the invalid sparse file format at header magi'
finished. total time: 0.002s
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot flash system ms330_root
_system.img
target reported max download size of 268435456 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.034s]
sending sparse 'system' 1/9 (257070 KB)...
OKAY [ 8.874s]
writing 'system' 1/9...
FAILED (remote: size too large)
finished. total time: 8.915s
Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!
IEatFood said:
Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!
Click to expand...
Click to collapse
My phone is doing the exact same thing after following the tutorial
CompFreak89 said:
My phone is doing the exact same thing after following the tutorial
Click to expand...
Click to collapse
Did it run successfully? If so sometimes you have to do the factory restet. Power off. Hold Vol down and power button. When the screen comes on keep holding down the vol down button let go of the power button and then push the power button again.
If it didn't run successfully please pm be with all the details including your phone model and all the output from the command line. Don't worry we'll get you squared away.
I updated the op to use an easier more standard way with TWRP.
tried it!
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way
To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/
azureee said:
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way
Click to expand...
Click to collapse
If your problem hasn't been resolved, can you please describe in further detail what happened. Were you using the obsolete instructions in post 3? Were you on the step where you reboot into the bootloader? If you're really stuck please feel free to pm me.
[email protected] said:
To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/
Click to expand...
Click to collapse
Hello, I appreciate your concern. On the topic of research, I was once told "a week in the lab can save you an hour in the library." I absolutely agree and would also encourage everyone to look deeper before plunging in head first.
If you are doubting the authenticity of my efforts and files allow me to elaborate on my method. As you will see, all the files were pulled directly off my personal phone and are not second hand impostors.
First, I looked up the partition table in adb using
Code:
ls -al /dev/block/platform/*/by-name
which output:
Code:
lrwxrwxrwx root root 1970-01-10 18:59 DDR -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-01-10 18:59 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 1970-01-10 18:59 abootbak -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-01-10 18:59 boot -> /dev/block/mmcblk0p33
lrwxrwxrwx root root 1970-01-10 18:59 cache -> /dev/block/mmcblk0p38
lrwxrwxrwx root root 1970-01-10 18:59 config -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-01-10 18:59 devinfo -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-01-10 18:59 drm -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 1970-01-10 18:59 eksst -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-01-10 18:59 encrypt -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-01-10 18:59 factory -> /dev/block/mmcblk0p35
lrwxrwxrwx root root 1970-01-10 18:59 fota -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-01-10 18:59 fsc -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 1970-01-10 18:59 fsg -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-01-10 18:59 grow -> /dev/block/mmcblk0p40
lrwxrwxrwx root root 1970-01-10 18:59 keystore -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-01-10 18:59 laf -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 1970-01-10 18:59 misc -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 1970-01-10 18:59 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-01-10 18:59 modemst1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-01-10 18:59 modemst2 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-01-10 18:59 mpt -> /dev/block/mmcblk0p36
lrwxrwxrwx root root 1970-01-10 18:59 persist -> /dev/block/mmcblk0p31
lrwxrwxrwx root root 1970-01-10 18:59 raw_resources -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 1970-01-10 18:59 raw_resourcesbak -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 1970-01-10 18:59 rct -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 1970-01-10 18:59 recovery -> /dev/block/mmcblk0p34
lrwxrwxrwx root root 1970-01-10 18:59 rpm -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-01-10 18:59 rpmbak -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-01-10 18:59 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-01-10 18:59 sbl1bak -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-01-10 18:59 sec -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-01-10 18:59 sns -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 1970-01-10 18:59 spare1 -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-01-10 18:59 spare2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 1970-01-10 18:59 ssd -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-01-10 18:59 system -> /dev/block/mmcblk0p37
lrwxrwxrwx root root 1970-01-10 18:59 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-01-10 18:59 tzbak -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-01-10 18:59 userdata -> /dev/block/mmcblk0p39
As you can see, "/dev/block/mmcblk0p37" is the block device for the system partition. From there you simply duplicate the data into a raw image by doing
Code:
dd if=/dev/block/mmcblk0p37 bs=2048 of=/storage/external_SD/system.img
To elaborate on what the command does, the input file is the system block mmcblk0p37 and the output file is created as "system.img" on the external sd card. From the man page, "bs=BYTES read and write up to BYTES bytes at a time." So it just means that the dd operation can read and write up to 2048 bytes at a time.
This process was simply repeated using a stock k330, rooted k330, stock ms330, and rooted ms330. After all the raw images were created I systematically flashed them to my personal phone using the instructions verbatim from my op to ensure that they indeed work.
I hope explaining my process sheds further light on the matter. If you want to investigate further on your own you can mount the raw image in linux. Assuming that the system.img file is in your home directory and you have the directory /mnt/tmp , simply run as root
Code:
mount -o ro ~/system.img /mnt/tmp
and you will then be able to see the contents of the image (build prop, preinstalled apps, and the like) in the /mnt/tmp folder.
If you have any further comments or questions I will happily oblige.
The whole point of my effort was to aid people in rooting there phones while mitigating the risk of bricking. I want to make the process as bullet proof as possible so all feedback is welcome. This includes testimonials from those whom this process worked. I guess the next step would be to post the TWRP backup zips to further automate of the process.
unbrick method
@azureee, I am so happy to hear that you found a solution to your problem. Thank you for sharing that link as well. I am sure it will help many people here. If you need any further explanation on installing xposed I would be happy to help.
Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.
Billybobjoe13245 said:
Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.
Click to expand...
Click to collapse
Thank you for the heads up about TWRP. I keep trying to add that tag, but it refuses to stick.
Edit: I had to delete the tag that wasn't showing up and readd it.
ledzepman71 said:
I updated the op to use an easier more standard way with TWRP.
Click to expand...
Click to collapse
Hi, thank you for the tutorial.
I do have a noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted? No need to install Kingroot or similar?
Thanks!
101...
saphta said:
Hi, thank you for the tutorial.
noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted?
Click to expand...
Click to collapse
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..
RaiderWill said:
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..
Click to expand...
Click to collapse
Thanks! I'll do that!

[INFO] ANDROID DEVICE PARTITIONS and FILESYSTEMS

NOTE:
I'm not a developer or something even near to that. I'm a newbie and will be, seems so. All information provided here is copied and compiled from different internet sources like this and many others.
This information is according to best of my knowledge and comprehension and is just for curious souls like me who want to understand things in quite simple words. It might be wrong and I will open-heartedly welcome any correction or addition from anyone.
I'm not responsible for any harm to you or your device resulting from this.
1. PARTITION TABLE
The Phone's Internal Memory (eMMC or UFS; not the SD card) is solid-state (flash) memory, aka NAND. Raw NAND, as it's called, is basically a pure flash memory dependent on CPU to control it. But in order to use flash memory just like a traditional hard drive (block device), NAND is equipped with an (embedded multimedia) micro-controller. It's called eMMC.
eMMC can be partitioned much like a hard drive on PC. PC's have traditionally been partitioned with BIOS compatible Master Boot Record (MBR) scheme in which first sector of disk contains the details of partitions called Partition Table. Limited size of boot sector (512 bytes) puts a limitation of at maximum 4 (primary) partitions listed in MBR. Extended partition has been used for 4+ partitions.
GUID Partition Table (GPT) was introduced with UEFI booting system which isn't dependent on first boot sector and hence may contain up to 128 partitions. GPT also does CRC check, has backup GPT, identifies partitions by GUID and partitions have a label.
Android devices use GPT. We can view and manipulate GPT using Linux tools such as parted and gdisk while fdisk is the traditional tool for MBR partitions.
To view partition table on internal memory:
Code:
~# parted /dev/block/mmcblk0
(parted) p free
~# gdisk -l /dev/block/mmcblk0
(The external SD Card can also be partitioned to include a section dedicated to storing user apps (like Link2SD does) or to create partitions for secondary or tertiary OS on Android device using some multiboot kernel and recovery system). Even we can put whole OS/ROM on an SD card.
2. BRIEF INTRO
Contents of Android partitions can be partially or completely modified by flashing an image (filesystem .img or executable binary or a flashable zip) to them. But we never need to modify most of them and whatever manufacturer wrote on them, resides there unmodified (read-only) for the whole of device life. A user uses only one partition /data to save personal data like photos, music etc. All the other are for device to run. There are typically in the range of 50 partitions on an Android device but only a few partitions are modified for the purpose of adding new features or upgrading the device. A custom ROM or minor upgrade is also limited to modify /boot, /system and /data partitions usually. Most of the partitions are almost intact, containing bootloaders, firmwares, settings etc. Here is a "summarized" detail to these partitions which matter to a common but interested user.
On most devices /system and /data are larger partitions (on some devices /custom or a similar partition too) covering almost 90% of eMMC. All others are smaller ones of a few KB's or MB's.
3. SoC / CHIPSET / PROCESSORS RELATED PARTITIONS
SoC is the first component when we start a PC or Mobile phone which initialzes hardware and processors and loads bootloaders in memory to bootstrap OS. It's an integrated chip containing multiple things e.g. CPU, GPU, modem, wifi etc. It varies for device manufacturers and SoC vendors (chipset plus processor).
Some partitions are specific to SoC, most of them are closed-source executable binary blobs (like aboot, sbl, rpm, tz, cmnlib, devcfg, keymaster, lksecapp and others on a Qualcomm device), loaded step-by-step by bootloaders.
MODEM or RADIO - the phone's radio
Also called baseband, it is responsible for signals and on older devices may control wifi, bluetooth, and GPS (on most newer devices, these are handled by the kernel and ROM). Upgrades are country dependent and may improve or diminish battery performance, network signal strength, and roaming capability. It is also sometimes required to have a minimum Baseband version to use a ROM so that the RIL will play nice with the Baseband.
Modem firmware is a mini-OS for the cellular radio chip which has its own processor. Firmware is a general term, firmware exists for a lot of things on phone. The wireless chip for WiFi, GPS, and Bluetooth often has a firmware as can the GPU core among other things. These firmware files are usually located inside the SYSTEM or VENDOR partition. The modem firmware is special because it has its own separate Baseband Processor (BP) so the firmware is left out of the system image in its own partition.
Modem is not an Android-specific partition. It is tied to the hardware of the phone, but the kernel has a code allowing Android to interact with the hardware. But the baseband processor (BP) - which runs modem and is responsible for all communication through mobile networks e.g. call, SMS and internet - is totally isolated from Application Processor (the one we call CPU) and is not governed by Android kernel; it runs an independent RTOS.
RIL/Radio Interface Layer
This is not a separate partition, but a part of the ROM and is like a driver for the Radio. RIL daemons provides telephony and cellular data i.e. adds phone to smartphone. There is a matching RIL for each Baseband version and you can flash it to match your Baseband after flashing a ROM. Having mismatched RIL and Baseband can range from having no effect at all, slight battery drain, loss of roaming, or even no connection to the cell network. Many ROMs keep their RIL updated to the latest. Job of the RIL is to translate all the telephony requests from the Android telephony framework and map them to the corresponding AT commands to the modem, and back again. AT set of commands is used to communicate with modem i.e. baseband processor (BP) which is a must have processor on Android devices in addition to normal CPU i.e. Application Processor (AP).
TZ (TrustZone) - used by ARM processors as an additional lock to security features. It combines user's encryption key with a hardware specific key generated by encryption processor (like TPM on Windows) to make security breaching more difficult. It can also be used to implement Trusted Execution Environment (TEE).
RPM (Resource/Power Management) which starts executing Primary/Primitive BootLoader (PBL) in BootROM - controls power to radio, modem etc.
DSP (Digital Signal Processor) - by Qualcomm to assist in things like smooth video playback (realtime media and sensors processor) as well as runs RTOS for modem
HYP (Hypervisor) - Virtual Machine Monitor, to enable Virtual Machine platform
4. BOOTLOADERS
Bootloaders - in many steps - hand over charge to kernel after loading in RAM. These are mostly standalone ELF executable files becuase at this stage no filesystem is loaded and only executable code may work. These are all closed source components on Android device, provided by SoC vendors - either built-in or as binary blobs.
SBL - Secondary bootloader loaded by SoC, loads ABOOT in memory, also provides (Emergency) Download Mode (EDL) on many devices, a Firmware Update Protocol.
ABOOT (bootloader.img or aboot.mbn file in Factory Firmware) - Applications Bootloader is the main bootloader responsible for loading kernel or recovey and fastboot - a Firmware Update Protocol - as well.
Kernelflinger is a similar bootloader on Intel devices.
Read ANDROID BOOT PROCESS to know more about bootloaders.
5. CORE AOSP PARTITIONS
BOOT - Kernel and initramfs (modern form of of ramdisk and ramfs/tmpfs)
A kernel is a layer of code that allows the OS and applications to interface with your phone's hardware. The degree to which you can access your phone's hardware features depends on the quality of code in the kernel. Several kernel code improvements give us additional features from our hardware that the stock kernel does not. When you flash a custom ROM, you automatically get a kernel. But you can also flash a standalone kernel on top of the existing one, effectively overwriting it. These days, the difference in custom kernels is less about new features and more about alternate configurations. Choosing a custom kernel is basically choosing one that works best with your ROM.
Device Tree Blob (DTB), along with hardware drivers, are baked with kernel source in boot.img. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
On a Linux system init along with scripts, binaries kernel drivers and modules (in initrd.img), kernel (vmlinuz executable) and bootloader configuration along with modules, they all reside on root or a separate partition (mounted) at /boot. While on Android, init along with a few binaries and configuration files and kernel reside in a separate partition named "boot" with a special filesystem. Boot.img is created using tools like mkbootimg after building kernel.
This is how kenrel and DTB are built:
vmlinux > Image > zImage / Image.gz > Image.gz-dtb
vmlinux: Large sized non-bootable Linux kernel (executable) with debug symbols, just an intermediate step to producing vmlinuz
vmlinux.bin: Same as vmlinux binary but with removed symbols, produced by 'objcopy'
vmlinuz: Compressed and bootable Linux kernel file; one of zImage or bzImage formats; compressed using zlib, LZMA, gzip or bzip2 etc.
zImage: Smaller format, for old kernels
bzImage: Big zImage
Image: vmlinux.bin of embedded devices
Image.gz: zImage or bzImage of embedded devices
.dts (multiple) < > .dtb (1 or more)
Converted using dtc (device tree compiler)
.dtb is appended to zImage / Image.gz i.e. zImage-dtb / Image.gz-dtb (simply concatenate)
zImage-dtb > dtb Can be extracted using split-appended-dtb
Packed as a part of kernel, "--dt" option is not needed when creating boot.img
mkbootimg --kernel *.Image.gz-dtb --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
.dtb is extracted as a part of kernel by unpackbootimg
.dtb < > dtb.img
Converted using mkdtimg
dtb.img is for dtb partition or second stage of boot.img
boot.img is created by using --dt option:
mkbootimg --dt dt.img --kernel *.Image.gz --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
dtb.img is extracted separately by unpackbootimg
Further Reading: Device Tree Overlays and Android Boot and Recovery Images
SYSTEM - ROM / OS
Contains system applications and libraries that have AOSP source code. During normal operation, this partition is mounted read-only; its contents change only during an OTA update or when flashing a new OS. Most ROM's don't allow root level (Admin rights in Windows) access by default. So, "rooting" is required to modify the contents of this partition. This is the actual User Interface we use on our phone i.e. system apps are installed on this partition on /system/app directory. Another important directory is /system/bin which contains executable binaries to perform each and every action by OS in background (as daemons) or by user in shell (bash) scripts or CLI (command line interface). These are native binaries (developed in C / C++ mostly) as opposed to Android apps which are developed in Java. A minimal form of Linux commands is also included in AOSP as toolbox or toybox (or user can add busybox or individual static binaries). /system/lib directory contains native libraries (shared by applications commonly) with .so extensions just like .dll on Windows.
VENDOR
This partition is replaced with a shortcut (symbolic link in fact) to /system/vendor directory. It contains system applications and libraries that do not have source code available on AOSP but added by vendors (OEM's). During normal operation, this partition is mounted read-only; its contents change only during an OTA update. It also contains SoC firmware images i.e. hardware specific libraries and binaries (OpenGL, ISP...).
Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL (hardware abstraction layer) is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors, though being abandoned by mainstream Linux.
PROJECT TREBLE
In an ideal world, there should be a generic AOSP OS and a single kernel for all Android devices, not tied to hardware and vendors. But unfortunately it isn't so because unlike PC world, there is no standardization in mobile world. AOSP is heavily modified on silicon vendor (SoC) as well as phone vendor level. One of the worst outcome of this situation is almost no Long Term Support (LTS). There are delayed or none updates once the consumers have phone, making it vulnerable to security issues and missing new features. Project Treble (starting from Android-8) addresses this issue somewhat by creating a separation between hardware specific code and generic AOSP code.
Previously, phone vendors used to get AOSP code from Google, mixing it with their own cutomizations (UI, apps etc.) and the hardware specific code from SoC vendor. If a minor fix needed to be applied to AOSP code, the whole process had to be repeated because code was intermingled and fixing one thing broke the other. Google resolved this issue by specifying /vendor partition for hardware specific code, /system containing only generic code. Interaction with AOSP code will be through HIDL interfaces, thus making it possible to upgrade the both codes independently. /oem and /odm partitions were added previously for the same purpose.
USERDATA
User applications are installed in different folders under /data. Apps data (user and system) is stored in /data/data. User personal data and some apps data is stored in /data/media. /data/media is also emulated as internal SDCard at /storage/emulated and symlinked at /sdcard. Personalized and apps settings are also stored in this partition. A folder /data/dalvik contains, in simple words, extracted apps to boost loading process. Java bytecode of Android apps is converted to executable code (.odex) by Dalvik Virtual Machine, separate instance of which is launched by zygote (an Android init daemon) for every app.
This partition is not normally touched by the OTA update process. A Factory Reset wipes this partition, normally excluding /data/media i.e. personal data.
When you do a factory reset (AKA: wipe, hard reset, factory wipe, etc.), you are erasing the /data and /cache partitions. Note that a factory reset does NOT put your phone back to its factory state from an OS standpoint. OS upgrades will stay because the OS lives in /system, and that is not touched during a factory reset. So it's not a factory reset. It's a factory DATA reset actually.
RECOVERY
Holds alternate boot partition and the recovery program that lets the device boot into a recovery console for performing advanced recovery and maintenance operations. It contains a second complete Linux system i.e. independent OS, including a user-interface application, kernel and the special recovery binary that reads a package and uses its contents to update i.e. flash or wipe itself or any other partition particularly during OTA updates.
Recovery is also the most commonly used method to flash custom ROM's.
ADB sideload mode through PC is a replacement of flashing files (usually .zip) through Recovery. ADB works when phone is switched on in Recovery (or ROM). ADB/fastboot setup is to be made on PC to use this mode.
CACHE - cached (frequently accessed) data from OS usage and contains the firmware update package downloaded from server during OTA updates. Temporary holding area used by a few applications with the expectation that files can disappear at any time. Major use is by recovery and OTA updates. Recovery last_log is also written to this partition.
6. OTHER PARTITIONS
CUST - also CUSTOM or PRELOAD on some devices, it's used by stock ROM's, holding some preloaded system apps and regional settings which are installed on first use.
MISC - also FOTA on older devices
It's a tiny partition used by recovery to communicate with bootloader store away some information about what it's doing in case the device is restarted while the OTA package is being applied.
It is a boot mode selector used to pass data among various stages of the boot chain (boot into recovery mode, fastboot etc.). e.g. if it is empty (all zero), system boots normally. If it contains recovery mode selector, system boots into recovery mode.
It may also carry some necessarily required information in the form of switches to control hardware or settings related tasks such as CID (Carrier or Region ID) information and USB configurations etc.
PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera etc.
Some package installers such as OpenGapps also make use of this partition to read configuration file.
EFS, MODEMST1, MODEMST2, FSG, BACKUP
These all are related to IMEI; a unique number used by GSM networks to identify and trace a mobile phone.
EFS may contain hardware info like configuration files, WiFi/BlueTooth MAC’s, IMEI (or ESN for a CDMA based device) etc.
EFS and MODEMST1 may be a single partition on some phones.
FSG (FileSystem Golden copy) and BACKUP are backups of MODEMST1 and MODEMST2 respectively. If MODEMST1 or MODEMST2 are erased (by wrong factory flashing say) and phone notices an invalid partition, FSG and BACKUP will be restored.
MODEMST1 and MODEMST2 also contains modem firmware files.
PARAM - stores a number of parameters, variables and settings of the hardware. It contains info whether MODEMST partitions are backed up or not. Also debug settings, custom ROMs flash count, current stage boot process etc.
OEM - like VENDOR, it incorporates OEM (Original Equipment Manufacturer i.e. hardware manufacturer or Mobile Phone brand) small customization (modifications) to original Android (AOSP) during OTA updates such as customized system properties values etc.
PAD - related to OEM
OTA, FOTA - OTA updates
DDR - Double Data Rate RAM
FSC - Modem FileSystem Cookies
SSD - Secure Software Download, a memory based file system for secure storage, stores some encrypted RSA keys
DEVINFO - device information including: is_unlocked (aboot), is_tampered, is_verified, charger_screen_enabled, display_panel, bootloader_version, radio_version etc. Contents of this partition are displayed by "fastboot oem device-info" command in human readable format. Before loading boot.img or recovery.img, bootloader verifies the locked state from this partition.
CONFIG/FRP/PDB - saves state of Factory Reset Protection (FRP), "Allow bootloader (OEM) unlocking" . (Developer Options), asks already associated account info. This partition is erased/reset if Factory Reset done from Settings.
DEVCFG - used by TZ for upgrades
LKSECAPP - "LK (Little Kernel) Security App", related to RPM, TZ online verification / update
LIMITS - Qualcomm Limits Management Hardware (LMh) driver in SBL writes the data in this partition to use for later reboots
SYSCFG - Qualcomm CPR (Core Power Reduction) Regulator for better performance and power saving of application processor by voltage control
DIP, MDTP - boot verification, use Qualcomm SafeSwitch technology to lock and track theft phones
CMNLIB, KEYMASTER - verified boot
SEC - contains fuse settings, mainly for secure boot (signing bootloaders for chain of trust) and oem setting
KEYSTORE - related to /data Full Disc Encryption (FDE)
MCFG - (Modem Configuration Framework) - on dual SIM devices, loads MBN (modem binary) files depending on SIM/carrier
SPLASH - splash image or boot logo which appears when device boots (at ABOOT stage).
CHGLOGO - charging screen that appears when charger is connected to powered off device.
MSADP, APDP, DPO - related to debug policies
GROW - empty for future expansion
7. FILESYSTEMS
Supported filesystems by your kernel can be viwewd by:
Code:
~# cat /proc/filesystems
Partitions with Mountable Filesystems
Following partitions are mounted during boot process:
system, vendor, odm, userdata (mounted at /data), cache, cust, persist (mounted at /persist or /mnt/vendor/persist), modem (mounted at /firmware or /vendor/firmware_mnt), dsp (mounted at /dsp or /vendor/dsp)
Modem is formatted as vfat while all others are usually ext4 or f2fs on newer devices.
All of these are listed in /fstab.* file which is processes by init. Starting with Android 8.0 (Treble release), fstab.* is moved to /vendor/etc/ and system, vendor and odm entries are included in dtb.
Other partitions don't contain a mountable filesystem. However, we may try to get an idea of the contents by reading smaller partitions e.g.:
Code:
~# cat /dev/block/bootdevice/by-name/config | strings
~# cat /dev/block/bootdevice/by-name/misc | strings
Pseudo / Virtual / in-Memory Filesystems (Kernel space)
These filesystems don't rely on a physical persistent storage but just live in RAM, to provide kernel services interfaces in user space.
rootfs (/) - mounted by kernel before calling init. More details here
sysfs (/sys) - information related to devices, populated by kernel
devpts (/dev/pts) - character device files representing slave side of pseudo terminal pairs
proc (/proc) - information related to all processes, updated as processes are started / killed
tmpfs (/dev) - all device nodes updated from sysfs, accessible from user space
configfs (/config) - intergrated with userspace sdcardfs, controls apps permissions to directories on internal/external sdcard by VOLume Daeomon, a replacement of fusefs
pstore (/sys/fs/pstore) - persistent storage, a replacement of /proc/last_kmsg, saves last kernel console messages on panic / crashes / sudden reboots, solution to volatile nature of pseudo filesystems
cgroup - cgroups manage hardware resources allocation to processes as per load
selinuxfs (/sys/fs/selinux) - implementation of Security-Enahanced Linux, a mandatory access controls (MAC) to manage file permissions, better than traditional Discretionary Access Control (DAC) mechanism (Read-Write-eXecute) of Linux
debugfs (/sys/kernel/debug) - to monitor and debug kernel space implementations from user space
tracefs (/sys/kernel/debug/tracing) - debugfs with better security
functionfs (/dev/usb-ffs/adb) - integrated with configfs, manages USB gadgets, ADB is implemented through functionfs on Android
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
8. Factory Firmware and Flashable ROMs:
When you flash a custom ROM, that ROM typically includes a kernel and an OS. That means the /boot and /system partitions will be modified at a minimum. Some ROMs require a clean install, so a format of the /data and /cache partitions is sometimes built into the .zip that you flash. This is essentially doing a Factory Reset.
Read here to know more about flashing partitions.
Factory Firmware contains original iamge files of almsot all important partitions. It's provided by OEM's, usually as a package which also incude a flasher software for PC. Or a general flasher software may be uses such as QFIL.
ROM Development
A ROM developer downloads AOSP source code from Google while device tree, driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs.
RELATED:
An Introduction to Android Firmware
First off, don't need be like your never be a dev, lol you never know. Secondly it's a good share. Appreciated
Drivers Partition
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?
saprey said:
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?
Click to expand...
Click to collapse
Camera and sound are related to your rom i.e. system partition. Do factory data reset or clean install rom
Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie
TommyWhite said:
Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie
Click to expand...
Click to collapse
At what point talking about primary / secondary partitions? Are you creating new partitions or using some tool / app to view partitions?
Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'
TommyWhite said:
Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'
Click to expand...
Click to collapse
Something like this attachment?
mirfatif said:
Something like this attachment?
Click to expand...
Click to collapse
yes, sorry for the very late response.
While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Click to expand...
Click to collapse
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?
Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?
argon9898 said:
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?
Click to expand...
Click to collapse
Booting in bootloader (or it's equivalent; like fastboot) mode is dependent on the phone manufacturer. Though most of the hardware manufacturers allow users to access bootloader for repair/maintenance or modified boot chain, some may restrict this for Digital Rights Management or to gain forced customer loyalty , irrespective of where bootloader resides. On most phones it's a partition. You may check your partition table to know about all partitions.
azoksky said:
Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?
Click to expand...
Click to collapse
Thanks for mentioning. I have added this to my post. By "blolbs" you mean DTB or hardware drivers? Well AFAIK, the blobs are included in every ROM where "ROM" is boot.img and system.img at least.
A ROM developer downloads AOSP source code from Google while device tree (map of hardware components), driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs. DTB and drivers are baked with kernel source in boot.img though DTB may live on a separate dtb partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but I don't think that is widely practiced. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly. Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors.
Click to expand...
Click to collapse
Hello everyone. I tell you that one day flashing my oneplus 5 lost the wifi. The MAC address shows me the typical 02: 00: 00: 00: 00: 00 address. The way to fix it is updating the Oreo but I could never do it, it is always in bootloop, I read all the forums and there is no case, do what I always do the same. It happens in many oneplus 5. So I forgot to fix it in that way. The other thing I saw is hundreds of forums with that problem but I could not fix it either, I've been doing it for three months now. What I am trying now is to erase all the partitions except recovery or bootloader but the phone does not start anymore. What I want is to delete all the partitions associated with wifi, delete modem1, modem2, persist, fsg but nothing, I just managed to lose the imei that does not matter to me because I have back up of the efs folder and even the qcn file of the phone. I know it's a lot of work but if someone tells me that they control each partition, I could erase it, load everything from scratch and that's it. Would someone give me a hand so I can fix that damn wifi on the phone ?. Thank you.
--------------------------------------------------------------------------------------------------------------------------------------
drwxr-xr-x 2 root root 1440 1970-05-03 14:23 .
drwxr-xr-x 4 root root 1600 1970-05-03 14:23 ..
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 LOGO -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 abl -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 ablbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 apdp -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 bluetooth -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot_aging -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cache -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64 -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64bak -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlibbak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 config -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devcfg -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devinfo -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dip -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dpo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dsp -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 frp -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsc -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4g9n4 -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4j1ed -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4t0n8 -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_8v1ee -> /dev/block/sde44
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hyp -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hypbak -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 keystore -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 limits -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logdump -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logfs -> /dev/block/sde37
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 md5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtp -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecapp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecappbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 minidump -> /dev/block/sde47
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 misc -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 modem -> /dev/block/sde10
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 msadp -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_dycnvbk -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_stanvbk -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 param -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmic -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmicbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 recovery -> /dev/block/sde22
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 reserve -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve1 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve2 -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpm -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpmbak -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 sec -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 splash -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 sti -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsec -> /dev/block/sde41
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsecbak -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 system -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 toolsfv -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tz -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tzbak -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 userdata -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xblbak -> /dev/block/sdc1
thank you
This is one of the best posts that I've ever read. I'm a hobbyist and reverse engineer learn. My primary phones are Samsung S 6 7 and 8 and I've soft bricked phones them more times than I can count (but recovered) justifying it as a learning experience. Sort of like putting your hand in the fire several times and calling it a learning experience. your post opens up more questions which are great. I root all my phones and I have a fear of new security patches disguised as updates disabling what methods work last week so to speak
So if I understand finally there is a section in bootloaders which is the first bootloader that is static yet upgradable but not downgradable as you referred to like the BIOS on PCs which acts as a verification process so you can't flash downgradable security patches. Much like I've encountered with partcyborg great work on rooting the S8 snapdragon however once you upgraded to the bootloader 2 you couldn't go back to the bootloader one. This is in reference to the build, not the partition.
If someone does reply, I'd like to know can you mod a certain file and Odin in the bootloader section when flashing an update to ensure that you stay at a certain bootloader level while the other files such as AP CP and CSC remain intact from the sam mobile stock firmware.(which I assume the term combo firmware file originates)
My most recent encounters are the device and binary are not the same which I attribute to this problem.
In theory from what I understand the phone has a section that is not Factory resettable which is the NAND that contains read-only but system upgrade information? However, it can be modified by a power Superuser rooted? This obviously risking hard bricking a phone
When upgrading firmware specifically the bootloader file in Odin what file(s) {bin} are essential to the new modification patches and can those files be substituted?
Any comment is considered very helpful. Odin itself is coming out with different versions for structures (prince cosmey) for example.
I explore the system file structure often wondering what I could change or alter as simple as a 0 or 1 or a true or a false to enable or disable my ability to access what I feel I need to access.
I could buy the z3x Samprotools but it defeats my intentions to learn the details.
If you do have a suggestion on a GUI Windows-based tool it would be great. Don't know Linux just as a footnote
Once again what a great post and definition of the different sections of terminology it's just enough to educate me and confuse me at the same time keep doing what you're doing. Any tricks or tips will be very appreciated.
partitions
What are partitions responsible on drivers like sound and camera,
Curious Q.!
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
whole partition table is here:
Code:
←7←[r←[999;999H←[6n←8potter:/ # ls -l /dev/block/bootdevice/by-name
total 0
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 DDR -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 abootbak -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 apdp -> /dev/block/mmcblk0p45
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 boot -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cache -> /dev/block/mmcblk0p52
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 carrier -> /dev/block/mmcblk0p34
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cid -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib64 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlib64bak -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlibbak -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 devcfg -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 devcfgbak -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dip -> /dev/block/mmcblk0p42
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dpo -> /dev/block/mmcblk0p47
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dsp -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 frp -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsc -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsg -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 hw -> /dev/block/mmcblk0p50
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 keymaster -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 keymasterbak -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 kpan -> /dev/block/mmcblk0p36
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 limits -> /dev/block/mmcblk0p40
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logo -> /dev/block/mmcblk0p33
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logs -> /dev/block/mmcblk0p44
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 metadata -> /dev/block/mmcblk0p35
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 misc -> /dev/block/mmcblk0p39
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modem -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst1 -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst2 -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 mota -> /dev/block/mmcblk0p41
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 msadp -> /dev/block/mmcblk0p46
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 oem -> /dev/block/mmcblk0p51
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 padA -> /dev/block/mmcblk0p48
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 persist -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 prov -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 provbak -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 recovery -> /dev/block/mmcblk0p38
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 rpm -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 rpmbak -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sbl1bak -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sec -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sp -> /dev/block/mmcblk0p49
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 ssd -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 syscfg -> /dev/block/mmcblk0p43
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 system -> /dev/block/mmcblk0p53
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 tzbak -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 userdata -> /dev/block/mmcblk0p54
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utags -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utagsBackup -> /dev/block/mmcblk0p26
potter:/ #
GEEKOFIA said:
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
Click to expand...
Click to collapse
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.
koler386 said:
What are partitions responsible on drivers like sound and camera,
Click to expand...
Click to collapse
Kernel and system
mirfatif said:
what about these two ?
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.
Click to expand...
Click to collapse
I got a script from a xda thread in which OP mentioned that this script is for wiping dalvik/ART cache.
Before flashing it i decided to analyse it,what i found that it was erasing my RPM partition on mmcblk0p2.
Is it really for dalvik cache ?

[GUIDE] Rooting the Ioutdoor X using Magisk man

Using Magisk for rooting is currently a good option for a simple way to root your device reasonably safe, special if it has been done once before. I will NOT work out every step in full detail as there are many good guides around
Warning: you risk your warranty and you might brick your phone if you make an error! It is your own responsibility!!!
Step 1: Make yourself developer in the setup screen
Step 2: In the developer menu allow your bootloader to be unlocked
Step 3: Reboot in the bootloader (power off and keep volume up and the power on until you see the bootloader)
Step 4: choose the fastboot option
Step 5: From your ADB directory type: "fastboot flashing unlock"
Step 6: Confirm on your mobile with the volume up button
Step 7: Download Patched boot image for Ioutdoor
Step 8: Type "fastboot flash boot <filename of patched boot image>"
Step 9: Type "fastboot flashing lock"
Step 10: reboot
Step 11: Install Magisk manager. Your phone is rooted now.
Enjoy your rooted phone!!!
Paul
P.S.: First of all: I myself ALWAYS create a full backup from my phone with the flash tool before doing ANYTHING of this nature. If you backup with the flash tool you need to use the "Readback" option. WARNING: with the DOWNLOAD menu of the flash tool you UPLOAD to your phone, better be warned!!!! Second: If you prefer to create your own patched boot image you need some more steps:
- Find the MT6763 scatter file
- use the flash tool to download the bootloader
- use CarlivImageKitchen to make the bootloader image the right size (unpack and repack)
- Install Magisk manager on your phone and choose the "patch bootloader image" option
More information for those who want to hack this phone
Preloader 00000000
BOOTPARA 00008000 /dev/block/mmcblk0p1
Recovery 00108000 /dev/block/mmcblk0p2
PARA 0212B000 /dev/block/mmcblk0p3
EXPD 02188000 /dev/block/mmcblk0p4
FRP 03588000 /dev/block/mmcblk0p5
NVCFG 03688000 /dev/block/mmcblk0p6
NVDATA 05688000 /dev/block/mmcblk0p7
METADATA 09688000 /dev/block/mmcblk0p8
PROTECT1 0B688000 /dev/block/mmcblk0p9
PROTECT2 0BE88000 /dev/block/mmcblk0p10
PROINFO 0D200000 /dev/block/mmcblk0p13
MD1IMG 0D500000 /dev/block/mmcblk0p14
MD1DSP 11500000 /dev/block/mmcblk0p15
SPMFW 12500000 /dev/block/mmcblk0p16
SSPM_1 12600000 /dev/block/mmcblk0p17
SSPM_2 12700000 /dev/block/mmcblk0p18
GZ1 12800000 /dev/block/mmcblk0p19
GZ2 13800000 /dev/block/mmcblk0p20
NVRAM 14800000 /dev/block/mmcblk0p21
IK 18800000 /dev/block/mmcblk0p22
IK2 18900000 /dev/block/mmcblk0p23
Boot 18a00000 /dev/block/mmcblk0p24
LOGO 1AA00000 /dev/block/mmcblk0p25
ODMDTBO 1B200000 /dev/block/mmcblk0p26
VENDOR 1D000000 /dev/block/mmcblk0p29
SYSTEM 5D000000 /dev/block/mmcblk0p30
CACHE 103800000 /dev/block/mmcblk0p31
USERDATA 110800000 /dev/block/mmcblk0p32
FLASHINFO 1D1DBFBE00 /dev/block/mmcblk0p33 Length 16mb
I have a version of TWRP running for this phone, but I am not satisfied with it yet. However, anyone who like to try, send me a private message.
bootloop
UPDATE: fixed boot img:
s000.tinyupload.com/index.php?file_id=18085276003223938832
Flashing your ioutdoor_patched_boot.img resulted in boot loop for ioutdooor X
Any chance you could post the stock backup?
Any update on TWRP?
cheers
wildwildwoods said:
UPDATE: fixed boot img:
s000.tinyupload.com/index.php?file_id=18085276003223938832
Flashing your ioutdoor_patched_boot.img resulted in boot loop for ioutdooor X
Any chance you could post the stock backup?
Any update on TWRP?
cheers
Click to expand...
Click to collapse
Sorry I only read your message today. Do you still need help? Send me a PM with your emailaddress I might be able to help you to obtain the stockbootrom. I was able myself to fix any bootloops by resetting the phone using the default recovery rom and do a full reset. Not sure what went wrong in your case but I did notice that the way you reset the phone matters. Anyway the TWRP I have is not fully perfect and you have to be carefull using it: some functions might cause bootloops.

Categories

Resources