Database Users

Kernel/bootloader/recovery

Hi guys,
1. What is the advantage/disadvantage of flashing a custom kernel?
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
7. Difference between unlocking bootloader and rooting.
8. How to find out N7's latest stock kernel version.
Many thanx
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
1. What is the advantage/disadvantage of flashing a custom kernel?
Click to expand...
Click to collapse
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
valapsp said:
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
Click to expand...
Click to collapse
I believe it does. I don't remember which one though, since I don't use CM.
valapsp said:
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
Click to expand...
Click to collapse
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
valapsp said:
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
Click to expand...
Click to collapse
I believe it contains stock ROM and kernel.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
valapsp said:
7. Difference between unlocking bootloader and rooting.
Click to expand...
Click to collapse
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
valapsp said:
8. How to find out N7's latest stock kernel version.
Click to expand...
Click to collapse
Google. Sorry, can't help you with this one.

That was a great answer @Rirere

Rirere said:
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
I believe it does. I don't remember which one though, since I don't use CM.
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
I believe it contains stock ROM and kernel.
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
Google. Sorry, can't help you with this one.
Click to expand...
Click to collapse
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.

valapsp said:
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
Click to expand...
Click to collapse
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).

Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.

kbeezie said:
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
Click to expand...
Click to collapse
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img

valapsp said:
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
Click to expand...
Click to collapse
bootloader img would be the original stock bootloader for the Nexus 7, chances are you never replaced it, you only unlocked it. There's usually no reason to replace the bootloader with a custom one since all you need to do is unlock it.
userdata.img would be the /data partition. The firmware download basically has a image for all of the partition in the original out-of-the-box stock state. Technically you don't even to flash it, as long as you wiped /data before rebooting (since that would be the same as a clean install if you instead flashed the system and boot partition).
Edit: If I were messing with it to get back stock rom (but not messing with recovery, cuz custom recovery is still handy to have), I would only flash the boot.img and system.img , then log into Recovery and wipe data (ie: factory reset which wipes cache and /data but doesn't touch /data/media), Then I would be able to reboot into a clean stock install of the rom.
(from there I could just make a backup from recovery so I wouldn't have to do a fastboot flash again).

kbeezie said:
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Click to expand...
Click to collapse
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.

@valapsp
Small but important clarification.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Essentially 100% of custom ROMs install a kernel. (Actually, a kernel plus a ramdisk packaged together as a single ("bootable image") file, typically named "boot.img".) So your preexisting boot image containing the kernel is always overwritten during a ROM installation. See next answer.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Almost, but not quite. If you want to use a different kernel than what ships with a given ROM, you flash it after you have installed the ROM, not beforehand. See prior answer.
One more thing. Since you are new to this stuff, I'll make a suggestion:
Learn how to create and restore full Nandroid backups (using the custom recovery) immediately. And get in the habit of copying them off your tablet to your PC. You will thank me later for this advice.
have fun

Rirere said:
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
Click to expand...
Click to collapse
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.

GedBlake said:
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
Click to expand...
Click to collapse
I believe you are correct! Theoretically, the script could rather easily check for added files by checksumming the entire /system partition before running the update (using a fast hash algorithm-- you're only looking for the presence of any changes, afterall). And I did have one OTA that went fine, other than losing root back on my Galaxy Nexus.
Again though, it's a classic case of should versus real life. Some root methods might alter things in /system without your knowing, or root actions might alter permissions. Either way, it's a tricky, nasty little game.
So far as recoveries go: yeah, OTAs have a nasty habit of trying to do that. Some of the more advanced recoveries can resist being overwritten though/slipstream a root ZIP into the update process.

GedBlake said:
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Click to expand...
Click to collapse
Typically the OTAs also update the boot image, so the boot partition (LNX) is also checked. The stock recoveries almost always use the same kernel (with a different ramdisk) as the boot image, so they are usually rewritten too.
Owners of tilapia N7 devices have reported successful flashing of everything but radio firmware images when they used a custom recovery to process the OTA bundle. Not a disaster, as their devices will still function with old radio firmware, but it puts them in an unusual position of being unable to use the OTA to subsequently update the radio, even if they restore the stock recovery (the system files and boot images will have been changed, so almost all of the checksums will fail). At that point, using fastboot is an alternate option, but then the newbs will need to read about OTA images, unpack them, yadda yadda yadda.
IMO it is just a dumb idea applying OTAs to anything but a pure stock device. And when I say pure stock, I mean including the stock recovery. The boot loader can be left unlocked, but that's about it.
There are a lot of ways to skin the cat, but IMO the best way to proceed is to operate with two parallel but independent tracks of Nandroid backups/restores: one track is a sequence of pure stock, and the other your customized ROM du jour.
Let's presume you have a Nandroid backup of the pure stock ROM. Make a backup of your current (customized) ROM & get it copied off the tablet (in the event of a disaster), restore the pure stock ROM nandroid backup, flash the stock recovery back to the tab, and then take the OTA.
At this point:
[ unlocked bootloader ] soft-boot (no flashing) a custom recovery using fastboot, and then make yet another Nandroid backup of the newly updated stock ROM including the recovery image. (This becomes the new baseline for future OTAs)
[ locked bootloader ] re-root with motochopper, capture the (new) stock recovery partition using 'dd', flash a custom recovery ('dd' or other method), make a Nandroid of this. (These two backups become the new baseline for future OTAs)
Then, repeat any rooting customizations (if you are a "lightly customized rooted stock" kinda person), and restore apps (Market apps only!) with TiBu.
This may seem like a great deal of work, but it is the only way to insure that you can revert to a prior starting position. Look: after going down a road like this you can even restore the old customized ROM backup to make TiBu app backups after the fact, simply because you can return to any point in time if you have made a backup (and kept a copy of it off the tablet).
Everybody makes mistakes - even the experts. But the lazier folks are (read: toolkit user) the more likely is a disaster. Everybody needs to make backups.

What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app

valapsp said:
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).

kbeezie said:
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
Click to expand...
Click to collapse
Thanks, and does backing up thru cwm also back up the build.prop?

valapsp said:
Thanks, and does backing up thru cwm also back up the build.prop?
Click to expand...
Click to collapse
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.

kbeezie said:
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
Click to expand...
Click to collapse
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app

valapsp said:
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
If it's a backup done with 4EXT or TWRP most certainly since it's just a tarball package (or tar+gzipped if you enabled compression) and can be easily unpacked by tar, or any popular archive utility like 7Zip for windows. (restoration generally just looks at the file info to see what partition type it's supposed to be, formats the partition as such, and then just un-tars the content, with the permissions and such retained).
If it's older where it's an actual jaffs (may have spelled that wrong) disk image, I'm not sure off the top of my head how you would mount it as a disk , and then mount the ext4 or ext3 partition in order to get to it. I would assume ClockworkMod would have upgraded their backup method to the same as TWRP or 4EXT, but it's possible that they didn't for compatibility reasons.

MotoG4+ XT1644 6.01 to 7.0 Saga (for others to avoid)

OK Please note (4-25-17) this message is a work in progress, as I slowly restore my system.
This is a listing and hopefully helpful listing of what I did (right and wrong)
in upgrading my Systemless-rooted (suuser) phone from 6.01 to 7.00 (nougat)
# 1. it did not work, and I went back to 6.01 successfully using the twrp recovery
I have previously used Bender's guid (here) to get the system-less root on 6.01.
essentailly, here's the best plan. Use the Minimal ADB and Fastboot package (MADB &F) (here)
(Explanation: the MADB&FB package will allow you do do LOTS of stuff related to updating your phone, with very little grief.)
it also includes the ability to automatically "push" a package over your usb connection if the ZIP file doesnt load right. **THIS will come in handy later!
Once MADB&F is installed, make note of your directory, and then make sure you start your dos window (for pc users) as an administrator!
BTW, if I HADN'T made the "TWRP backup" of my system, I'd be Sh*t out of luck right now...", because I screwed up the 7.0 upgrade.
the technical problem was that I had no data, no modem, no way of getting data/voice in/out.
SIMPLY using the TWRP restore fixed me!!!
(so far, we have MADB&FB, downloaded and bender's (chainfire) rootless guide.
Next you want to download the current firmware image for your phone. This will be a lifesaver, I promise!
3) Download a TWRP image (this will MAGICALLY load on your pc when you tell it you need help! Look HERE
(Athene is the Motorola Codename for the motoG4+)
3) copy the athene TWRP image into your madb&FB directory to make it easy to load
4) next, (you still haven't touched your phone yet, you realize: (skipping some basics here, you can search here on XDA to find more info)
a) plug your phone into your pc
b) make sure you are a developer
c) make sure your phone shows you are connected to your pc for file transfers, NOT for charging
5) in your MADB&FB directory, (aka a dos/(admin) window) type the following:
all commands at this point will take place in whatever directory you installed Minimal ADB & Fast boot (MADB&FB)
Connect your phone to your PC and open MADB&FB, check the connection with:
adb devices
return should include your "serial-no" and "device".
6) next, on pc, tell the system to reboot your phone to the bootloader!
Reboot into bootloader with:
adb reboot-bootloader
and check again with:
fastboot devices
7) Next you are going to download TWRP to your phone (not permanently, just for a bit!)
fastboot. flash recovery twrp-3.0.2-0-athene.img
Now you have TWRP (Team Windows RECOVERY PROJECT) loaded.
SO.. THIS is where you create a backup of your current stuff using the backup options.
NEXT:
take the suUser2.78 (stateless rooting), and once your backup is done, install it from TWRP
Then (I was) back to 6.01 rooted.
NEXT: 7.0 and then rooting... (will update tomorrow)
did a successful upgrade to 7.0,
then unsuccessfully tried to sideload supersu2.78, which bricked loader
then downgraded again to 6.01 (and rooted again, ok)
will continue tomorrow.
need working phone for now..
cheers to all, and to all, a happy spelunking!

