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.
Related
Sorry for the newb-ish question. I'm in a mad rush to build my FM app and would prefer not to have to research this issue for hours.
I have my FM app running on Blayo ROM, using btipsd_cli, and I think it should then work on the stock ROMs. AFAICT they also include btipsd_cli.
So I want to test on a stock ROM. Which one should I use ? I'm avoiding the RUU's because I don't want to have to mess with Windows etc.
So I'm looking at: OTA_Legend_Froyo_S_Vodafone_UK_3.14.161.1-2.05.161.1_R_P_release_135177_156984k4i146wit81sj23a.zip
But the embeded firmware.zip includes an HBoot and radio and recovery.
I don't want to lose my S-Off, or my CM recovery.
Can I do this ? What's the easiest/safest way ? Or any other stock ROM I should use ? Perhaps I should test with the oldest ROM and the newest ROM.
Thanks much !
Sure m8. Just extract whichever img you want and flash it via fastboot. I'm not sure about system.img. Some guys reported that flashing system.img doesn't actually work. In that case put it on /sdcard, fire up CWM, format system partition, mount it and then inside adb shell unyaffs the image into /system dir.
EDIT: Ahh one more thing. You can't just install any OTA you want. What OTA does is binary patching of existing files. That said it means you have to have binaries that actually match to their patches but I guess you knew that before
Sent from my HTC Legend
BlaY0 said:
Sure m8. Just extract whichever img you want and flash it via fastboot. I'm not sure about system.img. Some guys reported that flashing system.img doesn't actually work. In that case put it on /sdcard, fire up CWM, format system partition, mount it and then inside adb shell unyaffs the image into /system dir.
EDIT: Ahh one more thing. You can't just install any OTA you want. What OTA does is binary patching of existing files. That said it means you have to have binaries that actually match to their patches but I guess you knew that before
Click to expand...
Click to collapse
Thanks BlaY0 !
No I didn't know about the patching of files. So that's what the *.p files are for... Yuck, that's messy IMO.
I WOULD have known if I spent much time in this area but I haven't. A few months back I finally had my phone in a nice state and haven't looked back. It was VERY painful doing all that, and at least twice I messed up badly and had to restart. So I don't want to repeat that.
I haven't figured out how all the partitions/image files interact, so I won't go down that road at this time. I'm guessing it may not be possible to go back to stock temporarily and then revert to the other ROMs easily.
So for now I think I'll continue to use your ROM as a proxy for a stock ROM and hopefully my app will work as well on stock ROMs. BTW, I'm now running your new 8.4 and it's working very nicely thank you...
Those .p files are standard bsdiff patches. At least they should be, but HTC once again made some internal changing to that so I was unable to manually apply those patches on my PC.
If you are S-OFF which I believe you are, all you have to care about are boot.img and system.img. 1st is image made of kernel + initrd and 2nd is basically yaffs2 image. 1st can be flashed with flash_image and 2nd can be unpacked with unyaffs (after you format system partition and mount it on /system via CWM). All needed tools are available in CWM recovery and they are also part of AOSP and are compiled separately each as its own bin. Flashing can also be done via fastboot, but I'm not sure about HTC's system.img as I'm not S-OFF. You should try that.
Sent from my HTC Legend
Rooting and updating your MotoActv is about to get significantly easier! No more waiting games for developers to update their ROMs or tools when Motorola pushes a new OTA; now you can do it yourself! I honestly have not seen these types of files ANYWHERE else, so I had to create these myself (with quite a bit of help from [mbm]). But enough blabbing, here are the files and how to use them:
(Note: all these methods assume we have full fastboot access! -- Which we still have at this point)
- Stock Images:
These are not just mere update.zips that you might be accustomed to elsewhere in Android. Nor are these mere fxzs that you might be accustomed to elsewhere with newer Motorola devices. They are in fact both and more. There are 3 main ways to flash these files onto your device, giving you options based on what OS you run and how comfortable you are flashing files to your device.
1) FXZ:
- Operating System: Windows
- Requires: RSD Lite with FXZ Support
- Instructions: Simply load up the file as any standard fxz (it is very straight-forward)
2) Recovery:
- Operating System: Anything that can mount your device
- Requires: The ability to get into recovery
- Instructions: Place the file on the sdcard, boot into recovery, flash as normal
- Note: Recovery does not wipe your device, it is suggested that you do so before flashing stock images
3) Fastboot:
- Operating System: Windows/Linux/Mac
- Instructions (Windows): Unpack the zip, run flash-all.bat (if it fails, run as administrator)
- Instructions (Linux/Mac): Unpack the zip, run flash-all.sh (it should already have proper permissions)
Miscellaneous Images:
These miscellaneous images are nothing you haven't seen before at this point, but their purposes are new, so they too require explanation.
1) AnyRoot:
AnyRoot is based on koush's AnyKernel in the sense that it unpacks and repacks the boot.img on the fly. However, as the name suggests, AnyKernel is meant for kernels, while AnyRoot, actually roots the device on the fly. This will work on any MotoActv device. It is flashed as a normal update.zip and everything is done in the background so you won't noticed much. However, for ease of access, the stock and rooted boot.img is exported to your sdcard in /sdcard/recovery/. Also note, that if you happen to flash AnyRoot over an already rooted device, nothing will happen as it has built-in error checking.
2) rebootRecovery:
rebootRecovery is another fxz type zip, the same as the stock and rooted images, except it can't be flashed in recovery (would be a little redundant don't you think?). This flashes a specially made misc.img by [mbm] that tells the device to reboot into recovery from boot. This means you can flash AnyRoot on any stock device.
How Tos / FAQs:
Now that you know what the files do, I can explain in short steps how to use these files to get what you want:
1) How to Return the Device to Stock?
- flash a stock image using any of the 3 methods
- you can now update via Motocast if you so wish
2) How to Root a Stock Device?
- update your device via Motocast to the latest version (suggested)
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
3) How do I update my Rooted Device?
- flash a stock image using any of the 3 methods
- update your device via Motocast to the latest version
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
Q: After using rebootRecovery I can't get out of recovery!?
A: You are using an old recovery that doesn't clear the 'reboot-recovery' command; use the newer recovery: https://dl.dropbox.com/u/5849675/android/f100/CWMR5x_F100_recoveryB2.img
Q: What do these ROM offer over other custom ROMs?
A: Nothing, they are simply stock images, but you can upgrade with them.
Q: How much battery should I have when I flash?
A: Performing any kind of these flashes will drain at least 10% of your battery, I wouldn't suggest you flash below 60% ESPECIALLY IF YOU FLASH rebootRecovery!
Q: What happens if I flash a 16gb zip on my 8gb or visa-versa?
A: Don't freak, it will still boot, but it's not the best thing in the world to do, just go back and flash the correct model zip.
Q: Can I extract the images from your zips and flash them my own way?
A: yep (couldn't really think of anything else to say)
Q: I manually flashed the stock-boot.img from AnyRoot, and now I can't update. Why?!
A: The boot.imgs need to be truncated before they can be flashed to correctly work with Motorola's updates, just use the stock images.
Q: What's next?
A: HyprActv -- What's this?
Stock Images (w/ md5sums):
8gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_NA.zip (5e228bf56a67aced012c8cbb2d7f7c76)
16gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_16GB_NA.zip (21b067dc629f7ccd18b43799d8d5fb17)
8gb-EU: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_EU.zip (5b79a46d87728303fc2c920eec71c2e8)
Miscellaneous Images (w/ md5sums:
AnyRoot: https://dl.dropbox.com/u/5849675/android/f100/MA_AnyRoot.zip (2f867b006da42865ef861094db0eb6e6)
Reboot Recovery: https://dl.dropbox.com/u/5849675/android/f100/MA_RebootRecovery.zip (1623c9c61462db9bb20b55bc8f1144aa)
Mirror (thanks Iownox!): http://www.androtransfer.com/?developer=lownox&folder=MotoACTV
This is Reserved.
I rooted and flashed in recovery (the stock 4.55.97 and the the rooted version 4.55.97) and I stay on 4.55.78 no matter what! The flashes go through successfully... But nothing has changed and the System version still says 4.55.78... But like I said, the flashes both completed! I did a factory reset... and the updater-script wipes system, so what could be my issue?
Moose8106 said:
I rooted and flashed in recovery (the stock 4.55.97 and the the rooted version 4.55.97) and I stay on 4.55.78 no matter what! The flashes go through successfully... But nothing has changed and the System version still says 4.55.78... But like I said, the flashes both completed! I did a factory reset... and the updater-script wipes system, so what could be my issue?
Click to expand...
Click to collapse
It sounds like you flashed that old boot.img. Do you have the battery percentage in the status bar? According to TheEndGame7 that is another surefire way to tell if you are on 4.55.97, if you used any of the root tools, it's possible that they automatically flash the old boot.img.
CEnnis91 said:
It sounds like you flashed that old boot.img. Do you have the battery percentage in the status bar? According to TheEndGame7 that is another surefire way to tell if you are on 4.55.97, if you used any of the root tools, it's possible that they automatically flash the old boot.img.
Click to expand...
Click to collapse
I think I did flash the old boot.img (root tools :O ). I'll try flashing the modified boot img again. Thanks! I had no idea the root tool took me back to the old boot img
Moose8106 said:
I think I did flash the old boot.img (root tools :O ). I'll try flashing the modified boot img again. Thanks! I had no idea the root tool took me back to the old boot img
Click to expand...
Click to collapse
Yes, any and all tools that exist so far will need to be updated.
I wiped data / cache and used recovery (b) to install the rooted-4.55.97 zip and didn't have any luck either. I did not use the root tools to flash. Also wiped dalvik cache after and fastboot -w for fun.
innovatelife said:
I wiped data / cache and used recovery (b) to install the rooted-4.55.97 zip and didn't have any luck either. I did not use the root tools to flash. Also wiped dalvik cache after and fastboot -w for fun.
Click to expand...
Click to collapse
Did you end up doing any restore of some kind after you flashed?
Update
There are "new" instructions that might fix the issue where the rooted 4.55.97 appears to not flash. Simply wipe the boot.img image before you flash. And don't use the root tools until they are updated.
Also, if you have success, please post it. Usually "Thanks, it works" is annoying, but in this case where I don't have the device, I need to make sure this is working on some level.
I formated everything from recovery, now I got stuck with Moto logo with no animation when it starts, how to get out of this?
NA
Is there any mirrors for the download of these roms? the dropbox links are down
NORCALkID said:
Is there any mirrors for the download of these roms? the dropbox links are down
Click to expand...
Click to collapse
They were pulled, they're not working. There has been some form of mis-communication when I did my testing. I am not working on these until I can get the device from utkanos. Check Update 2, in the initial post.
Success
CEnnis91
I was lucky the second time, first time I succeeded to upgrade to rooted 4.55.97 but for some reason I didn't get the battery percentage on the status bar but all other issues are OK and status indicated version number 4.55.97, I repeated flash from recovery but after wiping and remounting all folders, this time for stock 4.55.97
Now I'm on stock 4.55.97 with battery percent on status bar and syncing from my mac.
thanks CEnnis91
NA
I went into recovery>mounts, and didn't see any wipe for boot. I took a shot at system since I had already wiped cache and data. Didn't seem to help either. Tried 'fastboot erase boot" and re-flashed. No go. Couldn't start back up the device at all. Tried flashing the latest rooted image using "fastboot flash boot boot.img". No go.
I messed around trying to get the device to boot back up for a while, but it won't even charge right. Only charges long enough to kick off the Motorola 'M', and that is it. On attempts at loading fastboot, I just keep getting an error saying that the battery is low. I know I can only blame myself for this. No fastboot access and no adb access. All attempts at resetting the device have failed.
Before I attempted all of this, my battery was full. Unfortunately, wouldn't charge anymore even plugged into the wall. Any ideas?
Hopefully nobody else makes my mistake.
Man I can't wait till this is perfect, you guys are fricken awesome. I raped your thanks buttons op lol
MoPhoACTV Initiative
Will be working on this tonight. I just found out how to make the flash script clear cache and dalvik for you, pre-install. That'll probably save some headache, but it works only in edify format. Not sure what the stock recovery uses...
Anyways, I'm home!
ClearD said:
Will be working on this tonight. I just found out how to make the flash script clear cache and dalvik for you, pre-install. That'll probably save some headache, but it works only in edify format. Not sure what the stock recovery uses...
Anyways, I'm home!
Click to expand...
Click to collapse
All recoveries will now use edify, amend is old and depreciated, you will only find that on old devices.
Corrupt Kernel...
innovatelife said:
I went into recovery>mounts, and didn't see any wipe for boot. I took a shot at system since I had already wiped cache and data. Didn't seem to help either. Tried 'fastboot erase boot" and re-flashed. No go. Couldn't start back up the device at all. Tried flashing the latest rooted image using "fastboot flash boot boot.img". No go.
I messed around trying to get the device to boot back up for a while, but it won't even charge right. Only charges long enough to kick off the Motorola 'M', and that is it. On attempts at loading fastboot, I just keep getting an error saying that the battery is low. I know I can only blame myself for this. No fastboot access and no adb access. All attempts at resetting the device have failed.
Before I attempted all of this, my battery was full. Unfortunately, wouldn't charge anymore even plugged into the wall. Any ideas?
Hopefully nobody else makes my mistake.
Click to expand...
Click to collapse
This is a classical case of a corrupt Kernel. Not that the images are corrupt, but somewhere along your update, your boot.img did not install the kernel properly and now you have a broken power manager within kernel.
What I would do is the following:
Hook your watch to the charger and let the M sign show up.
Even if it hangs on the M, leave your watch hooked over night.
Try downloading an older image and use fastboot to erase everything and then flash everything back again. This should return your watch to a working state again.
You may then choose to customize it as you see fit.
Root tool > "return to stock"
Sent from my HTC Inspire 4G using XDA-funded carrier pigeons
simx said:
CEnnis91
I was lucky the second time, first time I succeeded to upgrade to rooted 4.55.97 but for some reason I didn't get the battery percentage on the status bar but all other issues are OK and status indicated version number 4.55.97, I repeated flash from recovery but after wiping and remounting all folders, this time for stock 4.55.97
Now I'm on stock 4.55.97 with battery percent on status bar and syncing from my mac.
thanks CEnnis91
NA
Click to expand...
Click to collapse
I'm about to try this.. but it's making me think... Do you think the updater-script doesn't correctly format system? Think about it... our devices say 4.55.97 (mine changed to that after a reboot or two), and we only had partial features... sounds like something isn't wiping correctly.
I am having problems installing the 4.4.2 update via OTA. I am on rooted 4.4 android KRT16S build.
I have rooted.
I have installed xposed framework.
I have installed twrp recovery.
OTA update stucks on twrp and nothing happens.
I have tried the following things :
1) Uninstalled xposed framework and tried installing 4.4.2
2) flashed the zip instead of OTA, twrp says failed.
3) enabled survival mode in superuser app.
4) I have also tried flashing KRT16S first which installs successfully on twrp and then 4.4.2 which again fails.
My point is starting this thread is to know exactly what to do when an OTA updates comes so that you can successfully update to the latest android version and also retain your data back.
Sent from my Nexus 7 using Tapatalk
OTAs are meant only for 100% stock.
The fact that they can occasionally be installed on a non-stock ROM (or when using a non-stock recovery) is purely happenstance - not evidence that anyone should have an expectation of a similar success on a device with arbitrary modifications.
It really is just that simple.
Which means, no matter what, I'll have to start from scratch again? Install 4.4 images with data wipe and then install 4.4.2 via OTA or flashable zip, followed by all customization and data restore by TB??
Only solution?
Sent from my Nexus 7 using Tapatalk
There is no need for a wipe, you can also install boot.img and system.img by fastboot and root your device again afterwards. In that case you will keep your data.
Sent from my Nexus 7 using xda app-developers app
neo1691 said:
Which means, no matter what, I'll have to start from scratch again? Install 4.4 images with data wipe and then install 4.4.2 via OTA or flashable zip, followed by all customization and data restore by TB??
Only solution?
Click to expand...
Click to collapse
There are possibly 8 or 10 different ways to go about this:
[A] Don't worry about minor OTA updates - recently they don't seem to be very compelling.
Dirty-restore only the system and boot images from a Nandroid backup of the near-factory ROM corresponding to the same base ROM you are using. You DO make nandroid backups before you start modifying things, don't you?
[C] Use a well-supported dev ROM and wait for the dev to update the ROM to the new release base. Then, just dirty-flash the ROM (if the dev says that is OK). (Obviously, dirty-flashing is not a good idea between ROMs that are wildly different in origin.)
[D]* Treat it like you would any other ROM install. Launcher configuration backup, TiBu Backup, Nandroid Backup, (custom recovery) "factory reset", new ROM install, (root kit install if needed), TiBu restore, Launcher configuration restore.
[E] Attempt OTA install, inspect failures in /cache/recovery/recovery.log, hand-revert files back to factory**. Rinse and repeat.
[F] Pick apart the OTA installer and repackage your own version of the OTA zip to remove the parts that cause failure - both the individual checks and the corresponding file patch operations.
[G] Find a "flashable stock" ROM that matches the same base version as your current ROM and dirty-flash it. Obviously this nukes any of your customizations. Also note that if that the dev did something like "zipalign" or odexing/deodexing of the stock ROM, it is unlikely that the OTA will succeed - even though the ROM is close to identical in function to the factory ROM, the files have been diddled and so the OTA will fail.
[H] If you think the near-stock mods you have made are "minor", you could attempt a "dirty flash" of just the "system.img" and "boot.img" files from the factory images. This would mean avoiding the use of "fastboot erase" of anything and attempting a "fastboot -w update my-custom-image-nakasi-XXXX.zip" where your custom .zip file only has the boot.img and system.img files in it (remove recovery.img, userdata.img from the .zip archive and also check the "android-info.txt" file to see that it is consistent). I have not personally tried this; if you are going to try it, I would back up your entire device as a safety precaution.
* The Google factory image install instructions show a complete wipe of the userdata partition; this is fundamentally different than most ROM installs (potentially requiring hours of waiting on backup/restores of the "sdcard" area).
** Obviously, you need a source of factory original files. Yet another reason to make nandroid backups before beginning ANY customizations. You can dig them out of nandroid backups - for instance, TWRP ".win" files are just tarballs. Or get familiar with simg2img (or here), loopback mounts, and so forth. You can find older versions of Google factory images on oldblue910's site http://www.randomphantasmagoria.com/
OTA Installation Notes:
[size=+1]1 - OTA installation is a PATCHING process.[/size]
[size=+1]2 - OTA preliminary checks are STOP-ON-FIRST-FAIL.[/size]
[size=+1]3 - OTA installs are ALL OR NOTHING.[/size]
1) The patching process for any individual file that will be updated is like this:
[prior factory file] + [OTA patch file] ===>>> [replacement file]
From the above diagram, it is apparent that "replacement file" needs both the original (factory) file plus the OTA-delivered patching file. The patching process cannot succeed unless an exact version of the original file - down to the very last byte - is present on on the device and in it's original location. The reason things are done this way is that the patch (.p) files are typically much smaller than the originals - so it saves the carriers bandwidth to roll out updates this way to lots of customers. The OTAs do not contain replacement files! They only contain patching (.p) files! Even "blob" files such as boot images are updated this way (so, generally, having a custom kernel will also cause an OTA fail).
2 & 3) The OTAs are quite conservative in their checking; they don't do something like this:
check file1... patch file1... check file2... patch file2... ...
but rather do this:
check file1... check file2... ... check fileN... patch file1... patch file2... ... patch fileN
If any of the checks fail, the process stops immediately without running any further checks This is a good thing - if it didn't happen this way, the OTA could get partially through and then fail - and then it would be impossible to repeat the OTA because all the successfully patched files would no longer be the original versions; and you would have a ROM in a screwed up (inconsistent) state.
So, in light of those above observations, it is apparent that:
- usually it is safe to attempt an OTA install on a modified ROM. If any file (to be modified) is missing or altered, a preliminary file check (SHA-1 hash computation) will fail and nothing will be modified. It is a good thing that the OTA install process is conservative this way.
- this explains why sometimes OTAs succeed on lightly modified stock ROMs: it just happens that whatever files the device owner/user fooled with are not in the group of files to be patched by the OTA. But that's no guarantee for the next OTA that comes down the pike, nor the one after that....
- if there are several file checks that are going to fail as a result of user modification, when the OTA runs, you will only be shown the error for the first file that fails - instead of a list of all files which are screwed up. That means that if you thought you were going to hand-patch things, you might have to iterate the process (OTA-fail... hand-patch... OTA-fail... hand-patch...) several times. If you were going to go down that road, the amount of effort needed to get things back to an OTA-friendly state might be quite significant. The only alternative to avoiding this is to inspect the "updater-script" that the OTA uses, and manually go through every file mentioned in the OTA and compute the SHA1 hashes yourself (using the program "sha1sum"). At least then you would know ahead of time which files/blobs are going to cause a failure.
- Note that the the SHA-1 checksums require that the files be identical to the factory originals down to the very last bit and byte. If you used a "flashable factory image" where the dev decided to do something like "zipalign" the .apk files, or add or remove .odex files, an OTA isn't going to work correctly. The files don't just need to be identical in function, they need to be identical down to the last bit and byte.
So now you can see why you observe lazy rooters perpetually returning to this forum asking, "can anybody get me a copy of file such-and-such from version XYZ of the stock ROM?". They are trying to hand-revert their existing ROM so that an OTA will succeed. And the fact that they are asking that question means that they failed to make a (nandroid) backup of their near-factory ROM. If they had done that, they would have the file(s) in question, and -morover- they would also have the option of running a TiBu backup & nandroid backup, restoring the original (factory/near-factory) ROM, taking the OTA, repairing root, and restoring TiBu backups... and then re-applying their customizations. But failing to take a nandroid backup means that they have NEITHER
Well, hand-reverting a ROM so an OTA will succeed may not be "starting from scratch", but it could be quite a bit of effort, yes? You have to undo things by hand to get back to "close enough" to factory state so that you can get the OTA to work. And usually the OTA stomps on permissions of /system/{x}bin/su so that re-rooting is necessary (or else you involve yourself with some dumb "root saver app" ahead of time). And then re-apply the customizations that intersected the OTA causing its' failure(s). All of that takes time. Less time than biting the bullet and just making backups? Hard to say. But one approach paints you into a corner, and the other provides maximum repair/restore flexibility.
I get it that backups take time, and performing TiBu backup/restores takes time too. And if you don't use a launcher that allows configuration saves/restores, even more time wasted there re-configuring things to "the way they were". But really, there's no excuse for not making Nandroid backups - and copying them off the tablet for safe keeping. You can always delete them later if you don't use them.
whew. i'm done.
bftb0 said:
There are possibly 8 or 10 different ways to go about this:
Dirty-restore only the system and boot images from a Nandroid backup of the near-factory ROM corresponding to the same base ROM you are using. You DO make nandroid backups before you start modifying things, don't you?
[/0QUOTE]
Thanks for the awesome reply. I appreciate the time you spent in giving me such a concise and precise reply to my question.
So I have the nandroid backup ->
1) I will flash 4.4, with full wipe and update to 4.4.2
2) Flash twrp and root.
3) Restore my data from my old nandroid backup.
Click to expand...
Click to collapse
neo1691 said:
So I have the nandroid backup ->
1) I will flash 4.4, with full wipe and update to 4.4.2
2) Flash twrp and root.
3) Restore my data from my old nandroid backup.
Click to expand...
Click to collapse
Hmmm. By that do you mean a nandroid restore of /data only on top of a fresh (full wipe) install and OTA update? That's a bit unusual - if any changes occurred in the total count or naming of pre-installed system .apks, that could lead to UID mismatch problems. Also, sometimes OTAs do removal/cleanup of things in /data ... you ought to look in the updater-script (OTA .zip file META-INF/com/google/android/updater-script) to see if any of that is going on. That's why both AnDiSa and I suggested methods that leave the data in place during the OTA update.
I guess what I am saying is that what you are proposing *might* succeed but it's a little bit nonstandard. (It prevents the OTA process from cleaning anything up in /data. Admittedly, that's a little unusual, but I think I have observed it in the past.)
Whatever you do, take a full Nandroid of where you are now; if things get screwed up you can always go back to your current setup and try a different approach.
Thanks a lot for all your invaluable inputs. Too much for me to work on now. I'll report what happens.
Sent from my Nexus 7 using Tapatalk
I am ready to do a dirty wipe. But I am not able to find the boot.img and system.img in the zip of KRT16O.
It is the 4.4 base.
It has a folder called patch which contains boot.img.p , but no system.img
There should be Bootloader.IMG and another tgz. If you extract this tgz you will find boot.img, system.img, data.img.
Be careful to not mix up bootloader.img and boot.img.
Sent from my Nexus 7 using xda app-developers app
---------- Post added at 04:59 PM ---------- Previous post was at 04:58 PM ----------
... one question: are you sure you have the Google Factory Image?
Sent from my Nexus 7 using xda app-developers app
You were right, I was looking in the wrong file,
So extracted the real factory image and there was another zip in that which contained the respective files!! Lets see what I can do now!
Solved!!
Okay. I am now on 4.4.2!! Cheers!!
But dirty flashing didn't worked for me!
I flashed the system.img and boot.img from 4.4 base, and then tried flashing 4.4.1. It worked. But flashing 4.4.2 zip failed just like before.
So after that I took a backup of my sd card and did a full flash of 4.4 base. (KRTO) and then updated to 4.4.2>flashed twrp>waited for OTA>installed OTA from twrp. Worked like a charm.
Now the challenge lies in restoring the data back completely. I have a nandroid backup and TiBu. Guess I will be usin TiBu!!
This thread will be an excellent guide for people facing me problem update OTA over rooted stock rom!
Thanks everyone for their help and support!! Cheers
@neo1691
happy holidays indeed!
The nice thing about nandroids is that you can jump back and forth between two ROMs if necessary.
For instance, suppose you forgot to do TiBu in the prior ROM - no problem! Just make a nandroid of the current (new) ROM, restore the prior Nandroid, do the TiBu backup, restore the (new) ROM nandroid, and then perform the TiBu restores. Easy-peasy.
Backups are awesome. Make 'em often - you can always toss them after a while if you aren't going to use them.
Cheers.. Thanks again everyone
Sent from my Nexus 7 using Tapatalk
Alright so I apologize in advance if this thread has been posted a million times and believe me, I've spent the last 4-5 days combing through to make sure I could get every detail of this process done correctly. So I'm not just blindly asking for instructions on how to root my phone. Apologies also if I posted this in the wrong place.
For starters, I'm using Moto G4 Plus XT1641 6.0.1 Build Number MPJ24.139-23.3. My carrier is Koodo in Canada (unsure if that's important but I'll need to being it up again for another point). The files I downloaded were from a youtube tutorial and this includes ADB program, TWRP img 3.0.2.0, supersu zip 2.46 and Motorola Drivers 2.5.4, SOME of which I think may have been outdated versions.
So Saturday night I tried to root my phone with those files. I followed some more guides, I unlocked my bootloader and I think I mostly did everything right except for getting the right supersu version as I've seen up to version 2.82. I think this may have been my first mistake but maybe someone correct me if I'm wrong? My other mistake was not making a backup in TWRP. I'd read about possible wifi problems after rooting so I grabbed the elemental package and possibly even flashed that wrong. I can't even remember the steps of what I did but I'm sure it was all wrong.
Main point, after all that I didn't have ccell service, wifi, etc. The common problems that arise when you do it wrong. I ended up just taking my phone in and getting a new phone. Exact same one, same model. And this brings me to where I am now. I've downloaded some new files and I want to make sure that I've got everything right as to avoid misunderstanding some key parts to the process.
Minimal ADB and Fastboot 1.4.2, twrp-3.1.1-0-athene.img, SuperSU-v2.82-201705271822, Motorola Drivers 2.5.4, and lastly XT1641_ATHENE-TELUS_MPJ24.139-23.3_cid50_subsidy-TELUS_CFC.xml. Notice how that last one says Telus? It's the parent company of Koodo so I'm hoping I can use that as a failsafe.
I think I've covered all the key points so to sum up:
1. Did I use the wrong supersu zip version and could that be a reason why I had no wifi/cell service? Is that also possible because I may have flashed the wrong carrier athene file?
2. Are the files I have downloaded now the correct ones I need and up to date?
3. I'm following this guide. With the files I have downloaded, is it still a correct step by step process? Are there other guides that work better?(thats not a knock on the original guide I'm refering to). https://forum.xda-developers.com/moto-g4-plus/how-to/root-systemless-rooting-supersu-2-74-2-t3405772
I think I've got the right know how and tools to root my phone but I'm just nervous of doing what I did before again and would like some reassurance that I'm doing it right. I've just come from jailbreaks, the world of root is much different. I appreciate any help or tips you guys can throw me!
Hmm, that's odd how you lost radio signal when you rooted, did you obtain radio signal back after you unrooted?
A few things I noted:
1)You may wish to update your device to a newer build, you might get an OTA inviting you to update to MPJ24-139-63 (or 139-64), which was the latest Marshmallow build. Once you've rooted, you will not be able to install OTA updates until you have unrooted and restored the stock recovery (from the same build as you currently have). If you get an OTA notification for any build beginning with NPJ, that's for Nougat.
2)If you plan to stay on Marshmallow, you don't need the ElementalX kernel - a custom kernel like ElementalX is compulsory on Nougat, whereas Marshmallow is not as strict with regards to rooting.
3) I hope the carrier ROM is okay, though from other reports, flashing the incorrect ROM can corrupt device partitions, leaving with no IMEI/no service/no FP. We have possible ways of repairing that though.
The tools you've downloaded seem to be okay and Bender's guide is still okay - even though the tools they've used are out of date - so the general procedure would be (up to you if you've updated MM at this point):
Install adb on your computer.
Boot your device to the bootloader.
Flash TWRP 3.1.1 athene (either the offficial TWRP or an unofficial build from shreps or oadam11) as directed.
Reboot to recovery (to make sure the recovery sticks).
Back up all partitions on your device, make the name descriptive.
Make another backup of the boot partition - this contains your stock kernel, useful for switching root manager.
Once the backups have been made, flash SuperSU v2.82.
Wipe cache/Dalvik
Reboot.
echo92 said:
Hmm, that's odd how you lost radio signal when you rooted, did you obtain radio signal back after you unrooted?
A few things I noted:
1)You may wish to update your device to a newer build, you might get an OTA inviting you to update to MPJ24-139-63 (or 139-64), which was the latest Marshmallow build. Once you've rooted, you will not be able to install OTA updates until you have unrooted and restored the stock recovery (from the same build as you currently have). If you get an OTA notification for any build beginning with NPJ, that's for Nougat.
2)If you plan to stay on Marshmallow, you don't need the ElementalX kernel - a custom kernel like ElementalX is compulsory on Nougat, whereas Marshmallow is not as strict with regards to rooting.
3) I hope the carrier ROM is okay, though from other reports, flashing the incorrect ROM can corrupt device partitions, leaving with no IMEI/no service/no FP. We have possible ways of repairing that though.
The tools you've downloaded seem to be okay and Bender's guide is still okay - even though the tools they've used are out of date - so the general procedure would be (up to you if you've updated MM at this point):
Install adb on your computer.
Boot your device to the bootloader.
Flash TWRP 3.1.1 athene (either the offficial TWRP or an unofficial build from shreps or oadam11) as directed.
Reboot to recovery (to make sure the recovery sticks).
Back up all partitions on your device, make the name descriptive.
Make another backup of the boot partition - this contains your stock kernel, useful for switching root manager.
Once the backups have been made, flash SuperSU v2.82.
Wipe cache/Dalvik
Reboot.
Click to expand...
Click to collapse
Thanks for the reply, it helps me feel a little more confident in what I'm doing. I didn't get my cell service back as I just took my phone into Koodo and they just gave me a new one. A few questions.
Are there some clear guides on how to recover from lost wifi and cell service? I've seen a few but it appears they all have different directions so as a newcomer to Android it does seems a bit confusing to what the right way to do it is. I'm also hoping someone can chime in on the Telus carrier IMG file as that seems to be my backup in case anything goes terribly wrong again. I'd hate to have to bring my phone back again a second time. Also, is it an easy process to make a backup of the kernel in TWRP? I've figured out how to make a backup of the normal partition, just hoping backing up the kernel is just as easy.
I think I'm near ready to take the root plunge in the coming days. It's good to see such a strong community here. Totally different from the jailbreak scene.
lemonlimejones said:
Thanks for the reply, it helps me feel a little more confident in what I'm doing. I didn't get my cell service back as I just took my phone into Koodo and they just gave me a new one. A few questions.
Are there some clear guides on how to recover from lost wifi and cell service? I've seen a few but it appears they all have different directions so as a newcomer to Android it does seems a bit confusing to what the right way to do it is. I'm also hoping someone can chime in on the Telus carrier IMG file as that seems to be my backup in case anything goes terribly wrong again. I'd hate to have to bring my phone back again a second time. Also, is it an easy process to make a backup of the kernel in TWRP? I've figured out how to make a backup of the normal partition, just hoping backing up the kernel is just as easy.
I think I'm near ready to take the root plunge in the coming days. It's good to see such a strong community here. Totally different from the jailbreak scene.
Click to expand...
Click to collapse
Hmm, I'm not aware of any guides specifically dealing with lost Wi-Fi and lost mobile signal. There are a few posts where we've had some success in getting radios back, but it involves either hex editing https://forum.xda-developers.com/showpost.php?p=72340548&postcount=98 or flashing hw, modem or fsg partitions from a working device (in this case, XT1641) The instances I've seen of lost Wi-Fi/mobile signal appear to have occurred during a stock ROM fastboot flash, but hoping someone can chime in as to whether it was just flashing the wrong region firmware or something else.
If you want to back up your kernel in TWRP:
Boot to TWRP
Tap 'Backup' on the main menu
Select only the 'boot' partition - this is the partition that contains your kernel (should be stock and clean if you've not rooted).
Rename the file to remind you it's your kernel.
Swipe to back up.
If you need to revert to this kernel, unroot first (depending on your root manager, you may have to boot and then unroot. I recall SuperSU unroots via the SuperSU app settings), then boot to TWRP.
Tap 'Restore' on the main menu
Navigate to your boot backup
Flash your boot backup
You should now have a clean stock kernel, so if you wish to switch root managers, you should be able to obtain root with your new root manager. We want a clean kernel (no modifications made) since uninstalling the old root may leave traces of root on your existing kernel, and thus may cause issues if you re-root with a different manager.
Good luck in rooting
echo92 said:
Hmm, I'm not aware of any guides specifically dealing with lost Wi-Fi and lost mobile signal. There are a few posts where we've had some success in getting radios back, but it involves either hex editing https://forum.xda-developers.com/showpost.php?p=72340548&postcount=98 or flashing hw, modem or fsg partitions from a working device (in this case, XT1641) The instances I've seen of lost Wi-Fi/mobile signal appear to have occurred during a stock ROM fastboot flash, but hoping someone can chime in as to whether it was just flashing the wrong region firmware or something else.
If you want to back up your kernel in TWRP:
Boot to TWRP
Tap 'Backup' on the main menu
Select only the 'boot' partition - this is the partition that contains your kernel (should be stock and clean if you've not rooted).
Rename the file to remind you it's your kernel.
Swipe to back up.
If you need to revert to this kernel, unroot first (depending on your root manager, you may have to boot and then unroot. I recall SuperSU unroots via the SuperSU app settings), then boot to TWRP.
Tap 'Restore' on the main menu
Navigate to your boot backup
Flash your boot backup
You should now have a clean stock kernel, so if you wish to switch root managers, you should be able to obtain root with your new root manager. We want a clean kernel (no modifications made) since uninstalling the old root may leave traces of root on your existing kernel, and thus may cause issues if you re-root with a different manager.
Good luck in rooting
Click to expand...
Click to collapse
That's perfect thank you so much. Am I right to assume that if I get into a jam then I can just restore/reflash my backups and I'll be back to normal?
To be safe, flash the ElementalX kernel before rooting.
reCoded said:
To be safe, flash the ElementalX kernel before rooting.
Click to expand...
Click to collapse
See this is where I get confused, the guy above you said ElementalX isn't needed on Marshmallow but you say i should use it anyway? I've seen a few differing opinions on what should and shouldn't be done, just not sure which one is the right answer.
lemonlimejones said:
See this is where I get confused, the guy above you said ElementalX isn't needed on Marshmallow but you say i should use it anyway? I've seen a few differing opinions on what should and shouldn't be done, just not sure which one is the right answer.
Click to expand...
Click to collapse
ElementalX v0.07 is not required on Marshmallow (provided you are planning on staying on 6.0.1), you can root the stock ROM kernel. You may wish to flash the ElementalX kernel anyway as this custom kernel gives you more control and tuning options compared to the stock kernel. On stock Nougat, because the anti-rooting kernel security is much stricter and enforced (whereas on Marshmallow I don't think it's enforced), then you need ElementalX or vegito or a custom kernel to bypass the security, by in effect replacing the stock secure kernel with a kernel that doesn't have those restrictions. Without replacing the stock kernel on stock Nougat systems, you can run into a bootloop.
As an MM kernel as mentioned before has weaker security regarding rooting, it's up to you if you choose to root the stock kernel or ElementalX.
I've rooted MM (MPJ24.139-63) in the past with SuperSU (v2.79) and only used TWRP and SuperSU.
In response to your other post, the backups should get you out of a jam, since what you're doing should only affect the partitions you've backed up previously (they in theory shouldn't go anywhere near your modem, bootloader or critical firmware). Bear in mind that the TWRP backup if restored in full will revert your messages and data to that backup. You may wish to use Titanium Backup or other tools to take occasional snapshots of your apps data that you can restore should you have to roll back.
lemonlimejones said:
See this is where I get confused, the guy above you said ElementalX isn't needed on Marshmallow but you say i should use it anyway? I've seen a few differing opinions on what should and shouldn't be done, just not sure which one is the right answer.
Click to expand...
Click to collapse
If you're on Nougat, then you should use ElementalX. If you're on Marshmallow, you don't need it.
echo92 said:
ElementalX v0.07 is not required on Marshmallow (provided you are planning on staying on 6.0.1), you can root the stock ROM kernel. You may wish to flash the ElementalX kernel anyway as this custom kernel gives you more control and tuning options compared to the stock kernel. On stock Nougat, because the anti-rooting kernel security is much stricter and enforced (whereas on Marshmallow I don't think it's enforced), then you need ElementalX or vegito or a custom kernel to bypass the security, by in effect replacing the stock secure kernel with a kernel that doesn't have those restrictions. Without replacing the stock kernel on stock Nougat systems, you can run into a bootloop.
As an MM kernel as mentioned before has weaker security regarding rooting, it's up to you if you choose to root the stock kernel or ElementalX.
I've rooted MM (MPJ24.139-63) in the past with SuperSU (v2.79) and only used TWRP and SuperSU.
In response to your other post, the backups should get you out of a jam, since what you're doing should only affect the partitions you've backed up previously (they in theory shouldn't go anywhere near your modem, bootloader or critical firmware). Bear in mind that the TWRP backup if restored in full will revert your messages and data to that backup. You may wish to use Titanium Backup or other tools to take occasional snapshots of your apps data that you can restore should you have to roll back.
Click to expand...
Click to collapse
Right on, I think I feel comfortable with this now! One more question though, with newer versions of SuperSU is it still necessary to make the command echo systemless=true or was that mostly for older versions? Also if that part is needed, should I run SuperSU from the data folder in TWRP?
lemonlimejones said:
Right on, I think I feel comfortable with this now! One more question though, with newer versions of SuperSU is it still necessary to make the command echo systemless=true or was that mostly for older versions? Also if that part is needed, should I run SuperSU from the data folder in TWRP?
Click to expand...
Click to collapse
The 'echo systemless=true', as I understand it, isn't required on SuperSU 2.79 or newer, so if you're flashing 2.82, you should be able to flash as is without having to run the command too Also makes uninstalling easier!
Hi all, I posted this in the 6P bootloop thread, but didn't get a response. As that is a pretty LONG thread, i'm thinking my question may have gotten lost in the jumble.
Quick run down.
A few months back my 6P started the BLOD. I found the fix listed on these pages, applied it, and have been happily using my phone ever since. Phone is bone stock 7.1.2 other than the TWRP recovery and the modified EX kernel for 4 cores.
Since the fix, my phone FINALLY got the OTA update to go to Android 8.0 and i obviously want to get it done. My concern is HOW to do this without causing more headache.
Can anyone point me in the right direction? Should i use the OTA update or download the factory image from Google?
I've got some knowledge as i used to be into the "rooting" scene back in the day, but haven't for a while, so i feel a little lost.
Thanks for any help.
johnnyphive said:
Hi all, I posted this in the 6P bootloop thread, but didn't get a response. As that is a pretty LONG thread, i'm thinking my question may have gotten lost in the jumble.
Quick run down.
A few months back my 6P started the BLOD. I found the fix listed on these pages, applied it, and have been happily using my phone ever since. Phone is bone stock 7.1.2 other than the TWRP recovery and the modified EX kernel for 4 cores.
Since the fix, my phone FINALLY got the OTA update to go to Android 8.0 and i obviously want to get it done. My concern is HOW to do this without causing more headache.
Can anyone point me in the right direction? Should i use the OTA update or download the factory image from Google?
I've got some knowledge as i used to be into the "rooting" scene back in the day, but haven't for a while, so i feel a little lost.
Thanks for any help.
Click to expand...
Click to collapse
Well, for starters do NOT take the OTA. It will either fail or boot loop your phone. Due to the fact you have a modified boot.img you will need to update manually using fastboot with the full image. Re-apply the modified kernel after you finish updating the partitions, but BEFORE booting the first time. You can follow most guides on how to manually update a full image using fastboot, just add the step of flashing the modified kernel before booting.
Thanks for the reply and the help. If i could ask for a little more help, as this is my only phone.
Can you explain the difference between the modified boot.img and the modified kernel?
If i download the factory image from here (https://developers.google.com/android/images) is it ok to the get the latested one (Nov 2017) or do i need to get the original one (Sep 2017 as i'm on Fi)
Once i flash the factory image, is it going to replace the modified boot image as well as the modified kernel?
Follow the OP on this thread (https://forum.xda-developers.com/nexus-6p/general/guide-fix-nexus-6p-bootloop-death-blod-t3640279) in the downloads section there appear to be 2 files i would need, the "Boot.img from stock 6.17, 8.0 firmware" and "EX kernel version 5.03". Am i understanding that correctly?
Like i said, this is my only phone, and i'm probably just being overly paranoid about bricking it, but any clarification would be greatly appreciated.
johnnyphive said:
Thanks for the reply and the help. If i could ask for a little more help, as this is my only phone.
Can you explain the difference between the modified boot.img and the modified kernel?
If i download the factory image from here (https://developers.google.com/android/images) is it ok to the get the latested one (Nov 2017) or do i need to get the original one (Sep 2017 as i'm on Fi)
Once i flash the factory image, is it going to replace the modified boot image as well as the modified kernel?
Follow the OP on this thread (https://forum.xda-developers.com/nexus-6p/general/guide-fix-nexus-6p-bootloop-death-blod-t3640279) in the downloads section there appear to be 2 files i would need, the "Boot.img from stock 6.17, 8.0 firmware" and "EX kernel version 5.03". Am i understanding that correctly?
Like i said, this is my only phone, and i'm probably just being overly paranoid about bricking it, but any clarification would be greatly appreciated.
Click to expand...
Click to collapse
Use the latest November image. The boot.img contains the kernel and ramdisk, critical files necessary to load the device before the filesystem can be mounted. When you flash the new boot.img contained in the Google image, it will overwrite the patched kernel. You then need to re-patch it by installing EX kernel before booting. EX writes to (modifies) the stock boot.img. There are also pre-modifed boot.img files floating around. You will probably get more detailed help in the dedicated thread. Learning to flash manually (or remember how) is not really a big deal and a necessary skill for modding (and for getting yourself out of trouble). Good luck. :good:
v12xke said:
Use the latest November image. The boot.img contains the kernel and ramdisk, critical files necessary to load the device before the filesystem can be mounted. When you flash the new boot.img contained in the Google image, it will overwrite the patched kernel. You then need to re-patch it by installing EX kernel before booting. EX writes to (modifies) the stock boot.img. There are also pre-modifed boot.img files floating around. You will probably get more detailed help in the dedicated thread. Learning to flash manually (or remember how) is not really a big deal and a necessary skill for modding (and for getting yourself out of trouble). Good luck. :good:
Click to expand...
Click to collapse
Ok, so 1 last time (sorry)
1 - Downloaded the latest 8.0.0 factory image from google (this contains the bootloader, radio, and partitions (.zip).
2 - Get phone to fastboot and apply the above 3 new images
3- before rebooting, flash oreo4core (new, modified boot.img), TWRP recovery.img
4- reboot to recovery (TWRP) and apply the modified EX kernel
5 - reboot and (hopefully) profit
Am i missing anything, or doing anything that isn't needed?
johnnyphive said:
Ok, so 1 last time (sorry)
1 - Downloaded the latest 8.0.0 factory image from google (this contains the bootloader, radio, and partitions (.zip).
2 - Get phone to fastboot and apply the above 3 new images
3- before rebooting, flash oreo4core (new, modified boot.img), TWRP recovery.img
4- reboot to recovery (TWRP) and apply the modified EX kernel
5 - reboot and (hopefully) profit
Am i missing anything, or doing anything that isn't needed?
Click to expand...
Click to collapse
<<Disclaimer: I don't use the 4 core kernel, so I don't know if it comes with installer script or someone has just modified the latest boot.img>> Unzip the "partitions" zip you refer to and extract those image files to the same folder as bootloader and modem. For example, you can keep TWRP recovery if you don't flash the recovery.img. That is how you preserve your custom recovery. So in other words you'll now have a folder (your ADB folder?) with 5 image files.... bootloader, radio, boot, system, and vendor all in one folder. <<Note: it is my understanding you just substitute the latest oreo4core file (should be boot.img?) If this is true, copy that file into your ADB folder and let it overwrite the stock boot.img. Stop. Copy over flash-all.bat, change the *.bat extension to *.txt and open in notepad. You will see (and can copy/paste) the fastboot commands to get you started with bootloader and radio. Then flash the last 3 (boot, system, vendor). At this point you can reboot into the OS. Since you substituted the oreo4core boot.img file for the stock boot.img there is no need to use TWRP to flash anything. That and since you skipped flashing the recovery.img, TWRP is still there.
v12xke said:
<<Disclaimer: I don't use the 4 core kernel, so I don't know if it comes with installer script or someone has just modified the latest boot.img>> Unzip the "partitions" zip you refer to and extract those image files to the same folder as bootloader and modem. For example, you can keep TWRP recovery if you don't flash the recovery.img. That is how you preserve your custom recovery. So in other words you'll now have a folder (your ADB folder?) with 5 image files.... bootloader, radio, boot, system, and vendor all in one folder. <<Note: it is my understanding you just substitute the latest oreo4core file (should be boot.img?) If this is true, copy that file into your ADB folder and let it overwrite the stock boot.img. Stop. Copy over flash-all.bat, change the *.bat extension to *.txt and open in notepad. You will see (and can copy/paste) the fastboot commands to get you started with bootloader and radio. Then flash the last 3 (boot, system, vendor). At this point you can reboot into the OS. Since you substituted the oreo4core boot.img file for the stock boot.img there is no need to use TWRP to flash anything. That and since you skipped flashing the recovery.img, TWRP is still there.
Click to expand...
Click to collapse
Thank for the help! Everything seems to be up and running. I know you said you don't use the "4 cores" (can only assume your either on a different phone or yours isn't affected by the BLOD), but do you know if i still need to apply the EX kernel update, or know of a way to tell if it's already been applied?
Thanks again for all the help. I was pretty much in the right direction, but being as how i'd been away from it for a while, i wanted some backup
johnnyphive said:
Thank for the help! Everything seems to be up and running. I know you said you don't use the "4 cores" (can only assume your either on a different phone or yours isn't affected by the BLOD), but do you know if i still need to apply the EX kernel update, or know of a way to tell if it's already been applied? Thanks again for all the help. I was pretty much in the right direction, but being as how i'd been away from it for a while, i wanted some backup
Click to expand...
Click to collapse
I don't think you can flash EX kernel from now on. I think you have to use a modded boot.img that will contain his kernel/ramdisk. This is my guess. You really should be getting your information in the dedicated thread where everyone is actually installing and using it. Google "oreo 4 core" and you will find the XDA thread is the first hit. Good luck. :good: