Database Users

[Q] Unlock bootloader, still get updates?

Does having my bootloader unlocked affect getting updates? I have no interest in installing custom roms(for now), and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games. Figured I'd just unlock and root. I didn't plan on installing cwm so I could still get updates straight from google. I know an update would just overwrite root, but not sure if the bootloader would affect it. My galaxy nexus I always installed custom roms so I don't know how the bootloader affected OTA's. thanks guys.

In principle it should not affect updates.
Have a look at a prior OTA update's installer script
./META-INF/com/Google/android/updater-script
The OTAs perform binary patching on individual files, one by one. (That is why OTAs can be so small.) Before they perform the patching, a checksum is performed on every file on the tab/phone targeted for patching. If even one of those checksums fail, the entire install is aborted.
In addition the version of the recovery is sometimes checked, too - so merely having a custom recovery can trip up an OTA if that type of assert() check is performed.
To put that in general terms, you could say that an OTA update will almost always succeed if you merely add things to a ROM and leave the stock recovery in place.
If you want to flash stuff without altering the stock recovery just use a soft boot of a custom recovery, e.g. "fastboot boot custom-recovery-image-file.img"
If an OTA fails, don't get scared - you can simply unpack it, modify the updater-script file to remove the failing assert(), re-zip it and flash it. This would need to be done with a custom recovery, though as the modified OTA would no longer be correctly signed.
HTH

Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Sent from my Nexus 7 using Tapatalk 2

BrianDigital said:
Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Click to expand...
Click to collapse
yep.
The most recent OTA had the boot image file as one of its patching targets, so it was also subject to checksum verification during the initial assert() sequence of "updater-script".
I guess that means that if you hook anything into the boot sequence that needs to be in the ramdisk, that will trip up the OTA, as it is pretty typical for OTA updates to diddle the kernel or ramdisk. I guess that if you want to stay on a near-factory base distro including new ota updates, that puts the onus on you to either
(a) check the installers of the stuff you flash to make sure the boot image is not being re-packed -or-
(b) maintain a chain of pure stock backup sequences: then you can then restore them, run the OTA patch kit on them, make a new nandroid backup, and re-run your custom flashes. Probably use TiB to restore your apps on top of that, too. Almost like an OS re-install sequence, frankly.
cheers

thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.

tu3218 said:
thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.
Click to expand...
Click to collapse
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.

bftb0 said:
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.
Click to expand...
Click to collapse
Nah I haven't seen that. To be honest I've been so busy with flashing roms on my sgs3. I finally have settled down on a rom for my phone so I figured I'd give my nexus 7 a go. But I'd rather not be performing the whole backing up/flashing/modding on both. Its so much lol Plus my tablet I need to be dependable when I need it. That's why I hadn't planned on running roms, just basic root for blocking ads, etc. Before the last update this thing was so fast and enjoyable to use. It still is but its not to where it use to be. I was going to go back but I don't like knowing I'm not on the latest.

and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games.
Click to expand...
Click to collapse
Seeder doesn't fix lag. Doesn't work. If your n7 is lagging then there is another cause.
Sent from my Nexus 7 using Tapatalk HD

OTA Custom Recovery Misconception

Is it a misconception that an OTA update received on your phone will not install if you have a custom recovery? I just read an article on how an update will fail if you are running a custom recovery. However, when I updated from 4.2.1 to 4.2.2.. All I did was accept the OTA update notification I got on my phone and it installed fine through the TWRP recovery I had flashed on my Nexus.

It won't install automatically, as you found out. It has been said many times over that you are easily able to install the downloaded OTA yourself in your custom recovery.

peedub said:
It won't install automatically, as you found out. It has been said many times over that you are easily able to install the downloaded OTA yourself in your custom recovery.
Click to expand...
Click to collapse
Sorry maybe I didnt word my post correctly but what I am trying to say that it does install automatically. I got the update notification on my phone and it installed fine.

Rizy7 said:
Sorry maybe I didnt word my post correctly but what I am trying to say that it does install automatically. I got the update notification on my phone and it installed fine.
Click to expand...
Click to collapse
Yes its not new info as this has been discussed before in a number of threads back when the last OTA first came out.

Had a similar question, and in the spirit of not starting a new thread...
was this OTA just lucky in that regard?
ie. I want to root (for ads.. no other compelling reason for me.. I'm happy otherwise).. and would like to do so in a way that makes me as forward compatible for future OTA updates (ie. don't want to have to wipe data).
since I'm not looking for lots of typical custom recovery features, I'm wondering if I should even bother with a custom recovery.. and/or if any are likely to allow me to accept OTAs directly OTA.
thanks!