You can't root factory Nougat as is, it is well encrypted.
You need to replace first the kernel with the ElementalX one, or you will end up with bootloops.
Only after that you can do SuperSU, but only with the latest beta.

A few pointers from your story:
1)As you've found out the hard way, you won't be able to update to Nougat if you have root and/or TWRP, because the update requires a stock system - stock recovery, system and no modifications (bootloader status doesn't matter). In other words, you'll need to unroot and restore your stock recovery - might be easier to reflash the stock system, probably the quickest way to flash a stock ROM (and update to Nougat) is to use the fastboot ROM. https://forum.xda-developers.com/moto-g4-plus/how-to/moto-g4-plus-xt1640-43-athene-npj25-93-t3549369 Of course, this will remove root and TWRP, as well as potentially wipe your data, so back up accordingly. This should flash the NPJ25.93-14 build on your device, which appears to be the latest global build.
1a)Also, if you flash Nougat this way, your bootloader and GPT partitions will be updated, so if you wish to downgrade to Marshmallow at any point, when flashing do not flash these partitions from the Marshmallow ROM. Fastboot should stop you, but a brick may occur if these get flashed.
1b) You may find in the Guides section TWRP backups of Nougat builds, I don't recommend using these to update your system with. Granted, they have most of the Nougat system in a TWRP backup, but some crucial firmware (e.g. the baseband) is not included, and may cause you issues if your device is not formally flashed to Nougat.
2) As SoNic67 has already mentioned, the stock kernel security will cause your device to bootloop should you choose to try to root following the Marshmallow method. If you wish to use SuperSU, follow this guide: https://forum.xda-developers.com/mo...de-root-moto-g4-plus-supersu-android-t3587918 You may wish to use a more up to date TWRP than the official 3.0.2 (I recommend shrep's TWRP 3.0.3 n4 here:https://forum.xda-developers.com/mo...covery-twrp-3-0-2-r3-moto-g4-g4-plus-t3494337) Whatever you do, ensure you flash first the ElementalX kernel before you flash the SuperSU v2.79 SR3 beta (https://forum.xda-developers.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133), or apply the systemless fix with earlier SuperSU versions as directed in the aforementioned rooting with SuperSU guide. Else you'll be having bootloops or your device will not boot whatsoever. Here's my steps in successfully rooting Nougat: https://forum.xda-developers.com/showpost.php?p=71817346&postcount=225. Good luck either way.

