Database Users

KFHD Partitions

I'm jumping and starting to develop for this device and just got the mount points. This is for anyone else that cares :silly:
lrwxrwxrwx root root 2012-10-03 20:37 boot -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2012-10-03 20:37 bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2012-10-03 20:37 cache -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2012-10-03 20:37 crypto -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2012-10-03 20:37 dfs -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2012-10-03 20:37 dkernel -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2012-10-03 20:37 efs -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2012-10-03 20:37 idme -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2012-10-03 20:37 misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2012-10-03 20:37 recovery -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2012-10-03 20:37 system -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2012-10-03 20:37 userdata -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2012-10-03 20:37 xloader -> /dev/block/mmcblk0p1
Click to expand...
Click to collapse

timmytim said:
I'm jumping and starting to develop for this device and just got the mount points. This is for anyone else that wants that cares :silly:
Click to expand...
Click to collapse
Not to pick nits here, but those are actually the partition names -> device names. I hope you don't mind if I hijack your thread temporarily, but I think the following information is related.
Earlier this evening, a friend of mine let me borrow her KFHD for a few days with a "you break it, you bought it" proviso. Naturally, I've been playing around with it a bit.
I've also been looking at the way the storage space has been laid out on the KFHD. I think the most interesting change for most people will be the way the userdata partition is being used. I haven't seen this information posted anywhere, so I just wanted to share for the curious.
On the original KF, there are separate userdata and media partitions. The userdata partition gets mounted on /data and it's used mostly to store apps, settings, etc. The media partition gets mounted on /sdcard and that's used to store movies, music, books and other large files.
For the KFHD, the media partition is gone and the bulk of the storage space has been allotted to the userdata partition. That partition still gets mounted on /data, but /data now also contains a media directory. The KFHD then uses /data/media as the root for a virtual filesystem that gets mounted on /sdcard.
There have been at least a few users who mentioned repartitioning the original KF to get more space for apps by sacrificing space on /sdcard and vice versa. No such tradeoffs are required on the KFHD, because all of the user's files now get stored on one filesystem. As a result, the storage space gets a chance to be used more efficiently. I just thought that was a very tidy solution and an upgrade to the way things were done in the original.
Now, to get somewhat back on topic, here are the partition table details for the KFHD...
Code:
# parted /dev/block/mmcblk0 print
Error: Can't have overlapping partitions.
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131kB 262kB 131kB xloader
2 262kB 524kB 262kB bootloader
3 524kB 590kB 65.5kB idme
4 590kB 606kB 16.4kB crypto
5 606kB 608kB 2048B misc
6 1049kB 11.5MB 10.5MB dkernel
7 11.5MB 213MB 201MB ext4 dfs
8 213MB 230MB 16.8MB ext4 efs
9 230MB 238MB 8389kB recovery
10 238MB 246MB 8389kB boot
11 246MB 1175MB 929MB ext4 system
12 1175MB 1857MB 682MB ext4 cache
13 1857MB 15.6GB 13.8GB ext4 userdata

I dont mind at all. I've always referred to those as mount points but thinking about it now I realize I was wrong, lol.
Thanks man

kinfauns said:
Not to pick nits here, but those are actually the partition names -> device names. I hope you don't mind if I hijack your thread temporarily, but I think the following information is related.
Earlier this evening, a friend of mine let me borrow her KFHD for a few days with a "you break it, you bought it" proviso. Naturally, I've been playing around with it a bit.
I've also been looking at the way the storage space has been laid out on the KFHD. I think the most interesting change for most people will be the way the userdata partition is being used. I haven't seen this information posted anywhere, so I just wanted to share for the curious.
On the original KF, there are separate userdata and media partitions. The userdata partition gets mounted on /data and it's used mostly to store apps, settings, etc. The media partition gets mounted on /sdcard and that's used to store movies, music, books and other large files.
For the KFHD, the media partition is gone and the bulk of the storage space has been allotted to the userdata partition. That partition still gets mounted on /data, but /data now also contains a media directory. The KFHD then uses /data/media as the root for a virtual filesystem that gets mounted on /sdcard.
There have been at least a few users who mentioned repartitioning the original KF to get more space for apps by sacrificing space on /sdcard and vice versa. No such tradeoffs are required on the KFHD, because all of the user's files now get stored on one filesystem. As a result, the storage space gets a chance to be used more efficiently. I just thought that was a very tidy solution and an upgrade to the way things were done in the original.
Now, to get somewhat back on topic, here are the partition table details for the KFHD...
Code:
# parted /dev/block/mmcblk0 print
Error: Can't have overlapping partitions.
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131kB 262kB 131kB xloader
2 262kB 524kB 262kB bootloader
3 524kB 590kB 65.5kB idme
4 590kB 606kB 16.4kB crypto
5 606kB 608kB 2048B misc
6 1049kB 11.5MB 10.5MB dkernel
7 11.5MB 213MB 201MB ext4 dfs
8 213MB 230MB 16.8MB ext4 efs
9 230MB 238MB 8389kB recovery
10 238MB 246MB 8389kB boot
11 246MB 1175MB 929MB ext4 system
12 1175MB 1857MB 682MB ext4 cache
13 1857MB 15.6GB 13.8GB ext4 userdata
Click to expand...
Click to collapse
hello,
excuse me,i have a question: how have you got that? What's command have you write?
-> adb shell
-> su
-> parted
?

Android (Linux) Command Parted - Example
magikstar said:
hello,
excuse me,i have a question: how have you got that? What's command have you write?
-> adb shell
-> su
-> parted
?
Click to expand...
Click to collapse
magikstar,
The command is: parted here is examples on how the command is used:
Connect a Android Device to the PC USB, then reboot into recovery
At the command prompt type the command: adb shell
{
"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"
}
Open parted with the command: parted/dev/block/mmcblk0
To see The list of partitions and the capacity on the sdcard, type the command: print
The above example was not the Kindle, it is just to be used as an example.
---------- Post added at 07:15 PM ---------- Previous post was at 07:12 PM ----------
timmytim said:
I'm jumping and starting to develop for this device and just got the mount points. This is for anyone else that cares :silly:
Click to expand...
Click to collapse
timmytim,
Thank you for posting these Partition names, this is helpful.

How do I pull the 9, 10, & 11 blocks to a Windows 7 hard drive for future flashing?
timmytim said:
I'm jumping and starting to develop for this device and just got the mount points. This is for anyone else that cares :silly:
Click to expand...
Click to collapse
Is there a way using ADB to pull the boot, recovery, and system partitions to my hard drive for flashing if needed?

bobcat131 said:
Is there a way using ADB to pull the boot, recovery, and system partitions to my hard drive for flashing if needed?
Click to expand...
Click to collapse
Yes there is, see STEP 1. here - http://forum.xda-developers.com/showthread.php?t=2128848
Or this:
Code:
adb shell su -c "dd if=/dev/block/mmcblk0boot0 of=/sdcard/boot0block.img"
adb shell su -c "dd if=/dev/block/platform/omap/omap_hsmmc.1/by-name/boot of=/sdcard/stock-boot.img"
adb shell su -c "dd if=/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery of=/sdcard/stock-recovery.img"
adb shell su -c "dd if=/dev/block/platform/omap/omap_hsmmc.1/by-name/system of=/sdcard/stock-system.img" # This will take a few minutes
adb pull /sdcard/boot0block.img
adb pull /sdcard/stock-boot.img
adb pull /sdcard/stock-recovery.img
adb pull /sdcard/stock-system.img # This will take a few minutes
Credit to Hashcode :good:

Backup
Thanks for this quick answer. Where will these images be found - on the sdcard or on the hard drive?

bobcat131 said:
Thanks for this quick answer. Where will these images be found - on the sdcard or on the hard drive?
Click to expand...
Click to collapse
I think they are first saved to the SD Card then can pulled from there to your Hard Drive with the adb pull commands.

backup
Thanks again. I'll try on my KFSOWI today.