zim2dive said:
Had a similar question, and in the spirit of not starting a new thread...
was this OTA just lucky in that regard?
ie. I want to root (for ads.. no other compelling reason for me.. I'm happy otherwise).. and would like to do so in a way that makes me as forward compatible for future OTA updates (ie. don't want to have to wipe data).
since I'm not looking for lots of typical custom recovery features, I'm wondering if I should even bother with a custom recovery.. and/or if any are likely to allow me to accept OTAs directly OTA.
thanks!
Click to expand...
Click to collapse
Rooting your phone does not keep you from being able to update it. If all else fails you can always download the OTA and update it through your custom recovery. Which is what a lot of people did instead of waiting for Google to push it to their phone, myself included. Also you don't have to have a custom recovery installed if you don't want to after you root the phone. You could use one of the toolkit's to root it and it will install a temporary custom recovery used just for rooting then remove it when its done. Or just flash the stock recovery image after you root if you do it another way. If you go through the process of rooting I would recommend unlocking the bootloader too while you are at it but be warned this will erase all your memory so backup first.

Would it be plausible to use JTAG to rewrite an unlocked firmware?

I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?

I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.

tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?

I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?

Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"

They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.

tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+

The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.

Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting

tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?

dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom

dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work

tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing

dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.

dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.

tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader

Android 6.0 Marshmallow

Dumb question, but I'll ask anyway if I root will I not be able to receive OTA updates? Because I know whenever I did that with my Note 4 that if I tried it would give a message saying operating system is modified or something in that nature.

joe1blue said:
Dumb question, but I'll ask anyway if I root will I not be able to receive OTA updates? Because I know whenever I did that with my Note 4 that if I tried it would give a message saying operating system is modified or something in that nature.
Click to expand...
Click to collapse
You will not be able to take the ota. You have two options when marshmallow comes out.
1) Use the return to stock tool and take the ota them reroot
2) Wait for a flash able zip to become available.

TrenchKato said:
2) Wait for a flash able zip to become available.
Click to expand...
Click to collapse
Which will most likely be faster available than waiting for the OTA.

I'm not sure that will be the case for the MXPE. Fastboot shows the OS as "original," leading me to believe that OTA updates may work. Remember that on the Note 4, et al, unlocking the bootloader wasn't supported by the OEM or carrier. Since Moto is supplying the unlock codes, I suspect that OTA updates will not be disabled on the MXPE as long as no other OS changes are made. I could be wrong, but we'll find out when the time comes.

Tanker Bob said:
I'm not sure that will be the case for the MXPE. Fastboot shows the OS as "original," leading me to believe that OTA updates may work. Remember that on the Note 4, et al, unlocking the bootloader wasn't supported by the OEM or carrier. Since Moto is supplying the unlock codes, I suspect that OTA updates will not be disabled on the MXPE as long as no other OS changes are made. I could be wrong, but we'll find out when the time comes.
Click to expand...
Click to collapse
Chances are, if you unlocked your bootloader, you flashed a custom recovery. You can't take an OTA through a custom recovery -- not because it's "blocked," but because the OTA tool is not written to work with that recovery.

Could be. Easy enough to fix if so. Just tell TWRP to allow the OS to overwrite it, the reflash TWRP after the update.

Can't you just flash the stock recovery to take the OTA? Sure, you'll lose root, but you could still take the OTA, then flash your custom recovery again. Is there anything, other than a stock recovery, that prevents OTA updates?
I wish we had a release date. Getting excited for the new features. Should have kept my Nexus 5!

jonathanbailie said:
Can't you just flash the stock recovery to take the OTA? Sure, you'll lose root, but you could still take the OTA, then flash your custom recovery again. Is there anything, other than a stock recovery, that prevents OTA updates?
I wish we had a release date. Getting excited for the new features. Should have kept my Nexus 5!
Click to expand...
Click to collapse
A modified system will prevent the install. You would need to flash the system image as well.
Sent from my XT1575 using Tapatalk

I know some owners rooted their device for different reasons other than roms, but imo better to wait for 6.0 for OTA first. This phone comes with pure Android rom. Not like you need to remove bloat apps. Just need custom roms and kernels which is slow developing. Maybe the devs don't want to waste time with lp and their also waiting for marshmallow. I'm surprised how slow this device is moving under development. Oneplus one didn't have mass sale but their development was quick. Being so similar with nexus 6, hopefully we can get some love with MXP.
Sent from my XT1575 using XDA Free mobile app

I have been holding out on unlocking for this reason. I'm lazy and don't want to set everything up again so I will use Marsh to back everything up first then I will go to town

Tanker Bob said:
I'm not sure that will be the case for the MXPE. Fastboot shows the OS as "original," leading me to believe that OTA updates may work.
Click to expand...
Click to collapse
OTA will not work for rooted MXPE's.
1) Rooting the MXPE requires you to load an alternative recovery (TWRP), which doesn't work with the OTA installation scripts.
2) Rooting the MXPE modified /system files. And OTA updates check /system integrity before it runs the update. Rooted phones will fail that integrity check, and will fail to OTA for that reason.
You could restore your MXPE to stock conditions (un-root, and load stock recovery) to have it accept an OTA. I'm sure that most people will do that, and then re-install TWRP and re-root after that is done. However, I'd recommend you wait a bit for other people to try this first, just in case there are any issues and to verify that root is still available in Android Marshmallow 6.0

