This thread should be deleted.
Hello together,
as I wanted to see if I get F2FS and decryption running, I want to share my progress and exchange with others.
I got both working but there are a few issues once the system is running, at least if decrypted. When encrypted, everything seems running nice on f2fs.
Here's what I did:
ENABLE F2FS AND DISABLE ENCRYPTION (IF NEEDED)
1. Flash full fastboot rom to make sure everything is clean
2. Boot to stock recovery and wipe /data so it gets cleanly formatted as ext4 (not really needed)
3. Boot and install TWRP (blu_spark) and reformat /data as f2fs
I chose latest blu_spark recovery as I think it's more stable and I don't need recovery decryption for this matter
4. Reboot to recovery
5. Flash custom kernel with f2fs support or keep stock
blu_spark didn't work for me for some reason but Smurfkernel and ElementalX were fine, also STOCK KERNEL SUPPORTS F2FS BY NOW
6. Flash the universal dm-verity and forceencryption remover by zackptg5 found here
Only if you really need it! NOT RECOMMENDED AND NOT NEEDED FOR HAVING F2FS WORK
7. Flash Magisk v18.0
8. Reboot
9. Profit (or not)
Even if hard to believe with the already amazing speeds of the OP6/T, I think I could feel a little improvement in boot time and app opening times.
Update: I wouldn't recommend doing this as of now to anyone. Maybe results with an AOSP based rom are better (please try and report), but using OxygenOS in combination with currently available kernels, the system turns out unstable and is not usable reliably. There are different weird glitches etc. Do this on your own resposibility and please share if you make any progress making OOS and/or AOSP run stable (recovery versions, file patches, kernels, settings, etc). I'm not an Android developer myself.
ENCOUNTERED ISSUES
1. Can't use any unlock method. Deleting gatekeeper and locksetting files through TWRP works but setting a new PIN results in not being able to unlock again. The PIN is entered correctly but still it reports "wrong password". But actually it detects that the PIN is correct since it doesn't trigger a lockout time. Logcat occurences can be found below.
FIXED BY NOT DECRYPTING DATA (?)
2. On first boot there will be some app crashs and lags. They settle after a few minutes and one or two reboots.
ALSO FIXED BY NOT DECRYPTING DATA (?)
3. One time I had to reflash Magisk after the first boot
UNLOCK BUG LOGCAT OCCURENCES - HELP NEEDED!
Here are some logcat lines which I think are related to the unlock bug.
HTML:
E GatekeeperHalDevice: verify
E GatekeeperHalDevice: ret: 0
E GatekeeperHalDevice: resp->status: -24
E GatekeeperHalDevice: verify
E GatekeeperHalDevice: ret: 0
E GatekeeperHalDevice: resp->status: -30
I LockSettingsService: Device doesn't implement AuthSecret HAL
E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.password.key: open failed: ENOENT (No such file or directory)
E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/password.key: open failed: ENOENT (No such file or directory)
E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.pattern.key: open failed: ENOENT (No such file or directory)
E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.gesture.key: open failed: ENOENT (No such file or directory)
E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gesture.key: open failed: ENOENT (No such file or directory)
E keystore: Changing user 0's password while locked, clearing old encryption
E JavaBinder: *** Uncaught remote exception! (Exceptions are not yet supported across processes.)
E JavaBinder: java.lang.RuntimeException: android.os.RemoteException: Non-OK response verifying a credential we just set: -1
E JavaBinder: at android.os.Parcel.writeException(Parcel.java:1779)
E JavaBinder: at android.os.Binder.execTransact(Binder.java:765)
E JavaBinder: Caused by: android.os.RemoteException: Non-OK response verifying a credential we just set: -1
E JavaBinder: at com.android.server.locksettings.LockSettingsService.setUserKeyProtection(LockSettingsService.java:1602)
E JavaBinder: at com.android.server.locksettings.LockSettingsService.setLockCredentialInternal(LockSettingsService.java:1483)
E JavaBinder: at com.android.server.locksettings.LockSettingsService.setLockCredential(LockSettingsService.java:1397)
E JavaBinder: at com.android.internal.widget.ILockSettings$Stub.onTransact(ILockSettings.java:141)
E JavaBinder: at android.os.Binder.execTransact(Binder.java:752)
Nice work, I discovered these very same errors while decrypting myself. I just flashed the dm verity disabler by zackptg after a format. Yeah same exact issues. I am on the fence whether I felt any difference in speed etc. Unfortunately it seems we need encryption for this device to offer any security, unlike previous phones that didn't have a/b partitions
jacksummers said:
Nice work, I discovered these very same errors while decrypting myself. I just flashed the dm verity disabler by zackptg after a format. Yeah same exact issues. I am on the fence whether I felt any difference in speed etc. Unfortunately it seems we need encryption for this device to offer any security, unlike previous phones that didn't have a/b partitions
Click to expand...
Click to collapse
You won't notice and difference in disabling encryption as it's hardware based now instead of software like on the Nexus's and then it was a slight performance increase nothing else.
jacksummers said:
Nice work, I discovered these very same errors while decrypting myself. I just flashed the dm verity disabler by zackptg after a format. Yeah same exact issues. I am on the fence whether I felt any difference in speed etc. Unfortunately it seems we need encryption for this device to offer any security, unlike previous phones that didn't have a/b partitions
Click to expand...
Click to collapse
Yeah well I updated the thread. Without decrypting everything seems running great until now, even with stock kernel which supports f2fs by now. Also, if someone really wants it decrypted, I updated the post with your method, the disabler by zackptg5, which I didnt know of until now (way easier, thanks)
Also thanks @liam_davenport for mentioning the hardware based encryption, didnt know of that as well.
This means: I'm perfectly happy. Encryption in place, f2fs working and no issues yet.
Lartsch said:
Yeah well I updated the thread. Without decrypting everything seems running great until now, even with stock kernel which supports f2fs by now. Also, if someone really wants it decrypted, I updated the post with your method, the disabler by zackptg5, which I didnt knwo of until now.
Click to expand...
Click to collapse
Good to share ideas man, that furthers the development of Android.
nevermind!
So twice now (the first was above, but it's easy, while incredibly annoying, to fix after a reformat, so I edited the post thinking it was a one-time thing) I've rebooted my phone with data as F2FS only to boot directly into recovery. TWRP doesn't ask me to decrypt; I get the error "init_user_0 failed." I have to reformat my SDcard to get out of this error.
I don't know how to get recovery logs without decrypted data. damn TWRP saves them in /data/media/0 which is useless since it's encrypted.
Another issue i encountered which may be related: I've woken my phone up to have my unlock method reset to "swipe" as if the pattern doesn't work anymore. I can reset the pattern no problems. I think the next reboot after this error happens is when you run into the bootloop.
So, users beware: You get some tasty performance improvements when you switch to F2FS, but one day later you may reboot and be ****ed.
Maybe some smarter people can get on board and figure this out. F2FS is definitely a faster file system for flash devices such as our internal sdcard.
EXT4 for now though!
Lartsch said:
Hello together,
as I wanted to see if I get F2FS and decryption running, I want to share my progress and exchange with others.
I got both working but there are a few issues once the system is running, at least if decrypted. When encrypted, everything seems running nice on f2fs.
Here's what I did:
ENABLE F2FS AND DISABLE ENCRYPTION (IF NEEDED)
1. Flash full fastboot rom to make sure everything is clean
2. Boot to stock recovery and wipe /data so it gets cleanly formatted as ext4 (not really needed)
3. Boot and install TWRP (blu_spark) and reformat /data as f2fs
I chose latest blu_spark recovery as I think it's more stable and I don't need recovery decryption for this matter
4. Reboot to recovery
5. Flash custom kernel with f2fs support or keep stock
blu_spark didn't work for me for some reason but Smurfkernel and ElementalX were fine, also STOCK KERNEL SUPPORTS F2FS BY NOW
6. Flash the universal dm-verity and forceencryption remover by zackptg5 found here
Only if you really need it! NOT RECOMMENDED AND NOT NEEDED FOR HAVING F2FS WORK
7. Flash Magisk v18.0
8. Reboot
9. Profit (or not)
Even if hard to believe with the already amazing speeds of the OP6/T, I think I could feel a little improvement in boot time and app opening times.
Update: I wouldn't recommend doing this as of now to anyone. Maybe results with an AOSP based rom are better (please try and report), but using OxygenOS in combination with currently available kernels, the system turns out unstable and is not usable reliably. There are different weird glitches etc. Do this on your own resposibility and please share if you make any progress making OOS and/or AOSP run stable (recovery versions, file patches, kernels, settings, etc). I'm not an Android developer myself.
ENCOUNTERED ISSUES
1. Can't use any unlock method. Deleting gatekeeper and locksetting files through TWRP works but setting a new PIN results in not being able to unlock again. The PIN is entered correctly but still it reports "wrong password". But actually it detects that the PIN is correct since it doesn't trigger a lockout time. Logcat occurences can be found below.
FIXED BY NOT DECRYPTING DATA (?)
2. On first boot there will be some app crashs and lags. They settle after a few minutes and one or two reboots.
ALSO FIXED BY NOT DECRYPTING DATA (?)
3. One time I had to reflash Magisk after the first boot
UNLOCK BUG LOGCAT OCCURENCES - HELP NEEDED!
Here are some logcat lines which I think are related to the unlock bug.
E GatekeeperHalDevice: verifyE GatekeeperHalDevice: ret: 0E GatekeeperHalDevice: resp->status: -24E GatekeeperHalDevice: verifyE GatekeeperHalDevice: ret: 0E GatekeeperHalDevice: resp->status: -30I LockSettingsService: Device doesn't implement AuthSecret HALE LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.password.key: open failed: ENOENT (No such file or directory)E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/password.key: open failed: ENOENT (No such file or directory)E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.pattern.key: open failed: ENOENT (No such file or directory)E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gatekeeper.gesture.key: open failed: ENOENT (No such file or directory)E LockSettingsStorage: Cannot read file java.io.FileNotFoundException: /data/system/gesture.key: open failed: ENOENT (No such file or directory)E keystore: Changing user 0's password while locked, clearing old encryptionE JavaBinder: *** Uncaught remote exception! (Exceptions are not yet supported across processes.)E JavaBinder: java.lang.RuntimeException: android.os.RemoteException: Non-OK response verifying a credential we just set: -1E JavaBinder: at android.os.Parcel.writeException(Parcel.java:1779)E JavaBinder: at android.os.Binder.execTransact(Binder.java:765)E JavaBinder: Caused by: android.os.RemoteException: Non-OK response verifying a credential we just set: -1E JavaBinder: at com.android.server.locksettings.LockSettingsService.setUserKeyProtection(LockSettingsService.java:1602)E JavaBinder: at com.android.server.locksettings.LockSettingsService.setLockCredentialInternal(LockSettingsService.java:1483)E JavaBinder: at com.android.server.locksettings.LockSettingsService.setLockCredential(LockSettingsService.java:1397)E JavaBinder: at com.android.internal.widget.ILockSettings$Stub.onTransact(ILockSettings.java:141)E JavaBinder: at android.os.Binder.execTransact(Binder.java:752)
Click to expand...
Click to collapse
Hi, I have OnePlus 6t, when I flash the system clean the data section, then format it, flash the script from encryption, then the system boots to a new state, but because of the script, when I want to create a password, it is created, but immediately will not be true when you first start the phone or lock the screen. and I can't get over it, have you figured it out?
uhh186 said:
So twice now (the first was above, but it's easy, while incredibly annoying, to fix after a reformat, so I edited the post thinking it was a one-time thing) I've rebooted my phone with data as F2FS only to boot directly into recovery. TWRP doesn't ask me to decrypt; I get the error "init_user_0 failed." I have to reformat my SDcard to get out of this error.
I don't know how to get recovery logs without decrypted data. damn TWRP saves them in /data/media/0 which is useless since it's encrypted.
Another issue i encountered which may be related: I've woken my phone up to have my unlock method reset to "swipe" as if the pattern doesn't work anymore. I can reset the pattern no problems. I think the next reboot after this error happens is when you run into the bootloop.
So, users beware: You get some tasty performance improvements when you switch to F2FS, but one day later you may reboot and be ****ed.
Maybe some smarter people can get on board and figure this out. F2FS is definitely a faster file system for flash devices such as our internal sdcard.
EXT4 for now though!
Click to expand...
Click to collapse
Use adb while booted in twrp to pull recovery.
adb pull /tmp/recovery.log
uhh186 said:
So twice now (the first was above, but it's easy, while incredibly annoying, to fix after a reformat, so I edited the post thinking it was a one-time thing) I've rebooted my phone with data as F2FS only to boot directly into recovery. TWRP doesn't ask me to decrypt; I get the error "init_user_0 failed." I have to reformat my SDcard to get out of this error.
I don't know how to get recovery logs without decrypted data. damn TWRP saves them in /data/media/0 which is useless since it's encrypted.
Another issue i encountered which may be related: I've woken my phone up to have my unlock method reset to "swipe" as if the pattern doesn't work anymore. I can reset the pattern no problems. I think the next reboot after this error happens is when you run into the bootloop.
So, users beware: You get some tasty performance improvements when you switch to F2FS, but one day later you may reboot and be ****ed.
Maybe some smarter people can get on board and figure this out. F2FS is definitely a faster file system for flash devices such as our internal sdcard.
EXT4 for now though!
Click to expand...
Click to collapse
I get init_user0_failed randomly as well wish there was a fix
edit - reflashing ROM seems to get past it
Was looking at https://source.android.com/security/encryption/file-based and came across an idea,
It says it's possible to add exceptions to prevent certain directories from being encrypted.
In this manner, if the rom Dev is able to add exclusion to /data, isn't it possible that the device would work with pin set, on a decrypted op6t?
when i follow these steps OOS wont boot, it just forces back to recovery.
Related
Disclaimer: Usual disclaimer applies. I've tested this recovery but it might not work due to a different ROM / device / moon phase / etc. Use at your own risk.
Introduction
After working with upstream TWRP developers and fixing some bugs (in TWRP itself and in this port) this device finally has an official port
There were various builds available at different times (some with bugs) but most of them should now be fixed.
Features
Works
backup/restore
installing zips
ADB
MTP
Screen turns off
Basically the rest of this list
format /data
Adoptable storage
Decrypt /data
Doesn't work (please ask if you need this)
Encrypted backup (set password for /data/data)
USB-OTG
Untested
Backup/restore of stock system / data.
Installation instructions
Warning: only use it on the G800F/M/Y, NOT on the G800H! I only tested the G800F, but think G800M/Y will also work. G800H will most likely NOT work, as it is based on a different SoC (Qualcomm).
Download the recovery image from twrp.me. It also includes some installation instructions.
There are more extensive installation instructions over at the LineageOS ROM installation instructions.
I personally prefer using Heimdall, but you can also use Odin. Commands in Download/Odin mode (power off, then press home+Volume-Down+power):
Code:
heimdall flash --RECOVERY recovery.img
If you're using the stock ROM, use:
Code:
heimdall flash --RECOVERY recovery.img --no-reboot
When you come from the stock ROM you have to make sure the stock ROM doesn't overwrite TWRP: Pull the battery, wait 5 seconds, insert it again, and press home + volume up + power to enter TWRP and replace the stock ROM from there.
If you already have TWRP or LineageOS, it's much easier to install from there, see twrp.me.
Another method is using ADB (from your computer). I used it a lot during testing:
Code:
adb root
adb push twrp-3.1.1-1-kminilte.img /dev/block/mmcblk0p10
Changelog
Code:
2017-07-10:
* fix formatting /data while the partition is encrypted
(device is not encrypted by default)
* add support for adoptable storage
* accept kminiltexx etc. for flashing basebands
2017-06-20:
* ADB
* MTP at the same time as ADB
* Screen turns fully off
* fix for restoring backups made using `adb backup --twrp`
Source code
Kernel: https://github.com/TeamWin/android_kernel_samsung_kminilte/tree/cm-14.1
Device: https://github.com/TeamWin/android_device_samsung_kminilte/tree/cm-14.1
This recovery is built using a LineageOS tree. Instructions are similar to the instructions for building LineageOS for the S5 mini. Differences are: you don't need to patch the source (skip that step) and the last step is mka recoveryimage instead of mka bacon - this only builds the recovery resulting in much faster builds. Also see the official build instructions.
Thanks
Other people who have worked on this project:
Team Win, of course, for the recovery itself! In particular bigbiff which has worked with me to make this device official.
hennymcc
RVR
---
Note to moderators: this is my first DevDB thread started on XDA so I may have made mistakes.
XDA:DevDB Information
Team Win Recovery Project, ROM for the Samsung Galaxy S5 Mini
Contributors
ayke, hennymcc, RVR
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.4.x
Version Information
Status: Stable
Current Stable Version: 3.1.1
Stable Release Date: 2017-06-20
Created 2017-06-24
Last Updated 2017-07-09
Thanks!
OFFICIAL TWRP...I can't believe it
Great work on this one...many thanks.
Thanks a million @ayke ! However, I found some bugs I'd like to submit some bugs I discovered:
- Recovery is not SEANDROID enforcing" message when booting TWRP, didn't cause any trouble for me but still - it was fine in your previous unofficial build
- Some zip files (tested with latest modem flashable zip) report "This package is for kminiltexx devices; this is a kminilte", so it doesn't flash and fails with ERROR:7
I can confirm that decrypting a File-Based encrypted /data partition works, I didn't test the backup tool though.
P.S. Is it possible to add support for adopted storage, that would be awesome!
Nevertheless - thanks for making this device officialy supported!
Friedensfurz said:
Thanks a million @ayke ! However, I found some bugs I'd like to submit some bugs I discovered:
- Recovery is not SEANDROID enforcing" message when booting TWRP, didn't cause any trouble for me but still - it was fine in your previous unofficial build
Click to expand...
Click to collapse
The current kernel used upstream is somewhat older and hasn't enabled SELinux yet. I don't see why you would want enforcing SELinux in TWRP, though.
Friedensfurz said:
- Some zip files (tested with latest modem flashable zip) report "This package is for kminiltexx devices; this is a kminilte", so it doesn't flash and fails with ERROR:7
Click to expand...
Click to collapse
I think I have a fix for that, please test https://aykevl.nl/download/2017-06-25-recovery-fix-ota-asserts.img (not tested by me)
Friedensfurz said:
I can confirm that decrypting a File-Based encrypted /data partition works, I didn't test the backup tool though.
Click to expand...
Click to collapse
Nice!
Friedensfurz said:
P.S. Is it possible to add support for adopted storage, that would be awesome!
Click to expand...
Click to collapse
I might look into it. I don't use it at the moment but am considering it.
EDIT: I have fixed it, it will be included in the next build.
any chance for g800h support?
sasukesama said:
any chance for g800h support?
Click to expand...
Click to collapse
Not from me. The G800H is a completely different device. I have a G800F so I can't test it.
ayke said:
I think I have a fix for that, please test https://aykevl.nl/download/2017-06-25-recovery-fix-ota-asserts.img (not tested by me)
Click to expand...
Click to collapse
Sorry, but the build doesn't fix the wrong device id issue - still throws error " This is for kminiltexx your device is kminilte. Anyway - maybe the next build will fix it[emoji6]
Friedensfurz said:
Sorry, but the build doesn't fix the wrong device id issue - still throws error " This is for kminiltexx your device is kminilte. Anyway - maybe the next build will fix it[emoji6]
Click to expand...
Click to collapse
Can you give a link to where you downloaded this zip? Then I can test it myself.
I also get the device error with latest official and 2017-06-25-recovery-fix-ota-asserts.img.
Tried to flash one of Spookcity's kernels, you can find it here (search for "test9" that is what I used lately).
https://github.com/Spookcity/ROMS-G800F/issues/10#issuecomment-301915315
The latest pre-official TWRP 3.1.1-0 works (says kminiltexx).
ayke said:
Can you give a link to where you downloaded this zip? Then I can test it myself.
Click to expand...
Click to collapse
This file causes problems with the device id: http://pt.tapatalk.com/redirect.php...1_22.05.2017_DRE-flashable.zip&au_id=13587482
It is a TWRP flashable baseband file, hope this helps
@Friedensfurz @Pat750
I couldn't find a (still online) kernel from Spookcity and I'd rather not flash a new modem unless I know why I should do that. So I haven't verified it.
But here's another build you can try. My previous attempt was incomplete.
https://aykevl.nl/download/2017-06-27-recovery-fix-ota-asserts-2.img
On my device I've verified it has a ro.product.device property of kminiltexx.
ayke said:
@Friedensfurz @Pat750
I couldn't find a (still online) kernel from Spookcity and I'd rather not flash a new modem unless I know why I should do that. So I haven't verified it.
But here's another build you can try. My previous attempt was incomplete.
https://aykevl.nl/download/2017-06-27-recovery-fix-ota-asserts-2.img
On my device I've verified it has a ro.product.device property of kminiltexx.
Click to expand...
Click to collapse
Yeah,I removed all of my test build links from my google drive, but have a thread on here. I already sent you this though. I will test your new build and see if it helps.
Edit:
Yep,fixed. Good work Ayke!
Sent from my SM-G800F using Tapatalk
Friedensfurz said:
...
I can confirm that decrypting a File-Based encrypted /data partition works, I didn't test the backup tool though.
...
Click to expand...
Click to collapse
I'm having a few issues with TWRP 3.1.1 where "wipe / format data" (where you have to key "yes") generates the following error msg (I posted a similar msg in Slim Rom 7 thread):
Code:
Error:unable to wipe /data unknown file system 'auto'
unable to format encryption.
I'm now wondering whether decrypting the data partition from within TWRP will address my format data issue reported above.
Can I ask how you did this? I've dug around the TWRP menus but nothing has jumped out at me (maybe it's something you need to run from the terminal?)
Many thanks!
fidoedidoe said:
I'm having a few issues with TWRP 3.1.1 where "wipe / format data" (where you have to key "yes") generates the following error msg (I posted a similar msg in Slim Rom 7 thread):
Code:
Error:unable to wipe /data unknown file system 'auto'
unable to format encryption.
I'm now wondering whether decrypting the data partition from within TWRP will address my format data issue reported above.
Can I ask how you did this? I've dug around the TWRP menus but nothing has jumped out at me (maybe it's something you need to run from the terminal?)
Many thanks!
Click to expand...
Click to collapse
I have the same problem
Here also this message in unofficial builds, don't tried it, but I think its still present in this version.
fidoedidoe said:
I'm having a few issues with TWRP 3.1.1 where "wipe / format data" (where you have to key "yes") generates the following error msg (I posted a similar msg in Slim Rom 7 thread):
I'm now wondering whether decrypting the data partition from within TWRP will address my format data issue reported above.
Can I ask how you did this? I've dug around the TWRP menus but nothing has jumped out at me (maybe it's something you need to run from the terminal?)
Many thanks!
Click to expand...
Click to collapse
I still haven't found a method to decrypt the /data volume from within TWRP (a reference earlier in the thread implied it was possible)..the hope being this would mitigate the "wipe / format data" error:
Code:
Error:unable to wipe /data unknown file system 'auto'
unable to format encryption.
What I did discover was that when reverting to an older version of TWRP (2.8.x) using Odin, " format data" (where you have to type "yes" to proceed) didn't error. I'm not sure whether that cured the issue, but after that I updated TWRP image back to 3.1.1.0 and installed my ROM as normal.
Still looking for a recognised method to wipe encrypted /data volume from within latest stable TWRP if anyone has any experience of that.
EDIT
Another thread suggests (to my untrained eye) that "unknown file system 'auto" may be related to how twrp.fstab is configured.
I'm very much out of my here ( so apologies for the crude suggestion), but could it be that another build of a TWRP image is needed where twrp.fstab is changed to allow "format data" to work, ie substitute "fstype" from "auto" to "ext4" as outlined below :
Code:
...
/data ext4 /dev/block/mmcblk0p21 length=-16384
...
fidoedidoe said:
I still haven't found a method to decrypt the /data volume from within TWRP (a reference earlier in the thread implied it was possible)..the hope being this would mitigate the "wipe / format data" error:
Code:
Error:unable to wipe /data unknown file system 'auto'
unable to format encryption.
What I did discover was that when reverting to an older version of TWRP (2.8.x) using Odin, " format data" (where you have to type "yes" to proceed) didn't error. I'm not sure whether that cured the issue, but after that I updated TWRP image back to 3.1.1.0 and installed my ROM as normal.
Still looking for a recognised method to wipe encrypted /data volume from within latest stable TWRP if anyone has any experience of that.
EDIT
Another thread suggests (to my untrained eye) that "unknown file system 'auto" may be related to how twrp.fstab is configured.
I'm very much out of my here ( so apologies for the crude suggestion), but could it be that another build of a TWRP image is needed where twrp.fstab is changed to allow "format data" to work, ie substitute "fstype" from "auto" to "ext4" as outlined below :
Code:
...
/dataext4/dev/block/mmcblk0p21length=-16384
...
Click to expand...
Click to collapse
I got it to work by formatting/repairing/changing filesystem in TWRP. Just try some combinations, it will work eventually
Yes, I think it's because of the 'auto' in the fstab. I've set it to ext4 in this build (for data and cache):
https://aykevl.nl/download/2017-07-03-recovery.img
This build also contains the previous fixes (adoptable storage, fixing the kminiltexx error).
If it fixes the issue for you, I'll push the change for inclusion in the next official build.
I didn't see any negative consequences of changing the FS type in fstab. Even setting the fstab entry to 'f2fs' mounts /data as usual (as ext4) so I think it's safe.
ayke said:
https://aykevl.nl/download/2017-07-03-recovery.img
Click to expand...
Click to collapse
Can someone test this change? Then I'll integrate it in the official build.
My phone (3T) has an unlocked bootloader, is encrypted, not rooted, and running stock OOS 5.0.
I flashed TWRP and discovered that stock OOS restores the stock recovery in boot.
I saw the Oreo dm-verity thread by xenet, had a look at the zip file, noticed that it just modified fstab to prevent force encrypt, so I flashed it to see what happens.
And nothing happens. After the system had booted, fstab is unchanged from the original stock copy.
So I'm wondering whether this file is also restored when booting up on stock.
I get aggressive and go back to TWRP and delete /system/etc and /system/bin and modify build.prop.
Surely now the phone won't boot!
Wrong! It boots up and everything is back to normal in /system.
I go back to TWRP and have a look at /system and it shows me one without the etc and bin folders and has the modified build.prop.
What's going on? How can I see one version of /system in TWRP but a different version (ie, stock) when the phone has booted?
By the way I've been an Android user for many years and have rooted and flashed custom ROMs on a variety of phones and I've never seen anything like what's happening on my 3T. I'm sure that dm-verity is somehow involved in this.
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
nicknacknuke said:
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
Click to expand...
Click to collapse
Thanks.
I should have mentioned that I'm also not rooted. So stock OOS 5.0.
Sent from my OnePlus 3T using XDA Labs
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Click to expand...
Click to collapse
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Click to expand...
Click to collapse
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Click to expand...
Click to collapse
Thanks, you are correct. I'd forgotten that that TWRP remembers. Deleting .twrps does bring up the RO prompt after decrypting storage.
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
I had allowed changes to the system otherwise I couldn't have made changes to it, which includes the ability to restore the system partition.
But I'm still unclear why if I make changes to the system partition and boot with the stock kernel, then after the boot none of the changes are present in the system partition, but if I boot back into TWRP then the changes are all there.
I recall someone in another OOS 5 thread saying that the stock kernal replaces TWRP with stock recovery if you don't flash root (magisk/superSU). Is it possible that the kernel re-flashes system on boot? Another possibility is that TWRP thinks it's making changes to system but it's not actually? Not quite sure, I've never heard of anything like this before either, just throwing other ideas out there.
I've never read anything about the OP3T or any oneplus phones for that matter having A/B system partitions like the pixels. *shrug*
@nhshah7, something's like what you suggest must be going on to account for what I'm seeing. I'm hoping that someone can confirm my observations and provide a definite answer.
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Xennet said:
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Click to expand...
Click to collapse
Actually it doesn't explain how TWRP can make changes to system yet the phone boots up on an unmodified system if using the stock kernel. And then, when you boot back into TWRP and look at system, the changes are still there.
Where does the unmodified system come from?
Where does the modified system live?
Why doesn't modifying system result in a failed boot due to dm-verity, while restoring a backup of system does result in a failed boot?
So many questions with no answers.
BillGoss said:
....So many questions with no answers.
Click to expand...
Click to collapse
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
rk2612 said:
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
Click to expand...
Click to collapse
I'll come back to 1.
2. That makes sense and accounts for why a restore of the system partition with the stock boot image causes me to get dumped back in fastboot mode. If I flash the stock system zip file then the system boots properly.
3. I've not had any issues with strange boot behaviour. I'm always starting with stock or flashing kernels that modify the stock boot image, like Blu Spark.
4. I gathered this from my reading of various threads. If I want to make changes to the system partition and get them to stick and not fail dm-verity then I have to flash a custom kernel. I've proven this in my testing. (A rooting solution would also work, but I've not done this).
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
BillGoss said:
....
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
Click to expand...
Click to collapse
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
rk2612 said:
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
Click to expand...
Click to collapse
Good questions. They got me thinking more about how this could possibly work.
I had a look at the cache and there's definitely no copy of the system hiding there.
I also unpacked the ramdisk in the boot image and it had nothing in system. Furthermore, the boot position is only 64 MB, no where near enough to hold the system.
Then I installed Magisk so that I could browse around the phone's partitions and take copies.
I learnt two things from this:
1. If there's a second copy of the system there are only three partitions large enough to hold it (/proc/partitions shows the sizes in 1 kB blocks). The system is about 1 GB. There is space in the system partition (sde20) for 3 GB. There's also space in the data partition (sca15). And there's space in the major partition holding the modems (sdf).
I could eliminate the data partition by formatting it but restoring the internal storage (sdcard) is such a a pain.
So I'll just accept that there is space for a copy, but I'm unlikely to find out exactly where.
2. When I had Magisk installed installed and the system boot, I added a folder and file to /system/priv-app using a file manager (so not using TWRP). I then booted into recovery, flashed the stock boot image, and rebooted. I was expecting it to fail dm-verity (modified system) but it didn't. After booting up there's no evidence of the folder I added to priv-app.
And if I restore the Magisk boot image then the additions show up again.
I'm actually very impressed with how the stock system (kernel, recovery, system) protects itself from modification. Very cool!
I've been running LineageOS 14.1 on my OnePlus 3T since last March when I bought it. On Friday 2017-12-15, I installed the weekly LineageOS update and the phone got stuck on the boot animation after entering the encryption password. I let it sit for about 45 minutes and then powered it off. Has anyone else experienced this?
Info:
* LineageOS 14.1 (build 20171215); no google play services
* TWRP 3.1.0-1
* 128GB version of the Oneplus 3T
* /data formatting: encrypted f2fs (so far)
Here is the troubleshooting I've done thus far and my observations:
* I have noticed over the past few months that it has taken longer to flash ROMs than when it was new. Sometimes when booting (although rarely), the boot animation freezes for a bit.
* Without reformatting, I restored a nandroid backup from 2017-11-25. I have previously restored this backup, so it's known-good. When booting, it wouldn't get past the boot animation after entering the encryption passwd. Sometimes, the boot animation would freeze entirely.
* I installed OxygenOS (version OnePlus3TOxygen_28_OTA_028_all_1707141503_fc82c5d2e3054e44). The phone booted very quickly and got past the passwd prompt without issue. OxygenOS ran noticeably faster. I let it install the latest OTA and that also went quite quickly.
* I nuked /data and installed a fresh LineageOS build 20171215 with no modifications (besides the su addon). The phone was able to boot all of the way, but apps were slow and some froze. The OS crashed (soft-reboot) twice. I have a logcat for that (can't find a way to attach; are new members allowed to attach?).
* I reinstalled OxygenOS and downloaded my music to it (~50GB). The performance of the phone still seems fine. I'm doing this to test the theory that it might be an issue with wear-leveling on the flash.
Next steps / tests:
* Based on the behavior, I'm not convinced it's a hardware issue. I suspect that maybe the binary blobs / and/or kernel are responsible for the difference.
* I'll try LineageOS with /data formatted as ext4 instead of f2fs.
* I'll try LineageOS, but booted with Oxygen's kernel via fastboot boot. I'm not sure this will even work at all, but it's worth a try.
I'll report the results of my tests / troubleshooting here.
This might explain your problems with booting LOS.
From the official OnePlus 3/3T LineageOS thread post #2:
Started from lineage-14.1-20170207-nightly-oneplus3-signed.zip, we provide unified builds for both 3&3T, and you need to install certain firmware to pass the TrustZone assertion. Currently they're the OxygenOS Open Beta 19/11 ones. As oneplus won't update them every time new OTAs are rolling out, firmware from other versions might also pass the assertion.
Just wanted to point out the thread title say "5T" but everything in the post says "3T" so I do presume you are on the 3T. If so, you may want to update the title, to avoid confusion. I saw the thread title myself, and was going to post "Dude, wrong device section" until I read the content.
One test I did before updating my firmware:
I filled the userdata partition about half full with music (while running Oxygen). I then flashed my known-good backup and it booted. However, installing the update failed (boot animation for > 1 hour after entering encryption passwd). I wonder if there is something with the flash wear-leveling at play.
I upgraded the firmware from the latest OxygenOS beta (OnePlus3TOxygen_28_OTA_038_all_1711272148_5e0ea1454e8f4f0f.zip). Upgraded TWRP to 3.2.1-0 first. I'll do some more testing and report my results.
Only adspso.bin was the same.
Anyone know what each of these does? The more I understand, the better.
The complete list of files is:
Code:
BTFM.bin
NON-HLOS.bin
adspso.bin
cmnlib.mbn
cmnlib64.mbn
devcfg.mbn
emmc_appsboot.mbn
hyp.mbn
keymaster.mbn
logo.bin
mdtp.img
pmic.elf
rpm.mbn
tz.mbn
xbl.elf
After upgrading the firmware, I restored my known-good backup and performed the following upgrades:
* lineage build 20171124 (restored from backup) -> lineage build 20171201 -> lineage build 20171215
* lineage build 20171124 (restored from backup) -> lineage build 20171215
It made it through 3 upgrade cycles with normal behavior.
Previously, it hung after upgrades after entering the encryption passwd. This is the stage where it "optimizes" all of the apps (someone feel free to correct me if there's a better term for this). I suspect that all of this flashing / upgrading caused the wear leveling to swap out the bad blocks that were causing the hang (assuming that was the problem).
I'm going to try completely filling /data with random files (i.e. for loop; dd if=/dev/urandom etc). I'll then completely wipe the phone afterwards. I'm hoping this will cause any other bad blocks to get put out of service and prevent this problem in the future. Are there any better ways of doing this and/or any advanced diagnostic tools for UFS hardware?
After filling /data with random files, I ran through a few more upgrade cycles and it hung again. I noticed IOExceptions in the logcat, both on LineageOS and on OxygenOS. I'm pretty sure this is a hardware failure and I've filed an RMA with OnePlus. They're not making it easy (despite my detailed troubleshooting).
One interesting thing is they want to do essentially this procedure: https://forum.xda-developers.com/oneplus-3t/how-to/unbrick-unbrick-tutorial-oneplus-3t-t3515306
I don't think that will help considering it's just a different way of flashing the same bits to the storage.
This is the known side effect of using F2FS filesystem, me to had problems like this until I switched back to EXT4 and now it takes under a second to enter TWRP and phone doesn't go turtle when the storage gets filled up.
pitrus- said:
This is the known side effect of using F2FS filesystem, me to had problems like this until I switched back to EXT4 and now it takes under a second to enter TWRP and phone doesn't go turtle when the storage gets filled up.
Click to expand...
Click to collapse
Do you know why f2fs has this problem?
So I finally got my phone back from repairs yesterday (yes, it's been almost a month). I noticed that wiping the phone from twrp (using format data) and then re-encrypting the phone after flashing lineage causes corruption on /data, even though the encryption process completed without error. The phone would boot, accept my password, continue to boot, get to the lockscreen, and then crash immediately. There were IOExceptions in the logcat. Booting to twrp afterwards also resulted in IOExceptions in the logcat.
Flashing Oxygen, letting it boot once to force-encrypt, and then wiping and installing lineage without formatting /data (encryption preserved) did not result in this issue. The phone behaved normally. I even had to set the password in Oxygen. Setting it in lineage (via the GUI) caused the boot to hang.
Since the phone's stock rom is force-encrypt, I suspect there's some sort of incompatibility between the device and the older encryption process (launched via settings) from AOSP.
I'd like to troubleshoot why this is the case. Any good tools in the Lineage source (I have the tree locally)?
linux-colonel said:
Do you know why f2fs has this problem?
Click to expand...
Click to collapse
No idea, guessing it's simply a buggy filesystem implementation.
Hi! I followed the steps here to build stock CAF Android for my device.
I made the factory images and OTA zip, and it said everything was successful.
When I flash the factory images, it says that it's looking for a "QC Reference Phone" and my phone identifies as either msm8996 or oneplus3 (can't remember) so it won't flash.
When I flash the OTA zip, it says that this phone is a "oneplus3" and it needs "msm8996" so it wouldn't flash either, but I got around that by removing the checks in the updater script.
So I've got it flashed onto my device, but I'm facing a problem:
Once it's flashed, it boots, but then says Encryption Unsuccessful, and to factory reset my phone. However, if I do that, I get the same error.
Also, I noticed that when I run fastboot commands like "fastboot format userdata" it tells me
Code:
Couldn't parse erase-block-size '0x'.
Couldn't parse logical-block-size '0x'.
Could anyone help with this? I can even pay like 20$ if I get a good solution
Thanks
Have you tried completely wiping your data from TWRP? That is erasing everything from the "Format Data" option under "Wipe". You need to enter "yes" from the keyboard to confirm. This basically does the same thing as fastboot format user data. Try this, and let us know what happens.
thes3usa said:
Have you tried completely wiping your data from TWRP? That is erasing everything from the "Format Data" option under "Wipe". You need to enter "yes" from the keyboard to confirm. This basically does the same thing as fastboot format user data. Try this, and let us know what happens.
Click to expand...
Click to collapse
Do I do this before or after flashing the zip file?
Thanks, Nate
Follow these steps.
Wipe System/Data/Cache
Flash Zip
Reboot back into Recovery
Wipe all data as I've mentioned in the above post
Reboot.
thes3usa said:
Follow these steps.
Wipe System/Data/Cache
Flash Zip
Reboot back into Recovery
Wipe all data as I've mentioned in the above post
Reboot.
Click to expand...
Click to collapse
Thanks for the help. I flashed it, rebooted back to recovery, and chose Format Data - "yes" and it says:
Code:
Failed to mount '/data' (Device or resource busy)
Failed to mount '/data' (Device or resource busy)
Unable to recreate /data/media folder.
You may need to reboot recovery to be able to use /data again
Updating partition details...
Failed to mount '/data' (Device or resource busy)
...done
Unable to mount storage
I rebooted anyways just to see, and it goes like normal on the OnePlus logo, then the boot animation, and then I get the same screen. https://imgur.com/a/hD8Zm
Rebooted again back to recovery and did the same format, and that time it worked successfully. I rebooted back into the OS, and same error.
NateDev said:
Thanks for the help. I flashed it, rebooted back to recovery, and chose Format Data - "yes" and it says:
Code:
Failed to mount '/data' (Device or resource busy)
Failed to mount '/data' (Device or resource busy)
Unable to recreate /data/media folder.
You may need to reboot recovery to be able to use /data again
Updating partition details...
Failed to mount '/data' (Device or resource busy)
...done
Unable to mount storage
I rebooted anyways just to see, and it goes like normal on the OnePlus logo, then the boot animation, and then I get the same screen. https://imgur.com/a/hD8Zm
Click to expand...
Click to collapse
Seems like your data partition is completely corrupt. You may want to try the Unbrick tool, to get your device back working. "Fastboot Format Userdata" was the last thing you could do, and it doesnt work.
Are you sure the build compiled correctly? I've never seen something like this happen, and it's quite weird. It's happened to me, but under completely different circumstances.
Are you on the recommended TWRP? That is Acuicultors TWRP for the 3/3T? It is bug free.
thes3usa said:
Seems like your data partition is completely corrupt. You may want to try the Unbrick tool, to get your device back working. "Fastboot Format Userdata" was the last thing you could do, and it doesnt work.
Click to expand...
Click to collapse
What's weird though is when I was trying this before and got this issue, I went back and flashed OxygenOS and it booted fine. This attempt now was straight off of OxygenOS and it doesn't work.
Do you think it's still worth trying the Unbrick tool, as OOS worked fine inbetween? idk but maybe it could be more of an issue with the ROM, but I built it with no modifications straight from OnePlus' GitHub.
EDIT: Didn't see your second post, about the build compiling.
It looks like it compiled correctly, didn't show any errors, and the final message was green, not red.
I'm on the TWRP from twrp.me, is that the reccomended one?
EDIT2: Tried this TWRP https://androidfilehost.com/?fid=746010030569948067, I flashed the ROM and when I go to format data, it says:
Code:
mkfs.f2fs -t 0 -r 16384 /dev/block/sda15 process ended with ERROR: 1
Unable to wipe Data.
Unable to format to remove encryption
That line about encryption is interesting, is there a way to disable encryption on the 3T? I saw this https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748 but idk if it would as it says its only for OOS.
Then I just tried this https://android.stackexchange.com/questions/98228/removing-encryption-from-recovery to remove encryption but the boot just gets stuck on the boot animation, even after setting it to on and reflashing, so I'm going to hope I didn't brick my phone and am going to try the unbrick tool if flashing stock does nothing.
Thanks for your help
NateDev said:
What's weird though is when I was trying this before and got this issue, I went back and flashed OxygenOS and it booted fine. This attempt now was straight off of OxygenOS and it doesn't work.
Do you think it's still worth trying the Unbrick tool, as OOS worked fine inbetween? idk but maybe it could be more of an issue with the ROM, but I built it with no modifications straight from OnePlus' GitHub.
EDIT: Didn't see your second post, about the build compiling.
It looks like it compiled correctly, didn't show any errors, and the final message was green, not red.
I'm on the TWRP from twrp.me, is that the reccomended one?
EDIT2: Tried this TWRP https://androidfilehost.com/?fid=746010030569948067, I flashed the ROM and when I go to format data, it says:
Code:
mkfs.f2fs -t 0 -r 16384 /dev/block/sda15 process ended with ERROR: 1
Unable to wipe Data.
Unable to format to remove encryption
That line about encryption is interesting, is there a way to disable encryption on the 3T? I saw this https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748 but idk if it would as it says its only for OOS.
Then I just tried this https://android.stackexchange.com/questions/98228/removing-encryption-from-recovery to remove encryption but the boot just gets stuck on the boot animation, even after setting it to on and reflashing, so I'm going to hope I didn't brick my phone and am going to try the unbrick tool if flashing stock does nothing.
Thanks for your help
Click to expand...
Click to collapse
Sorry for the late reply, got a little busy there.
Did you flash OOS after flashing the Custom Build? If you did so, and it worked, it may not be the device, it may be the build.
thes3usa said:
Sorry for the late reply, got a little busy there.
Did you flash OOS after flashing the Custom Build? If you did so, and it worked, it may not be the device, it may be the build.
Click to expand...
Click to collapse
Yea I flashed OOS after my custom build, which does point to the build being the problem.
That's weird because everything completed with no errors, and I used the source straight from OnePlus.
And, seeing how inactive they are on GitHub, doesn't look like I'll be getting a solution from them anytime soon
Is there a similar ROM source code that I could use? I'm looking for barebones CAF, basically. I saw this: https://github.com/AOSP-CAF but I don't even know if it's possible to configure that for the 3T without extensive work, as it looks to just be a generic build.
NateDev said:
Yea I flashed OOS after my custom build, which does point to the build being the problem.
That's weird because everything completed with no errors, and I used the source straight from OnePlus.
And, seeing how inactive they are on GitHub, doesn't look like I'll be getting a solution from them anytime soon
Is there a similar ROM source code that I could use? I'm looking for barebones CAF, basically. I saw this: https://github.com/AOSP-CAF but I don't even know if it's possible to configure that for the 3T without extensive work, as it looks to just be a generic build.
Click to expand...
Click to collapse
You should try LineageOS's source, if you're looking for barebones. Can't say it's similar to CAF though. If you're an Amateur at these stuff, use Sources that are already readily built for the 3T, so you can do your own customizations without having to worry about the build failing.
thes3usa said:
You should try LineageOS's source, if you're looking for barebones. Can't say it's similar to CAF though. If you're an Amateur at these stuff, use Sources that are already readily built for the 3T, so you can do your own customizations without having to worry about the build failing.
Click to expand...
Click to collapse
Is LineageOS CAF based or AOSP? I searched but couldn't find a clear answer. If it's indeed CAF I will probably go ahead and try that.
Sucks that OnePlus's own GitHub for building for the 3T fails, and I kinda would have liked the experience of bringing up the system from the most barebones it could get, but if I can't even get an initial build to boot up with no modifications whatsoever, then I'll have to do Lineage.
I'll keep my OSS sources on my PC for the next week or 2 and resync and rebuild in the hopes that they change something that fixes it.
Thanks for your help
NateDev said:
Is LineageOS CAF based or AOSP? I searched but couldn't find a clear answer. If it's indeed CAF I will probably go ahead and try that.
Sucks that OnePlus's own GitHub for building for the 3T fails, and I kinda would have liked the experience of bringing up the system from the most barebones it could get, but if I can't even get an initial build to boot up with no modifications whatsoever, then I'll have to do Lineage.
I'll keep my OSS sources on my PC for the next week or 2 and resync and rebuild in the hopes that they change something that fixes it.
Thanks for your help
Click to expand...
Click to collapse
LineageOS is AOSP based, but has one of the most trusted sources, that are confirmed to be working.
It's OnePlus. Obviously their sources are going to be messed up. Look at their absolutely horrible Camera2 API Implementation. It's the reason why we need so many add-on fixes for HDR+ and other features to be working on the front camera.
Try resyncing the Repo, or completely start the sync over from scratch. Who knows, maybe your saved sources are messed up, and that's what causing the build error.
Good luck with the building!
thes3usa said:
LineageOS is AOSP based, but has one of the most trusted sources, that are confirmed to be working.
It's OnePlus. Obviously their sources are going to be messed up. Look at their absolutely horrible Camera2 API Implementation. It's the reason why we need so many add-on fixes for HDR+ and other features to be working on the front camera.
Try resyncing the Repo, or completely start the sync over from scratch. Who knows, maybe your saved sources are messed up, and that's what causing the build error.
Good luck with the building!
Click to expand...
Click to collapse
"It's OnePlus. Obviously their sources are going to be messed up. Look at their absolutely horrible Camera2 API Implementation. It's the reason why we need so many add-on fixes for HDR+ and other features to be working on the front camera." Haha yep you're right lol.
Thanks, I'll try LOS and keep trying OnePlus's sources, and I will resync as well incase that's the issue.
Thanks so much for all your help
I have tested some unofficial recovery, but none of those worked.
issues :
1. Touch doesn't response.
2. Only in pitchblack recovery touch worked, but doesn't shows internal storage files, just shows unknown inaccessible files which I don't have in internal storage.
So, does anyone know about a recovery with which I can flash gapps?, or any other way to flash gapps without root, like with pc?
Similar problem here. Unoffical TWRP doesn't respond to touch inputs for me, PBRP does. The garbeled letters inside your storage is probably because of the encryption of the phone.
I don't know on which version you are, but I downgraded to MIUI 11, there you can access the files, sometimes I have to enter my phone password, sometimes not.
It's still encrypted with "FBE" (File Based Encryption) though... At least my console is giving me that output. I can reach the files anyways and flash them, a few of them are working, but often I get errors while trying to flash different types of zip files. The errors are often because of this "FBE" encryption, so the recovery can't mount some partitions or can't access some files (Permission denied)...
But by now, I did not find any way or flashable zipfile (LazyFlasher, etc.) in the web that works to turn the decryption off.
the only build where touch works is 0108. https://androidfilehost.com/?fid=17248734326145712658
iReebu said:
Similar problem here. Unoffical TWRP doesn't respond to touch inputs for me, PBRP does. The garbeled letters inside your storage is probably because of the encryption of the phone.
I don't know on which version you are, but I downgraded to MIUI 11, there you can access the files, sometimes I have to enter my phone password, sometimes not.
It's still encrypted with "FBE" (File Based Encryption) though... At least my console is giving me that output. I can reach the files anyways and flash them, a few of them are working, but often I get errors while trying to flash different types of zip files. The errors are often because of this "FBE" encryption, so the recovery can't mount some partitions or can't access some files (Permission denied)...
But by now, I did not find any way or flashable zipfile (LazyFlasher, etc.) in the web that works to turn the decryption off.
Click to expand...
Click to collapse
Thanks for the reply,
All the things are same for me too. But for most of the people unofficial twrp 3.4.2b works fine, i don't know the problem with my device, and i'm in miui 12.0.3