Backup/Restore
Gilly10 said:
I think they are first saved to the SD Card then can pulled from there to your Hard Drive with the adb pull commands.
Click to expand...
Click to collapse
I dumped them and pulled them to my hard drive okay. However, when I flashed them, all went well, until the system.img. I got this error when flashing the system img. "Invalid sparse file format at header magi"
How do I fix this?

If you are on the 2013 that makes more sense, the system image on a 2013 model you pull can't fit in fastboot's buffer so it would be useless, though I don't get why it thought it was sparsed, it shouldn't have been. I do recall seeing that error at one point while we were researching a way to restore the 2013 model when it gets bricked.
Sent from my Amazon Kindle Fire HD using Tapatalk

stunts513 said:
If you are on the 2013 that makes more sense, the system image on a 2013 model you pull can't fit in fastboot's buffer so it would be useless, though I don't get why it thought it was sparsed, it shouldn't have been. I do recall seeing that error at one point while we were researching a way to restore the 2013 model when it gets bricked.
Sent from my Amazon Kindle Fire HD using Tapatalk
Click to expand...
Click to collapse
Is there a way to increase fastboot's buffer size?
Sent from my 2013 Kindle Fire HD

Backup/Restore
stunts513 said:
If you are on the 2013 that makes more sense, the system image on a 2013 model you pull can't fit in fastboot's buffer so it would be useless, though I don't get why it thought it was sparsed, it shouldn't have been. I do recall seeing that error at one point while we were researching a way to restore the 2013 model when it gets bricked.
Sent from my Amazon Kindle Fire HD using Tapatalk
Click to expand...
Click to collapse
Yes, it is the 2013 edition. Now it is stuck at the boot logo (color Kindle Fire). It has ADB and fastboot recognition and I have a factory cable.
Any suggestions on how to unbrick this device using fastboot ??

Mineturtle33 said:
Is there a way to increase fastboot's buffer size?
Sent from my 2013 Kindle Fire HD
Click to expand...
Click to collapse
There are 2 reasons we can't do this, one is because even if we adjusted it we have no way to sign the new uboot so the device would hard brick upon flashing. The second reason is the buffer the file gets stored on is the devices ram. In this case the system image is around 1.3 GB, while the kindle only has 1gb of ram so there's a physical limitation.
bobcat131 said:
Yes, it is the 2013 edition. Now it is stuck at the boot logo (color Kindle Fire). It has ADB and fastboot recognition and I have a factory cable.
Any suggestions on how to unbrick this device using fastboot ??
Click to expand...
Click to collapse
Good news is this was recently developed: http://forum.xda-developers.com/showthread.php?t=2685090
It should restore it as long as you can get it into fastboot. Because of the fastboot buffer limitation, this pushes a partial resized system image that has just enough file to boot up, then pushes a amazon update to the device and forces it to update the system partition to a full os. Its really clever.
Sent from my Amazon Kindle Fire HD using Tapatalk

stunts513 said:
There are 2 reasons we can't do this, one is because even if we adjusted it we have no way to sign the new uboot so the device would hard brick upon flashing. The second reason is the buffer the file gets stored on is the devices ram. In this case the system image is around 1.3 GB, while the kindle only has 1gb of ram so there's a physical limitation.
Good news is this was recently developed: http://forum.xda-developers.com/showthread.php?t=2685090
It should restore it as long as you can get it into fastboot. Because of the fastboot buffer limitation, this pushes a partial resized system image that has just enough file to boot up, then pushes a amazon update to the device and forces it to update the system partition to a full os. Its really clever.
But how to restore, if system.img is unflashable. I tride but still stuck at boot logo. HELP!:crying:
Click to expand...
Click to collapse

His system image is flashable because of some modifying he did, though I'm not sure if he included the matching boot image and recovery that goes with it, I'll check on it in a bit.
Sent from my Amazon Kindle Fire HD using Tapatalk

stunts513 said:
His system image is flashable because of some modifying he did, though I'm not sure if he included the matching boot image and recovery that goes with it, I'll check on it in a bit.
Sent from my Amazon Kindle Fire HD using Tapatalk
Click to expand...
Click to collapse
I'm scratching my head, either i'm its not there or i'm stupid, i don't see the utility to download to fix the problem on the gdrive. Am i missing something?

I have Kindle Fire HD7 2012. After including of my kindle device(press the power button) is showing the Kindle Fire logo and then is showing the coloured inscription of "Provisioning Fail"

I been looking but to no avail... Is there a problem with backing up all 12 partitions and maybe making a zip file for otheres to use in KFFAide or is it gonna contain information thats personal to device and to user?

[GUIDE] VZW Note-4 DE Backup Developer Partitions