echo92 said:
A few pointers from your story:
[...]
1b) You may find in the Guides section TWRP backups of Nougat builds, I don't recommend using these to update your system with. Granted, they have most of the Nougat system in a TWRP backup, but some crucial firmware (e.g. the baseband) is not included, and may cause you issues if your device is not formally flashed to Nougat.
[...]
Click to expand...
Click to collapse
After updating my US retail xt1644 to nougat, by restoring totally-stock marshmallow then taking the OTA, I wiped data and made a *complete* TWRP backup using @Shreps' unofficial 3.1 TWRP build (https://moto.shreps.fr/Moto G4 (athene)/recovery/twrp-3.1.0-athene_shreps.img).
This version of TWRP allows backup/restore of the full set of firmware partitions including baseband, DSP, etc.
In other words, I believe the TWRP backup folder in the following .zip file provides a one-stop path to the latest xt1644 USRET firmware by doing a restore from TWRP 3.1.0.
https://drive.google.com/file/d/0B4XobQzgZVHyRTlmSDMtYkdZeUU/view?usp=drivesdk
My only uncertainly is if the ota process modified the partition table in a way that might make this backup image incompatible with the xt1644 still in the marshmallow state.
I've often wondered if I (or a more skilled enthusiast) couldn't build a TWRP-flashable .zip that would setup the partition table, update the baseband, etc. This is what I've grown used to from devs on other phones I've had, but perhaps there's something about the way moto does things that makes this problematic.
Sent from my Moto G4 Plus using Tapatalk

