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.

[Q] Read the Sticky, still can't flash stock or lollipop kernels

I wonder whether there is help for someone who thought he knew how to flash a kernel but apparently is deluded. I have the original nexus seven Wi-Fi tablet android version 4.3 build number JWR66V. The system still wants to update me to 4.3 because I ripped some files out of the cache directory to prevent OTA updates. I have both fastboot and adb. I have read the stickies about flashing.
The phone is rooted and the bootloader is unlocked. I use TWRP custom recovery, and it's a good thing, because I solidly bricked myself up just trying to get my lollipop. I know there are tools to root a nexus seven even with stock lollipop, so I thought I'd upgrade my phone to stock lollipop and then use one of those methods. I tried both the stock lollipop kernel and the one provided by chain fire, which I understand is rooted already. (I'm assuming upgrading to lollipop will lose me my root, unless I want to recover back to 4.3.)
I tried to do these things a couple of different ways. When I tried fast boot, I got the message "error: neither -p product specified nor ANDROID_PRODUCT_OUT set". There was a YouTube video suggesting how to deal with this error message. I'm pretty sure I followed the instructions but no go. (I was using the "flash all" command.) This was after I had put the file containing lollipop in the directory, both zipped and unzipped (so that I had an .img file instead of a zip file). I tried using both the zip file with all of the lollipop partitions and the system image file individually. No go. I also had a message that android-info.txt could not be found, even though it was in the same, working directory.
I could be wrong but I don't think you can install a complete updated kernel from a file on the device. I think that works only with update.zip.
I'm still thinking fastboot is my best bet, but there are dependencies apparently and I don't know what files to include in its directory. Then, am I wise to go to stock and then root, or should I simply flash the stock kernel already rooted? I assume that's what chainfire is providing, correct?
I notice the lollipop official ROM nor Chainfire’s supposedly-rooted image have any file named nakasi. I have only .img files, no .zip files.
I found a dozen sets of instructions on how to flash a kernel but something I need is missing from all of them. Does anyone know what it is or can anyone offer some helpful advice?
Thank you,
Leon M.

had to give back note 7 so im resurrecting my note 3 thats still on mje/4.3

I was wondering if someone could give me a direct answer because i cant seem to find one sifting through the forums.
I originally rooted with root master back when i got the phone. it is still on mje/4.3 stock build. things look a little more complicated then i remember, since my phone hasn't seen an update in over 3 years. I originally froze the verizon ota updates with tibackup, along with all the other bloatware.
My main questions are:
1. I would like to get a 6.0 Rom that looks like the note 7 did, can i do it all with odin and just flash a bunch of files?
2. Do I need a custom recovery like twrp or cwm?
3. I've read about an activation lock but can't find it in my menus, did it not exist yet on 4.3?
If anyone can point me in the right direction I would appreciate it, I really dont wanna brick my phone.

I'm still on MJE firmware, but using an older CM13 (temasek) ROM. So it's marshmallow but no Touchwiz or other Samsung add-ons.
Here are the MJE-specific issues:
1) You can't boot N* or O* stock kernels because of differences in the way that DTB (device tree blobs) are packed into the boot image. I've played with re-packing the boot images, but the kernels seem to run off into the weeds after a few tens of seconds.
2) TowelRoot works on MI9 through NC2(leak) but I think not thereafter - if you wanted to avoid a bootloader firmware upgrade but re-flash via Odin the MJE firmware for "starting from scratch" purposes, you have a means to re-root that does not require a PC.
3) If you retain the MJE bootloader, use the TWRP (hltevzw) -4.3 recovery; the -4.4 recovery will not boot, presumably due to issues similar to (1) above.
4) Not specific to MJE - but important - is the fact that if you want to boot either a custom kernel or custom recovery, you need to unlock your bootloader first. You can unlock your bootloader from any rooted ROM, but be aware that flashing stock firmware with Odin thereafter will re-lock the bootloader.
If you were to "start from scratch" but upgrade to more recent stock software before rooting, be aware that there is no publicly available root for NC4 or NK1; you would need to install stock OB6 or OF1, and follow that by using those "yemen" rooting tools. (Are they safe to use? I don't know frankly)
I am assuming that the N* and O* series bootloaders are backwards compatible with regard to device tree booting issues (see #1 above), because the temasek CM13 roms (having a custom kernel) boot on both OF1- and (my) MJE- bootloader phone. I guess that means it uses a "4.3" DTB packing in the boot image.
You are probably going to want to use TiBu to make important backups, and also copy everything off the phone that is important to you. You should assume that if anything goes wrong, an Odin re-install and factory reset are in the device's future.
Having said all this, I'm not sure there is such a thing as a ROM which "looks like Note7" - this is an old phone with almost no ROM developers left. There might have been more, but the bootloader unlock was achieved 2+ years after the phone's release, and most of the active developers moved on to new phones before that happened.
good luck

Second time trying to root phone and I want to make sure I've got this 100%

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!

Bootloader updates for Android 6+ on an S5 Dev Edition: needed, or not?

Hi there,
I have a rooted Verizon S5 Developer Edition (CID 15, if it matters) running Android 4.4.4 (NK2, bootloader NCG). I am trying to get this phone up-to-date, with root, on at least the newest VZW stock Android release for now, and probably LineageOS in the future.
I’ve been spending hours searching through the forums trying to understand what is the deal with the bootloader requirements for these newer Android versions, and I’m stumped. In this QL1 thread it’s said that the bootloader doesn’t ever need to be changed to install a newer OS version, and LineageOS doesn’t mention anything about needing to do bootloader updates in its installation instructions. However, the ROMs from jrkruse with full installation instructions, like their QA1 ROM, clearly state that the bootloader “MUST BE ON PD1+”.
Can someone please clarify this apparent contradiction for me, so I know the correct way to proceed? I’ve tried reading through the hundreds of pages of comments on those threads as well as the bootloader unlocking thread, and there’s so much noise that I’ve been unable to find the answer, if it already exists.
Also, I know this is kind of an academic point, but if it’s true that the bootloader does need updating, is there a way to get an updated bootloader without changing the phone’s CID, since it is already an unlocked Dev Edition phone? (Search results are absolutely overwhelmed with people talking about “make your S5 a Dev Edition S5” so I have been unable to find any information about the actual Dev Edition phones.) The SamsungCID code seems to append a hard-coded blob of data onto the end of any bootloader; is this really all that needs to be done? The extra data at the end of my original NCG bootloader is 668 bytes, not 256 bytes, so it’s not obvious to me if it really is enough to just copy it straight over.
Thank you!

1CDT said:
Hi there, I have a rooted Verizon S5 Developer Edition (CID 15, if it matters) running Android 4.4.4 (NK2, bootloader NCG)..........
Click to expand...
Click to collapse
Since you've got a G900V device, with a CID15, you are able to unlock the bootloader. The following threads OP provides the instructions for unlocking the bootloader.
https://forum.xda-developers.com/showthread.php?t=3561529
From there you will be able to install TWRP Recovery and thus install a Custom Firmware like LineageOS.
Regarding the updates, the G900V is the only GS5 variant that doesn't require the Bootloader to be updated. Regarding the Firmware Baseband Modem Updates, the following thread provides them all that you can flash via Odin.
https://forum.xda-developers.com/showthread.php?t=3926673
Good Luck!
~~~~~~~~~~~~~~~
Unless asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX2 Forum App on my Sanyo Juno device.

Hi Ibuprophen,
Thank you for your help!
Ibuprophen said:
Since you've got a G900V device, with a CID15, you are able to unlock the bootloader. The following threads OP provides the instructions for unlocking the bootloader. […]
Click to expand...
Click to collapse
The phone already has a TWRP recovery installed, and is a Dev Edition phone so the bootloader is factory unlocked. As such, my understanding is that those unlocking instructions don’t apply unless I need a newer bootloader. Is this correct?
Ibuprophen said:
Regarding the updates, the G900V is the only GS5 variant that doesn't require the Bootloader to be updated. […]
Click to expand...
Click to collapse
It’s interesting to hear that the G900V is the only variant which doesn’t require the bootloader to be updated along with the system and baseband software, since the other threads I linked with the bootloader requirement are also G900V-specific. Do you know it’s not the case because you’ve personally used an Android 6+ ROM with a pre-PD1 bootloader? I know I could just flash the new ROM to Try It And See, but I’m hoping to avoid wasting time and energy on something that other experienced people know won’t work.
Thanks again!

1CDT said:
Hi Ibuprophen, Thank you for your help! The phone already has a TWRP recovery installed, and is a Dev Edition phone so the bootloader is factory unlocked..........
Click to expand...
Click to collapse
I only stated that the Bootloader doesn't have to be updated for the G900V device.
The Baseband Modem Firmware does require updates (as their released).
Though, it's not harmful to this device to flash the Bootloader, it won't do anything different and you'll actually end up locking the bootloader again and have to go through the process of unlocking it.
The Verizon variant just passes on the same Bootloader image from one Firmware to the next one. This is just a Verizon thing and they don't make sense for allot of what they do.
If you want to update the Bootloader, that's, of course, up to you...
~~~~~~~~~~~~~~~
Unless asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX2 Forum App on my Sanyo Juno device.

So I will keep working on this, but I can’t currently verify that the bootloader doesn’t need to be updated on SM-G900V, based on the work I did today. So far I can only verify that LineageOS will boot and work with an NCG bootloader, except for some bug where it destroys data in the EFS partition which I suppose is not actually bootloader-related
First, after backing everything up in TWRP, I started with the baseband modem and firmware updates to QL1. The steps for this were:
1. Boot into download mode (vol dn + home + power)
2. Run heimdall flash --RECOVERY recovery.img --BOOT boot.img --no-reboot using the files from the stock QL1 image (any of them will do)
3. Hold power button to turn off phone
4. Pull battery
5. Boot into download mode
6. Verify that “Current Binary” is ”Samsung Official”
7. Run heimdall flash --MODEM modem.bin --APNHLOS NON-HLOS.bin --RPM rpm.mbn --SBL1 sbl1.mbn --DBI sdi.mbn --TZ tz.mbn using the files from the stock QL1 image (or from the baseband firmware thread, they are the same)
8. Hold power button to turn off phone
9. Pull battery
10. Boot phone back into download mode
11. Run heimdall flash --RECOVERY twrp.img to reinstall TWRP
12. Hold power button to turn off phone
13. Boot into recovery (vol up + home + power) to verify the flash and to ensure it doesn’t get erased
14. Reboot to system
This caused every application to crash on boot in the already-installed NK2 system ROM. I don’t know if I did something wrong, or if they are just incompatible; I did wipe cache and dalvik cache from TWRP, but that didn’t make things work. (I had the same problem when I had to roll back everything later; more on that in a bit.)
Since everything suddenly was broken, I assumed that the baseband update must have been successful (I later verified in LineageOS that it was indeed successful), so I followed the LineageOS instructions to sideload LineageOS and Open GApps from TWRP. This was successful and the OS installed and booted to the setup wizard.
The first problem I encountered at this point was that the mobile network wasn’t connecting during the setup wizard. I skipped this step of the wizard and continued on to configuring the OS settings. Eventually the mobile network connected while I was doing that.
When I started installing apps, I noticed that it took a very long time to receive SMS from the network. Upon investigation I discovered that LineageOS was using legacy CDMA for voice and SMS. I did research and discovered that LineageOS does not, and apparently never will, support VoLTE on klte. Since this is a non-starter for me (Verizon will be LTE-only by the end of next year, so I have no idea how LineageOS klte will exist at that point) I opted to wipe and load stock QL1.
While preparing to load stock QL1, I restarted the phone accidentally, and noticed that I’d permanently lost mobile network connectivity. I tried restoring my EFS backup from TWRP; this didn’t seem to fix the problem. I was going to install stock QL1 system anyway due to the VoLTE problem so I didn’t think about it any more.
At this point I followed these steps to flash stock QL1:
1. Boot to download mode
2. Run heimdall --BOOT boot.img --SYSTEM system.img --no-reboot using files from the stock QL1 image
3. Turn off phone
4. Reboot to recovery
5. Wipe data, cache, dalvik cache
6. Reboot to system
After 15 minutes at the Verizon logo while the dalvik cache was built, the setup wizard started and mobile network connection was working and I was able to complete initial setup for stock QL1. However, the system was not OK:
1. Wifi would not enable
2. The back and menu buttons did not work
3. When the phone locked, after a while, the notification LED turned red and the phone wouldn’t respond to any button presses (I had to pull the battery; this happened multiple times)
At this point I needed a working phone, so I found an NK2 stock image (this was difficult because all the links on xda-developers are dead and sammobile wants money for these old versions, so someone might want to reupload these!) and ran these steps to roll back:
1. The same steps above for installing the baseband modem and firmware, except using NK2 images and firmware
2. Boot to recovery
3. Wipe data, cache, dalvik cache
4. Restore NK2 TWRP backups of System, Boot, Data, EFS
5. Reboot to system
Instead of being fully restored, every app was crashing on boot again, like when I had updated the QL1 firmware and rebooted into the old NK2 system. I was finally able to get my full backup restored successfully by following these extra steps:
1. Boot to TWRP
2. Wipe Data
3. Reboot to system, until the setup wizard starts
4. Turn off the phone without running the wizard
5. Boot to TWRP
6. Restore Data
7. Reboot to system, everything is OK now
The hard buttons and wifi problem are noted by @jrkruse on the unlocking the bootloader thread. I had to get my phone back in a working state for tomorrow so I didn’t try the instructions to reflash the PD1 boot+recovery+firmware. I’m not actually sure if it’s correct today to reflash PD1 firmware instead of QL1 firmware; clarity here would be helpful. If anyone also sees a clear mistake in the steps I outlined above, I would be grateful to know that.
If I can’t get stock QL1 to not be broken, and it’s due to the bootloader requirement, then I guess I am stuck unless I start messing with the bootloader (given the “We still are unsure if changing the CID causes app store, verification, activation, provision, or other issues, everything you do is at your own risk!” warning, this means me trying to transplant my dev signature onto the EMMC 15 bootloaders even though my signature is a different size). I’m pretty terrified of doing that since there’s conflicting information about whether it’s possible to flash an old bootloader once you’ve upgraded past certain versions, and I haven’t learned yet how bricked the phone becomes if a bad bootloader is flashed. I know it’s not possible to flash old bootloaders on a retail device; is that true on Dev Edition devices too?
Thanks again for your help! I wish I had more positive news.

1CDT said:
Hi there,
I have a rooted Verizon S5 Developer Edition (CID 15, if it matters) running Android 4.4.4 (NK2, bootloader NCG). I am trying to get this phone up-to-date, with root, on at least the newest VZW stock Android release for now, and probably LineageOS in the future.
I’ve been spending hours searching through the forums trying to understand what is the deal with the bootloader requirements for these newer Android versions, and I’m stumped. In this QL1 thread it’s said that the bootloader doesn’t ever need to be changed to install a newer OS version, and LineageOS doesn’t mention anything about needing to do bootloader updates in its installation instructions. However, the ROMs from jrkruse with full installation instructions, like their QA1 ROM, clearly state that the bootloader “MUST BE ON PD1+”.
Can someone please clarify this apparent contradiction for me, so I know the correct way to proceed? I’ve tried reading through the hundreds of pages of comments on those threads as well as the bootloader unlocking thread, and there’s so much noise that I’ve been unable to find the answer, if it already exists.
Also, I know this is kind of an academic point, but if it’s true that the bootloader does need updating, is there a way to get an updated bootloader without changing the phone’s CID, since it is already an unlocked Dev Edition phone? (Search results are absolutely overwhelmed with people talking about “make your S5 a Dev Edition S5” so I have been unable to find any information about the actual Dev Edition phones.) The SamsungCID code seems to append a hard-coded blob of data onto the end of any bootloader; is this really all that needs to be done? The extra data at the end of my original NCG bootloader is 668 bytes, not 256 bytes, so it’s not obvious to me if it really is enough to just copy it straight over.
Thank you!
Click to expand...
Click to collapse
Hi, I'm the guy who did the bootloader unlock. It's kind of a complicated situation, upgrading bootloaders after having an unlocked retail bootloader. The issue is that once you have a dev device (CID + matching RSA signature, the extra 256 bytes), the bootloader write-protects the eMMC where aboot lives. Normally, if we wanted to upgrade the bootloader and maintain our unlocked bootloader, we'd grab the new bootloader, append our dev blob/signature, and just flash to the aboot partition.
The only way to get the newest bootloader is to flash the latest stock ROM (which locks your bootloader), and then unlock it again by rooting and appending the dev blob. I'm not sure if the latest ROMs can be rooted or not since I don't play with my S5 very often. You don't have to change the CID ever again. If you have a real dev device (you purchased it from Samsung as unlocked, not using our exploit), you will want to back up your device signature by just making a copy of the aboot partition. If this is the case for you, you can feel free to send me your aboot partition, and I'll carve out the signature that you need.
It's more so a limitation of the bootloader trying to prevent people from accidentally re-locking the bootloader. When Samsung signs the real dev device bootloaders, the dev blob/sig is apart of the code being signed, which means we can flash that in Odin while retaining your unlocked bootloader. We don't want to use an ancient bootloader, so this isn't useful. You can PM me if you want and I can walk you through the process, but it's pretty complicated so I feel better not posting the whole process and having people possibly brick their devices.
TL;DR
Just send me a PM and I'll walk you through everything. Don't flash or change anything if you have Developer Edition device that you purchased directly from Samsung. We want to preserve your device-unique "key".