GUIDE how to backup Verizon Developer Device aboot Partition​
All Samsung Developer Devices are identical to retail devices with exception of one partition "aboot". What is all this fuss aboot? This partition holds the magic that unlocked your bootloader. It has a signed SHA256 key that a thousand Monkeys could not crack. If this partition is overwritten or corrupt the DE phone could brick, and bootloader will lock. Welcome to retail. This partition is device ID specific and coded to the device with super encryption. If this partition is backed up prior to corruption, it could be possible to restore a locked developer device. Some discussion of DE's aboot here and here
As of this writing several DE owners were smart enough to backup aboot, several were able to restore their unlocked bootloader. They were able to restore with the help of several XDA devleopers that were able to take the pre-saved aboot, and make it into an Odin flashable tar. It was reported that EFS Professional could create an Odin flashable aboot.tar.gz, that doesn't need any prior modifications. This info was incorrect, all backups of aboot will require modification prior to flashing. If you accidentally "Retail" your DE, post to this thread, and myself or one of the other devs will fix your backup. There is risk involved with restore, so please don't perposly flash your device to retail.
(No you can't flash aboot on your retail phone)
There are several ways to backup this unique partition, these procedures are not real difficult, but care should be taken. One method is by using ADB. Big learning curve, but rewarding. install Google SDK and use ABD [ADB Guides] Setup and run ADB, and backup the partition using dd command. This is a computer to Android terminal interface via USB. If you have used Linux scripts, this should easy peasy once ADB is functional. Copy and paste a script to copy aboot to SD, and the rest of the partitions using the ADB Method below.
You could even copy aboot to your phone's SD using your recovery file editor, or use ADB pull (permissions, mount, could make this tough though).
There is a cool program built by XDA contributor @lyriquidperfection, it's called EFS Professional It is a very powerful tool, it runs on windows computers, and uses a GUI, no scripts, just point and, click, click, click Easy Method.
Both interfaces require ROOT, and use Busybox. SuperSU, and busybox must be installed on your device prior, as well as Samsung drivers (Direct link to VZW Note 4 DE )
I like BusyBox Tools by Stephen (Stericson), or try Busybox On Rails
Disclaimer: If you are careful, study a bit, and follow direction closely there isn't much risk. Please be careful, these tools are capable of bricking your phone if you blindly explore other commands. If you run into problems, Post to this thread, someone will help you. If you go poking around the advanced user commands and mess it up, good luck. Don't hate on me if you do something stupid.
1. ADB Method Here is a quick guide that I made while backing up my note-4 DE. I point out the path to the partitions on Note-4. The VZW note-4 aboot partition is mmcblk0p7 This location and partition number are different in other DE models. This backup will need to be made flash-able if it's ever needed.
2. EFS Professional Easy Method (This guide will work for the other developer devices too. Tested on Note-3 & Galaxy S5 Developer Editions)
Download EFS Professional on windows computer, install EFSProfessional. This program has an imbedded version of ADB built in (don't run any other ADB programs at the same time)
Make sure USB debug is checked under phone's setting "Developer options", tick "USB debugging" (might already be ticked) If "developer options" tab is missing from "Settings", go to "Settings", "About phone", then tap, tap, tap, on "Build number" do it spasticly until it unlocks, aboot 7 times. ha ha Canada
(Click on the attached thumbnails to enlarge them to huge)
View attachment 3075958 View attachment 3075959
Hook the phone to USB & computer prior to running EFSPro. Keep an eye on the phones screen when the program starts, a few popups will probably pop up on the phone, allow your computer's RSA key, tic the always remember, and allow access to your computer. SU will pop up on the screen too, grant access. (If it doesn't connect, check phone's drop down for connection options. Worst case, toggle usb debug off/on while attempting connection in efspro).
{
"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"
}
Click on EFS Professional, The only folder you need to use is under the backup tab. Don't mess around under the other tabs, just click on backup.
View attachment 3048807 View attachment 3125707
Under the Backup Tab select "manage" Then select "Create New". Now you will create a PIT file, the map of your DE's system.
View attachment 3075885 View attachment 3075886
Type in the File name, display name, and description. I typed "note-4" in all three boxes.
View attachment 3181033
Click "Read Pit" a popup will nag, just click "OK" and continue, device written, click "OK", Then hit "Save".
View attachment 3075888
You now have your DE's PIT, the road map to your system partition. Ready to backup aboot? Lets go, press "Manage" then "refresh". Now your new pit should be visible under the "manage" drop down.
View attachment 3075899
From the drop down find your device (Note-4), and "select" it.
View attachment 3075900 View attachment 3075901
"Deselect all", then tic aboot only (You don't want to save all in one zip, it's +3GB, and will take forever, and most likely choke on it's self. Later after backing up aboot you can go back, and save the other partitions that aren't backed up by TWRP).
View attachment 3075902 View attachment 3075911
Click "backup". When it's finished you should now have two copies of aboot zipped up in a nice file (Note-4_xxxxxxxx.tar.gz) in EFSProBackup folder on your internal SD (or External SD), and on your computer both locations should contain a TAR of aboot. You can rename it "MyNote4_aboot.tar.gz". Later you should also manually move this to external SD using Root Explorer or ES File explorer
View attachment 3075912
Now is the time to donate to @lyriquidperfection , or a least go back to his OP and hit the thanks button.
View attachment 3075913
If a stock Tar is accidentally flashed, locking the boot loader, the phone won't be able to run EFS Pro because it requires root, and busybox, and may not boot anyway. If you do somehow lock your boot loader. Post your request for help to this thread, someone will PM you asking for your aboot backup, one of the devs here will make your aboot odin flashable, and send it back ready to go.
*Odin can't flash all the partitions, only the ones that are mapped in your PIT file. Please do a second backup, make a combined zip, select the following: aboot.mbn, NON-HLOS.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn. This will up your insurance policy to premium
Now that your are "out of the woods", go back into EFSPro and backup all partition blocks, minus a few huge ones that are already backed up by your recovery. I back up all blocks on a fresh DE image, before installing a bunch of apps (recovery, SuperSU, and Busybox). If you have a bunch of stuffs already installed you might want to skip blocks: 25 Cache, and 27 User Data. They are huge, and redundant if you already backed up everything in TWRP. You do have everything backed up in TWRP, right???
Eye glazing stuffs: The backups can be un-zipped to a tar, aboot.mbn.tar. Then unzipped again to reveal the unzipped partitions. These can be selectively modified into an Odin flash-able tar.md5. This part should be done by a developer because some hex editing and special software adds an md5 checksum .
Don't be the one that flashes a stock image tar, or allows a repair kiosk to touch your precious. Hopefully the insurance policy you just made won't ever have to be claimed.
Check back for correction, and updates. Please post your results good, or bad to this thread.
THANKS!

Nice guide I will have to do this

radionerd said:
Samsung Developer Devices are identical to retail devices with exception of one partition "aboot". If this partition is overwritten or corrupt the phone will brick, and bootloader will lock. This partition is device ID specific and coded to the boot partition, and device. If both of these partitions are backed up prior to corruption, it would be possible to restore a locked developer device.
There are several ways to backup these unique partitions, these procedures are not real difficult, but care should be taken. One method is by using ADB. install Google SDK and use ABD [ADB Guides] Setup and run ADB, and backup the partitions using dd command. This is a computer to phone terminal interface via USB. If you have used Linux scripts, this should easy peasy once ADB is functional.
There is a cool program built by XDA contributor lyriquidperfection, it's called EFS Professional It is a very powerful tool that runs on windows computers, and uses a GUI, no scripts, just point and click
Both interfaces use Busybox, so it must be installed on your device prior.
I like BusyBox Tools by Stephen (Stericson), or Busybox On Rails
Disclaimer: If you are careful, study a bit, and follow direction closely there isn't much risk. Please be careful these tools are capable of bricking your phone if you explore other commands. If you run into problems, I will try to help.
1. ADB Method Here is a quick guide that I made while backing up my note-4 DE. The VZW note-4 aboot partition is mmcblk0p7 This location and name are different in other models.
2. EFS Professional Method
Download EFS Professional on windows computer, install it. This program has a imbedded version of ADB built in (don't run any other ADB programs at the same time)
Make sure USB debug is checked under phone's setting, Developer options tick USB debugging (should already be ticked) If developer options is missing, go to settings, About phone, tap tap tap "Build number" spasticly until it unlocks.
Hook the phone to USB prior to running EFSPro. Keep an eye on the phones screen when the program starts, a few popups will probably pop up on the phone, Tic the always remember, and allow access to the computer. SU will pop up on the screen too, grant access.
View attachment 3048807
(Click on the attached photos to enlarge them)
The only folder you need to use is under the backup tab. Don't mess around under the other tabs, just backup.
Under the Backup Tab select "manage" Then select "Create New". Now you will create a PIT file, and grab a map the DE system.
View attachment 3048818
Type in the File name, display name, and description. I typed "note-4".
Then Click "read device", it should look like the picture below. Then hit "Save".
View attachment 3048835
You now have a Note-4 PIT, and map. Ready to backup aboot and boot, just press "Manage" then "refresh". Now your new pit should be visible under "manage drop down".
From the drop down find your device, and "select" it.
View attachment 3048845
"Deselect all", then tic aboot and boot only (You don't want to save all in one zip, it's Gigs, and will take forever, and most likely choke on it's self later you can go back and save the other partitions that aren't backed up by TWRP).
Then click "backup", when it's done you should now have an efsprofessional folder on your internal SD, and on your computer that contains a TAR of aboot and boot.
View attachment 3048866
Now is the time to donate to Liquid Perfection, or a least go back to his OP and hit the thanks button.
This is a ruff work in progress, but it's getting late, so check back for typos, correction, and updates. Please post your results good, or bad to this thread.
THANKS!
Click to expand...
Click to collapse
This is great work. Thanks so much. We've already seen a couple of our fellow Note 4 DE owners need a aboot backup to restore their unlocked bootloader. This is a must for any DE owner. It's like an insurance policy.

How do you restore?
Once you use the dd command in terminal emulator or in adb, or once you have an efs-professional backup of your aboot, so you have an aboot.mbn or aboot.bak, how do you restore it if you have inadvertently, let's say, flashed a retail edition aboot by flashing a retail full tar file from Odin for instance? I bought a Note 3 DE last year, and I made a copy of my aboot as soon as I got it, using the dd command, the file is about 2mb, but so far I don't know how to restore it if it does get the retail aboot installed on it by accident. Could you please shed some light on the restoration procedure as well?
Also, I know if you backup your /efs partition on twrp, it can't be restored if you mess it up, supposedly that's what makes the phone tick and gives it its identity, I have read about a few people on this forum that accidentally deleted their /efs partition and their phone never worked right after that, like their unlock screen wouldn't work and a lot of other stuff was messed up, as they described. If you make a /efs backup with efs-professional, could it be restored correctly if the /efs partition gets corrupted by accident? I don't really know why anyone would need to delete that partition, but I think some rom or modem update procedure did it, but just in case it happens.
Thank you for the great work and tutorial

newuser134 said:
Once you use the dd command in terminal emulator or in adb, or once you have an efs-professional backup of your aboot, so you have an aboot.mbn or aboot.bak, how do you restore it if you have inadvertently, let's say, flashed a retail edition aboot by flashing a retail full tar file from Odin for instance? I bought a Note 3 DE last year, and I made a copy of my aboot as soon as I got it, using the dd command, the file is about 2mb, but so far I don't know how to restore it if it does get the retail aboot installed on it by accident. Could you please shed some light on the restoration procedure as well?
Click to expand...
Click to collapse
Hopefully no one will have to be the Guinea Pig, and restore a corrupted aboot from accidentally flashing a retail TAR on their DE. As far as I know only one guy has tried aboot restore successfully, with big help from a dev who made his prior saved aboot flashable.
As far as I know aboot restore is untested with efsprofessional, I have successfully restored other partitions using efspro on my note-3 DE.
Unfortunately every DE version that has been released has had several folks overwrite aboot; accidentally, or in desperation flash retail Tars, by themselves, by Samsung service center, or at a retail store kiosk, like bestbuy.
Your DE warranty, and insurance is your backups. Samsung won't fix your corrupted system, if they do (only if no knox trip 0x0), you will receive your phone with a retail image put on it. Having an aboot backup could possibly bring it back to DE.
newuser134 said:
Also, I know if you backup your /efs partition on twrp, it can't be restored if you mess it up, supposedly that's what makes the phone tick and gives it its identity, I have read about a few people on this forum that accidentally deleted their /efs partition and their phone never worked right after that, like their unlock screen wouldn't work and a lot of other stuff was messed up, as they described. If you make a /efs backup with efs-professional, could it be restored correctly if the /efs partition gets corrupted by accident? I don't really know why anyone would need to delete that partition, but I think some rom or modem update procedure did it, but just in case it happens.
Click to expand...
Click to collapse
Been there done that, Most of the guys that had efs messed up on Note-3 DE, including myself, we used the first T-mobile TWRP version that didn't backup the right efs partition, upon TWRP restore we had major problems, some of us compounded the problems, me too TWRP was quickly updated, and a few of us figured out ways to rebuilt /efs.
"What I learned was backup your backup, then back that up too" I do complete TWRP backup as soon as rooted, DD of all partitions, then backup all partitions, except a few huge partitions using efspro.
newuser134 said:
Thank you for the great work and tutorial
Click to expand...
Click to collapse
Thanks WIP, hope to add soon "copy and paste" scripts for all the partitions.

Thanks for the instructions. I hope to never need it, but I will follow this procedure just to be on the safe side.

Doesn't TWRP handle this by ticking on the EFS checkbox when making a backup?

solidunit said:
Doesn't TWRP handle this by ticking on the EFS checkbox when making a backup?
Click to expand...
Click to collapse
TWRP does backup EFS, but not aboot, or a handful of other partitions. EFS pro can backup all partitions.

radionerd said:
Type in the File name, display name, and description. I typed "note-4".
Then Click "read device", it should look like the picture below. Then hit "Save".
View attachment 3048835
Click to expand...
Click to collapse
When I get to the "read device" step I get an error saying it cannot find the pit file in the EFS folder. What am I missing? Thanks

tfly212 said:
When I get to the "read device" step I get an error saying it cannot find the pit file in the EFS folder. What am I missing? Thanks
Click to expand...
Click to collapse
Did you click on the Manage box and select "create new"
Then read device
Then name note-4 on device name, display name, and description, then click save
go back to manage, click refresh
Then go to device filters, find your note 4
de-select all, then select aboot
Then click backup.
Now you should have a "double zipped" file of aboot in your computer efsprofessional folder, and on your sdcard.
Attached a few pictures from my note 3

radionerd said:
Did you click on the device filter box "v" and select "create new"
Then read
Click to expand...
Click to collapse
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.

tfly212 said:
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.
Click to expand...
Click to collapse
Great!
I will go look at the wording of the OP

tfly212 said:
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.
Click to expand...
Click to collapse
Buy him some nappies for his kid
Thanks man,
I updated my OP with 27 8"x10" color glossy photos with circles and arrows

radionerd said:
Buy him some nappies for his kid
Thanks man,
I updated my OP with 27 8"x10" color glossy photos with circles and arrows
Click to expand...
Click to collapse
Will do...I have a little one also, and while a beer sounds better, the way they go through diapers is staggering.

How do I find my computers RSA key? I am on windows 8.1?

texasez said:
How do I find my computers RSA key? I am on windows 8.1?
Click to expand...
Click to collapse
You don't need to know the computer's RSA key, The RSA pop-up comes up on your phone when entering ADB mode. The key is in the pop-up, Just grant access.

Is the "sbl1bak" a backup of the "sbl1" ????????

larrycjr said:
Is the "sbl1bak" a backup of the "sbl1" ????????
Click to expand...
Click to collapse
Yup,
However sb1bak is empty on my note 4
Easy look at Note 4 partition Mounts by-name (trltevzw)
aboot -> /dev/block/mmcblk0p7 (2048KB)
apnhlos -> /dev/block/mmcblk0p1
boot -> /dev/block/mmcblk0p17
cache -> /dev/block/mmcblk0p25
carrier -> /dev/block/mmcblk0p26
dbi -> /dev/block/mmcblk0p5
ddr -> /dev/block/mmcblk0p6
efs -> /dev/block/mmcblk0p13
fota -> /dev/block/mmcblk0p19
mdm1m9kefs1 -> /dev/block/mmcblk0p14
mdm1m9kefs2 -> /dev/block/mmcblk0p15
mdm1m9kefs3 -> /dev/block/mmcblk0p10
mdm1m9kefsc -> /dev/block/mmcblk0p16
misc -> /dev/block/mmcblk0p20
modem -> /dev/block/mmcblk0p2
pad -> /dev/block/mmcblk0p11
param -> /dev/block/mmcblk0p12
persdata -> /dev/block/mmcblk0p23
persist -> /dev/block/mmcblk0p22
recovery -> /dev/block/mmcblk0p18
rpm -> /dev/block/mmcblk0p8
sbl1 -> /dev/block/mmcblk0p3
sbl1bak -> /dev/block/mmcblk0p4
ssd -> /dev/block/mmcblk0p21
system -> /dev/block/mmcblk0p24
tz -> /dev/block/mmcblk0p9
userdata -> /dev/block/mmcblk0p27

I finally get past the RSA problem by using installer mode on phone but the phone auto changes back to media device and then efs pro does not recognize the phone. I tried camera (ptp) mode but it will not go past pressing the device info button on efs pro. How do I make the phone stay in installer mode. I keep getting popups wanting me to install the verizon software but I did not install.
How do I keep the installer mode active?

Your obviously on the dev edition?? Correct? If so if it's not to much to ask will you send me a copy of your sbl1. Please.
Sent from my SM-N910V

Backup EFS

Can someone post how one can backup efs? I did it thru adb on my one. Just want to make sure how to do it on the two. Thank you

From TWRP recovery choosing into backup only EFS

damsolu said:
From TWRP recovery choosing into backup only EFS
Click to expand...
Click to collapse
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again

i lost my efs with no backup anyhelp?

godzulu said:
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again
Click to expand...
Click to collapse
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst2). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.

Spannaa said:
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst1). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.
Click to expand...
Click to collapse
yeah..i have backup EFS from twrp but only realize that the EFS backup from TWRP is not EFS, now my IMEI2 lost & i dont know how to solve it. really head ache

I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?

akashpopat21 said:
I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?
Click to expand...
Click to collapse
Did you read the last few posts?

there is one more option, you can backup via flashfire

On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa

Droidlover123 said:
On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa
Click to expand...
Click to collapse
The oem_stanvbk partition contains the modem (static_nvbk.bin) which is included in OOS roms.
Not sure why you'd want to explore it...

I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.

pryggi said:
I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.
Click to expand...
Click to collapse
It doesn't, it's just the modem/radio.
AFAIK, the IMEIs are in modemst1 & modemst2 (The two modem firmware data partitions).

Yep, this is my understanding too. On op2 the modem firmware is in
oneplus2:/ # ls -l /dev/block/platform/soc.0/f9824900.sdhci/by-name
..
lrwxrwxrwx 1 root root 20 1970-08-26 21:51 modem -> /dev/block/mmcblk0p1
And the modem settings/imeis are in:
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst1 -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst2 -> /dev/block/mmcblk0p18
The question is, if it is possible to figure out the format of the data on p17/p18 and edit it by adding the imei2 back.
It doesn't seem to be a file system:
Oneplus2:/ # fdisk -l /dev/block/mmcblk0p17
Disk /dev/block/mmcblk0p17: 1 MB, 1572864 bytes
4 heads, 16 sectors/track, 48 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device /dev/block/mmcblk0p17: doesn't contain a valid partition table
file -L /dev/block/mmcblk0p17
/dev/block/mmcblk0p17: block special
and
blkid -o value -s TYPE /dev/block/mmcblk0p17
does not return anything.
And if you open the modemst1/2.bin files it seems to be binary data, which does not make sense even in hex editor.
I wonder if oneplus staff could help the poor souls who have lost the imei2 and disclose this info how to get imei2 back...

Motorola Moto G Partitions Explained

DISCLAIMER: This thread is unofficial and may contain errors. This information comes from personal knowledge and research from other threads. I am not responsible for what you do with your device.
Context
This thread is intended to provide an explanation of the function and importance of each partition on the Motorola Moto G. Some partitions are very ambiguous, but I will attempt to describe what these partitions store, and whether they are unique/permanent/temporary etc. Again, I am not a developer, but I hope that this will explain the structure of the partitions to new users. Also, feel free to leave more information about these partitions in the comments, and I will try to update the OP with that information.
The following partition layout can be found with root access using various commands such as
Code:
ls /dev/block/platform/msm_sdcc.1/by-name
List of partitions
Code:
DDR -> /dev/block/mmcblk0p3
aboot -> /dev/block/mmcblk0p4
abootBackup -> /dev/block/mmcblk0p11
boot -> /dev/block/mmcblk0p31
cache -> /dev/block/mmcblk0p33
cid -> /dev/block/mmcblk0p25
clogo -> /dev/block/mmcblk0p28
dhob -> /dev/block/mmcblk0p20
fsc -> /dev/block/mmcblk0p22
fsg -> /dev/block/mmcblk0p21
hob -> /dev/block/mmcblk0p19
kpan -> /dev/block/mmcblk0p35
logo -> /dev/block/mmcblk0p27
logs -> /dev/block/mmcblk0p9
misc -> /dev/block/mmcblk0p30
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p17
modemst2 -> /dev/block/mmcblk0p18
padA -> /dev/block/mmcblk0p10
padB -> /dev/block/mmcblk0p16
pds -> /dev/block/mmcblk0p26
persist -> /dev/block/mmcblk0p29
recovery -> /dev/block/mmcblk0p32
rpm -> /dev/block/mmcblk0p5
rpmBackup -> /dev/block/mmcblk0p12
sbl1 -> /dev/block/mmcblk0p2
sdi -> /dev/block/mmcblk0p7
sdiBackup -> /dev/block/mmcblk0p14
sp -> /dev/block/mmcblk0p24
ssd -> /dev/block/mmcblk0p23
system -> /dev/block/mmcblk0p34
tz -> /dev/block/mmcblk0p6
tzBackup -> /dev/block/mmcblk0p13
userdata -> /dev/block/mmcblk0p36
utags -> /dev/block/mmcblk0p8
utagsBackup -> /dev/block/mmcblk0p15
Partition explanations
Terminology
- Partition: A hard drive, eMMC, or any storage device can be divided into separate section called partitions. Most Windows, OS X or Linux machines have 1 to 3 partitions but android devices tend to have many.
- Unique: This means this partition contains data is specific to only that device, e.g. serial numbers, IMEIs, MAC addresses etc. This data cannot be found on the internet and so one should be careful not to modify or lose it.
- Flashing: Writing data to a disk or partition, replacing what was already there.
- Root ("/"): Not to be confused with "root access", this is the Unix term for the top directory. Similar to C:\, but everything is stored in it, including partition mount points.
Common Partitions
boot: This partition contains the boot image, which includes the kernel, a device tree blob (this describes the hardware to the kernel), and the ramdisk for the root filesystem (not root access - see above). This partition is usually flashed when installing custom or stock ROMs, and can be found within stock firmware. This partition does not contain the bootloader.
system: This partition contains the Android system files (i.e. the ROM). This is what is flashed (alongside 'boot') when installing a ROM, and what is modified to give root access. Before rooting or installing a ROM, one should backup this partition (and boot) to ensure they can restore to stock.
recovery: This partitions hold the files that allow one to enter ‘recovery mode’, which is essentially a second boot partition that allows one to apply OTAs, make/restore backups, and install ROMs or root binaries. This partition will either hold the stock recovery, or a custom recovery. Custom recoveries can be flashed and allow the user to backup, restore, install to and wipe other partitions, among other features. This partition can be safely modified but ensure to always have a stock recovery flashed when applying stock OTAs.
userdata: Also known as the Data partition, this is where every user file, preference and is stored, e.g. photos, settings, app settings, messages, and everything created directly or indirectly by the user. This partition is empty on a new device, and is mounted at /Data. This partition should always be backed up before modifying the phone as it contains essentially everything personal on the phone.
cache: Another common partition; this historically contained temporary data that allows the system and apps to run more efficiently. Now it is mostly used by the recovery. Nothing important is stored here, and so it can, and often should, be wiped when necessary.
Other Partitions
Bootloader Related Partitions
aboot: This partition seems to be the main part of the bootloader. It loads the kernel and is responsible for the bootloader menu and fastboot functionality. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
abootBackup: This likely stores a backup of the aboot partition.
tz: This partition also seems to be related to the bootloader, specifically something called 'Trust Zone' . This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
tzBackup: Again, this likely stores a backup of the 'tz' partition.
rpm: Another bootloader related partition. This partition could possibly be the 'Resource and Power Manager' manager partition. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
rpmBackup: hopefully you get the general idea by now...
sdi: I have no idea, but it is flashed as part of motoboot.img, therefore it must be bootloader related. Is included with stock firmware.
sdiBackup: A backup of the above.
sdb1: Bootloader related. Interestingly, after looking around, I found that this appears to contains files relating to a 'Secondary BootLoader'. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
Network Related Partitions
modemst1 and modemst2: These partitions appear to contain non-essentials/temporary network related data. Interestingly, they are erased when flashing a stock rom, meaning they are probably not crucial, possibly some kind of ‘baseband cache’?
modem: The modem partition contains modem/baseband related files. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it also is likely not unique (again ensure to get firmware for the right region).
fsg: This partition also contains files related to the modem firmware/baseband. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it likely contains non-unique data (but ensure to get firmware for the right region).
Maybe ‘fsg’ and ‘modem’ are related to the modemst1 and modemst2 partitions?
Important/Unique Partitions
pds: This partition likely contains important device specific data like the IMEI, Serial Number, etc. It is important to backup this partition when you get the chance, as people in other threads attribute the loss of the IMEI to this partition. This is not included in stock firmware, reinforcing the importance of backing up this partition.
persist: Apparently this partition contains files related to WiFi, Bluetooth, MAC addresses etc. Nevertheless, it is quite important and should be backed up if possible.
hob and dhob: The exact function is not known, but they appear to contain very important information relating to the modem and/or IMEI.
fsc: Appears to be empty. Although, this partition could sometimes store important IMEI related info. Not included in factory firmware and so best left alone.
Extra
ssd: This partition appears to contains files related to something called the ‘Secure Software Download’ feature. These files are not included in factory firmware so should be left alone.
logo: This partition contains the startup splash screen and bootloader unlock warning. This partition is included with stock firmware.
clogo: After doing some research, it appears this partition might store the boot logo in an image format. Interestingly, this is not included in stock firmware, unlike the 'logo' partition.
cid: This partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
sp: Like CID, this partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
misc: This partition contains ‘miscellaneous system settings’, more specifically, this partition also helps the bootloader boot to recovery and pass information between boot stages. This partition is best left alone as it is apparently very important, and not included in stock firmware.
padA and padB: Apparently these are empty.
kpan: This partition seems to store kernel panic data.
logs: Possibly stores some form of log files.
utags: These partition seem to contain information used by the barcodes option in the bootloader menu.
utagsBackup: A backup of the above.
Unknown Partitions
DDR <-- Device Description Repository?.. Dance Dance Revolution?..
I could not find any information about the function of the above partitions. Although, none of these partitions are included in factory firmware, so they are likely important and best left alone. Anyone is welcome to share they own knowledge or opinion on what these partitions are for in the comments.
Sources/Interesting information:
Moto G Partition Layout.
http://forum.xda-developers.com/showthread.php?t=2540799
Bootloader Related Partitions (motoboot.img - tz, rpm, sdi, aboot, and sbl1).
http://forum.xda-developers.com/showthread.php?t=2644703&page=2
http://forum.xda-developers.com/mot...rom-xt1033-t3357718/post66336145#post66336145
Great reading about partitions on Samsung phones, although it appears a lot of this information is relevant to the Moto G. Specifically, this thread gives some hints about the function of motoboot.img, baseband partitions and the 'ssd' partition.
http://forum.xda-developers.com/showthread.php?t=1959445
Possible explanation of modemst1, modemst2 and fsg partitions. (About Samsung partitions but still relevant).
http://forum.xda-developers.com/showthread.php?p=49587431#post49587431
Instructions on flashing factory firmware.
http://forum.xda-developers.com/showthread.php?t=2542219
CID, Trust Zone, and SP partition Information.
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
Possible /misc explanation, also some simple explanation of common partitions for new users.
http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
Some more /misc info
http://linux-sunxi.org/Android/partitions
Thread with some information relating to 'hob' and 'dhob'
http://forum.xda-developers.com/moto-g/help/imp-imei-backup-scripts-moto-g-eall-t3174569
Moto X Boot Logo Change - Appears to show purpose of 'clogo' partition on Moto G
http://www.talkandroid.com/guides/m...on-the-moto-x-splash-screen-no-root-required/
Info on Persist partition
http://forum.xda-developers.com/google-nexus-5/general/guide-to-fix-persist-partition-t2821576
https://forums.lenovo.com/t5/MOTO-G...gs-like-hell-after-update/td-p/3231064/page/2
Likely explanation of 'kpan' partition - although 'Kernel PANic' does fit well
https://plus.google.com/+hashcode0f/posts/W84mLxfMomf
Information vaguely referencing 'logs' partition
http://www.ptsmobile.com/tc55/tc55-integrator-guide.pdf
http://techtablets.com/forum/topic/help-windows-fell-by-flash-android/
Info on 'utags'
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/page26
Finally, thanks to @_that for extra information and corrections.

Most awesome first post I've ever seen. :good:
A few additions:
"boot" and "recovery" both contain a boot image. It begins with the magic string "ANDROID!" and they contain a Linux kernel image, a device tree blob (tables describing the hardware for the kernel), and a ramdisk image for the root ("/") filesystem.
"system" is actually mounted at /system at runtime. "userdata" is mounted on "/data".
"cache" is mostly used for communicating with the recovery.
"aboot" is the Android bootloader. It is the last step in the bootloader chain which loads the kernel. It also implements the bootloader menu and the fastboot protocol.
"logo" contains the startup splash screen and the ugly "your bootloader is unlocked" image. The boot animation is part of /system.
"misc" is used, among other things, by Android to tell the bootloader to boot to recovery.
"padA" and "padB" are really empty.
"hob" and "dhob" are somehow very important for the modem to work.

_that said:
Most awesome first post I've ever seen. :good:
A few additions:
"boot" and "recovery" both contain a boot image. It begins with the magic string "ANDROID!" and they contain a Linux kernel image, a device tree blob (tables describing the hardware for the kernel), and a ramdisk image for the root ("/") filesystem.
"system" is actually mounted at /system at runtime. "userdata" is mounted on "/data".
"cache" is mostly used for communicating with the recovery.
"aboot" is the Android bootloader. It is the last step in the bootloader chain which loads the kernel. It also implements the bootloader menu and the fastboot protocol.
"logo" contains the startup splash screen and the ugly "your bootloader is unlocked" image. The boot animation is part of /system.
"misc" is used, among other things, by Android to tell the bootloader to boot to recovery.
"padA" and "padB" are really empty.
"hob" and "dhob" are somehow very important for the modem to work.
Click to expand...
Click to collapse
Thanks _that. I've updated the OP with this info.

Which of these partitions stores the PRL file
Professor Gibbins said:
DISCLAIMER: This thread is unofficial and may contain errors. This information comes from personal knowledge and research from other threads. I am not responsible for what you do with your device.
Context
This thread is intended to provide an explanation of the function and importance of each partition on the Motorola Moto G. Some partitions are very ambiguous, but I will attempt to describe what these partitions store, and whether they are unique/permanent/temporary etc. Again, I am not a developer, but I hope that this will explain the structure of the partitions to new users. Also, feel free to leave more information about these partitions in the comments, and I will try to update the OP with that information.
The following partition layout can be found with root access using various commands such as
Code:
ls /dev/block/platform/msm_sdcc.1/by-name
List of partitions
Code:
DDR -> /dev/block/mmcblk0p3
aboot -> /dev/block/mmcblk0p4
abootBackup -> /dev/block/mmcblk0p11
boot -> /dev/block/mmcblk0p31
cache -> /dev/block/mmcblk0p33
cid -> /dev/block/mmcblk0p25
clogo -> /dev/block/mmcblk0p28
dhob -> /dev/block/mmcblk0p20
fsc -> /dev/block/mmcblk0p22
fsg -> /dev/block/mmcblk0p21
hob -> /dev/block/mmcblk0p19
kpan -> /dev/block/mmcblk0p35
logo -> /dev/block/mmcblk0p27
logs -> /dev/block/mmcblk0p9
misc -> /dev/block/mmcblk0p30
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p17
modemst2 -> /dev/block/mmcblk0p18
padA -> /dev/block/mmcblk0p10
padB -> /dev/block/mmcblk0p16
pds -> /dev/block/mmcblk0p26
persist -> /dev/block/mmcblk0p29
recovery -> /dev/block/mmcblk0p32
rpm -> /dev/block/mmcblk0p5
rpmBackup -> /dev/block/mmcblk0p12
sbl1 -> /dev/block/mmcblk0p2
sdi -> /dev/block/mmcblk0p7
sdiBackup -> /dev/block/mmcblk0p14
sp -> /dev/block/mmcblk0p24
ssd -> /dev/block/mmcblk0p23
system -> /dev/block/mmcblk0p34
tz -> /dev/block/mmcblk0p6
tzBackup -> /dev/block/mmcblk0p13
userdata -> /dev/block/mmcblk0p36
utags -> /dev/block/mmcblk0p8
utagsBackup -> /dev/block/mmcblk0p15
Partition explanations
Terminology
- Partition: A hard drive, eMMC, or any storage device can be divided into separate section called partitions. Most Windows, OS X or Linux machines have 1 to 3 partitions but android devices tend to have many.
- Unique: This means this partition contains data is specific to only that device, e.g. serial numbers, IMEIs, MAC addresses etc. This data cannot be found on the internet and so one should be careful not to modify or lose it.
- Flashing: Writing data to a disk or partition, replacing what was already there.
- Root ("/"): Not to be confused with "root access", this is the Unix term for the top directory. Similar to C:\, but everything is stored in it, including partition mount points.
Common Partitions
boot: This partition contains the boot image, which includes the kernel, a device tree blob (this describes the hardware to the kernel), and the ramdisk for the root filesystem (not root access - see above). This partition is usually flashed when installing custom or stock ROMs, and can be found within stock firmware. This partition does not contain the bootloader.
system: This partition contains the Android system files (i.e. the ROM). This is what is flashed (alongside 'boot') when installing a ROM, and what is modified to give root access. Before rooting or installing a ROM, one should backup this partition (and boot) to ensure they can restore to stock.
recovery: This partitions hold the files that allow one to enter ‘recovery mode’, which is essentially a second boot partition that allows one to apply OTAs, make/restore backups, and install ROMs or root binaries. This partition will either hold the stock recovery, or a custom recovery. Custom recoveries can be flashed and allow the user to backup, restore, install to and wipe other partitions, among other features. This partition can be safely modified but ensure to always have a stock recovery flashed when applying stock OTAs.
userdata: Also known as the Data partition, this is where every user file, preference and is stored, e.g. photos, settings, app settings, messages, and everything created directly or indirectly by the user. This partition is empty on a new device, and is mounted at /Data. This partition should always be backed up before modifying the phone as it contains essentially everything personal on the phone.
cache: Another common partition; this historically contained temporary data that allows the system and apps to run more efficiently. Now it is mostly used by the recovery. Nothing important is stored here, and so it can, and often should, be wiped when necessary.
Other Partitions
Bootloader Related Partitions
aboot: This partition seems to be the main part of the bootloader. It loads the kernel and is responsible for the bootloader menu and fastboot functionality. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
abootBackup: This likely stores a backup of the aboot partition.
tz: This partition also seems to be related to the bootloader, specifically something called 'Trust Zone' . This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
tzBackup: Again, this likely stores a backup of the 'tz' partition.
rpm: Another bootloader related partition. This partition could possibly be the 'Resource and Power Manager' manager partition. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
rpmBackup: hopefully you get the general idea by now...
sdi: I have no idea, but it is flashed as part of motoboot.img, therefore it must be bootloader related. Is included with stock firmware.
sdiBackup: A backup of the above.
sdb1: Bootloader related. Interestingly, after looking around, I found that this appears to contains files relating to a 'Secondary BootLoader'. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
Network Related Partitions
modemst1 and modemst2: These partitions appear to contain non-essentials/temporary network related data. Interestingly, they are erased when flashing a stock rom, meaning they are probably not crucial, possibly some kind of ‘baseband cache’?
modem: The modem partition contains modem/baseband related files. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it also is likely not unique (again ensure to get firmware for the right region).
fsg: This partition also contains files related to the modem firmware/baseband. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it likely contains non-unique data (but ensure to get firmware for the right region).
Maybe ‘fsg’ and ‘modem’ are related to the modemst1 and modemst2 partitions?
Important/Unique Partitions
pds: This partition likely contains important device specific data like the IMEI, Serial Number, etc. It is important to backup this partition when you get the chance, as people in other threads attribute the loss of the IMEI to this partition. This is not included in stock firmware, reinforcing the importance of backing up this partition.
persist: Apparently this partition contains files related to WiFi, Bluetooth, MAC addresses etc. Nevertheless, it is quite important and should be backed up if possible.
hob and dhob: The exact function is not known, but they appear to contain very important information relating to the modem and/or IMEI.
fsc: Appears to be empty. Although, this partition could sometimes store important IMEI related info. Not included in factory firmware and so best left alone.
Extra
ssd: This partition appears to contains files related to something called the ‘Secure Software Download’ feature. These files are not included in factory firmware so should be left alone.
logo: This partition contains the startup splash screen and bootloader unlock warning. This partition is included with stock firmware.
clogo: After doing some research, it appears this partition might store the boot logo in an image format. Interestingly, this is not included in stock firmware, unlike the 'logo' partition.
cid: This partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
sp: Like CID, this partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
misc: This partition contains ‘miscellaneous system settings’, more specifically, this partition also helps the bootloader boot to recovery and pass information between boot stages. This partition is best left alone as it is apparently very important, and not included in stock firmware.
padA and padB: Apparently these are empty.
kpan: This partition seems to store kernel panic data.
logs: Possibly stores some form of log files.
utags: These partition seem to contain information used by the barcodes option in the bootloader menu.
utagsBackup: A backup of the above.
Unknown Partitions
DDR <-- Device Description Repository?.. Dance Dance Revolution?..
I could not find any information about the function of the above partitions. Although, none of these partitions are included in factory firmware, so they are likely important and best left alone. Anyone is welcome to share they own knowledge or opinion on what these partitions are for in the comments.
Sources/Interesting information:
Moto G Partition Layout.
http://forum.xda-developers.com/showthread.php?t=2540799
Bootloader Related Partitions (motoboot.img - tz, rpm, sdi, aboot, and sbl1).
http://forum.xda-developers.com/showthread.php?t=2644703&page=2
http://forum.xda-developers.com/mot...rom-xt1033-t3357718/post66336145#post66336145
Great reading about partitions on Samsung phones, although it appears a lot of this information is relevant to the Moto G. Specifically, this thread gives some hints about the function of motoboot.img, baseband partitions and the 'ssd' partition.
http://forum.xda-developers.com/showthread.php?t=1959445
Possible explanation of modemst1, modemst2 and fsg partitions. (About Samsung partitions but still relevant).
http://forum.xda-developers.com/showthread.php?p=49587431#post49587431
Instructions on flashing factory firmware.
http://forum.xda-developers.com/showthread.php?t=2542219
CID, Trust Zone, and SP partition Information.
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
Possible /misc explanation, also some simple explanation of common partitions for new users.
http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
Some more /misc info
http://linux-sunxi.org/Android/partitions
Thread with some information relating to 'hob' and 'dhob'
http://forum.xda-developers.com/moto-g/help/imp-imei-backup-scripts-moto-g-eall-t3174569
Moto X Boot Logo Change - Appears to show purpose of 'clogo' partition on Moto G
http://www.talkandroid.com/guides/m...on-the-moto-x-splash-screen-no-root-required/
Info on Persist partition
http://forum.xda-developers.com/google-nexus-5/general/guide-to-fix-persist-partition-t2821576
https://forums.lenovo.com/t5/MOTO-G...gs-like-hell-after-update/td-p/3231064/page/2
Likely explanation of 'kpan' partition - although 'Kernel PANic' does fit well
https://plus.google.com/+hashcode0f/posts/W84mLxfMomf
Information vaguely referencing 'logs' partition
http://www.ptsmobile.com/tc55/tc55-integrator-guide.pdf
http://techtablets.com/forum/topic/help-windows-fell-by-flash-android/
Info on 'utags'
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/page26
Finally, thanks to @_that for extra information and corrections.
Click to expand...
Click to collapse
Thanks for posting such an in depth explanation on what all those partitions mean. I am using the Moto G3 2015 and I would like to know which one of those partitions stores the PRL file, I would like to manually update my PRL as I am using Cyanogenmod and do not want to deal with the hassle of going to Stock just to perform this one simple task, so I figure that I can perform a back up with Partitions Backup and Restore app, then mount the image on ubuntu, copy the new .prl file there, unmount image and then restore the image to the corresponding partition. I am assuming that's all what it would take to change my prl provided that the prl is actually stored on one of those partition.

Nice post but lacks informations about hob and dhob partitions. This post says
1. Dhob and Hob are nothing but plain text partitions, Dhob is dynamic hob and Hob is static Hob.
2. Dhob stores cryptotext by default, this crypto text contains information like Imei, ESN, Meid etc.
3. The Hob partition is a XML formatted plain-text file that contains Data which i am not sure about.
4. Uses a PBKDF2 key for encryption and decryption of Dhob.
5. The size field in Hob is Hex. So, 16 is 22 and 32 is 50.
6. The modem updates NV items on the fly which is why you can get 0 and null IMEI by fiddling.
7. In case the IMEI doesn't match with equipment then NV item is made 0.
8. EFS is created on the go not sure.
Click to expand...
Click to collapse

[Req] Vbmeta partition and others -- attempt to fix fingerprint

Hello,
I managed to break my fingerprint reader. I don't think the problem is my /persist because all sensors work fine. But unfortunately, I had never backed up the rest of the sensitive partitions: vbmeta, vbmeta_system, keystore, keymaster, odm, core_nhlos, secdata, abl, cmnlib, cmnlib64, devcfg, dsp, hyp, xbl, xbl_config, tz, rpm, aging, aging_mod.
Could someone on a TMO 7t Pro 5G McLaren (with a working fingerprint reader preferably running the latest 10.0.35 software, please pull and post these partition img files? If you don't know how, it's very simple, please ask.
I point to this because my previous phone, Essential PH1, had similar issues, but at least Essential had posted all of the firmware images on their website every month, and flashing the above partitions would fix it. 1+ doesn't provide anything and even the MSM doesn't restore all of these partitions.
Thanks so very very much in advance!
Edit: If possible, could one extract all partition img files from 10.0.35 in addition to those requested above?
EDIT2: ODM partition has 1st priority for anyone who can help.
Edit3: odm is fine. After looking through some logs,
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.

You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..

ttabbal said:
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
Click to expand...
Click to collapse
If you don't already have a backup of every partition, please please please do so urgently. Or an RMA will most likely be in your future. That should be in huge bold print with a link to instructions at the very top of the root and bootloader unlock threads.
I've never had a device with these issues before. It's starting to get ridiculous.
Edit: If you didn't take backups before unlocking the bootloader, Widevine L1 support (being able to watch Netflix in HD instead of 480p crap on our giant beautiful screens) is lost forever (except for RMA). And just flashing a "bad" canary version of magisk was enough to kill the fingerprint sensor. Of course I didn't learn any of this until it was too late.
MSM will get your phone back to life but not fully heal it. Basically all the MSM is guaranteed to do is get the phone to boot. No sensors, no fingerprint, no Widevine L1, no IMEI and wifi Mac address fix (if one is really screwed). And 1+ didn't take any measures to protect the sensitive partitions once bootloader is unlocked. It's all just a clusterf**k
Same issues on 7T and 8 and 8pro if that makes you feel any better ¯\_(ツ)_/¯

Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.

ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
Yeah, system, vendor, product, and odm are stored in super.img on Android 10. But u found it. Find out what slot you are on, running 10.0.35, and you'd want the _a or _b files that match your current slot.

ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?

starcms said:
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
Click to expand...
Click to collapse
Doesn't look really interesting to me, but here's the ls output.
Code:
OnePlus7TProNR:/sdcard/img # ls -l /odm
total 20
drwxr-xr-x 4 root root 4096 2008-12-31 17:00 etc
drwx------ 2 root root 16384 2008-12-31 17:00 lost+found
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc
total 12
-rw------- 1 root root 2735 2008-12-31 17:00 build.prop
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_dirs
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_files
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 selinux
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 vintf
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/selinux/
total 728
-rw-r--r-- 1 root root 733547 2008-12-31 17:00 precompiled_sepolicy
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.plat_sepolicy_and_mapping.sha256
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.product_sepolicy_and_mapping.sha256
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/vintf/
total 16
-rw-r--r-- 1 root root 5300 2008-12-31 17:00 manifest.xml
-rw-r--r-- 1 root root 1369 2008-12-31 17:00 manifest_ese.xml
-rw-r--r-- 1 root root 622 2008-12-31 17:00 manifest_noese.xml
I can try, but my upstream sucks. It might be faster for someone else to grab them.
-rw-r--r-- 1 travis travis 816K Jun 4 15:40 img/odm-verity.img
-rw-r--r-- 1 travis travis 1.3G Jun 4 15:41 img/product-verity.img
-rw-r--r-- 1 travis travis 2.2G Jun 4 15:40 img/system_root-verity.img
-rw-r--r-- 1 travis travis 884M Jun 4 15:43 img/vendor-verity.img

After looking through some logs, you can ignore most of that.
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
Thanks for all of your time @ttabbal. Sorry if I'm driving you crazy Been driving myself crazy trying to fix this for 2 weeks now lol
My /odm seems to be fine. Matches yours. I was mainly concerned about those 2 files with 0 size. But I don't have any of the -verity.imgs from /dev/block/mapper. I'm pretty sure they are supposed to be created and mounted at boot (from super.img and by verity/vbmeta). I'm hoping those 2 vbmeta partitions will fix things up. If not, then I'll try keystore and keymaster. And then I'll have to send it in...
Edit:. Just curious, I'm assuming you are bootloader unlocked and running Magisk? Just confirming since you have those -verity.imgs

ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.

ttabbal said:
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
Click to expand...
Click to collapse
Well, not exactly lol.
Flashed your two images via fastboot, still broken fingerprint and still missing -verity files from /dev/block/mapper/ , went to flash my backups of vbmeta and vbmeta_system via fastboot, got into a bootloop, and after a couple hours of screwing with it, finally got back where I started from...except using your images.
I don't understand. vbmeta and vbmeta_system are NOT device specific. One from my phone, one from your phone, one from anyone's phone running 10.0.35 should be exactly the same.
What exact method did you use to pull the images? dd to a tmp dir on device and then adb pull img? dd directly to computer? or adb pull the partitions themselves direct to computer? Shouldn't all 3 methods return the same results?
I swear, after the RMA I really don't know if I am going to risk unlocking the bootloader again (this is coming from someone who has had s-off/bootloader unlock/root/su/Magisk on every single android device ever owned over the past 10 years...without ever having any problem I couldn't fix by myself)

It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.

ttabbal said:
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
Click to expand...
Click to collapse
What is the need or result of the "bs=1M" in the command? I've never seen that before in other threads. I'm assuming it means block size equal to 1MB. Is that definitely required to get a good pull? Same bs for any/all partitions?
If you have persist and both EFS images backed up, you should be okay. The MSM tool can restore I think everything else. I'd keep a backup especially of any partitions that don't end in _a or _b. The MSM tool definitely takes care of the rest (those ending in _a and _b). I just hate using it because there's no way to make it not wipe userdata. And without being able to make a nandroid backup due to no fully working twrp due to A10, it's just a giant pain.
And unfortunately we can't just OTA our way to the latest, at least not by manually downloading an OTA from 1+. Only way to update is with a real OTA update from T-Mobile.
The A/B partitioning isn't the problem with development. That's been around since Android 7 or 8. It's the new dynamic partitioning format that all phones that launch with Android 10 (or newer) have. Even the Pixel 4 doesn't have fully working twrp yet. It's coming soon though...
Edit: Also, for the dd commands, did you use /dev/block/actual_partition or /dev/block/by-name/friendly_name_of_partition? Again, should it really make a difference?
Edit2: All of these issues have a root cause from Android 10. The new required partitioning system for any phones that launch with it. That's why unlocking the bootloader wipes reserve.img. Because it's in userdata (cause of A10) and 1+ forgot about that and didn't rewrite the algorithm used when the bootloader is unlocked. It's also their negligence (combined with A10) which causes persist (and other key partitions) to become so easily corrupted. Virtually all devices launched since Android 7 use "fastboot flashing unlock" and then "fastboot flashing unlock_critical" to allow changes to device specific partitions. For some reason 1+ still is using the antiquated "fastboot oem unlock" command which unlocks literally everything, even some stuff that unlock_critical doesn't, and which in the old days, didn't matter. A10 especially should not ever be used with fastboot oem unlock. Google says so lol.
If it makes you feel better, this isn't unique to this phone. It's a problem on every device 1+ has launched with A10 and still is (OP7T/TPro/OP8/Pro). Because of A10 partitioning combined with the use of an antiquated bootloader that only supports "fastboot oem unlock"

The block size doesn't matter for the pull and doesn't change the image at all. It just reads in chunks, making it faster.
Yes, I used by-name and it shouldn't matter if you use that or the sd# names.

It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.

LLStarks said:
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
Click to expand...
Click to collapse
The issue is I had a backup of my unique persist. And restoring it doesn't fix the dang fingerprint. That's why I was thinking the issue had to be elsewhere