Database Users

[Q] Nexus 7 reboots constantly every 2 mins or so

My stock/unlocked nexus 7 2012 updated to android 4.4.0 KRT16S after being idle about 12 hours, i picked it up and just a couple minutes into browsing it started rebooting on it's own.
The weird things don't end here, since after every reboot it goes back to the exact same state it was before: if it were done updating an app, or I enabled ADB or turned off the wifi or whatever, and then suddenly reboots, all these things would go to the state they were before (WIFI on, ADB off, changes in apks, even files sideloaded).
I tried to clear the cache through recovery, but it didn't work, I also tried sideloading the ota update to 4.4.2, but it won't find the file in the root folder, as it just disappears. When i went to the nexus tool kit i was not able to unlock the bootloader, or to factory reset( not even from the device itself) or do anything to get out of this situation.
The only thing i can do for now is turn the tablet off and do nothing with it.
Has anyone an idea i can try?

Can really nobody help?
Sent from my Nexus 4 using Tapatalk

You have to create a hypothesis and then perform an experiment that tests that hypothesis. (There's a ferociously complicated processor and millions of lines of code involved; nobody is going to put their finger on the exact cause of a vaguely described problem from across the internet)
For instance:
Hypothesis A: There is a significant hardware problem which causes spontaneous reboots, and it doesn't matter what software is running for the fault to appear.
Test A: Plug the tablet in to the charger and boot it in to the recovery. Let it sit a while. Does it spontaneously reboot?
Hypotheses B: There is a software problem with the ROM I am using that causes sponateous reboots.
Test B: Back up your data, wipe the tablet, install a brand new ROM, and use it for a while. Does it still reboot?
Hypotheses C: The userdata partition got corrupted somehow which causes it to remount automatically in read-only mode. (Changes are not persistent and the ROM reboots all the time as a result)
Test C: Similar to test B, but destroy the userdata partition and reformat it using fastboot. Put a new ROM on a USB memory stick and use the OTG mounting features of the recovery to deliver a new ROM to the tablet. Is it still rebooting?
See how that goes?
Not trying to be mean or anything, but the lack of responses are probably due to several things; the leading candidate of which is that you mentioned using a toolkit - a sure sign of lack of understanding of how most of this stuff actually works.
It's OK to not understand everything - all of us are learning all the time, and everybody has to start at the beginning. Toolkits surely make some jobs faster - at the cost of hiding the details of how things actually work - and making their users helpless when something goes wrong. Try to avoid them if you can.
good luck

Thank you for the long and elaborate response! I will be the first to admit that I have limited knowledge about these things but the main reason that I used the toolkit was that everything else I tried failed. Of course, as you said there are plenty of things I could have tried, and I tried to explain everything I did to make the job easier for someone to help me out, surely not to let my questions unanswered!
So thank you for the answer, and i'll try everything as soon as possible and keep it posted up
Sent from my Nexus 4 using Tapatalk

Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk

Googsx said:
Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.

bftb0 said:
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.
Click to expand...
Click to collapse
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?

Googsx said:
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?
Click to expand...
Click to collapse
The settings you (try to) apply when the ROM is running (eg the USB debugging toggle) do not affect the recovery. The entire point of a recovery is to have a standalone boot that doesn't depend on other partitions.
Having said that, the use of a "pseudo" SD card that is actually part of the userdata filesystem sometimes does cause problems for the recovery - it tries to mount /data to get you access to ROM files, nandroid backups, etc. I recall getting my N7 into a condition where TWRP's touch interface wouldn't come up because of problems with the userdata partition. But, adb was still available as was fastboot (in the bootloader mode). Also, I was not having spontaneous reboots.
The fact that you are observing spontaneous reboots in the recovery indicates that you might have Hypothesis A going on - flaky hardware. At a minimum however, it means you will not be able to run any long duration backups... for instance, trying to make a rescue backup of your SD card.
You could try and do
Code:
fastboot erase userdata
fastboot format userdata
with the tablet in bootloader mode. Obviously this step will destroy all of your data.
If your tablet is still spontaneously rebooting after that (in the recovery) then your only option will be to return it for repair (motherboard replacement).

Apps Cannot Access Internal Memory after TWRP Recover

Background:
Trying out ROMs here and there, making backups along the way in TWRP. Turn out I had my favorite ROM from the start, so clean all the slates and performed a restore to Hybrid X Series 1.07. Everything is as it was...almost.
Apps are complaining about not being able to download to internal memory, there not being enough space, etc (there's plenty). Switching the download directory of these apps to the extSdCard is my current workaround.
What I've tried:
Fix Permissions from TWRP
Repair partition /data from TWRP using e2fsck
recursive busybox chown to 1001 on /data/media
restorecon on /data/media/0
This Fix Script Also found a similar flashable ZIP which did the same thing, but to no avail
None of these seem to have any effect. Also, trying to change permissions from Root Browser works on /sdcard, but not on any subfolders. Error returned is "Changing permissions was not successful. Please note that some file systems do not allow permission changes."
Any thoughts

funkeywoookey said:
Background:
Trying out ROMs here and there, making backups along the way in TWRP. Turn out I had my favorite ROM from the start, so clean all the slates and performed a restore to Hybrid X Series 1.07. Everything is as it was...almost.
Apps are complaining about not being able to download to internal memory, there not being enough space, etc (there's plenty). Switching the download directory of these apps to the extSdCard is my current workaround.
What I've tried:
Fix Permissions from TWRP
Repair partition /data from TWRP using e2fsck
recursive busybox chown to 1001 on /data/media
restorecon on /data/media/0
This Fix Script Also found a similar flashable ZIP which did the same thing, but to no avail
None of these seem to have any effect. Also, trying to change permissions from Root Browser works on /sdcard, but not on any subfolders. Error returned is "Changing permissions was not successful. Please note that some file systems do not allow permission changes."
Any thoughts
Click to expand...
Click to collapse
First off, this is an ownership issue, not a permissions issue
Second, chown 1001 gives ownership to Radio, not System. Chown to 1000 for System ownership
I never did find a solution to this problem. In my attempts to correct the problem, I ran chown on the entire /data partition by accident. The ROM booted, but everything crashed. After this, I just decided to salvage what little I might be able to save and move on with life.
The problem even persisted through wipe/reinstall of the ROM.
Finally, as a last resort, I had flash the stock version through Odin and start over from scratch.

Modify the system partition on Android Nougat?

Hi all,
has anyone been able to do this? Following the guide here, no longer works for Android N. The phone boots, but ignores all changes to system. How do I modify both build.prop and hosts? It seems that there are now possibly two system partitions?
Thanks!

Same issue on Nexus 5X

No answer on this? How is it that nobody else seems to be having this issue?

What I've done
It looks to me like everyone has moved to systemless and the /system partition cannot be adequately modified in this way anymore.
Maybe this will help others:
I was modifying the system directory for two reasons: 1. modify /system/etc/hosts to remove ads and modifying build.prop to increase lcd.density. I found that here are the alternatives for each:
Removing Ads
Using something similar to AdAway_systemless_hosts_v2.zip (google it for a copy) and modifying the hosts file in that zip file to be the one I use (and rezipping, deploying on the Android device). This basically mounts over /system/etc/hosts with a custom hosts file instead of actually modifying the system specific hosts file which is no longer writable.
The alternative is to use Netguard which routes non https network traffic through a private VPN where you can block ads according to a hosts file. This seems to work OK, but I have noticed that websites seem to take longer to load.
Modifying lcd.density
You can use the same trick as AdAway_systemless_hosts_v2.zip uses, but modify it to also mount a modified copy of build.prop. Alternatively just use the Android N Display settings that are small (what I did anyhow).

I have been able to edit build.prop and still maintain systemless root.
Sent from my Nexus 6P using XDA-Developers mobile app

I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root

ArminasAnarion said:
I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root
Click to expand...
Click to collapse
Have you been able to do this with simply fastboot boot <twrp-image>, mounting system in rw mode and modifying it? I did that as I didn't want to root the phone, and while it looks like it did the write, it does not affect the system partition that is used by the phone after boot. I think there are two system partitions, and twrp mounts only one in rw mode. It does seem like it may be possible to do what you say using adb though after the phone is fully booted up. I'll try that!

dontblinkwatchout said:
Have you been able to do this with simply fastboot boot <twrp-image>, mounting system in rw mode and modifying it? I did that as I didn't want to root the phone, and while it looks like it did the write, it does not affect the system partition that is used by the phone after boot. I think there are two system partitions, and twrp mounts only one in rw mode. It does seem like it may be possible to do what you say using adb though after the phone is fully booted up. I'll try that!
Click to expand...
Click to collapse
I had the same problem. I don't want to root but I do make a few changes to my /system partition through adb in recovery such as the hosts file and some font files (namely the Emoji font file). I had modified stock boot image to not enforce encryption. I would boot back up into the system and couldn't see any changes made. The only thing I found that worked was installing a custom kernel (I use ElementalX). After that, changes I made to /system in TWRP were reflected in the OS. I don't know enough about kernel development to understand why on (mostly) stock kernel my changes couldn't be seen but on a custom one they were.
I never had this "problem" prior to Nougat.

Same issue here. Something has changed with how this is handled in Nougat.
I don't want to root just to overwrite the hosts file...
I'll keep debugging but my capability in this is definitely limited!

I use a similar approach as described in the OP's linked guide except I use my own recovery image that I compiled as an engineering build from source, and I am also experiencing the same behavior. Modifying the hosts file seems to have no impact on the system though the changes persist. Comparing the host file I installed and the host file from the latest Nexus 5X image with 'ls -lZ' the SELinux info looks to be the same. The only information that appears to differ is the modified date and one additional line in the file itself for testing. I thought I was doing something wrong with my hosts file, even though I have been using this approach since Android 6.0. However, I agree, it appears that changes to system are being ignored. Further, changing the system partition no longer shows the red warning at boot about the system being corrupted.
---------- Post added at 09:58 PM ---------- Previous post was at 09:38 PM ----------
DanRyb;68654939 I would boot back up into the system and couldn't see any changes made.[/QUOTE said:
Oooh. You're right. Neither /etc/hosts or /system/etc/hosts is modified in the booted OS after I modify it from live image, but the change is retained when I reboot into live image and mount system. Hmm, so either:
1) Need to figure out where the the system files are being loaded from and modify them from live image if possible
2) Use a mechanism similar to what dontblinkwatchout described AdAway is using of having a custom mount setup (have to reverse engineer AdAway I guess to see what it's doing)
3) ?
Click to expand...
Click to collapse

There's absolutely no way to modify or mount system partition r+w unless you disable dm-verity
Enviado desde mi Nexus 6P mediante Tapatalk

alexiuss said:
There's absolutely no way to modify or mount system partition r+w unless you disable dm-verity
Enviado desde mi Nexus 6P mediante Tapatalk
Click to expand...
Click to collapse
dm-verity has been around since Android 4.4. Are you saying there is something new around this in Android 7.0?
You can modify the system partition by compiling an engineering build of Android and booting it, then mounting the system partition and modifying it. I've been doing this to update the hosts file since Android 6.0 for every OTA update (since more recently OTA updates bomb out unless you reflash the clean "uncorrupted" system.img first). Changing the system image before Android 7.0 did result in an extra screen with a red warning about a corrupted something or other (I'm sure because dm-verity checking failed). Regardless, you can still change the system partition, the information just no longer seems to be used, which is a bit perplexing to me atm.