Makes sense. Somebody has to be first. I will do a nandroid backup before attempting to update by any means.

Prior comments in this thread:
"You will not be able to take the ota. You have two options when marshmallow comes out.
1) Use the return to stock tool..."
and
"You could restore your MXPE to stock conditions (un-root, and load stock recovery) to have it accept an OTA..."
I just wanted to clarify that the Return to Stock tool does not currently remove TWRP...
Factory image will appear here once available: https://motorola-global-portal.custhelp.com/app/standalone/bootloader/recovery-images
(Must log in with Motorola registered ID or gmail address)
Keep in mind you will see a Moto X (2nd Gen) Pure Edition already there...that is not ours.

hijax2001 said:
Prior comments in this thread:
"You will not be able to take the ota. You have two options when marshmallow comes out.
1) Use the return to stock tool..."
and
"You could restore your MXPE to stock conditions (un-root, and load stock recovery) to have it accept an OTA..."
I just wanted to clarify that the Return to Stock tool does not currently remove TWRP...
Factory image will appear here once available: https://motorola-global-portal.custhelp.com/app/standalone/bootloader/recovery-images
(Must log in with Motorola registered ID or gmail address)
Keep in mind you will see a Moto X (2nd Gen) Pure Edition already there...that is not ours.
Click to expand...
Click to collapse
More clarification: Restore-To-Stock-Tool does replace TWRP. Have a gander inside the zip. I spy recovery.img within. What do you see?

PiousInquisitor said:
More clarification: Restore-To-Stock-Tool does replace TWRP. Have a gander inside the zip. I spy recovery.img within. What do you see?
Click to expand...
Click to collapse
Yup, you're correct ... I just used the tool earlier today and I do indeed have stock recovery.
Sent from my XT1575 using Tapatalk

Sharing my experience... good it's supposed to. Didn't for me, for some reason, until 2nd power cycle. It is stock recovery now though. Sorry for the confusion.

Pros/Cons of Rooting Moto G5 Plus!?

I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?

yourSAS said:
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
Click to expand...
Click to collapse
It is not possible to root without unlocking the bootloader on this device...
If you don't have a specific reason to root, don't do it.
And once rooted, you cannot accept any OTA... most likely case if you do it will just fail, worst possible case it bricks (which can happen but is extremely rare).

To answer the question in your title, about the advantages of rooting...
Rooting gives you near full access to your device, and thus the ability to customize it beyond the options provided to you via the default interface. Also, some apps provide additional features on rooted phones. For example, some security programs recommend rooting your device so that it can more forcefully integrate itself with the device to protect against malware, hacking, etc. I tend to install a security package that works better on a rooted device, as well as make use of features that tend to only work on a rooted device, such as folder mounting from the internal SD card to the external one. Also, allows me to access system files that are unavailable otherwise, allowing me to customize certain sounds (or copy them at least).
If you decide you want to root your device, make sure you understand the steps to take BEFORE trying it. That means when you come across a guide on how to do it, make sure you get all the files that will be required and reading through the instructions step by step. If any of the steps sound like it will leave you lost on what to do, then DO NOT do any of it. Also, make sure you read the comments for the guide as well, looking for any mention of issues encountered and consider if you might encounter those issues as well. For example, if it causes issues for devices that use a particular carrier and you use that same carrier, you might want to leave well enough alone. Compare your phone version numbers with what others report having issues with (kernel, baseband, build, etc). Anything that someone has an issue with where their phone somehow matches up with yours in some way, take that as a sign to investigate deeper, so as to avoid having any issues yourself.
For the most part, unless you have a need or desire for a feature/function that requires rooting your device, don't mess with it. I'm not kidding, as one mistake can leave you without a working phone and without any options for returning/replacing it.

Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?

yourSAS said:
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
Click to expand...
Click to collapse
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Unrooting is easy, the issue arises undoing what you did with root, undoing them all depends what you changed.
I don't know of any reasons specific to this device to root.

acejavelin said:
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Click to expand...
Click to collapse
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?

yourSAS said:
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
Click to expand...
Click to collapse
No, the status of your bootloader is not relevant... Moto will notify you of an available update and happily attempt to apply it regardless if your bootloader is locked or not.
What matters is if the boot or system partitions is changed, if there is ANY change to those, among other things like if the radio version or recovery versions don't match or the partition table is changed, the update will fail. If you flash any custom recovery it will fail as well.

On this subject I mention a slight con which is that some banking or financial apps might complain to you if they detect root. I have maybe 10 different bank and credit apps installed and all work flawlessly except 1. The Huntington Bank app wont allow me to use fingerprint login but otherwise the app is fully functional like mobile deposits. Just wanted to mention to be aware.