bmeek said:
After updating my US retail xt1644 to nougat, by restoring totally-stock marshmallow then taking the OTA, I wiped data and made a *complete* TWRP backup using @Shrep's unofficial 3.1 TWRP build (https://moto.shreps.fr/Moto G4 (athene)/recovery/twrp-3.1.0-athene_shreps.img).
This version of TWRP allows backup/restore of the full set of firmware partitions including baseband, DSP, etc.
In other words, I believe the TWRP backup folder in the following .zip file provides a one-stop path to the latest xt1644 USRET firmware by doing a restore from TWRP 3.1.0.
https://drive.google.com/file/d/0B4XobQzgZVHyRTlmSDMtYkdZeUU/view?usp=drivesdk
My only uncertainly is if the ota process modified the partition table in a way that might make this backup image incompatible with the xt1644 still in the marshmallow state.
I've often wondered if I (or a more skilled enthusiast) couldn't build a TWRP-flashable .zip that would setup the partition table, update the baseband, etc. This is what I've grown used to from devs on other phones I've had, but perhaps there's something about the way moto does things that makes this problematic.
Sent from my Moto G4 Plus using Tapatalk
Click to expand...
Click to collapse
Nice one, hopefully that'll help more XT 1644 users I'm still not sure if TWRP can backup/flash the baseband by itself, but I don't have a XT 1644 to test. I imagine your backup will need a clean flash (wipe data/cache/Dalvik) to work?
The OTA process does update the partition table, but as far as I know, that should not prevent you from flashing back to Marshmallow/Nougat as you wish, so long as you did not try to downgrade the GPT/bootloader.
There was an effort to create TWRP flashables of the stock ROMs a little while ago (you can see the thread here: https://forum.xda-developers.com/moto-g4/development/fxz-athene-twrp-flashable-fastboots-t3562147) which if I understood it created flashable radios and ROMs from the firmware files we have. We can't touch the GPT/bootloader since, as I recall, you need a signed stock firmware to do so (and besides, downgrading GPT might be asking for a brick). I recall some users mention they were able to run Nougat TWRP flashes on the MM bootloader/GPT without issue.
There were issues with simply flashing the Nougat 93-14 radio baseband files for some US users, losing LTE in the process and appears the only resolution was to flash the stock ROM - I don't know what the cause was (perhaps no/incorrect CDMA support in the radio files?). Your TWRP flash is from a US based phone so may have better luck in that department, and will likely behave on your device since that OTA has updated all the firmware on your device that TWRP isn't able to touch. I still am not sure if we can use this TWRP backup to update on a MM device without issue, but only one way to find out...

Need Help Understanding ROMs after I rooted

I had 6p since release. I didn't want to root while still getting OTA updates. I figured Oreo may be last I will get so I rooted with Skipsoft Toolkit and all went well. Now onto Roms. My main question is, can I flash any ROM regardless of the Android version? As I'm on Oreo, can I flash Pure Nexus running 7.1.2, or must I only flash Oreo Roms?

It's more the custom recovery u need than being rooted.
If your bootloader is unlocked and you got TWRP as recovery installed u can flash any custom rom u want to.
If you like to stay up to date with security patches you should flash Oreo roms in the future.

cigator said:
I had 6p since release. I didn't want to root while still getting OTA updates. I figured Oreo may be last I will get so I rooted with Skipsoft Toolkit and all went well. Now onto Roms. My main question is, can I flash any ROM regardless of the Android version? As I'm on Oreo, can I flash Pure Nexus running 7.1.2, or must I only flash Oreo Roms?
Click to expand...
Click to collapse
It's inadvisable to jump to a custom ROM based on a different version of Android. So, if you were on stock Oreo and you wanted to flash a custom Nougat ROM, you'd be better to revert to the factory Nougat images and then flash an N-based ROM. Regardless of what you try though, make sure you have the latest TWRP and have a full backup (also referred to as a Nandroid backup) before you flash any modifications. If you end up borking things then you can simply restore your device to it's last stable state.
When it comes to rooting, recoveries and flashing ROMs, I'd highly recommend you become familiar with, and follow, the guide at https://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928 as it's very clear to how you do most modifications to your device.
Happy flashing.

ultyrunner said:
It's inadvisable to jump to a custom ROM based on a different version of Android. So, if you were on stock Oreo and you wanted to flash a custom Nougat ROM, you'd be better to revert to the factory Nougat images and then flash an N-based ROM. Regardless of what you try though, make sure you have the latest TWRP and have a full backup (also referred to as a Nandroid backup) before you flash any modifications. If you end up borking things then you can simply restore your device to it's last stable state.
When it comes to rooting, recoveries and flashing ROMs, I'd highly recommend you become familiar with, and follow, the guide at https://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928 as it's very clear to how you do most modifications to your device.
Happy flashing.
Click to expand...
Click to collapse
Thanks for that link. I thought I knew what I was doing, but I see I already screwed up, because I installed TWRP and rooted. Set phone the way I wanted and made a Nandroid. I never made a Nandroid of my stock Oreo set up. Damn. Hope that doesn't come back to bite me.

cigator said:
Thanks for that link. I thought I knew what I was doing, but I see I already screwed up, because I installed TWRP and rooted. Set phone the way I wanted and made a Nandroid. I never made a Nandroid of my stock Oreo set up. Damn. Hope that doesn't come back to bite me.
Click to expand...
Click to collapse
As long as the setup is working and mostly the way you want it, that's what you want the nandroid for. Most people will just ensure they have a working ROM for a backup before they begin flashing other stuff. I'd also recommend moving a copy to your computer. If you ever do a 'complete' wipe that includes your sd card, your backups will be gone too.
The one thing to be aware of with nandroid backups is, if you have any kind of screen PIN/security, when you restore it, you're temporarily locked out as the PIN doesn't work. If this happens to you, it's not the end of the world, but you have to boot into TWRP, go into your system files and delete the three lockscreen db files, then you'll effectively have an unlocked screen and can reset your PIN, pattern and fingerprint. The easiest thing to do (which I never remember) is to remove lockscreen security before you make the backup.

[mini-GUIDE] BRICKED / DOWNGRADE / SAME / UPGRADE - also ALTERNATIVE to RSDlite

I am not responsible for your bricked phone or pigeon poo on your toupe. Do at your own risk.
Many thanks to @SupahCookie for idea and motivation!
INTENTIONALLY DOES --NOT-- LOCK BOOTLOADER!!!
Get factory images here:
https://forum.xda-developers.com/mo...ock-images-t3736767/post75236696#post75236696
THIS GUIDE IS FOR FACTORY/STOCK ROMs - NOT YOUR AVERAGE CUSTOM ROM which may not have bootloaders!!! (thanks!!!!! @echo92 )
FIX:
IF YOU ARE ABLE TO GET TO FASTBOOT THIS SHOULD WORK.
IF YOU HAVE 8.x bootloaders AND ARE DOWNGRADING TO 7, use "Alternative to RSDlite" below.
1 boot to win - 7 or 10 works fine.
2 boot phone to fastboot, and connect phone to computer.
3 start RSDlite
pick a ROM. I believe I used a 7.1.1 rom
3Nov9-ADDISON_NPNS26.118-22-2-8_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip
RSDlite installed it and fixed the problem.
- -
I was then able to use RSDlite to install @rafikowy 's signed 8.0 . - going up from 7 to 8.
- -
- -
If you are on 8.x bootloaders and want to go to 7.x bootloaders, use this (RSDlite throws an error and stops):
ALTERNATIVE TO RSDlite:
1 I used 7zip to extract that 7.1.1 zip (or any ROM zip) into a folder x,
2 add all the adb and fastboot junk to folder x,
3 add the attached file (rename it to flash.bat) to folder x.
4 boot phone to fastboot and connect to computer.
5 click on flash.bat - it throws a lot of "slot" errors but works just fine.
6 reboot your phone if it hasn't already and go through the 7.x install stuffs.
7 you will not show an IMEI if you are coming from an 8.x bootloader. However, it IS there.
NOTE: you may need to add a line to the flash.bat if there are more/less sparsechunk's in your FACTORY/STOCK ROM...
THIS IS NOT FOR CUSTOM ROMs!!!!!!!
EDIT: 3-8-19: I just did this myself to go back very briefly to 7.1 - be sure you don't flash TWRP to it if your going to take OTAs - it will brick it. boot to TWRP if you need TWRP briefly: fastboot boot twrpimg.img
----------
If you can boot to fastboot screen, you can do anything.
Never OTA a ROM if you have modified recovery (TWRP, etc) or if magisk is present.
https://forum.xda-developers.com/mo...p-flashing-t3813498/post77011495#post77011495
I changed the attached file to add pause and reboot and exit to make it slightly more automated.

I have successfully used this many times going back and forth. If you can boot to fastboot screen, you can save your phone and flash anything you want.

You may wish to advise users that if they downgrade to Nougat not to use Nougat OTA updates. The reason being that a downgraded stock Oreo device may still have the Oreo bootloader on it. Thus, attempting to use Nougat OTA updates may hard brick their device (as the bootloader is likely corrupted, meaning no fastboot).
Users could either use the Feb 2018 NPN26.118-22-2-17 firmware from your link https://mirrors.lolinet.com/firmware/moto/addison/official/RETAIL/ as that was the last Nougat firmware (and thus no Nougat OTA updates) or avoid using OTA updates whilst downgraded.

echo92 said:
You may wish to advise users that if they downgrade to Nougat not to use Nougat OTA updates. The reason being that a downgraded stock Oreo device may still have the Oreo bootloader on it. Thus, attempting to use Nougat OTA updates may hard brick their device (as the bootloader is likely corrupted, meaning no fastboot).
Users could either use the Feb 2018 NPN26.118-22-2-17 firmware from your link https://mirrors.lolinet.com/firmware/moto/addison/official/RETAIL/ as that was the last Nougat firmware (and thus no Nougat OTA updates) or avoid using OTA updates whilst downgraded.
Click to expand...
Click to collapse
Interesting. I used the above GUIDE to go up and down a number of times on my phone (about 20 total) , installing and running on both 7 and 8, and then went down to a Nov 7.1.1 and let it ota all the way up to 8.0 and that is what I am using now. I found that when i used a factory zip, and the above procedure, it corrected the bootloaders to the appropriate version that i was flashing - either RSDlite or the more manual path which ignores the errors worked for me.
Using the above procedure , you get the correct bootloaders, which are in the zip.
Please correct me if i am wrong!

KrisM22 said:
Interesting. I used the above GUIDE to go up and down a number of times on my phone (about 20 total) , installing and running on both 7 and 8, and then went down to a Nov 7.1.1 and let it ota all the way up to 8.0 and that is what I am using now. I found that when i used a factory zip, and the above procedure, it corrected the bootloaders to the appropriate version that i was flashing - either RSDlite or the more manual path which ignores the errors worked for me.
Using the above procedure , you get the correct bootloaders, which are in the zip.
Please correct me if i am wrong!
Click to expand...
Click to collapse
That's intriguing - we saw previously on Z Play that users downgrading their stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/help/hard-brick-moto-z-play-patch-abril-t3782927 )and then using OTA updates hard bricked their device (hence the number of users asking for a blankflash, as fastboot no longer works). I don't know if these users hard bricked by downgrading their firmware too far and then flashed an OTA radically different to their previous firmware, or whether it's a risk that's taken by any downgrading of firmware.
When you used fastboot, did you see any 'security downgrade errors' when you flashed the bootloader, and is your bootloader version now C180, as you've flashed the Oreo OTA?

echo92 said:
That's intriguing - we saw previously on Z Play that users downgrading their stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/help/hard-brick-moto-z-play-patch-abril-t3782927 )and then using OTA updates hard bricked their device (hence the number of users asking for a blankflash, as fastboot no longer works). I don't know if these users hard bricked by downgrading their firmware too far and then flashed an OTA radically different to their previous firmware, or whether it's a risk that's taken by any downgrading of firmware.
When you used fastboot, did you see any 'security downgrade errors' when you flashed the bootloader, and is your bootloader version now C180, as you've flashed the Oreo OTA?
Click to expand...
Click to collapse
YES - that's why I wrote these 3 guides - before, it was quite possible to wind up with a bootloader mix - esp depending on the zip you use! - factory/stock only!!!
I added a line to the guide saying that it is only intended to be used for the factory/stock zips as these have (I believe) the bootloaders appropriate to the ROM.
Many thanks for pursuing this! - I wonder if we'll have to exclude certain ROMs that are in the factory lists?????

echo92 said:
That's intriguing - we saw previously on Z Play that users downgrading their stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/help/hard-brick-moto-z-play-patch-abril-t3782927 )and then using OTA updates hard bricked their device
Click to expand...
Click to collapse
If you have TWRP (or I assume any custom recovery) present when you try to ota, it can download just fine and then reboot to the update. I had TWRP and wound up in a situation where my phone would only boot to twrp no matter what I flashed or restored. I booted phone to fastboot, RSDlite'ed that 11-09-17 factory zip and all was well. In that particular case I did not fully install 7.x but immediately RSDlite'ed rafikowy's 8.0 signed stock and went on with my testing. Since then I always boot to TWRP rather than intalling it and do my thing. (thanks @jceballos )
When you used fastboot, did you see any 'security downgrade errors' when you flashed the bootloader, and is your bootloader version now C180, as you've flashed the Oreo OTA?
Click to expand...
Click to collapse
Sorry - since it throws a million errors I never look at it if it works.
The particular build I am on at the moment - is BL: C1.82
This one started from that Nov '17 build and ota'ed all the way to 8.0 Apr.
I root and unroot as needed per rafikowy's method but using a boot to TWRP - never an install TWRP.
I'll put up a new guide ref ota and recovery and brick.

KrisM22 said:
If you have TWRP (or I assume any custom recovery) present when you try to ota, it can download just fine and then reboot to the update. I had TWRP and wound up in a situation where my phone would only boot to twrp no matter what I flashed or restored. I booted phone to fastboot, RSDlite'ed that 11-09-17 factory zip and all was well. In that particular case I did not fully install 7.x but immediately RSDlite'ed rafikowy's 8.0 signed stock and went on with my testing. Since then I always boot to TWRP rather than intalling it and do my thing. (thanks @jceballos )
Sorry - since it throws a million errors I never look at it if it works.
The particular build I am on at the moment - is BL: C1.82
This one started from that Nov '17 build and ota'ed all the way to 8.0 Apr.
I root and unroot as needed per rafikowy's method but using a boot to TWRP - never an install TWRP.
I'll put up a new guide ref ota and recovery and brick.
Click to expand...
Click to collapse
1) If you have TWRP, then using an OTA will fail - as you've not got stock recovery (and likely other modifications, including possibly a system partition set to read-write status). As you noted, having TWRP seems to cause a bootloop when rebooting - I'm not sure if the OTA sets a boot flag to stay in recovery until the update is completed. For the G4/Plus, there's a possible solution by wiping the misc partition but I don't know if there's a similar partition for Z Play devices: https://forum.xda-developers.com/moto-g4/help/troubleshooting-twrp-boot-loop-ota-t3714325
The only other solution I've seen is a clean flash of the stock ROM to get your device booting properly.
Booting to TWRP rather than flashing would mean your stock recovery is still present on your device. The only downside is if you need to make modifications, you'd need your computer to boot to TWRP.
2)BL C1.82 seems to be the bootloader provided by the Oreo April 2018 security patch update, so your device looks to be on the right bootloader. It's still curious that the Nov 2017 firmware worked whereas countless other 'factory' stock ROMs caused hard bricks when downgraded to and then OTA updates were installed.
As you mentioned, custom ROMs don't have bootloaders and thus don't care about your bootloader version usually (though I've seen some ROMs require a certain bootloader). However, stock ROMs and stock OTA updates do have bootloaders, which is why downgrading can be risky.

echo92 said:
1) If you have TWRP, then using an OTA will fail - as you've not got stock recovery (and likely other modifications, including possibly a system partition set to read-write status). As you noted, having TWRP seems to cause a bootloop when rebooting - I'm not sure if the OTA sets a boot flag to stay in recovery until the update is completed. For the G4/Plus, there's a possible solution by wiping the misc partition but I don't know if there's a similar partition for Z Play devices: https://forum.xda-developers.com/moto-g4/help/troubleshooting-twrp-boot-loop-ota-t3714325
The only other solution I've seen is a clean flash of the stock ROM to get your device booting properly.
Booting to TWRP rather than flashing would mean your stock recovery is still present on your device. The only downside is if you need to make modifications, you'd need your computer to boot to TWRP.
2)BL C1.82 seems to be the bootloader provided by the Oreo April 2018 security patch update, so your device looks to be on the right bootloader. It's still curious that the Nov 2017 firmware worked whereas countless other 'factory' stock ROMs caused hard bricks when downgraded to and then OTA updates were installed.
As you mentioned, custom ROMs don't have bootloaders and thus don't care about your bootloader version usually (though I've seen some ROMs require a certain bootloader). However, stock ROMs and stock OTA updates do have bootloaders, which is why downgrading can be risky.
Click to expand...
Click to collapse
Downgrading is a piece of cake if you don't use RSDlite - it throws an error and stops. Using the bat file it can happily throw all the errors it wants and all I care is at the end I have what I want.
It does indeed change the entire environment when you bat file the zip contents. You can bat file to get from 8 to 7 and then use RSDlite to flash a different 7 OR 8 zip file. There is no resulting difference in whether you RSDlite it or bat file it - the bat file simply comes from the .xml file that is within the zip. There is very little or no difference between that among addison factory/stock zips. Other zips are different (custom ROMs.)
Grab any factory/stock zip for addison and expand it and you will see modems, bootloaders, indeed absolutely everything you would find on that phone if you went to a store and bought it. SupahCookie simply added a couple lock command lines because it was intended for folks who somehow thought that if phone was locked they could take it back to the store and get their money back. Or some such. I found that ATT folk didn't care if you were on CM or whatever if you just needed to swap SIMs or whatever.
I DON'T want to lock the phone as it prevents me from modifying forever. Oh yeah that reminds me I was going to post the obligatory guide (again) about how to flash a white boot logo so you don't get that message - it's still there LOL but since the font is in white, you can't see it.

I have a Moto Z2 Play and used this to get out of a rather sticky situation.. My IEMI shows 0 now and I'm curious if there's a way to fix this? Also, You say you've done OTA updates? My phone is telling my I have some, is it safe to try?

Necrowr said:
I have a Moto Z2 Play and used this to get out of a rather sticky situation.. My IEMI shows 0 now and I'm curious if there's a way to fix this? Also, You say you've done OTA updates? My phone is telling my I have some, is it safe to try?
Click to expand...
Click to collapse
Thanks for feedback and great on success.
IMEI will show zero if using oreo, It will show again if using N. Remember that if you go from O to N you need to use the "Alternative to RSD" as RSD will simply throw an error and stop.
If you have TWRP and/or Magisk you must get rid of them before ota - if twrp present you will soft brick and have to do alternative again - flash a stock recovery. Simply uninstalling/flash magisk will probably not be enough - it will likely d/l but error part way through update. If you are sitting on rafikowy's stock oreo, and haven't modified it, you should be fine. I know Apr and June are out there. I flashed his stock 8.0 and took June fine. Z2 should be no different though of course I can't guarantee it
If you have success, let us know what you have done so others looking in will know. Thanks!

KrisM22 said:
Thanks for feedback and great on success.
IMEI will show zero if using oreo, It will show again if using N. Remember that if you go from O to N you need to use the "Alternative to RSD" as RSD will simply throw an error and stop.
If you have TWRP and/or Magisk you must get rid of them before ota - if twrp present you will soft brick and have to do alternative again - flash a stock recovery. Simply uninstalling/flash magisk will probably not be enough - it will likely d/l but error part way through update. If you are sitting on rafikowy's stock oreo, and haven't modified it, you should be fine. I know Apr and June are out there. I flashed his stock 8.0 and took June fine. Z2 should be no different though of course I can't guarantee it
If you have success, let us know what you have done so others looking in will know. Thanks!
Click to expand...
Click to collapse
I actually flashed to this: ALBUS_C_7.1.1_NPS26.118-24_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip Which is a 7.1.1 variant and it is showing 0 when I check settings and when I dial *#06#. However upon connecting to the computer and running mfastboot getvar imei it returned a value. I only did the steps above which would mean I don't have TWRP or Magisk (when I fastboot and click recovery I get "no command")
****** Additional information *********
XT1710-01 Duel Sim Variant
I started your steps, only being able to access fastboot. The device would throw an error (I don't recall exactly but it ended up showing me them in the bootloader logs) whenever I tried to start it, or go to recovery. #DefinitelyThoughtItWasDead

Necrowr said:
I actually flashed to this: ALBUS_C_7.1.1_NPS26.118-24_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip Which is a 7.1.1 variant and it is showing 0 when I check settings and when I dial *#06#. However upon connecting to the computer and running mfastboot getvar imei it returned a value. I only did the steps above which would mean I don't have TWRP or Magisk (when I fastboot and click recovery I get "no command")
****** Additional information *********
XT1710-01 Duel Sim Variant
I started your steps, only being able to access fastboot. The device would throw an error (I don't recall exactly but it ended up showing me them in the bootloader logs) whenever I tried to start it, or go to recovery. #DefinitelyThoughtItWasDead
Click to expand...
Click to collapse
What rom was on phone when you got it and what have you done to it? Has it ever run 8.x?
original country of phone?
The bat file will always throw a lot of slot errors.
https://mirrors.lolinet.com/firmware/moto/albus/official/RETUS/
or
https://mirrors.lolinet.com/firmware/moto/albus/official/RETAIL/
might have some stock ROMs of interest...

KrisM22 said:
What rom was on phone when you got it and what have you done to it? Has it ever run 8.x?
original country of phone?
The bat file will always throw a lot of slot errors.
might have some stock ROMs of interest...
Click to expand...
Click to collapse
It had 7.1.1 stock. I rooted it, and then flashed Resurrection Remix (which was yes 8.1 I believe) and the upgraded bootloader. I then found out my service wouldn't work with that.. so I attempted to flash back to stock which gave me a flurry of issues.. eventually getting to nothing but fastboot working. Flashed back to working with your guide to 7.1.1
If it helps in in fastboot it tells me BL: C0.CD

Necrowr said:
It had 7.1.1 stock. I rooted it, and then flashed Resurrection Remix (which was yes 8.1 I believe) and the upgraded bootloader. I then found out my service wouldn't work with that.. so I attempted to flash back to stock which gave me a flurry of issues.. eventually getting to nothing but fastboot working. Flashed back to working with your guide to 7.1.1
If it helps in in fastboot it tells me BL: C0.CD
Click to expand...
Click to collapse
Custom ROMs won't usually update the bootloader (even if they are newer) as stock ROMs typically only have the bootloader firmware.
You could look into flashing the stock Oreo albus 8.0 ROM https://forum.xda-developers.com/z2-play/how-to/fastboot-rom-oreo-retail-via-fastboot-t3786153 or the 8.0 June 2018 firmware https://forum.xda-developers.com/z2-play/how-to/fastboot-rom-albusretail8-0-0opss27-76-t3822195 but please check that firmware has been released for your device variant.
I don't know if updating your baseband to stock Oreo formally may fix your IMEI issue.

Necrowr said:
It had 7.1.1 stock. I rooted it, and then flashed Resurrection Remix (which was yes 8.1 I believe) and the upgraded bootloader. I then found out my service wouldn't work with that.. so I attempted to flash back to stock which gave me a flurry of issues.. eventually getting to nothing but fastboot working. Flashed back to working with your guide to 7.1.1
If it helps in in fastboot it tells me BL: C0.CD
Click to expand...
Click to collapse
"BL: C0.CD" even right after flashing that albus 7.1.1 using "alternative" above?
What happens if you flash one of the oreo roms from the links I gave you above?
Yeah, RR wouldn't change bootloaders... so you upgraded bootloaders independendently?- that could easily lead to a soft brick... -
I read RR on Z2 and it says nothing about bootloaders even though it says 8.1 based, so i wonder if it needs 7.x bootloaders? I did not read entire thread...
In a reverse, I would wonder if you put an 8 on there if you wouldn't see your IMEI. (On the Z if you flash 8 You won't see the IMEI until you return to 7.)(wondering if z2 is reversed)

KrisM22 said:
"BL: C0.CD" even right after flashing that albus 7.1.1 using "alternative" above?
What happens if you flash one of the oreo roms from the links I gave you above?
Yeah, RR wouldn't change bootloaders... so you upgraded bootloaders independendently?- that could easily lead to a soft brick... -
I read RR on Z2 and it says nothing about bootloaders even though it says 8.1 based, so i wonder if it needs 7.x bootloaders? I did not read entire thread...
In a reverse, I would wonder if you put an 8 on there if you wouldn't see your IMEI. (On the Z if you flash 8 You won't see the IMEI until you return to 7.)(wondering if z2 is reversed)
Click to expand...
Click to collapse
Yes, right after flashing that is the BL that fastboot is showing me. I don't recall updating the bootloader so to speak, however RR did require an updated variant of twrp which I flashed 3.2.2 I believe to get (unsure if that would have changed the bootloader or not). I also tried flashing a stock Oreo (which you've stated stock Roms usually only have the bootloaders so maybe somewhere during this process I updated it?). I wish I had all the notes for what I did to give more precise information, but I'm in a position where I really need my phone so I kinda just panicked and started flashing things when my service wouldn't work.
I'm highly considering trying to run an OTA (though very afraid of bricking). - On a side note though, it wouldn't even tell me I had OTA's until I did the steps in the original post here (doing the different 7.1.1. and 8.0 flashes, it wouldn't ever tell me I had updates, and now it does).
*** Edit ***
Looks like I'm able to enter stock recovery, which makes me believe everything is stock at the moment.

