Related
On my Samsung GT-N7000 I'm trying Omnirom again. I've tried it in the past and also tried vanilla CM stable and nightlies. I have also tried SuperNexus and PA and some other stuff that left no impression. Basically on this device for functional hardware, reasonable user control and a coherent UI it is Samsung's Touchwiz rooted, or Omnirom.
It is a bit too hard to install Omnirom and it can be horribly tedious to go from Omnirom back to stock or to another ROM. It's OK after you have done it a few times, but it is a huge obstacle for anyone trying to discover the way via inaccurate, misleading and fragmented documentation. The install guide at omnirom.org is actually utterly useless for this particular device, a complete non-starter. XpLoDWilD your GT-N7000 specific thread at http://forum.xda-developers.com/showthread.php?t=2516933 almost guarantees a boot loop because it only mentions but doesn't identify or link to versions of CWM which are adequate. In fact unless the user by diligent searching (or more likely by blind chance) comes across a link to the specific suitable raw kernel then it is one big dead end. You could spend hours and days searching for a suitable CWM and never find it because actually you should be searching for raw_kernel_r#_j##.zip. But how is anyone meant to know this. It turns what is actually a reliable and rather trouble free 15 or 20 minute process into a some kind of waking torment. In the past the documentation on installing via CWM was so bad that I used ODIN, which is less than ideal IMO because it means that anyone switching from stock to Omni doesn't get the chance to make a full nandroid backup of the original system (so to revert means a very tedious clean install).
So assuming the end user somehow finds the right raw kernel whose recovery can install Omnirom, what should they do? Of course they should back up their current apps and also make a nandroid backup. Apps backup is easy with oandbackup or titanium or similar. How about a nandroid backup to external SD? No problem in CWM but once you have TWRP installed you can't use it to access anything on an exfat formatted external SD card! You can back up before installing Omnirom but afterwards you can't restore! This is 100% nuts. exfat has now been around for 8 years. CWM supports it brilliantly. Even my crusty old Debian stable desktop reads and writes to exfat at very high speeds even via a FUSE FS and my puny Asus EeePC netbook running XP Home handles it fine. TWRP? Nope. exfat? Wha tha? Aaaaaagh.
Sorry to rant But for these specific devices Omnirom (with an exfat SD) is really the only high quality competitor to the stock Samsung, and there surely isn't a good reason for it being so frustrating to install and also to revert? Is TWRP really such a killer facility that it is worth foregoing the ability to backup and restore to the now very common exfat microSDHC? I run plain CM 11 on another device and OTA updates work fine on that. In these days of phatter pipes is it really worth making a huge compromise in functionality simply to avoid 200MB of downloads sometimes? On this device the delta updates are going to fail for many anyway unless they use an exfat card, but if they use an exfat card they.....oooouuuurrrggg...vicious circle.
/rant over.
Loving Omnirom btw and writing as a fan.
#blamesamsung
The Exynos Galaxy S2 family are some of the only devices remaining that don't have separate recovery partitions. This has always led to various annoyances for custom firmware users since it's impossible to change recovery without changing kernel.
Probably the documentation could be updated to indicate a double-flash though. Flash once to get a working recovery, flash a second time to get a working /system
Entropy512 said:
#blamesamsung
The Exynos Galaxy S2 family are some of the only devices remaining that don't have separate recovery partitions. This has always led to various annoyances for custom firmware users since it's impossible to change recovery without changing kernel.
Probably the documentation could be updated to indicate a double-flash though. Flash once to get a working recovery, flash a second time to get a working /system
Click to expand...
Click to collapse
Thanks for responding. I do appreciate that the exynos based devices are sons-of-b...b...bad persons.
I know documentation is boring and mostly thankless but it also matters a lot, most especially for projects which invite the user to perform realtively complex and potentially hazardous tasks.
Personally I would be very happy to edit/update XpLoDWilD's guide, but of course I can't because it's a forum post, not a wiki, so he owns it and it will remain there guiding new and trusting people into disappointment and boot loop oblivion until he decides to change it.
Omnirom has some issues but on the GT-N7000 is probably the only really mature and coherent alternative UI to Samsung's Touchwiz. To me it seems simply insane to direct newcomers into an unnecessary, time consuming, badly described and potentialy hazardous obstacle course, when in fact installation can be done with only small inconvenience.
I'm currently looking for information about installing OmniROM (I'm currently running CM11 nightlies), and I can attest the information in XpLoDWilD's post is somewhat vague, and also doesn't fully correlate with the directions to install Omni at the official wiki -- I'm assuming this lack of correlation is partly due to the fact, mentioned in this thread, that the N7000 doesn't have a separate recovery partition.
Something which made me especially uncertain about the installation process is the following part:
XpLoDWilD said:
- Make sure you're running a proper working ClockworkMod-Recovery - WITH SELINUX SUPPORT!
Click to expand...
Click to collapse
My understanding is that SeLinux is a feature of the kernel -- not the recovery console -- am I wrong about this? Or should I look for SeLinux in the features of the recovery console as well? (if so, how?)
What I currently do, is run adb, or start a console from the normal operating mode (not recovery mode), run the command:
Code:
getenforce
and confirm the reply is:
Code:
Enforcing
which means I have a kernel with SeLinux. Is that good enough to ensure the requisites for the installation are provided?
I'd appreciate any input about this matter.
julian67 said:
Personally I would be very happy to edit/update XpLoDWilD's guide, but of course I can't because it's a forum post, not a wiki, so he owns it and it will remain there guiding new and trusting people into disappointment and boot loop oblivion until he decides to change it.
Click to expand...
Click to collapse
Cant you add device-specific installation guide at the official wiki?
sagie said:
Cant you add device-specific installation guide at the official wiki?
Click to expand...
Click to collapse
I'm back on rooted Samsung TouchWiz. As things stand I wouldn't encourage any normal end user with a GT-N7000 to try a ROM. Hardware support is poor and unlikely to improve, installation documentation is misleading, backup is difficult, and restoring stock Samsung successfully requires ODIN. Also you stand a real chance of bricking the device. On my B+N Nook HD CM11 nightly is, as far as I can tell, beyond criticism but on these Exynos based devices all the third party ROMs have poor hardware support, poor multimedia support, poor stability and truly terrible battery life (even with no gapps installed). I will keep trying out ROMs occasionally and if the day arrives where the hardware is truly supported I will write a guide and drink a bottle of french fizz, but at the moment I would discourage any regular end user from doing anything to their GT-N7000 except running the newest available official firmware and rooting it if required.
I'm pretty sure I can save my twrp backups to my exfat sdcard.
edit: yup. just touch "internal storage" on the twrp backup page and select your sdcard.
julian67 said:
I'm back on rooted Samsung TouchWiz. As things stand I wouldn't encourage any normal end user with a GT-N7000 to try a ROM. Hardware support is poor and unlikely to improve, installation documentation is misleading, backup is difficult, and restoring stock Samsung successfully requires ODIN. Also you stand a real chance of bricking the device. On my B+N Nook HD CM11 nightly is, as far as I can tell, beyond criticism but on these Exynos based devices all the third party ROMs have poor hardware support, poor multimedia support, poor stability and truly terrible battery life (even with no gapps installed). I will keep trying out ROMs occasionally and if the day arrives where the hardware is truly supported I will write a guide and drink a bottle of french fizz, but at the moment I would discourage any regular end user from doing anything to their GT-N7000 except running the newest available official firmware and rooting it if required.
Click to expand...
Click to collapse
i've been using omnirom as my daily driver for 2 weeks now. love kitkat and omnirom features, but its still very unstable i think. stuff that's bothering me for now:
-stock camera is really plain, can't even switch to front camera
-video playback sometimes fail
-music playback will fail the first time i launch and play a song or 2. have to reboot and it'll work all day long
-intermittent random reboots, about 3 times so far the whole week
-wifi signal range is somewhat lower compared to touchwiz rom
-stock clock app, can't manually input time via keypad when you want to add an alarm
-contacts app is very confusing, can't even add a contact with ease. well at least for me that is
other than that kit kat is sure a welcome on this legendary device. contemplating the switch back to stock touchwiz, but loathe at the idea of setting up everything again zzz
In answer to this, and if it can help.
That the second time I install a ROM on my N7000, so it was still a bit frightening for me
Based on a CM10.1, I already had an old CWM.
1) From CWM I've just installed Philz Touch
2) On Philz, i've wiped everything, formated both internal and external sd cards (well I wanted something reeeally clean)
3) Used abd for copying omnirom and Gapp zip on the root
4) installed them from Philz Touch.
And it works like a charm (... but not enough feedback yet, just 2 days).
Now the question is to know if a day Omnirom will accept CWM based recoveries for updates.
TWRP is unfortunately not available on N7000 (from what I see, only USA flavors of Galaxy Note1).
Thanks!
Polux
Polux44 said:
In answer to this, and if it can help.
That the second time I install a ROM on my N7000, so it was still a bit frightening for me
Based on a CM10.1, I already had an old CWM.
1) From CWM I've just installed Philz Touch
2) On Philz, i've wiped everything, formated both internal and external sd cards (well I wanted something reeeally clean)
3) Used abd for copying omnirom and Gapp zip on the root
4) installed them from Philz Touch.
And it works like a charm (... but not enough feedback yet, just 2 days).
Now the question is to know if a day Omnirom will accept CWM based recoveries for updates.
TWRP is unfortunately not available on N7000 (from what I see, only USA flavors of Galaxy Note1).
Thanks!
Polux
Click to expand...
Click to collapse
Per my earlier post - You cannot change kernels on the Samsung GS2 family (including N7000) without also changing recovery.
Conversely, you can't change recovery without changing kernel. It's a limitation of this device since the recovery partition is not actually used, and recovery is in the normal kernel.
Once you flash Omni, your recovery will be TWRP. The reason TWRP doesn't "officially" support any of the GS2 family is because, as I said - you can't change recoveries without changing kernels.
Entropy512 said:
Once you flash Omni, your recovery will be TWRP. The reason TWRP doesn't "officially" support any of the GS2 family is because, as I said - you can't change recoveries without changing kernels.
Click to expand...
Click to collapse
Yes thanks for the precision, i've just seen that now my recovery was TWRP. (well which is good for me since it means I can use OTA). Your details helped me to understand why recovery and kernel are linked together, for my device.
Does it mean that installing omni on a non GS2 device (let's say a more recent device) will not overwrite the existing recovery?
Thanks again!
Polux44 said:
Yes thanks for the precision, i've just seen that now my recovery was TWRP. (well which is good for me since it means I can use OTA). Your details helped me to understand why recovery and kernel are linked together, for my device.
Does it mean that installing omni on a non GS2 device (let's say a more recent device) will not overwrite the existing recovery?
Thanks again!
Click to expand...
Click to collapse
Correct. Sony devices also have this limitation, there is a semi-workaround (where the kernel pulls recovery ramdisk from another location) on those that *in theory* could be done on the old Samsungs... but so few people are working on the old Samsungs that it isn't likely to happen.
Pretty much all GS1s and Exynos GS2s had this limitation. Qualcomm GS2s (Skyrocket/Hercules) had a separate recovery, as did all GS3s and onwards.
Hello everybody,
I created a tool - initially for the nexus 9 (flounder|flounder_lte) - that gets rid of the ForceEncrypt flag in a generic way (meaning it should work no matter what rom you are on). It does that by patching the currently installed boot.img.
I enhanced that tool to make it work for other devices too. (See the list below to see if your device is supported)
Disclaimer
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about the features in this tool
* before using it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
*/
Background
The Android CDD (Compatibility Definition Document) suggests demands that all devices with the appropriate horse power SHOULD MUST enable full disk-encryption (FDE) by default. Even though I support every step towards more security I have to criticize this approach. Full-disk-encryption comes at a price. Encryption takes time because some component has to de- and encrypt the stuff on the disk at some point and in current devices it's the CPU's task. Even though modern devices have quite fast CPU cores you can still easily feel the difference between FDE in the on- or off-state. The I/O is faster and boot-times take only half as long. (I did not do any scientific measurements though)
There is an ongoing discussion about this topic in cyanogenmod's gerrit for the nexus 9. Although it's a fun read it is pretty clear that this exchange of views is not going anywhere near a useful outcome. Additionally, Google's stock ROMs always have forced encryption enabled on newer devices.
Because performance is important to me and at least my tablet does not need the extra security I created the FED-Patcher (ForceEncrypt Disable Patcher).
How does it work?
FED-Patcher is a simple flashable ZIP that is supposed to be run in a recovery that has busybox integrated (like TWRP or CWM). This is what it does:
Checks if your device is compatible
Dumps the currently installed boot.img.
Unpacks the dump of your currently installed boot.img. The unpacking process is done via a self-compiled, statically linked version of unmkbootimg.
It patches the filesystem tables which include the force-encrypt flags. This process will change "forceencrypt" to "encryptable".
Then, if necessary, it patches the filesystem tables to not use dm-verity. This is done by removing the "verify" mount-parameter.
Creates a new boot.img. The unpacking process is done via a self-compiled, statically linked version of mkbootimg.
Flashes the modified boot.img
Supported devices
HTC Nexus 9 WiFi (flounder)
HTC Nexus 9 LTE (flounder_lte)
Motorola Nexus 6 (shamu)
LG Nexus 5X (bullhead)
Huawei Nexus 6P (angler)
Version History
v1 - Initial version with HTC Nexus 9 WiFi (flounder) support
v2 - Added Motorola Nexus 6 (shamu) support
v3 - Added support for HTC Nexus 9 LTE (flounder_lte)
v4 - Added support for signed boot-images
v5 - Changed error handling to compensate for missing fstab files. Some roms seem not to ship with the complete set of boot-files from AOSP.
v6 - FED-Patcher will enforce the same structure for the patched boot.img that the original boot.img had. Additionally, the kernel commandline will also be taken over. This should fix pretty much every case where devices would not boot after patching.
v7 - FED-Patcher will now disable dm-verity in fstab to get rid of the red error sign on marshmallow roms.
v8 - Added support for LG Nexus 5X (bullhead) and Huawei Nexus 6P (angler)
What do I need to make this work?
A supported device
An unlocked bootloader
An already installed ROM with forceencrypt flag. (like cyanogenmod CM12.1)
A recovery that includes busybox (TWRP, CWM)
How do I use it?
Make a thorough, conservative backup of your data if there is any on your device
Go into your recovery (TWRP, CWM)
Flash fed_patcher-signed.zip
If your device is already encrypted (You booted your ROM at least once) you need to do a full wipe to get rid of the encryption. This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before. If you don't do a backup and want to restore your data... well... Call obama.
How do I know if it worked?
Go into your "Settings"-App. In "Security", if it offers you to encrypt your device it is unencrypted. If it says something like "Device is encrypted" it indeed is encrypted.
IMPORTANT: If you update your ROM you have to run FED-Patcher again because ROM-updates also update the boot-partition which effectively removes my patch. So, if you are on CM12.1 for example and you used my patch and do an update to a newer nightly you have to run FED-Patcher again. If you don't do so Android will encrypt your device at the first boot.
Is it dangerous?
Well, I implemented tons of checks that prevent pretty much anything bad from happening. But, of course, we're dealing with the boot-partition here. Even though I tested FED-Patcher quite a lot there is still room for crap hitting the fan.
Screenshot
Scroll down to the attached thumbnails.
Credits
* pbatard for making (un)mkbootimg (dunno if he is on xda)
* @rovo89 for his xposed framework - I used some of his ideas by reading the source of his xposed installer flashable ZIP for FED-Patcher.
GibHub: https://github.com/gladiac1337/fed-patcher
XDA:DevDB Information
FED-Patcher, Tool/Utility for all devices (see above for details)
Contributors
gladiac, rovo89
Version Information
Status: Beta
Current Beta Version: v8
Beta Release Date: 2015-10-27
Created 2015-10-27
Last Updated 2016-10-23
Hi @gladiac and first of all thanks for the work and time spent developing this amazing tool.
I'm currently running stock Marshmallow on my Nexus 6 and i plan to stay like that, but would like to test my device with ForceEncrypt disabled. Here are my doubts.
1 - Does this work on stock?
2 - Would i be able to flash the monthly security update images without having to wipe my device every time?
3 - In your opinion, do the speed gains justify the all the work?
Thanks in advance.
cyberon said:
Hi @gladiac and first of all thanks for the work and time spent developing this amazing tool.
I'm currently on stock Marshmallow and i plan to stay like that, but would like to test my device with forcencrypt disabled. Here are my doubts.
1 - Does this work on stock?
2 - Would i be able to flash the monthly security update images without having to wipe my device every time?
3 - In your opinion, do the speed gains justify the all the work?
Thanks in advance.
Click to expand...
Click to collapse
Hi @cyberon,
good questions!
Yes, FED-Patcher works on stock! Marshmallow made it necessary to do a new release, v7, to get rid of an error message at boot but other than that, FED-Patcher works just fine on Android 6.
Well, I don't know how the monthly security-updates will be deployed. I guess it will be done by OTA (Over the Air) updates. OTA will probably not work after modifying the boot-image. However, flashing factory images should work just fine. Additionally, most of the time, OTA-zips are being posted here on xda or androidpolice whenever they become available so doing manual OTA updates is another possibility to do updates.
To get back to your question - wiping should not be necessary after an upgrade - be it via OTA or factory images. Google did a fantastic job with the upgrade-functionality in newer Android versions. However, whenever you do an update, be sure to run FED-Patcher afterwards because, in case the boot-partitions got updated, forced encryption will be in place again and on the first boot it will encrypt you device.
Well, I do all my tests on a HTC Nexus 9 (flounder). It is a pretty fast beast. However, on an unmodified stock rom, it was clearly tangible that the GUI had more latency than necessary. Apps loaded pretty slowly - compared to my Sony Xperia Z1 (honami) it took like twice as long to start youtube - and in general it just did not behave like a beast. This was why I started writing FED-Patcher. In my opinion it was worth my time. (it wasn't that much actually)
I hope I could help.
Enjoy, gladiac
Thanks for the quick and detailed answer @gladiac, now regarding point number 2.
I never wait for the OTA, but always flash the images manually.
As far as i understand from your answer, it would it be ok to flash all the img files manually, then flash TWRP and finally flash FED without booting the OS.
Am i missing something?
cyberon said:
Thanks for the quick and detailed answer @gladiac, now regarding point number 2.
I never wait for the OTA, but always flash the images manually.
As far as i understand from your answer, it would it be ok to flash all the img files manually, then flash TWRP and finally flash FED without booting the OS.
Click to expand...
Click to collapse
That's pretty much how I would do it. You don't even have to flash TWRP if you just skip flashing the recovery.img which is included in the factory-image package.
Thanks @gladiac, will try that way.
PS: I have a feeling that if we had this option added to a toolkit like Wugfresh Nexus Root Toolkit, it would be an instant success.
hi @gladiac
first of all thanks for your patch
I'm on Nexus 6 with stock Marshmallow and all I want to do is disable encryption and enable root.
Is your patch + SuperSU enough or I need something else?
Thanks a lot
Worked on my N9 - thanks!
provolinoo said:
hi @gladiac
first of all thanks for your patch
I'm on Nexus 6 with stock Marshmallow and all I want to do is disable encryption and enable root.
Is your patch + SuperSU enough or I need something else?
Thanks a lot
Click to expand...
Click to collapse
Hi @provolinoo,
well, FED Patcher will disable the forced encryption for you. However, SuperSU will not work so easily. The reason for that is that the stock ROM has SeLinux enabled in "enforcing" mode. SuperSU does not work without adding more SeLinux Policies to the stock ROM. Unfortunately, it's not in the scope of FED Patcher to add SeLinux policies for SuperSU. This should be done inside the flashable ZIP of SuperSU instead.
The last time I tested SuperSU with marshmallow stock was with version 2.52 BETA. It did not work. The result was a boot-loop because of one or more SeLinux denials. A little more info on that matter is here.
So, to get SuperSU working you would have to set SeLinux to "permissive" mode. Alternatively, you can use @Chainfire's boot.imgs to make SuperSU work.
Have fun, gladiac
Thank you gladiac. Your FED patcher (v8) works flawlessly on my Nexus 9. Edit: I am using TWRP 2.8.7.1
The gerrit conversation you linked is interesting. I am grateful that someone with your skills decided to support our ability to choose whether or not to encrypt. CM thinks I am smart enough for root priveleges but I am too stupid to be trusted with decryption?
Don't some major vendors allow the disabling of encryption from within Android?
Anyway, thanks for the patcher.
dmantilal said:
Thank you gladiac. Your FED patcher (v8) works flawlessly on my Nexus 9.
The gerrit conversation you linked is interesting. I am grateful that someone with your skills decided to support our ability to choose whether or not to encrypt. CM thinks I am smart enough for root priveleges but I am too stupid to be trusted with decryption?
Don't some major vendors allow the disabling of encryption from within Android?
Anyway, thanks for the patcher.
Click to expand...
Click to collapse
I agree, I love CM roms but their decision to force encryption when most of cm users are power-user is a nonsense
Sooo....basically, I cannot use a stock Marshmallow that is FEDpatched and with root (using SuperSU, unless there is alternative)? If I want those, I have to get one of the custom ROMs?
EDIT: also, I tried using Chainfire's modified boot. It is stated that it will disable the forceencrypt. It didn't work in mine, still encrypted.
jamesalfred said:
Sooo....basically, I cannot use a stock Marshmallow that is FEDpatched and with root (using SuperSU, unless there is alternative)? If I want those, I have to get one of the custom ROMs?
EDIT: also, I tried using Chainfire's modified boot. It is stated that it will disable the forceencrypt. It didn't work in mine, still encrypted.
Click to expand...
Click to collapse
Did you follow the directions and format the entire "data" partition?
dmantilal said:
Did you follow the directions and format the entire "data" partition?
Click to expand...
Click to collapse
I too have the same problem didnt work for me.
im on the the new 6.0 L build but went ahead and flashed the modified boot image for K build just so I could flash the TWRP img.
Once TWRP was installed, I installed the Fed path ZIP and that went well supposedly. and then after that I did a factory reset, then I WIPED the DATA, CACHE and Dalvik.. I rebooted setup my device and it still shows encrypted.
nextelbuddy said:
I too have the same problem didnt work for me.
im on the the new 6.0 L build but went ahead and flashed the modified boot image for K build just so I could flash the TWRP img.
Once TWRP was installed, I installed the Fed path ZIP and that went well supposedly. and then after that I did a factory reset, then I WIPED the DATA, CACHE and Dalvik.. I rebooted setup my device and it still shows encrypted.
Click to expand...
Click to collapse
It did not work because you did not follow the directions.
Flash TWRP. Flash FED. Full wipe (or format, depending on your choice of terminology). OP goes on to clarify by saying "This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before.", meaning if you did not lose everything on data, which includes "/sdcard", you most likely did it wrong.
Give us more info so we can help (assuming you fid it right initially).
P.S. - 6.0 is M(arshmallow), not L(ollipop).
dmantilal said:
Did you follow the directions and format the entire "data" partition?
Click to expand...
Click to collapse
dmantilal said:
It did not work because you did not follow the directions.
Flash TWRP. Flash FED. Full wipe (or format, depending on your choice of terminology). OP goes on to clarify by saying "This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before.", meaning if you did not lose everything on data, which includes "/sdcard", you most likely did it wrong.
Give us more info so we can help (assuming you fid it right initially).
P.S. - 6.0 is M(arshmallow), not L(ollipop).
Click to expand...
Click to collapse
i solved my issue. i was wiping DATA but not choosing internal storage. i did that and rebooted and now it says ENCRYPT not ENCRYPTED
THANKS!
so currently I have a modified boot image from the K build, TWRP and now a modifier boot.img kernel for no force encrypt BUT I am not rooted and dont plan on it. does this mean I can still get OTAs?> i would guess not since my boot image has been modified and i am unlocked? would i even want an OTA? wouldnt that just give me a stock boot.img again causing me to get encrypted on the next boot after OTA?
nextelbuddy said:
i solved my issue. i was wiping DATA but not choosing internal storage. i did that and rebooted and now it says ENCRYPT not ENCRYPTED
THANKS!
so currently I have a modified boot image from the K build, TWRP and now a modifier boot.img kernel for no force encrypt BUT I am not rooted and dont plan on it. does this mean I can still get OTAs?> i would guess not since my boot image has been modified and i am unlocked? would i even want an OTA? wouldnt that just give me a stock boot.img again causing me to get encrypted on the next boot after OTA?
Click to expand...
Click to collapse
Side-loading the OTA then following that with a FED flash seems much safer.
Loading an OTA directly would over-write the boot.img with a ForceEncrypt boot.img, logically Forcing Encryption (derp) at boot.
I am using chroma ROM which doesn't force encryption and my device is still encrypted. Can I still use this?
jamespat93 said:
I am using chroma ROM which doesn't force encryption and my device is still encrypted. Can I still use this?
Click to expand...
Click to collapse
You can if you want But if you want to unencrypt your phone, backup your ROM, copy sd content to your computer, wipe everything! in recovery (twrp) including Format Data, Factory reset, internal storage etc. Connect your phone while in recovery to your computer (you'll see 25.98GB instead of 23.03GB), copy sd content back to your phone, restore your rom backup and you'll be fine.
I can't get it work on Nexus 6 and chroma rom r26.
My steps: wipe everything, push folder (rom,patcher and gapps), flash chroma, flash gapps, flash patcher, wipe everything but system
after boot in setting/security it is again encrypted. what I am doing wrong?
Are any devs working on a method to repartition the Pixel? It seems that most flashing issues are due to the A/B partition scheme. Also, in the case of custom ROMs, the duplicate partitions are a waste of space (unless you want to dual boot, which doesn't work well either since the data partition is shared).
Anyway, it would be awesome if the Pixel could be repartitioned.
I think this is highly unlikely. The Nexus 7 had a laughably small system partition, which led to people being SOL when trying to get newer Android versions and gApps to work together. The other reason this is unlikely is because it's a pretty dangerous process (mess something up and you might completely brick the device, since factory images don't do any partitioning work), and this would modify the hashes used by SafetyNet, so there would be no easy way of passing the CTS checks.
The a/b partitions weren't made for dual booting, they were made for google and ota's/updates
Now, you can dual boot with the same custom rom, one rooted, the other non-rooted same with stock.
Sent from my Pixel using XDA-Developers Legacy app
creeve4 said:
Are any devs working on a method to repartition the Pixel? It seems that most flashing issues are due to the A/B partition scheme. Also, in the case of custom ROMs, the duplicate partitions are a waste of space (unless you want to dual boot, which doesn't work well either since the data partition is shared).
Anyway, it would be awesome if the Pixel could be repartitioned.
Click to expand...
Click to collapse
What space are you wasting? Its the system partition. The biggest reason I think that it exists is for the seamless updates. Its also a redundancy should you not be able to boot or an OTA fries your device.
The only issues I have ever had (and most of the ones I have encountered) were users not doing research. Its not hard to flash on this device, its just that details arent laid out very well and up to date in any one spot.
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
You can create dumps of your partitions using ADB shell in system; TWRP is not required to do this.
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
A very similar thread with the same topic has been discussed a few days ago - you can check here
Anyone can compile TWRP - it's opensource. Pixel 6+ owners are unlikely to get an official build from TWRP since it requires a volunteer to maintain the repo, deal with bug reports, etc.
It's recommended to simply compile the image on an individual basis (you really don't want to rely on a third-party supplied image when you have no way of knowing whether it's safe or not). Compiling isn't a difficult process, but does require an hour or two of reading TWRP's and Google's applicable developer pages, along with ~30 - 60 minutes of set up time on a PC/laptop (I prefer to compile within an Ubuntu VM, but I believe it can also be done in Windows' WSL).
robroy90 said:
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
Click to expand...
Click to collapse
They still haven't finished official support for Android 12. Since recovery resources on A12+ are located in vendor_boot, bigbiff is trying to figure out a decent way for TWRP to live there, at least as far as the Pixel 5 is concerned. Not sure what other obstacles may be present on the Pixel 6 series and above.
nooted1 said:
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
Click to expand...
Click to collapse
Hey thanks for this! How did you flash just the recovery partiton on the Pixel? I am an old hand with Odin on the Samsung devices, but Google official devices are still new to me. Will the StagOS recovery recognize an external USB-C flash drive for storage?
s3axel said:
A very similar thread with the same topic has been discussed a few days ago - you can check here
Click to expand...
Click to collapse
Thank you, I went over there and read everything. Much appreciated!
@SkewedZeppelin
Hello, I installed the latest DivestOS version today as I was previosuly pretty dissapointed with standard LineageOS due to the amount of google and propiertry blobs it contained. I have followed divestOS for a while now and when my Lineage boot looped this morning I thought it was a good time to test DivestOS.
First off, I am very impressed with DivestOS, extremely slimmed down OS and I am much more comfortable with the privacy aspects that DivestOS is accomplishing. So thank you for all your efforts with the OS, it really is great and I would without a doubt recommend anyone who hasn't given it a spin to try it asap.
Now, I have a few issues I hoped @SkewedZeppelin or anyone else for that matter might be able to help me with. I have read the DivestOS documentation completely so understand what the recommendations and preferences of the developer is and why. I get it. That being said, we don;t live in an ideal world and unfortunately I do have some specific requirements that I can't go without and so I wanted to see how/if they could be incorporated. First of, which I know is a big no-no for the DivestOS developer, I need to root. I absolutely require call recording and without the native ability to automatically do it I have to really on a very good magisk module. Secondly, I need to be able to use TWRP with the ROM. I know TWRP has not been great with Lineage build but, I was able to unencrypt lineage-20.0-20230105 with the last @Siddk version, which the developer has now discontinued. So https://forum.xda-developers.com/t/recovery-11-12-13-unofficial-twrp-for-oneplus-6-6t.4382121/ is the last version I can use. Unfortunately @Siddk TWRP does not unencrypt the latest DivestOS. I need TWRP for recovery, like this morning when my lineageos boot looped for no apprent reason all my private data was lost, only for @Siddk TWRP saved the day and allowed me to unencrypt and adb pull it all out.
So to overcome these hurdles I would like to install an older version of DivestOS that would allow @Siddk TWRP to work. I had a copy of divested-20.0-20230123 so tried that but it is also too new and not working with TWRP. I would then assume that although the DivestOS is strongly against rooting, I would be able to flash Magisk as normal and then flash TWRP as my recovery. So i end up with an older DivestOS, running TWRP recovery, rooted with Magisk so I can run the call record magisk module. I am aware that rooting will effect future updates however I won't be wanting future updates because I need to stay on the same version to make sure TWRP continues to work.
Sooo, a very long winded way of asking for some links to older DivestOS builds, based on lineage-20.0-20230105 that @Siddk TWRP will work on and also to double check that I can infact still root the OS (even against the advice of the developer) if that is what i need to do.
Many thanks
You don't need an older build.
Just use the latest LineageOS recovery to flash Magisk and then you'll have root for your call recorder app.
Backup your device using Seedvault + copying files over MTP.
Also note there is a known issue recently on these devices where they may appear to bootloop, but it is just a race-condition and you can reboot a few times and they'll work: https://gitlab.com/LineageOS/issues/android/-/issues/5587
Thanks. I prefer a custom receovery (TWRP) that can decrypt the phone so when the phone does crash I have access to my data and it can be saved. If I couldn't use TWRP yesterday then everything since my last backup would have been lost for me. Do you have any links to older builds? Is it something you could possible provide?
Dissapointing that you chose just to ignore my last post. Pretty valid points on my part. Guess you want to keep your build locked down rather than having it open to user. Always a privacy and security concern when developers go down that route.
xs_pam said:
Dissapointing that you chose just to ignore my last post. Pretty valid points on my part. Guess you don't want to keep your build locked down rather than having it open to user. Always a privacy and security concern when developers go down that route.
Click to expand...
Click to collapse
mate the source code is right here, if you don't like my decisions you're welcome to compile with anything you want included: https://github.com/divested-mobile
there is even a written and video version of the build guide to make it very easy: https://divestos.org/pages/build
xs_pam said:
TWRP
Click to expand...
Click to collapse
Is not supported by DivestOS due to the stronger encryption used: https://github.com/Divested-Mobile/...d_system_extras/0001-ext4_pad_filenames.patch
you'd have to compile TWRP with that patch included
I understand, it's your ball, your decisions. Open source developers usually make previous releases available to allow users to snag issues etc, that was all I was asking but I accept your decison.
If TWRP would not work in any event, that means that there is no effective data recovery mechanism for your OS? You are maybe isolating a large part of your market there, I understand there is trade off between security and accesss but I would suggest the option to recover personal data form a bricked/looped OS would be more in demand than having data that absolutely no one can recover, including by the owner. At the end of the day having a recovery option uses the same access decryption method as the general phone access, means the data would still be as secured with a recovery option as it would be on a functioning os. It's the same methos to decrypt.
xs_pam said:
Open source developers usually make previous releases available
Click to expand...
Click to collapse
That is hundreds of gigabytes for each release batch, do you wanna pay that server bill?
That idea of yours wouldn't even work and as noted isn't even neccessary to get Magisk installed.
xs_pam said:
no effective data recovery mechanism for your OS
Click to expand...
Click to collapse
Seedvault is included for app backups.
xs_pam said:
no one can recover
Click to expand...
Click to collapse
it is your responsibility to make backups of your data regardless of what software you use
Fairpoint, I didn't realise the server costs were such an issue.
Your conflating back-up and recovery, they are two seperate things. Backing up is scheduled and planned, recovery is not. Unless you are backing up and then extracting that backup from your phone multiple times per day then you are at risk of losing important data should the unexpected occur. Data recovery is AS important but seperate to backing up. An OS without a data recovery option, or that blocks data recovery options, is significantly lacking. I understand that you use the lineage recovery but that does not provide an option to recover data.
xs_pam said:
Fairpoint, I didn't realise the server costs were such an issue.
Your conflating back-up and recovery, they are two seperate things. Backing up is scheduled and planned, recovery is not. Unless you are backing up and then extracting that backup from your phone multiple times per day then you are at risk of losing important data should the unexpected occur. Data recovery is AS important but seperate to backing up. An OS without a data recovery option, or that blocks data recovery options, is significantly lacking. I understand that you use the lineage recovery but that does not provide an option to recover data.
Click to expand...
Click to collapse
there are workarounds to what you are trying to achieve, i don't own a oneplus but i have achieved it with this OS.