So, just posted this a while ago at reddit, and some guy over there points out that maybe XDA is better place for this.
I'm just realized this afternoon by looking my android one device (sprout_b, indonesian version).
The Indian version (sprout) got updated to lollipop, and have the new device protection. Even if I flashed and used the said update on my device, I can't use the new device protection.
So I tried to compare both system files and boot.img, and found 1 partition missing on my device, FRP.
I investigated more about this, and it seems that both nexus 6 and 9 got this partition too (under the name PST).
And then, wild sudden clarity appears! FRP = Factory Reset Protection.
So, both my devices (nexus 5 and nexian journey 1 -android one- ) probably didn't receive this protection, because the partition needed for it isn't there.
For more info, here's the fstabs from both android one branch (sprout and sprout_b):
sprout:
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/mtk-msdc.0/by-name/system /system ext4 ro wait
/dev/block/platform/mtk-msdc.0/by-name/userdata /data ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check,encryptable=/dev/block/platform/mtk-msdc.0/by-name/metadata
/dev/block/platform/mtk-msdc.0/by-name/cache /cache ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check
/dev/block/platform/mtk-msdc.0/by-name/protect1 /protect_f ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check
/dev/block/platform/mtk-msdc.0/by-name/protect2 /protect_s ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check
/dev/block/platform/mtk-msdc.0/by-name/oem /oem ext4 ro,context=u:object_r:oemfs:s0,nosuid,nodev wait
/devices/platform/mtk-msdc.1/mmc_host* auto vfat defaults voldmanaged=sdcard0:auto,noemulatedsd
/dev/block/platform/mtk-msdc.0/by-name/frp /persistent emmc defaults defaults
sprout_b:
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/mtk-msdc.0/by-name/system /system ext4 ro wait
/dev/block/platform/mtk-msdc.0/by-name/userdata /data ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check,encryptable=/dev/block/platform/mtk-msdc.0/by-name/metadata
/dev/block/platform/mtk-msdc.0/by-name/cache /cache ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check
/dev/block/platform/mtk-msdc.0/by-name/protect1 /protect_f ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check
/dev/block/platform/mtk-msdc.0/by-name/protect2 /protect_s ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check
/dev/block/platform/mtk-msdc.0/by-name/oem /oem ext4 ro,context=u:object_r:oemfs:s0,nosuid,nodev wait
/devices/platform/mtk-msdc.1/mmc_host* auto vfat defaults voldmanaged=sdcard1:auto
FRP is also mentioned in file_contexts file in boot.img:
Code:
/dev/block/mmcblk0p18 u:object_r:frp_block_device:s0
So, what do you guys think?
So its a hardware partition that attaches itself to a google account? pardon my knwledge..m a dental surgeon..
Interesting. Creating a FRP partition by taking away some space from userdata would not hurt.
The rest is to find the files which responsible to the factory reset protect.
bitdomo said:
Interesting. Creating a FRP partition by taking away some space from userdata would not hurt.
The rest is to find the files which responsible to the factory reset protect.
Click to expand...
Click to collapse
there's also this build.prop entry:
Code:
ro.frp.pst=/dev/block/platform/mtk-msdc.0/by-name/frp
in case of nexus 6:
Code:
ro.frp.pst=/dev/block/platform/msm_sdcc.1/by-name/frp
and nexus 9:
Code:
ro.frp.pst=/dev/block/platform/sdhci-tegra.3/by-name/PST
also, this article.
awaaas said:
there's also this build.prop entry:
Code:
ro.frp.pst=/dev/block/platform/mtk-msdc.0/by-name/frp
in case of nexus 6:
Code:
ro.frp.pst=/dev/block/platform/msm_sdcc.1/by-name/frp
and nexus 9:
Code:
ro.frp.pst=/dev/block/platform/sdhci-tegra.3/by-name/PST
also, this article.
Click to expand...
Click to collapse
What is the size of the FRP partition?
Can you light me up what is this factory reset protection actually do? Does it prevent to perfrom a factory reset or event after you do factory reset you still have to enter the pin lock or enter the pattern? How do you enable it on a supported device? How do you know it is enabled?
bitdomo said:
Can you light me up what is this factory reset protection actually do? Does it prevent to perfrom a factory reset or event after you do factory reset you still have to enter the pin lock or enter the pattern? How do you enable it on a supported device? How do you know it is enabled?
Click to expand...
Click to collapse
I believe it will not let you factory reset the device unless you enter your Google account username and password.
bitdomo said:
What is the size of the FRP partition?
Can you light me up what is this factory reset protection actually do? Does it prevent to perfrom a factory reset or event after you do factory reset you still have to enter the pin lock or enter the pattern? How do you enable it on a supported device? How do you know it is enabled?
Click to expand...
Click to collapse
Let say that X's phone is stolen by Y, Y then proceed to factory reset the phone from recovery mode because the lockscreen is protected by a password.
The system will let Y to do that, but, upon starting the system, the setup wizard will not allow him to pass unless you gave him the last google account username and password that was active on that phone.
Bootloader is locked and you must toggle the unlock state in developer options (like nexus 6), so no custom recovery to wipe the frp partition, and re-flashing with factory image also doesn't touching that partition too.
From android police
I don't have a device that support it, but will search about the size around.
awaaas said:
Let say that X's phone is stolen by Y, Y then proceed to factory reset the phone from recovery mode because the lockscreen is protected by a password.
The system will let Y to do that, but, upon starting the system, the setup wizard will not allow him to pass unless you gave him the last google account username and password that was active on that phone.
Bootloader is locked and you must toggle the unlock state in developer options (like nexus 6), so no custom recovery to wipe the frp partition, and re-flashing with factory image also doesn't touching that partition too.
From android police
I don't have a device that support it, but will search about the size around.
Click to expand...
Click to collapse
I played a little.
I made frp partition. As I saw from the previous link it is a 512 kb large unformated partition.
I built a kernel with adding the frp partition to the fstab and context file.
I edited the build.prop to add the ro.frp.pst string.
I could not make it work, but some data appeared on the frp partition. 35 bytes of data
I am lost at the moment what else I could do. I should somehow get logs but have no idea what I have to look for in dmesg or logcat.
Maybe there are some libs and scripts? Or we need some reverse engineering? Or it needs stock rom? Anyone knows if this feature works on the custom roms of nexus 6 or 9?
bitdomo said:
I played a little.
I made frp partition. As I saw from the previous link it is a 512 kb large unformated partition.
I built a kernel with adding the frp partition to the fstab and context file.
I edited the build.prop to add the ro.frp.pst string.
I could not make it work, but some data appeared on the frp partition. 35 bytes of data
I am lost at the moment what else I could do. I should somehow get logs but have no idea what I have to look for in dmesg or logcat.
Maybe there are some libs and scripts? Or we need some reverse engineering? Or it needs stock rom? Anyone knows if this feature works on the custom roms of nexus 6 or 9?
Click to expand...
Click to collapse
maybe the GServices check for the device?, also take a look at the note edge, the OTA to Lollipop on the sprint variant has an interesting comment
Added Factory Reset Protection. so by this thread, it also got the device protection feature?
bitdomo said:
I played a little.
I made frp partition. As I saw from the previous link it is a 512 kb large unformated partition.
I built a kernel with adding the frp partition to the fstab and context file.
I edited the build.prop to add the ro.frp.pst string.
I could not make it work, but some data appeared on the frp partition. 35 bytes of data
I am lost at the moment what else I could do. I should somehow get logs but have no idea what I have to look for in dmesg or logcat.
Maybe there are some libs and scripts? Or we need some reverse engineering? Or it needs stock rom? Anyone knows if this feature works on the custom roms of nexus 6 or 9?
Click to expand...
Click to collapse
In the article I mentioned earlier, it mentioned the new service for this, android.service.persistentdata.IPersistentDataBlockService (frameworks/base/services/core/java/com/android/server/PersistentDataBlockService.java) for it to be active.
Also, for sprout, I had to dig in more:
So, in fstab.sprout, it listed like this:
Code:
/dev/block/platform/mtk-msdc.0/by-name/frp /persistent emmc defaults defaults
and in file_contexts, it listed like this:
Code:
/dev/block/mmcblk0p18 u:object_r:frp_block_device:s0
after downloading several stock rom for sprout, I looked at their scatter file (like PIT for samsung devices), and didn't found about FRP partition. So, I searched about this mmcblk0p18 mentioned earlier in file_contexts, turns out it is actually a partition called "gen", and the size is 71.5 MB. This partition is actually available in my sprout_b device, yet the corresponding feature didn't work out.
awaaas said:
In the article I mentioned earlier, it mentioned the new service for this, android.service.persistentdata.IPersistentDataBlockService (frameworks/base/services/core/java/com/android/server/PersistentDataBlockService.java) for it to be active.
Also, for sprout, I had to dig in more:
So, in fstab.sprout, it listed like this:
Code:
/dev/block/platform/mtk-msdc.0/by-name/frp /persistent emmc defaults defaults
and in file_contexts, it listed like this:
Code:
/dev/block/mmcblk0p18 u:object_r:frp_block_device:s0
after downloading several stock rom for sprout, I looked at their scatter file (like PIT for samsung devices), and didn't found about FRP partition. So, I searched about this mmcblk0p18 mentioned earlier in file_contexts, turns out it is actually a partition called "gen", and the size is 71.5 MB. This partition is actually available in my sprout_b device, yet the corresponding feature didn't work out.
Click to expand...
Click to collapse
Awesome! I am checking the source code of the persistent datablock service. Now atleast I know what do I have to look for to find errors (hope i will find).
I will give it a try tomorrow. My poor phone was wiped like 10 times today.
I could not rest.... my mind was constantly ticking on this.
Well this is something.
I tell the rest tomorrow, but at first look it is working. It didnt let me pass by entering other email addresses it just jumped back to the wifi selection mode without saying anything (is that normal?). Anyway after I loged in with my google account it let me pass.
I got it working without making any new partition.
I am using the partition called "grow", 5,5 kiB in size, as it is not being used by or for anyithing. It looks like that amount of space is enough.
What I did to make it work:
I went back to stock LMY47I rom from my AOSP rom.
I added this line to /system/build.prop:
Code:
ro.frp.pst=/dev/block/platform/msm_sdcc.1/by-name/grow
I extracted the kernel's ramdisk and added the folowing lines to the following files:
fstab.hammerhead
Code:
/dev/block/platform/msm_sdcc.1/by-name/grow /peristent emmc defaults
file_contexts
Code:
/dev/block/platform/msm_sdcc\.1/by-name/grow u:object_r:frp_block_device:s0
ueventd.hammerhead.rc
Code:
/dev/block/platform/msm_sdcc.1/by-name/grow 0600 system system
Then I packed the kernel (get it) and flashed it to the phone.
I added these changes to the hammerhead device tree if someone is intrested.
awaaas said:
Bootloader is locked and you must toggle the unlock state in developer options (like nexus 6), so no custom recovery to wipe the frp partition, and re-flashing with factory image also doesn't touching that partition too.
Click to expand...
Click to collapse
So 'fastboot oem unlock' no longer works? With that you could load a custom recovery and wipe any partition.
frankusb said:
So 'fastboot oem unlock' no longer works? With that you could load a custom recovery and wipe any partition.
Click to expand...
Click to collapse
Fastboot oem unlock will be disallowed by default. You must toggle the option under developer settings to be able to do that.
awaaas said:
Fastboot oem unlock will be disallowed by default. You must toggle the option under developer settings to be able to do that.
Click to expand...
Click to collapse
It will be disallowed by default? By the Nexus 5 boot loader? In what cases? It either is or it isn't today. I can't try it on my Nexus 5.
I looked for that option under development options on my Nexus 5 and did not find anything.
frankusb said:
It will be disallowed by default? By the Nexus 5 boot loader? In what cases? It either is or it isn't today. I can't try it on my Nexus 5.
I looked for that option under development options on my Nexus 5 and did not find anything.
Click to expand...
Click to collapse
That option comes up only if you have a dedicated frp partition, but for nexus 5 it is useless to enable or disable it because the bootloader will not check the OEM enable bit on the dedicated frp partition unlike nexus 6's bootloader.
frankusb said:
It will be disallowed by default? By the Nexus 5 boot loader? In what cases? It either is or it isn't today. I can't try it on my Nexus 5.
I looked for that option under development options on my Nexus 5 and did not find anything.
Click to expand...
Click to collapse
that is the case of nexus 6 (and probably 9).
Today, my Indonesian android one device got update to LMY47O, and lazy google is lazy, they didn't rip out the device protection option bit from my device, it didn't work at the first place. They didn't even bother to edit the boot.img ramdisk, leaving Indian setting there.
Related
This thread will list and link to all core device essential stuff.
PM me if there is new stuff or something doesn't work please
STOCK ASUS FIRMWARE
WW_epaduser_11_4_1_17_UpdateLauncher.zip: HERE
US_epaduser_11_4_1_17_UpdateLauncher.zip: HERE
WW_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
US_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
CN_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
TW_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
US_epaduser_10_26_1_7_UpdateLauncher.zip: HERE
TW_epaduser_10_26_1_7_UpdateLauncher.zip: HERE
CN_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
JP_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
US_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
WW_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
CN_epaduse_10_14_1_45_UpdateLauncher.zip: HERE
How to flash:
Step 1: Download and unzip the zipfile of your choice.
Step 2: Copy the new Zipfile and paste it in root directory of your internal SdCard, then reboot the device and the update will automatically start.
ASUS SOURCE CODE
kernel_10_14_1_42.rar: HERE
kernel_10_14_1_45.rar: HERE
kernel_10_14_1_47.rar: HERE
kernel_10_26_1_7.rar: HERE
kernel_10_26_1_18.rar: HERE
kernel_11_4_1_17.rar: HERE
UNLOCK YOUR DEVICE
0820-0954_SIGNED_UnLock_for_TF701_repart.apk: HERE
How to unlock:
- Download the Asus unlock app
- Install and run the app. This will require a valid google account (if you use one time passwords, you'll need to generate one for this purpose) and internet access.
- When booting with [vol-] + [power] pressed, the transformer will show the message "The device is unlocked"
ROOT TOOLS
Read here: http://forum.xda-developers.com/showthread.php?t=2516215
CUSTOM RECOVERY
CWM Recovery V6.0.4.8. for 4.3*: HERE
ATTENTION: you must have an unlocked bootloader
How to flash this:
- reboot device into fastboot mode:
- adb reboot bootloader
- now flash the recovery using : fastboot flash recovery recovery.img [where recovery.img is the name of the file image you downloaded]
CUSTOM ROM'S
By Sbdags based on stock with quite some enhancements: HERE
CyanogenMod 11 Preview Proxy thread: HERE
THEMES
Non available yet
BOOTANIMATIONS
Non available yet
OTHER MOD'S
None available yet
PARTITION INFORMATION**
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
RECOVERY.FSTAB**
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
BLOB**
Code:
name size description status
10.14.1.47: [ATTACH]2435244[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248[/ATTACH]
10.26.1.7: [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
**= Thanks to Ipdunwell for sharing this info
HOW TO UNBRICK YOUR DEVICE
Read here: http://forum.xda-developers.com/showpost.php?p=47933481&postcount=1
ATTENTION
YOUR WARRANTY COULD BE VOID DUE TO ROOTING AND UNLOCKING YOUR DEVICE (depending of which country you reside)
I am NOT responsible for bricked devices, dead SD cards or dead docks.
Please do some research if you have any concerns about the files here BEFORE flashing anything!
When you have no clue what we are talking about here you better leave your hands off it!!
YOU are choosing yourself freely to use these file(s) all by yourself!!!
Updated Recovery for 4.3 with working "external" SD card, found here
http://forum.xda-developers.com/show....php?t=2621051
Custom Rom's
Cromi-x
http://forum.xda-developers.com/show....php?t=2608129
CM11 -Preview (Unofficial)
http://forum.xda-developers.com/show....php?t=2621028
Delete
Root and firmware.
Hello all. I'm new to the site, and very sorry if this is a dumb question, but Id rather sound dumb than brick my transformer.. I'm planning to root my TF701 following lpdunwells guide. One of the prerequisites is to have 10.14.1.47 as the firmware version. My question is this.. When I unlock my bootloader and it wipes my tablet, will it reset me back to the original firmware version? Or will this matter?
My current firmware version is 10.26.1.18
Thank you very much in advance for your help, also, I will greatly appreciate any and all help and info regarding this matter.
tf701mega said:
Hello all. I'm new to the site, and very sorry if this is a dumb question, but Id rather sound dumb than brick my transformer.. I'm planning to root my TF701 following lpdunwells guide. One of the prerequisites is to have 10.14.1.47 as the firmware version. My question is this.. When I unlock my bootloader and it wipes my tablet, will it reset me back to the original firmware version? Or will this matter?
My current firmware version is 10.26.1.18
Thank you very much in advance for your help, also, I will greatly appreciate any and all help and info regarding this matter.
Click to expand...
Click to collapse
If you want to root then use my guide as it is for 10.26.1.18. Downgrading to .47 and back up again is really painful.
download problem
Hi OP,
Download links are down...
please fix theme?
henengel said:
Hi OP,
Download links are down...
please fix theme?
Click to expand...
Click to collapse
anyone know where I can get the files? links are broken
kuthedude said:
anyone know where I can get the files? links are broken
Click to expand...
Click to collapse
Which files are you looking for?
Most of the files are available from ASUS's website and the ROM and recovery links are old and newer ones are available in the Development section of this form.
Sorry for the inconvenience.
Asked in the OP to PM me if there is new stuff or if somethings doesn't work but received nothing.
Files will be back end of the day with latest firmware and kernel source.
Hi, I am getting my tablet soon, and I am assuming the tablet will be on 4.3 or earlier by the time I get it.
What firmware/kernal/boot loader is the best setup to get me onto the latest 4.3 OS. I only am wanting this because I want to avoid the 4.4.2 battery drain issues (since I am most likely going to flash an AOSP ROM after I get this tablet).
Also, how would I be able to properly update the tablet with the firmware/kernal/boot loader? Thanks for the help!
Sent from my SCH-I545 using Tapatalk 2
Hi, I tried pushing my firmware file to root, but it wouldn't work. I would use root explorer and it would just freeze and restart. anyone know why this would happen? Im trying to update to 4.3 without getting into 4.4.2. please help if you can
You have to unpack the file, inside this is another zip file. Put it then in sd root this should work as far as i know
Gesendet von meinem LG-D855 mit Tapatalk
Hi
There is a new firmware version 11.4.1.27.
Is it posible to add this version to the post?
Hi. There is a thread here where we are wondering if SuperSu full unroot is enough to allow an OTA to succeed (assuming no other mods were made to the system other than root) (Nexus 6, Lollipop). There is speculation but hard to find a definitive answer on the subject. Anyone here able to shed light on that? Thanks!
It depends.
OTAs can update various parts of the system in various ways.
Previous to Lollipop, updates to the system partition were usually (but not always) done file-based. Which meant that if you removed/renamed all the modified files and put back their originals, the OTA would work. And thus, SuperSU's OTA survival option and/or the unroot option would allow OTAs to complete.
Partition-based OTAs have become standard with Lollipop. Some OEMs have used them before (different implementation), but it was rare. This new style OTA does not patch the differences between files, but on the underlying partition contents. If you make changes to a partition's filesystem and then revert them so that all the files and their contents are original again, this does not actually mean the partition contents are completely the same. In fact, just remounting /system read-write and not making any modification changes the partition contents - that specific change is actually the first thing these OTAs check.
If the OTA is partition based (which by far most OTAs upgrading from 5.0 to something newer will be) the only way to guarantee the correct contents of the system partition so that the patch script will succeed is to reflash the entire partition.
Chainfire said:
Partition-based OTAs have become standard with Lollipop.
Click to expand...
Click to collapse
I wonder if that is because of problems from rooted devices and modified System partitions. They now replace the entire partition to ensure a successful update.
Chainfire said:
In fact, just remounting /system read-write and not making any modification changes the partition contents - that specific change is actually the first thing these OTAs check.
Click to expand...
Click to collapse
Is that because some people leave '/system' read-write or is there some residual change even after the partition is returned to read-only. In other words: if someone remounts '/system' read-write and immediately returns it to read-only without any writes to it, is there some detectable change that remains.
Frank
Frank Westlake said:
I wonder if that is because of problems from rooted devices and modified System partitions. They now replace the entire partition to ensure a successful update.
Click to expand...
Click to collapse
No, it's for dmverity. A kernel-based security system that verifies the system partition contents are as the manufacturer intended. It requires the partition contents to be predictable and verifyable on block level. See https://source.android.com/devices/tech/security/secureboot/index.html for further details.
Frank Westlake said:
Is that because some people leave '/system' read-write or is there some residual change even after the partition is returned to read-only. In other words: if someone remounts '/system' read-write and immediately returns it to read-only without any writes to it, is there some detectable change that remains.
Click to expand...
Click to collapse
Yes, there is.
From what I can see though (in updater-script), in current OTA for past Nexus devices, they are still file-based, even for 5.0>5.0.1(2) upgrade path.
This is not truth for Nexus 6 and 9 OTAs, which are partition-based from day one.
Hell, I've decided to restore stock on my Moto and sell it, as I'm pretty sure I'm going to settle with the OnePlus One I also got with their offers.
I think I recall while flashing ROMs for this device I had to reformat Data to EXT4, but now when I go to change the FS again I don't have option for F2FS.
Could one of you please load up recovery, go into Wipe > Advanced Wipe > check "Data" choose "Repair or Change File System" and verify what the line "current file system" says for you?
Would be much appreciated.
Shemploo said:
Hell, I've decided to restore stock on my Moto and sell it, as I'm pretty sure I'm going to settle with the OnePlus One I also got with their offers.
I think I recall while flashing ROMs for this device I had to reformat Data to EXT4, but now when I go to change the FS again I don't have option for F2FS.
Could one of you please load up recovery, go into Wipe > Advanced Wipe > check "Data" choose "Repair or Change File System" and verify what the line "current file system" says for you?
Would be much appreciated.
Click to expand...
Click to collapse
Mine says EXT4.
My data partition is on F2FS on stock lollipop.
sivarticus85 said:
Mine says EXT4.
Click to expand...
Click to collapse
Which partition did you check?
divergens said:
My data partition is on F2FS on stock lollipop.
Click to expand...
Click to collapse
I wonder why TWRP does not have option to change to F2FS, I'm using 2.8.4.1
Shemploo said:
I wonder why TWRP does not have option to change to F2FS, I'm using 2.8.4.1
Click to expand...
Click to collapse
I just tried booting TWRP 2.8.4.0 and I don't see an option for F2FS either. Was this available before in older versions of TWRP? I never bother to switch from the stock recovery to TWRP at any point.
Shemploo said:
Which partition did you check?
Click to expand...
Click to collapse
You asked for the Data partition.
I brought it up in the TWRP thread. Maybe someone there can answer this for us.
sivarticus85 said:
You asked for the Data partition.
I brought it up in the TWRP thread. Maybe someone there can answer this for us.
Click to expand...
Click to collapse
divergens said:
I just tried booting TWRP 2.8.4.0 and I don't see an option for F2FS either. Was this available before in older versions of TWRP? I never bother to switch from the stock recovery to TWRP at any point.
Click to expand...
Click to collapse
Yes, it was in a previous version, I remember changing partitions cause of ROM not working.
Its interesting that both of your partitions are different. Did neither of you change them?
Shemploo said:
Yes, it was in a previous version, I remember changing partitions cause of ROM not working.
Its interesting that both of your partitions are different. Did neither of you change them?
Click to expand...
Click to collapse
I never purposefully changed partitions via TWRP, in fact I never have used TWRP on my Moto X yet. All the flashing I have done was with fastboot.
Now that you mention it, I remember my data partition being EXT4 back in kitkat. I don't know if it changed because of lollipop. I did flash a lollipop image from motofirmware at one point. However, then I went back to kitkat using Motorola's official kitkat image and took the OTA to lollipop.
Yeah I never purposefully changed it either. Twrp just doesn't format it to f2fs like it should. I wonder if doing a factory reset from within the stock recovery will revert it back?
Edit: Yeah that did it. Stock recovery reverts it back to f2fs. Verified by checking it twrp again afterward. That's the only way to get back as of right now.
Ha! - I got the same thing, I booted the latest TWRP and checked the partition, it's listed as F2FS, it would seem that 4.4.x is EXT4 and the upgrade to Lollipop changes is to F2FS, very interesting.
UPDATE: It looks like the option to change FS to F2FS is there when you install a theme, I got it under TWRP Materiel theme, but it seems that this might just be a button designed in case the function is introduced as it actually does not convert the FS.
UPDATE2: After loading the Material theme to get the Change FS to F2FS, the log says "mkfs.f2fs binary not found, using rm -rf to wipe"
Seems something is missing from the latest TWRP release?
I think twrp don't have f2fs because its not really cross platform mountable. Ext4 can be mounted easily with windows, Linux or Mac so it makes things easier for "devs", " tweakers" to just have ext4 support.
Since the first Nougat dev build, I've been running stock unlocked Android. However, I haven't been able to keep my recovery installed, and I've had to reflash it via my computer every time I wanted to be able to flash things via TWRP. In addition, nothing I flash (except when I root the device, for some reason) survives the reboot into system, even if it was a successful flash. Any help is appreciated.
Nexus 6
Stock Android 7.0 Nougat
Unlocked, but not rooted
Sent from my Nexus 6 using Tapatalk
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
doitright said:
Specifically, the script at /system/bin/install-recovery.sh.
Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
I've never made an edit to the recovery.sh file but I've always ran a noforce nonverify boot img and TWRP always stuck for me. I read that when you allow TWRP to modify system that it automatically edits this file which I do. Is this way it's sticking? I never had any problems and it seems a lot of "TWRP not sticking" threads are popping up.
Sent from my Nexus 6 using XDA-Developers mobile app
doitright said:
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
Could you explain how to do all of that? I have no idea what to edit or where those things are.
Sent from my Nexus 6 using Tapatalk
Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.
vp1117 said:
Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.
Click to expand...
Click to collapse
all partitions are set to RO because of dynamic partitions
gianonceu said:
all partitions are set to RO because of dynamic partitions
Click to expand...
Click to collapse
This does not answer my question how to get RW on this particular model. Probably, you know that RW can be easily achieved on other realme phones. Actually, on dozens of phones with super partition where we're bound to have dynamic partitions.
Also, when you say "...partitions are set to RO..." what exactly you mean? Set by whom? To repeat: I've manually removed shared_blocks features on all super sub-partitions and then re-created super. When I flash it, I can clearly check in TWRP that tune2fs -l does not show shared_blocks anymore. So, who has set partitions to RO?
If you know what mechanism of android sets RO on super sub-partitions with shared_blocks removed - please share your knowledge.
Well, judging by no responses the question appears to be of almost zero interest for forum members. Is this the case?
I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.
so i have this problem yet
Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!
vp1117 said:
I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.
Click to expand...
Click to collapse
Can u guide me in same issue I'm also stuck paid no problem
lebigmac said:
Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!
Click to expand...
Click to collapse
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.
vp1117 said:
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.
Click to expand...
Click to collapse
Bro can u try something for me?
In your root dir have folder with name "proc" can u go inside and cut file and move to sdcard or any other modifications to check whether this past also editable or not?