Necrowr said:
Yes, right after flashing that is the BL that fastboot is showing me. I don't recall updating the bootloader so to speak, however RR did require an updated variant of twrp which I flashed 3.2.2 I believe to get (unsure if that would have changed the bootloader or not). I also tried flashing a stock Oreo (which you've stated stock Roms usually only have the bootloaders so maybe somewhere during this process I updated it?). I wish I had all the notes for what I did to give more precise information, but I'm in a position where I really need my phone so I kinda just panicked and started flashing things when my service wouldn't work.
I'm highly considering trying to run an OTA (though very afraid of bricking). - On a side note though, it wouldn't even tell me I had OTA's until I did the steps in the original post here (doing the different 7.1.1. and 8.0 flashes, it wouldn't ever tell me I had updates, and now it does).
*** Edit ***
Looks like I'm able to enter stock recovery, which makes me believe everything is stock at the moment.
Click to expand...
Click to collapse
If you flashed a stock O that would have changed bl to O, but doing the above with the stock 7.1.1 would have changed them back to N. No matter (other than academic) that you don't remember the path - flashing a stock anything reverts it to that point in time. However, IMEI may have been moved - don't know. It will likely show on EITHER 7.x or 8.x stock - just don't know which.
If you flash a stock 8.x from those links I gave you above, it should offer you ota, ASSUMING there are any at this point in time(Z has 2). Adding Magisk at any point seems to hose you for receiving any more ota's - don't understand why, even with magisk uninstall, so that would mean going back to the latest stock and losing what you have (which is why I try to take a TBPro and copy that backup to PC (because re-flashing 8.x stock will likely reset internal storage.).
yes, if you enter stock recovery, you are likely at stock, though you could reflash the latest 7 or 8 stock to be sure, depending on which you want to use as base. Since 8 is having security fixes released, I choose 8 and will likely have no more interest (no time!) in 7.

So, ran the OTA and it was fine running the update and staying on N. I also downloaded the OTA for Oreo, when trying to update the recovery error'd out. It looked like the error said "Error in modem unexpected results" or something similar.

Necrowr said:
So, ran the OTA and it was fine running the update and staying on N. I also downloaded the OTA for Oreo, when trying to update the recovery error'd out. It looked like the error said "Error in modem unexpected results" or something similar.
Click to expand...
Click to collapse
did it offer to let you d/l it again? you could try that.
However, there exist O stock zips in those links I gave you so you could just flash the latest...

[Q] XT1768 getting September Security Update

Hello all,
Been a LONG while since I've actively played around with rooting and unlocking an android device. I finally "upgraded" from my very aged Galaxy S4 to the Moto E4 XT1768. I have successfully unlocked the bootloader, got TWRP installed, rooted with Magisk, and gotten Xposed installed with my favorite modules.
This morning, I got a prompt that a new security update is available, and like a noob, I tried to take the update. This resulted in me getting stuck in a loop where the phone only wanted to boot into TWRP. I got that fixed thanks to XDA, got the pending and failing update completely cleared and am booted back into the device normally, and have frozen the moto update service.... but now...
Is there a way without completely flashing back to stock rom? I know how to take titanium or nand/twrp backups, but I feel like this would still be hours of work to go back to stock, flash, re-root restore all apps blah blah. what are the chances of there being a dirty-flashable zip put out at this point?

The way I normally do these type of upgrades is to download the firmware (from here), use fastboot commands to wipe (erase) and flash the needed partitions (everything but data and recovery), boot to TWRP - flash the no-verity-opt-encrypt.zip & root, and then reboot to system - done. It's easy enough for me, but I know some prefer to being able to use a flashable zip in TWRP.
Also, I have to ask - did you get your e4 cheap? It's was replaced by the e5, some other phones seem to be getting replaced like the G6 series (it's gone on clearance at some places), so they can be had cheap.