crashenx said:
dm-verity has been around since Android 4.4. Are you saying there is something new around this in Android 7.0?
Click to expand...
Click to collapse
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.

sfhub said:
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
Click to expand...
Click to collapse
That's good info and makes total sense. Thanks! Pretty neat actually, just a bummer for me.
Yeah so SuperSU path is not really one I want to pursue. I could learn how to update the dm-verity shas used for verification. That'd probably be the most secure, but it's gonna be a PITA I bet. I imagine I'd need to compile my own image similar to how I made my live image and update a few things. Might have to deal with encryption which is probably an even bigger headache. Also, I bet it would break OTA and have to reflash to update, though that's true now.
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
I really appreciate you pointing us in the right direction.

I am glad found this thread..willing to assist here without permanent root..

Ericarthurc said:
I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root
Click to expand...
Click to collapse
I was trying to create a /system/xbin/post-boot but couldn't remount /system, and so I added busybox to the front of my command. I am not using adb so I cut that part off. Thanks a lot!

OP 5T - FBE /dev/block/sda13 or /data partition - file restoration / residues scan

Hello,
unfortunately, my Google Keep app had just decided to wipe its db file up. (/data/data/com.google.android.keep/databases/keep.db)
It is not (and never was) synchronized to Google.
When it happened I just copied (dd'ed over adb) /dev/block/sda13.
From mount command output, I could recognized /dev/block/sda13 as /data backing block device.
Then I did some searches in the output image file and noticed it actually encrypted per file.
I learned from it OP uses FBE (file-based-encryption). I wanted to try and run some ext4 recovery tools (autopsy, undelete ...).
FBE encrypts also filenames so I can't use the generated image as is.
I checked what caused FBE on /data partition and it's the encryption setting. I read it uses the fingerprint/pattern/password to decrypt the encrypted /data.
I didn't power-off the phone since then to avoid any more losses.
My questions:
1. Given /dev/block/sda13 as an image file, how can one decrypt it and use forensics/restoration tools on it?
2. Another option - how to acquire the unencrypted /dev/block/sda13 from the running device?
3. Maybe there is some backup partition for files in /data?
4. Can I run the mentioned tools straight on some unencrypted device file? (Assuming cross-compilation to android)
5. Any caches/other places I can search for residues? (I tried dumping CursorWindow ashmem the Keep app used but the app has restarted since then)
6. OP compiled the kernel without DEVMEM. Maybe there is other option to acquire the whole RAM to try to scan for residues?
More side-notes:
- I tried other files in the Keep app directory to try to recover some residues, pictures where saved outside the db file so I was able to restore them (but what is important are the notes stored in the db itself(
- I was able to notice keep.db was replaced with an empty sqlite3 db file (for some strange reason ...). My guess was it didn't overridden the original db file so if I had the ext4 /data partition, I will be able to scan it with the tools mentioned above.
References:
* https://forum.xda-developers.com/t/...-encrypt-data-partition-on-oneplus-5.3642144/
* https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/
If some details are missing, please let me know!

https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/ is really interesting.
The problem now is how to get a full memory dump without /proc/mem and signed kernel modules.

Any help? I'm out of ideas but it seems like a solvable problem.

[SOLVED] Restore decrypted nandroid backup of FBE

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

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

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