bast525 said:
Hello all,
Been a LONG while since I've actively played around with rooting and unlocking an android device. I finally "upgraded" from my very aged Galaxy S4 to the Moto E4 XT1768. I have successfully unlocked the bootloader, got TWRP installed, rooted with Magisk, and gotten Xposed installed with my favorite modules.
This morning, I got a prompt that a new security update is available, and like a noob, I tried to take the update. This resulted in me getting stuck in a loop where the phone only wanted to boot into TWRP. I got that fixed thanks to XDA, got the pending and failing update completely cleared and am booted back into the device normally, and have frozen the moto update service.... but now...
Is there a way without completely flashing back to stock rom? I know how to take titanium or nand/twrp backups, but I feel like this would still be hours of work to go back to stock, flash, re-root restore all apps blah blah. what are the chances of there being a dirty-flashable zip put out at this point?
Click to expand...
Click to collapse
Flashing back to stock and taking the updates is really the best way. Unless you can find a complete firmware package of the new update which of course takes back to stock as well. Really the only way to do it. @MotoJunkie01 makes some TWRP flashable stock roms. And he also creates the partition updater which updates your oem partition and other important things that can't be done in the Twrp flashable stock ROM.

madbat99 said:
Flashing back to stock and taking me updates is really the best way. Unless you can find a complete firmware package of the new update which of course takes back to stock as well. Really the only way to do it. @MotoJunkie01 makes some TWRP flashable stock roms. And he also creates the partition updater which updates your oem partition and other important things that can't be done in the Twrp flashable stock ROM.
Click to expand...
Click to collapse
Speaking of that, @ALI12 just posted a stock firmware package for the NCQS26.69-64-10 build. He gave me approval to use it to update my firmware thread to the latest build, so I'll be updating that OP shortly.

MotoJunkie01 said:
Speaking of that, @ALI12 just posted a stock firmware package for the NCQS26.69-64-10 build. He gave me approval to use it to update my firmware thread to the latest build, so I'll be updating that OP shortly.
Click to expand...
Click to collapse
This will be for the XT1766, correct? Or will same build work for XT1768 (me thinks not)?

So what would the easiest/quickest way be to get updated with all of my apps and data intact? Twrp backup of data partition? Or would there be any way to do this without wiping data at all?

bast525 said:
So what would the easiest/quickest way be to get updated with all of my apps and data intact? Twrp backup of data partition? Or would there be any way to do this without wiping data at all?
Click to expand...
Click to collapse
If you're going to slash a firmware package you'll want to wipe everything. Especially data. Make a backup of your data first of course. After you flash TWR P you can try restoring your data and see if everything comes back. but everything in your downloads folder and all of that will be gone once you format data to remove encryption again.