Related
Let me start off by saying that I have tried everything I can find. I have tried the ADB sideload method. I have tried to go to the firmware it's trying to upgrade from. I've tried both stock recovery and CWM. I'm not a n00b when it comes to unlocking, rooting, flashing etc. Anyway, here's the story. My dad bought a Nexus 7 32GB and it kept asking him to update to 4.1.1 for the landscape rotation. The first time he tried it, it failed because it was trying to update from a specific firmware that he didn't have. He has JRO03S. It was trying to update from JRO03D to the new 4.1.1 update. It fails every time no matter what. Like I stated earlier, I've tried both stock recovery and CWM, but they both error out. I've included some pictures of the error in CWM and the about device screen, but nothing from stock recovery. I was too lazy to put the stock recovery back on there to take a picture, but if it's necessary for a solution then I will. Yes, I have searched here and google. Every solution that I have found has not worked. If anyone can help me then you would be a lifesaver. Thanks for taking the time to read through all this. If I'm not being specific enough then please let me know what else you need to know.
The assert() failure you see in the custom recovery is to be expected - it is the installer script checking to make sure that someone is attempting to apply the update to an exact version of the factory software. In this case, exact also means the version of the recovery boot in use which is trying to process the update.
In general, you can not use a custom recovery with an unmodified OTA installer file because of that first assert.
The OTA updates are NOT complete re-installs; they use a patching tool to fix up existing files on the device. That allows their size to be quite a bit smaller than a full new install. Read that again - existing files!.
It is my impression (someone correct me if I am wrong) that the installer scripts also do checksums on each individual target files that are intended to be patched, and if a single one of them fails, the install will spontaneously abort - part way through the process.
That has serious consequences, as now a failed partial install will block a subsequent attempt - if any of the target files get successfully patched, they will no longer have the checksum expected by the update script - they will no longer have the (old file) checksum. [ note I might be fuzzy on whether the individual file checks cause a wholesale abort of the installation session, or they cause a per-file abort ]
In general, you can only use an OTA patch kit on a modified phone if you have not altered any of the files involved in the patching process, and you are using the stock recovery. If you want to use a custom recovery, for certain you need to diddle the update .zip file at a minimum to remove that initial assert(), and also verify that you have not removed or fooled with any of the files from the original distro that are involved in the patching process.
Given where you are, I suggest you make backups (possibly including using Titanium Backup), and start over with the phone (flash a stock 4.1.x or 4.2.x installation or a custom ROM). OR, if you happen to have a near bone-stock backup (meaning the only thing you have done is install the Superuser.apk and su binary), you could restore that, restore the stock recovery, and then proceed with the update from there.
good luck
bftb0 said:
The assert() failure you see in the custom recovery is to be expected - it is the installer script checking to make sure that someone is attempting to apply the update to an exact version of the factory software. In this case, exact also means the version of the recovery boot in use which is trying to process the update.
In general, you can not use a custom recovery with an unmodified OTA installer file because of that first assert.
The OTA updates are NOT complete re-installs; they use a patching tool to fix up existing files on the device. That allows their size to be quite a bit smaller than a full new install. Read that again - existing files!.
It is my impression (someone correct me if I am wrong) that the installer scripts also do checksums on each individual target files that are intended to be patched, and if a single one of them fails, the install will spontaneously abort - part way through the process.
That has serious consequences, as now a failed partial install will block a subsequent attempt - if any of the target files get successfully patched, they will no longer have the checksum expected by the update script - they will no longer have the (old file) checksum. [ note I might be fuzzy on whether the individual file checks cause a wholesale abort of the installation session, or they cause a per-file abort ]
In general, you can only use an OTA patch kit on a modified phone if you have not altered any of the files involved in the patching process, and you are using the stock recovery. If you want to use a custom recovery, for certain you need to diddle the update .zip file at a minimum to remove that initial assert(), and also verify that you have not removed or fooled with any of the files from the original distro that are involved in the patching process.
Given where you are, I suggest you make backups (possibly including using Titanium Backup), and start over with the phone (flash a stock 4.1.x or 4.2.x installation or a custom ROM). OR, if you happen to have a near bone-stock backup (meaning the only thing you have done is install the Superuser.apk and su binary), you could restore that, restore the stock recovery, and then proceed with the update from there.
good luck
Click to expand...
Click to collapse
I appreciate your response. I think I may have left some things out. I am not rooted. I have only flashed the custom recovery and unlocked the bootloader. That's it. If I have to start completely over then I will. I have already tried that though. I'm willing to try any solutions that anyone has. Thanks again for your response.
Evo4eva said:
I appreciate your response. I think I may have left some things out. I am not rooted. I have only flashed the custom recovery and unlocked the bootloader. That's it. If I have to start completely over then I will. I have already tried that though. I'm willing to try any solutions that anyone has. Thanks again for your response.
Click to expand...
Click to collapse
OK. I saw the "ClockworkMod Recovery v6.0.1.0" banner and assumed rooting.
Well, let's look at the assert that you show failing (first image)
assert failed: apply_patch_check("EMMC: /dev/block/platform/sdhci-tegra.3/by-name/LNX:5007....)
Click to expand...
Click to collapse
The "LNX" partition is the "boot.img" area of the device - the kernel and ramdisk for your regular OS boot.
The fact that the assert fails means one of two things:
- that your boot partition has been modified from "stock", or
- the update .zip file is intended for some other version of a factory rom.
One of those two things. Would be sort of surprising if the OTA process mis-judged which factory release was currently on the phone. From the first image, it sure looks like the update package is intended for a from/to migration of:
JRO03S -> JZ054K
and your status screen does show JRO03S. Are you sure don't have a slightly modified boot partition?
I'm not sure what the four parameters in the assert statement are - I would think that at least one of them has to be a checksum. As the LNX (boot) partition is just a binary blob there is no filesystem present; perhaps the shorter numbers are byte lengths within the partition.
If you want to download the same OTA and fool with it (for instance to omit that first assert in META-INF/com/google/android/updater-script, re-zip it & try with TWRP), this link seems to be working:
http://android.clients.google.com/p...signed-nakasi-JZO54K-from-JRO03S.d41da8f6.zip
That's the same place the OTA process gets it from (and stuffs it into /cache along with a recovery-command file).
good luck
---------- Post added at 02:22 PM ---------- Previous post was at 02:04 PM ----------
Update -
On a lark I downloaded the OTA (referenced in the URL above) and took a look at
META-INF/com/google/android/updater-script
the assert that you see failing is the very last check before it actually begins the patching process!
That means that all the other checks (things in the /system partition) passed before that last check failed.
That certainly seems to imply a boot image that has been diddled with. Since you still show JRO03S (I'm not sure about the kernel string - I don't know what it is supposed to be), most likely this would have been a flashable zip that modified something only in the ramdisk. Does that sound familiar?
bftb0 said:
OK. I saw the "ClockworkMod Recovery v6.0.1.0" banner and assumed rooting.
Well, let's look at the assert that you show failing (first image)
The "LNX" partition is the "boot.img" area of the device - the kernel and ramdisk for your regular OS boot.
The fact that the assert fails means one of two things:
- that your boot partition has been modified from "stock", or
- the update .zip file is intended for some other version of a factory rom.
One of those two things. Would be sort of surprising if the OTA process mis-judged which factory release was currently on the phone. From the first image, it sure looks like the update package is intended for a from/to migration of:
JRO03S -> JZ054K
and your status screen does show JRO03S. Are you sure don't have a slightly modified boot partition?
I'm not sure what the four parameters in the assert statement are - I would think that at least one of them has to be a checksum. As the LNX (boot) partition is just a binary blob there is no filesystem present; perhaps the shorter numbers are byte lengths within the partition.
If you want to download the same OTA and fool with it (for instance to omit that first assert in META-INF/com/google/android/updater-script, re-zip it & try with TWRP), this link seems to be working:
http://android.clients.google.com/p...signed-nakasi-JZO54K-from-JRO03S.d41da8f6.zip
That's the same place the OTA process gets it from (and stuffs it into /cache along with a recovery-command file).
good luck
---------- Post added at 02:22 PM ---------- Previous post was at 02:04 PM ----------
Update -
On a lark I downloaded the OTA (referenced in the URL above) and took a look at
META-INF/com/google/android/updater-script
the assert that you see failing is the very last check before it actually begins the patching process!
That means that all the other checks (things in the /system partition) passed before that last check failed.
That certainly seems to imply a boot image that has been diddled with. Since you still show JRO03S (I'm not sure about the kernel string - I don't know what it is supposed to be), most likely this would have been a flashable zip that modified something only in the ramdisk. Does that sound familiar?
Click to expand...
Click to collapse
All I did was use the nexus 7 toolkit to unlock the bootloader and flash CWM touch. Yes, I do think CWM was a zip file. I'm not sure though. It's been a while since I did all that. I didn't flash anything else though.
Evo4eva said:
All I did was use the nexus 7 toolkit to unlock the bootloader and flash CWM touch. Yes, I do think CWM was a zip file. I'm not sure though. It's been a while since I did all that. I didn't flash anything else though.
Click to expand...
Click to collapse
Well, I don't know what to tell you then. Everything looks kosher except for the fact the installer is complaining about the existing boot partition not matching what it is looking for. If you took that check out, and let the patcher-thingy do its work, it could easily bork your boot image and render your tablet OS unbootable.
At this point, if you are intent on staying on 4.1.x, I suggest you install Titanium Backup, back up all your User apps & data (not the system apps), and install the full factory image for JZO54K from here
To be on the safe side, make a backup of everything on your "SD card" - after you have done the Titanium Backup.
bftb0 said:
Well, I don't know what to tell you then. Everything looks kosher except for the fact the installer is complaining about the existing boot partition not matching what it is looking for. If you took that check out, and let the patcher-thingy do its work, it could easily bork your boot image and render your tablet OS unbootable.
At this point, if you are intent on staying on 4.1.x, I suggest you install Titanium Backup, back up all your User apps & data (not the system apps), and install the full factory image for JZO54K from here
To be on the safe side, make a backup of everything on your "SD card" - after you have done the Titanium Backup.
Click to expand...
Click to collapse
Well, unfortunately I have already tried that factory image on stock recovery and through ADB. It failed also. I appreciate all the help so far, but it looks like my dad has a bunk tablet. I'll just flash the stock recovery and have him get an exchange. I don't see another option. Thanks again!
Evo4eva said:
Well, unfortunately I have already tried that factory image on stock recovery and through ADB. It failed also. I appreciate all the help so far, but it looks like my dad has a bunk tablet. I'll just flash the stock recovery and have him get an exchange. I don't see another option. Thanks again!
Click to expand...
Click to collapse
Well I would think that is a failure with a different root cause as the factory installs don't really care about what is on the tablet - well, except maybe for a version check of the bootloader, and I do see that JZO54K did have the older v3.41 bootloader. That's a possibility.
What error occurs when you try to flash that factory image?
FWIW, oldblue910 mantains an archive of Nexus 7 factory images. You didn't mention whether or not you were on the WiFi only version (nakasi) or 3G version (nakasig), but he has both on his site.
good luck
PS I note that I never checked if there was a different OTA depending on whether or not the unit in question was 3G vs. WiFi-only, although TBH it would be weird if the wrong one got delivered over the air to the tablet. It does seem quite odd though, that the only thing which doesn't pass the initial OTA assert checks (checksums) is the boot image.
bftb0 said:
Well I would think that is a failure with a different root cause as the factory installs don't really care about what is on the tablet - well, except maybe for a version check of the bootloader, and I do see that JZO54K did have the older v3.41 bootloader. That's a possibility.
What error occurs when you try to flash that factory image?
FWIW, oldblue910 mantains an archive of Nexus 7 factory images. You didn't mention whether or not you were on the WiFi only version (nakasi) or 3G version (nakasig), but he has both on his site.
good luck
PS I note that I never checked if there was a different OTA depending on whether or not the unit in question was 3G vs. WiFi-only, although TBH it would be weird if the wrong one got delivered over the air to the tablet. It does seem quite odd though, that the only thing which doesn't pass the initial OTA assert checks (checksums) is the boot image.
Click to expand...
Click to collapse
It's the WiFi only version. I know this whole situation is weird. I've been rooting and flashing since the G1 and have never encountered anything like this. I did make sure I tried the one that was for the WiFi version and it still didn't work though. Thanks again for all your help.
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
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.
I've been going through posts around here. I'm currently on OF1, but I see a ton of concerns on the OneClick method, reports of success being across the board. I'm confused on how we're not consistent on one method. But! That's my question - Which has most success / is most reliable? Opinions? I'd love direct links to the ones you prefer.
What bootstrap is current? I see TWRP is still on 4.3/4.4, and Safestrap apparently lost development? What are people using? I'm currently on 5.0 OF1 without root or bootstrap.
..And I saw something about unlocking the bootloader? The phone is recognized as a dev version afterword? Does this allow us to freely install whatever bootstrap we desire? I'd prefer to get TWRP if I can. I've got no fear of ODIN'ing the crap out of this thing.
I've seen comments all over the board on what ROMs work. Like, I can't seem to find much commonality from post to post. I'm a go-for-stable type of person. I adore stock, and don't need fluff. But the thing I do need ( If anyone can advise ) is to crack open this N900V to work on Straighttalk. This phone currently isn't active, and I've already got a Straight-talk SIM. Without any of this modding the SIM is "Unrecognized" per the phone, and I'm unable to change APN settings.
So if there are common setups to flash, I'd love a link to a Modem / GApps typically flashed if needed. Another love would be to get a CM13 (Or Any CM really, I saw CM11 for unlocked bootloader?) variant running, but again, opinions seem to be varied.
Any suggestions, opinions, directions, or guides welcome!
Thanks in advance.
alexmohr1990 said:
I've been going through posts around here. I'm currently on OF1, but I see a ton of concerns on the OneClick method, reports of success being across the board. I'm confused on how we're not consistent on one method. But! That's my question - Which has most success / is most reliable? Opinions? I'd love direct links to the ones you prefer.
What bootstrap is current? I see TWRP is still on 4.3/4.4, and Safestrap apparently lost development? What are people using? I'm currently on 5.0 OF1 without root or bootstrap.
..And I saw something about unlocking the bootloader? The phone is recognized as a dev version afterword? Does this allow us to freely install whatever bootstrap we desire? I'd prefer to get TWRP if I can. I've got no fear of ODIN'ing the crap out of this thing.
I've seen comments all over the board on what ROMs work. Like, I can't seem to find much commonality from post to post. I'm a go-for-stable type of person. I adore stock, and don't need fluff. But the thing I do need ( If anyone can advise ) is to crack open this N900V to work on Straighttalk. This phone currently isn't active, and I've already got a Straight-talk SIM. Without any of this modding the SIM is "Unrecognized" per the phone, and I'm unable to change APN settings.
So if there are common setups to flash, I'd love a link to a Modem / GApps typically flashed if needed. Another love would be to get a CM13 (Or Any CM really, I saw CM11 for unlocked bootloader?) variant running, but again, opinions seem to be varied.
Any suggestions, opinions, directions, or guides welcome!
Thanks in advance.
Click to expand...
Click to collapse
I will say in advance that this phone was my first time going thru any of this, so take what I have to say with a grain of salt if you would like. I have been rooted for about a week, unlocked bootloader and flashed Jasmine 6.1 rom yesterday.
I tried using this method of root for a few days with no results (http://forum.xda-developers.com/ver...b6-of1-n900v-note-3-verizon-oneclick-t3333569). I tried on multiple computers running Windows 7 x64 with no luck. It would start the process, but would never reboot my phone into download mode.
After failing at that, I ended up trying this method with both computers running Win 7 x64 (http://forum.xda-developers.com/verizon-galaxy-note-3/general/root-n900v-5-0-of1-one-click-t3330098) since there were multiple posts saying that it worked for them using Win 7 and running as admin. It would reboot my phone and then the computer program would freeze before the phone would start to download. I ended up taking the free Win 10 update on the wife's laptop and tried again. Phone was rooted in about 90 seconds. All I did was download KEIS and install the drivers it had, then try the program again. Worked flawlessly.
I followed this (http://forum.xda-developers.com/ver.../how-to-unlock-verizon-galaxy-note-3-t3360309) to unlock my bootloader. The one exception, is that I followed a YouTube video on how to do it by using a Terminal Emulator on the phone rather than via PC. In the video the guy adds "samsung" to a couple places in the code, but I did not. I followed the code exactly as is in the post I linked and it worked.
To install TWRP via FlashFire, you have to unlock bootloader. Once you unlock the bootloader, FlashFire will give you an option to download and flash TWRP.
Poor Man's App Freeze
@RaaidR
FWIW, you can also perform a similar "freezing" function by going in to the /system/app folder and doing a
chmod 0000 filename.apk
On the .apk and .odex files you want to freeze. (For all I know that might be the technique that TiBu uses)
Note that since /system is typically mounted read-only, you have to temporarily mount it read-write when doing this. For example, in a terminal emulator:
Code:
su
mount -o remount,rw /system
cd /system/app
chmod 0000 Knox*.apk Knox*.odex
...
cd /
sync
mount -o remount,ro /system
exit
exit
Unless you need to make room inside of /system/app to install other apps (which will then survive a recovery-boot "factory reset"*), there's almost nothing to be gained by actually removing them rather than freezing them. They don't consume any runtime resources and probably don't even affect boot time following a cache/dalvik-cache wipe once they are "frozen".
Here is a list of things I froze in an older stock ROM; mostly to prevent OTA nagging, Knox BS, and some VZW spyware:
ContainerAgent.apk
ContainerAgent.odex
ContainerEventsRelayManager.apk
ContainerEventsRelayManager.odex
FWUpgrade.apk
FWUpgrade.odex
KLMSAgent.apk
KLMSAgent.odex
KNOXAgent.apk
KNOXAgent.odex
KNOXStore.apk
KNOXStore.odex
KnoxAttestationAgent.apk
KnoxAttestationAgent.odex
LocalFOTA.apk
SDM.apk
SDM.odex
VMS.apk
This post (from 4.3) has a more extensive list of debloating; I haven't used it so I can't vouch for it.
*some market apps don't seem to behave correctly when you drop their .apk into /system/app, so ymmv on this style of hack.
@alexmohr1990
Sorry for the small tangent/thread-jack.
If you like solid, bugfree performance, stick with rooted stock (but kill off stuff you dont want to be running via freezing and Android's built in app "Disable" feature in Settings==>Application manager)
Frankly, the only things you need to "freeze" are apps that do not appear in the Application manager - e.g. stuff like Verizon spyware (VMS.apk) and Knox crapola. For anything that shows up in the App manager, you can use the "Disable" feature. (TiBu "freezing" pre-dates
the appearance of the app Disable feature in Stock Android, so a lot of long time users of TiBu don't seem to be aware of Android's now built in app disable feature)
Can't help with the carrier stuff; I've only been on Verizon.
good luck
bftb0 said:
@RaaidR
FWIW, you can also perform a similar "freezing" function by going in to the /system/app folder and doing a
chmod 0000 filename.apk
On the .apk and .odex files you want to freeze. (For all I know that might be the technique that TiBu uses)
Note that since /system is typically mounted read-only, you have to temporarily mount it read-write when doing this. For example, in a terminal emulator:
Code:
su
mount -o remount,rw /system
cd /system/app
chmod 0000 Knox*.apk Knox*.odex
...
cd /
sync
mount -o remount,ro /system
exit
exit
Unless you need to make room inside of /system/app to install other apps (which will then survive a recovery-boot "factory reset"*), there's almost nothing to be gained by actually removing them rather than freezing them. They don't consume any runtime resources and probably don't even affect boot time following a cache/dalvik-cache wipe once they are "frozen".
Here is a list of things I froze in an older stock ROM; mostly to prevent OTA nagging, Knox BS, and some VZW spyware:
ContainerAgent.apk
ContainerAgent.odex
ContainerEventsRelayManager.apk
ContainerEventsRelayManager.odex
FWUpgrade.apk
FWUpgrade.odex
KLMSAgent.apk
KLMSAgent.odex
KNOXAgent.apk
KNOXAgent.odex
KNOXStore.apk
KNOXStore.odex
KnoxAttestationAgent.apk
KnoxAttestationAgent.odex
LocalFOTA.apk
SDM.apk
SDM.odex
VMS.apk
This post (from 4.3) has a more extensive list of debloating; I haven't used it so I can't vouch for it.
*some market apps don't seem to behave correctly when you drop their .apk into /system/app, so ymmv on this style of hack.
@alexmohr1990
Sorry for the small tangent/thread-jack.
If you like solid, bugfree performance, stick with rooted stock (but kill off stuff you dont want to be running via freezing and Android's built in app "Disable" feature in Settings==>Application manager)
Frankly, the only things you need to "freeze" are apps that do not appear in the Application manager - e.g. stuff like Verizon spyware (VMS.apk) and Knox crapola.
Can't help with the carrier stuff; I've only been on Verizon.
good luck
Click to expand...
Click to collapse
I went with Jasmine 6.1 so that I could use the Xposed software since it requires a deodexed rom.........stock rom isn't deodexed from what I read.
Also, I read a few list's like that, but wasn't sure on how much I could screw up in 5.0 since the list's were from previous versions of Android.
@RaaidR : This is the type of post I'm looking for. I've been ROMing since a Droid 2, but never hadid as much trouble as this silly vzw version note. Thanks!
@bftb0 Well. Typically I would stay stock. But even stock has anyone crafted an unofficial stock higher than 5.0? I saw something about s7 firmware. I did recently install CM13 for a friend on a S4. Made me super jelly and wanted to try it. My biggest concern is getting this thing unlocked to the point I can use preferably LTE on straighttalk. So I definitely need to be able to modify apn settings, but unlocking is a point I've never dived into, much less on such a difficult model.
alexmohr1990 said:
@RaaidR : This is the type of post I'm looking for. I've been ROMing since a Droid 2, but never hadid as much trouble as this silly vzw version note. Thanks!
@bftb0 Well. Typically I would stay stock. But even stock has anyone crafted an unofficial stock higher than 5.0? I saw something about s7 firmware. I did recently install CM13 for a friend on a S4. Made me super jelly and wanted to try it. My biggest concern is getting this thing unlocked to the point I can use preferably LTE on straighttalk. So I definitely need to be able to modify apn settings, but unlocking is a point I've never dived into, much less on such a difficult model.
Click to expand...
Click to collapse
You are welcome. If you run across any issues, I might be able to help, but my knowledge is limited. Good luck going forward, let me know how it works out for you.
Excellent! @RaaidR all of it for the most part worked like a charm. Root was no trouble, same for bootloader. Both on first try. Had to flash TWRP Manually through Odin, but I got it. Good stuff. Now to hunt down a ROM. Thanks a ton for such a precise response!
So... For ROMs... Does this mean I can now access Developer Version ROMs? I'm looking for something unlocked (Or can easily modify carrier settings) and stable. Not into the idea of "Whelp. Guess it decided not to boot today" that I've run into with ROMing on previous phones. Haven't really got to play with Xposed yet, so it'd be cool to tool around with it too.
Jasmine 6.1 comes with Xposed infused and is very close to stock rom from what I have experienced so far and from what others have said about it. As far as Developer Roms go, that I can't tell you much about that. I went straight to Jasmine because from everything I have read it seems to be the most stable of what is out there. Hopefully somebody on here can give you some different options. If you decide to go with Jasmine, make sure to remember to flash the partial firmware thru Odin after flashing the rom.
Is this the Jasmine ROM you refer to? http://forum.xda-developers.com/showthread.php?t=2760380
Guess I've never had a device with an unlocked bootloader. Hah. I guess my next question would be - I wouldn't be able to use any Pre-5.0 ROMs? Not that I truthfully want to for the most part. But as you said, there just seems to be a slim amount of things about as I guess many have moved on to newer devices and Root/Bootloader progress came so late.
I'll give it a try though. Plan to make a day of flashing.
Edit: For Jasmine... It makes note of a retail version and developer version... Are we technically on the dev version after the unlock? I didn't see a mention to tell the difference.
I believe you are not able to downgrade from 5.0 once you go to it, or at least that was my understand pre-root. If that has changed post-root, I cannot say but I didn't attempt it.
Also, although we now have the developer mode enabled due to unlocking bootloader, I didn't know the difference and chose to follow the retail instructions and it worked flawlessly.
I searched for "Jasmine 6.1 install" on YouTube and followed the video by EverythingSamsungPro since I also followed his video on bootloader unlock.
alexmohr1990 said:
Edit: For Jasmine... It makes note of a retail version and developer version... Are we technically on the dev version after the unlock? I didn't see a mention to tell the difference.
Click to expand...
Click to collapse
unlocked bootloader == developer edition.
Having a "DevEd" device means that the bootloader will no long prevent you from booting unsigned "bootable" partitions (boot and recovery). And, also that Odin no longer requires things flashed in the AP slot such as boot.img, recovery.img, and system.img to be Samsung signed.
The implications is that the "Retail" version of Jasmine is required to use the pure stock boot image, and no custom recovery, whereas the DevEd version can do one or both. Small mods of the boot.img blob are the most likely.
Noting that the "boot.img" binary blob is actually three separate pieces:
boot.img = kernel + ramdisk + devicetree
I can't tell you if the DevEd version of Jasmine modifies the stock kernel, the ramdisk, or the device treee (or any combination thereof). Intuition tells me that mods of the devicetree are highly unlikely and small mods of the ramdisk are the most likely. Is the kernel modded? I don't know, you'll have to dig into that thread to find out.
Practically speaking, having only a single boot which is rooted is a bit of a hazard, but it is far more of a hazard if the bootloader is still locked. If that one boot/ROM started boot-looping after a broken modification by the owner, the only recourse is to go back to pure stock using Odin and start re-rooting. With an unlocked bootloader, in principle you could install a custom recovery (flashing it with Odin) at any time, so a 2nd independent, rooted custom boot/recovery is available to perform system maintenance.
So you can use either the DevEd version or the Retail version on an unlocked phone. Probably you should dig in to the Jasmine thread to find out if the differences between the two are compelling to you based on whatever it is you want your phone to do.
good luck
PS. See this very nearly identical inquiry & reply in the Q&A Forum, especially the remarks about "partial firmware flashing". You do not want to over-flash your unlocked bootloader.
---------- Post added at 11:23 PM ---------- Previous post was at 11:08 PM ----------
RaaidR said:
I believe you are not able to downgrade from 5.0 once you go to it, or at least that was my understand pre-root. If that has changed post-root, I cannot say but I didn't attempt it.
Click to expand...
Click to collapse
What is known for sure is that the Samsung bootloader (which is actually a whole slew of partitions) enforces an Anti-Rollback policy on the bootloader firmware.
It is actually not known if it would be possible to run a 4.3.x or 4.4.x stock ROM on later versions of bootloader firmware. For instance, if your bootloader firmware was OB6 or OF1 ("5.x") but you flashed stock versions of NC4/NK1 ROM software (4.4.x "boot.img" and "system.img")
Why is it not known? Because AFAIK, no-one has tried it. (Well, actually @ryanbg tried all sorts of dangerous flashing combinations in the old days, but I'm not sure if he published the details). I suspect it would be safe to try these experiments (clean flash of only boot.img and system.img from prior releases) - if and only if you have an unlocked bootloader. (If they don't work, flash something that does; hard to imagine they will cause a hard-bricking on what is a DevEd phone).
So it is probably most accurate to say "we can't flash OB6 or OF1 bootloader firmware back to NC4", but "it's not known if OB6/OF1 bootloader would successfully boot 4.4.x (or even 4.3.x) ROMs" (boot.img + system.img)
I hope that's not too confusing. It's a little subtle, but makes far more sense to anyone who realizes that there are a ton of partitions in these Samsung phones, and that "4.3", "4.4", "5.0" are more closely associated with boot.img and system.img than they are with the (many) bootloader partitions.
You can get CM13 here: http://forum.xda-developers.com/ver...opment/rom-temaseks-unofficial-build-t3364382
I've been running it for a couple of weeks and I have found it to be the only usable MM rom at the moment. Otherwise that Jasmine ROM is a solid choice.
bftb0 said:
unlocked bootloader == developer edition.
Having a "DevEd" device means that the bootloader will no long prevent you from booting unsigned "bootable" partitions (boot and recovery). And, also that Odin no longer requires things flashed in the AP slot such as boot.img, recovery.img, and system.img to be Samsung signed.
The implications is that the "Retail" version of Jasmine is required to use the pure stock boot image, and no custom recovery, whereas the DevEd version can do one or both. Small mods of the boot.img blob are the most likely.
Noting that the "boot.img" binary blob is actually three separate pieces:
boot.img = kernel + ramdisk + devicetree
I can't tell you if the DevEd version of Jasmine modifies the stock kernel, the ramdisk, or the device treee (or any combination thereof). Intuition tells me that mods of the devicetree are highly unlikely and small mods of the ramdisk are the most likely. Is the kernel modded? I don't know, you'll have to dig into that thread to find out.
Practically speaking, having only a single boot which is rooted is a bit of a hazard, but it is far more of a hazard if the bootloader is still locked. If that one boot/ROM started boot-looping after a broken modification by the owner, the only recourse is to go back to pure stock using Odin and start re-rooting. With an unlocked bootloader, in principle you could install a custom recovery (flashing it with Odin) at any time, so a 2nd independent, rooted custom boot/recovery is available to perform system maintenance.
So you can use either the DevEd version or the Retail version on an unlocked phone. Probably you should dig in to the Jasmine thread to find out if the differences between the two are compelling to you based on whatever it is you want your phone to do.
good luck
PS. See this very nearly identical inquiry & reply in the Q&A Forum, especially the remarks about "partial firmware flashing". You do not want to over-flash your unlocked bootloader.
---------- Post added at 11:23 PM ---------- Previous post was at 11:08 PM ----------
What is known for sure is that the Samsung bootloader (which is actually a whole slew of partitions) enforces an Anti-Rollback policy on the bootloader firmware.
It is actually not known if it would be possible to run a 4.3.x or 4.4.x stock ROM on later versions of bootloader firmware. For instance, if your bootloader firmware was OB6 or OF1 ("5.x") but you flashed stock versions of NC4/NK1 ROM software (4.4.x "boot.img" and "system.img")
Why is it not known? Because AFAIK, no-one has tried it. (Well, actually @ryanbg tried all sorts of dangerous flashing combinations in the old days, but I'm not sure if he published the details). I suspect it would be safe to try these experiments (clean flash of only boot.img and system.img from prior releases) - if and only if you have an unlocked bootloader. (If they don't work, flash something that does; hard to imagine they will cause a hard-bricking on what is a DevEd phone).
So it is probably most accurate to say "we can't flash OB6 or OF1 bootloader firmware back to NC4", but "it's not known if OB6/OF1 bootloader would successfully boot 4.4.x (or even 4.3.x) ROMs" (boot.img + system.img)
I hope that's not too confusing. It's a little subtle, but makes far more sense to anyone who realizes that there are a ton of partitions in these Samsung phones, and that "4.3", "4.4", "5.0" are more closely associated with boot.img and system.img than they are with the (many) bootloader partitions.
Click to expand...
Click to collapse
I did flash the partial firmware on mine and did not flash the modem part for the developer edition, so far I have had no issues. Am I missing something I am supposed to have?
RaaidR said:
I did flash the partial firmware on mine and did not flash the modem part for the developer edition, so far I have had no issues. Am I missing something I am supposed to have?
Click to expand...
Click to collapse
Well, the point of that partial firmware was to upgrade the bootloader firmware set (if needed) and also install a stock boot and recovery images. Here's the contents of that .tar.md5.7z archive:
Code:
-rw-r--r-- hsbadr/staff 5932800 2015-07-16 06:39 NON-HLOS.bin
-rw-r--r-- hsbadr/staff 1110652 2015-07-16 06:39 [b][color=red]aboot.mbn[/color][/b]
-rw-r--r-- hsbadr/staff 10840336 2015-07-16 06:39 [b]boot.img[/b]
-rw-r--r-- hsbadr/staff 56542976 2015-07-16 06:36 modem.bin
-rw-r--r-- hsbadr/staff 11796752 2015-07-16 06:39 [b]recovery.img[/b]
-rw-r--r-- hsbadr/staff 164388 2015-07-16 06:39 rpm.mbn
-rw-r--r-- hsbadr/staff 280976 2015-07-16 06:38 sbl1.mbn
-rw-r--r-- hsbadr/staff 32356 2015-07-16 06:38 sdi.mbn
-rw-r--r-- hsbadr/staff 321284 2015-07-16 06:38 tz.mbn
The one shown in red - "aboot.mbn" is the final (third) stage of the bootloader, and it corresponds to the "aboot" partition which is modified by the bootloader unlock technique. "aboot.mbn" is the code you visually observe running on the phone in Odin mode and during bootloader sequences.
So, what you did was that you re-locked your bootloader, and if you had a custom recovery installed you overwrote that with the stock version. If you were to boot into Odin mode, you will no longer see the "MODE: DEVELOPER" message.
If you want to unlock the bootloader, just run the unlock tool again as root. (You will have to destroy your external SD card again)
Good luck
PS. This is a little of a tangent but it is worthwhile that you look at that file listing above as you are new to this. Whenever a (Note 3) "bootloader" firmware upgrade is performed in Odin, all of the following files are flashed in the same Odin session:
NON-HLOS.bin, aboot.mbn, modem.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn
These files each are flashed into separate partitions, but they have interlocking dependencies; you can't flash them individually in a willy-nilly fashion. If you ever do that you are risking a hard-bricking.
The only exception in this group is the "modem.bin" radio firmware. (Some people fool around (mix-n-match) with various radio firmwares, probably without any firm evidence to support their claims as to why they engage in such behavior.)
When people distinguish between "ROM" and "bootloader firmware", they mean by ROM these files:
recovery.img (stock ROMs; omitted if you already have a custom recovery)
boot.img
system.img.ext4
cache.img.ext4
That's what made the bundle you flashed "partial" - it didn't contain the stock system.img or cache.img
bftb0 said:
Well, the point of that partial firmware was to upgrade the bootloader firmware set (if needed) and also install a stock boot and recovery images. Here's the contents of that .tar.md5.7z archive:
Code:
-rw-r--r-- hsbadr/staff 5932800 2015-07-16 06:39 NON-HLOS.bin
-rw-r--r-- hsbadr/staff 1110652 2015-07-16 06:39 [b][color=red]aboot.mbn[/color][/b]
-rw-r--r-- hsbadr/staff 10840336 2015-07-16 06:39 [b]boot.img[/b]
-rw-r--r-- hsbadr/staff 56542976 2015-07-16 06:36 modem.bin
-rw-r--r-- hsbadr/staff 11796752 2015-07-16 06:39 [b]recovery.img[/b]
-rw-r--r-- hsbadr/staff 164388 2015-07-16 06:39 rpm.mbn
-rw-r--r-- hsbadr/staff 280976 2015-07-16 06:38 sbl1.mbn
-rw-r--r-- hsbadr/staff 32356 2015-07-16 06:38 sdi.mbn
-rw-r--r-- hsbadr/staff 321284 2015-07-16 06:38 tz.mbn
The one shown in red - "aboot.mbn" is the final (third) stage of the bootloader, and it corresponds to the "aboot" partition which is modified by the bootloader unlock technique. "aboot.mbn" is the code you visually observe running on the phone in Odin mode and during bootloader sequences.
So, what you did was that you re-locked your bootloader, and if you had a custom recovery installed you overwrote that with the stock version. If you were to boot into Odin mode, you will no longer see the "MODE: DEVELOPER" message.
If you want to unlock the bootloader, just run the unlock tool again as root. (You will have to destroy your external SD card again)
Good luck
PS. This is a little of a tangent but it is worthwhile that you look at that file listing above as you are new to this. Whenever a (Note 3) "bootloader" firmware upgrade is performed in Odin, all of the following files are flashed in the same Odin session:
NON-HLOS.bin, aboot.mbn, modem.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn
These files each are flashed into separate partitions, but they have interlocking dependencies; you can't flash them individually in a willy-nilly fashion. If you ever do that you are risking a hard-bricking.
The only exception in this group is the "modem.bin" radio firmware. (Some people fool around (mix-n-match) with various radio firmwares, probably without any firm evidence to support their claims as to why they engage in such behavior.)
When people distinguish between "ROM" and "bootloader firmware", they mean by ROM these files:
recovery.img (stock ROMs; omitted if you already have a custom recovery)
boot.img
system.img.ext4
cache.img.ext4
That's what made the bundle you flashed "partial" - it didn't contain the stock system.img or cache.img
Click to expand...
Click to collapse
In the download screen I still show as being in developer mode, but I did unlock the bootloader before flashing Jasmine ROM. So would flashing the partial firmware be the reason why I had to reflash TWRP with FlashFire after flashing Jasmine?
RaaidR said:
In the download screen I still show as being in developer mode, but I did unlock the bootloader before flashing Jasmine ROM. So would flashing the partial firmware be the reason why I had to reflash TWRP with FlashFire after flashing Jasmine?
Click to expand...
Click to collapse
For sure, yes. (cause of recovery needing to be re-flashed).
But that is really very surprising that you still have Developer Mode showing. I guess I'll look into something (perhaps the DE sig is flashed into the back end of the aboot partition and it survived the new flash because the aboot.mbn image is not sufficiently large to cause an erasure of the erase block that the sig lives in.)
That's new information you just discovered right there.
I assume that you do not get the "Unauthorized Software" pop-up message when you boot the custom recovery, is that right?
Thanks for the information.
bftb0 said:
For sure, yes. (cause of recovery needing to be re-flashed).
But that is really very surprising that you still have Developer Mode showing. I guess I'll look into something (perhaps the DE sig is flashed into the back end of the aboot partition and it survived the new flash because the aboot.mbn image is not sufficiently large to cause an erasure of the erase block that the sig lives in.)
That's new information you just discovered right there.
I assume that you do not get the "Unauthorized Software" pop-up message when you boot the custom recovery, is that right?
Thanks for the information.
Click to expand...
Click to collapse
Nope, I don't get any warnings or pop-ups about anything when I load TWRP. When I boot to TWRP, it just boots right to it like it should without any warnings at all.
Just so you know, this is exactly what I did in order:
Rooted phone (Yemen n900v 5.0 of1 one click)
Unlocked bootloader with Terminal Emulator
Downloaded FlashFire and flashed TWRP
Flashed Jasmine 6.1 ROM with FlashFire (in FlashFire I selected Wipe and chose System Data, 3rd Party Apps, Dalvik cache) and set reboot in FlashFire to Bootloader
Flashed partial firmware via ODIN in AP slot
During reboot, I removed battery and booted into Recovery Mode (Vol Up, Home, Power Button)
Wipe/Factory Reset
Wipe Cache Partition
Reboot and complete setup
After this I re-downloaded all of them and restored data via TB. During this, I noticed that I no longer had TWRP. Opened FlashFire again and downloaded and flashed TWRP one more time.
Being new to all of this, I assumed that TWRP got wiped when I flashed new ROM and did all of the wipes so I just assumed that it wiped everything else also. After this, everything works perfectly. I don't have any issues with anything, except I wish I could download some new themes to use with the ROM (may be able to, I just haven't found out how to yet. I have been looking, just haven't come across the correct stuff to read).
As far as it being new information, leave it up to the noob to stumble across it haha.
RaaidR said:
Being new to all of this, I assumed that TWRP got wiped when I flashed new ROM and did all of the wipes so I just assumed that it wiped everything else also.
Click to expand...
Click to collapse
Shouldn't be "the ROM" that did that. Devs can do whatever they want, but it has been the custom for ROM devs to avoid packaging up recovery images for flashing during a ROM install. First because (strictly speaking) it's not needed by "the ROM" to function, and second because many devices have more than one choice for custom recoveries, so doing that would be over-riding the owners' decisions about what custom recovery to use.
In this case though, the dual- or triple- purpose Jasmine ROM (DevEd/Retail/Multiboot) has to install a stock boot image for Retail versions. In most stock distributions, the device or carrier vendor uses the identical kernel in the "boot.img" file that is used in the "recovery.img" file. (The ramdisks are different, and that accounts for their wildly different behaviors - the recovery doesn't need to rely on /system or /data to boot up to a primitive UI such as TWRP... and that's exactly why recoveries are used for OTA installations, upgrades and repairs - neither /system nor /data need to be mounted for them to boot up a UI; in a way of speaking, those file systems are "offline" when the recovery is booted. That of course makes manipulating them, erasing them, etc much more convenient).
I haven't followed the Jasmine thread much, but since there have been version releases which are based off of different stock releases, hsbadr needs to insure that the correct stock boot partition (file "boot.img") is installed along with the customized stock ROM (Jasmine) for the Retail version, and that's the purpose of that "partial firmware" flash. I suppose he left the recovery.img in there simply because it is good practice to keep stock recovery images in lockstep with stock boot images. And of course, that development predates the appearance of "Unlocked" bootloaders, so there was no reason on Retail devices to have anything except a stock recovery installed.
.
bftb0 said:
Shouldn't be "the ROM" that did that. Devs can do whatever they want, but it has been the custom for ROM devs to avoid packaging up recovery images for flashing during a ROM install. First because (strictly speaking) it's not needed by "the ROM" to function, and second because many devices have more than one choice for custom recoveries, so doing that would be over-riding the owners' decisions about what custom recovery to use.
In this case though, the dual- or triple- purpose Jasmine ROM (DevEd/Retail/Multiboot) has to install a stock boot image for Retail versions. In most stock distributions, the device or carrier vendor uses the identical kernel in the "boot.img" file that is used in the "recovery.img" file. (The ramdisks are different, and that accounts for their wildly different behaviors - the recovery doesn't need to rely on /system or /data to boot up to a primitive UI such as TWRP... and that's exactly why recoveries are used for OTA installations, upgrades and repairs - neither /system nor /data need to be mounted for them to boot up a UI; in a way of speaking, those file systems are "offline" when the recovery is booted. That of course makes manipulating them, erasing them, etc much more convenient).
I haven't followed the Jasmine thread much, but since there have been version releases which are based off of different stock releases, hsbadr needs to insure that the correct stock boot partition (file "boot.img") is installed along with the customized stock ROM (Jasmine) for the Retail version, and that's the purpose of that "partial firmware" flash. I suppose he left the recovery.img in there simply because it is good practice to keep stock recovery images in lockstep with stock boot images. And of course, that development predates the appearance of "Unlocked" bootloaders, so there was no reason on Retail devices to have anything except a stock recovery installed.
.
Click to expand...
Click to collapse
Ah, I gotcha. Yea, I just guessed that since I did all those wipes that was cause for it having disappeared rather than me flashing that firmware, which makes more sense. Is there "Dev" or "Retail" version of Jasmine or is it just the install process that changes depending on whether your phone is developer or retail?
RaaidR said:
Ah, I gotcha. Yea, I just guessed that since I did all those wipes that was cause for it having disappeared rather than me flashing that firmware, which makes more sense. Is there "Dev" or "Retail" version of Jasmine or is it just the install process that changes depending on whether your phone is developer or retail?
Click to expand...
Click to collapse
TBH I don't know. I'd say "read the thread" but it's what - 1200+ pages long?
Maybe search that thread for keywords.
One way to determine it would be two download the installation bundles for each and pick them apart or perform checksums e.g. on the boot.img file from each. If they have identical checksums (MD5 or SHA1 or whatever), then the kernel+ramdisk (== boot image) are the same. The same can be done for any pair of files to test for "sameness". If the checksums are different, then you have to pick them apart more carefully to find out what the differences are.
The boot image controls many long lived "services" that get started by the parent of all processes in Unix/Linux - the "init" process. So many times even stock-derived boot images have tweaks in their ramdisk (which contain files such as the "init.*.rc" files that control how init behaves), even if a pure stock kernel is used. But I don't know if the DevEd version of Jasmine has mods like that; it well might though.
Warning: This is the most dangerous tool I've personally ever seen!!! It writes to your partitions without checking.. you could accidentally write a text file to the partition!!!
I created tool specifically for downgrading. I have to be away 1 to 4 weeks and then I will continue progress. It is my goal to downgrade to Android 5.01, take root, then upgrade to Nougat with full root. Some ideas are to flash OJ1 files using this tool then reflash them again with Odin. You may have to shrink the system.img and flash cache.img last, if at all. Another idea is to get twrp from a Note 5 BOTA0 and BOTA1 along with RECOVERY partitions then flash them to the device.. risky would be an understatement but I've tested writing to a lot of other partitions already.. just not those.
i'm so tired right now.. it works and i will make it better but i need sleep.. (see the readme on github)
https://github.com/droidvoider/Android_6.01__DD_Dcow
IGNORE THE REMAINING POSTS THEY ARE OUTDATED... I am rushing to finish this tonight because I won't have time for 1 to 4 weeks. Please post issues I will address them.
droidvoider said:
when you flash the correct one your phone will text AT&T a coded message
Click to expand...
Click to collapse
Can you please rephrase this? Is there any way for us to intercept or interfere with such a message.
Anonymously_Unknown said:
Can you please rephrase this? Is there any way for us to intercept or interfere with such a message.
Click to expand...
Click to collapse
You can avoid it by flashing your entire firmware again. I haven't tried to avoid the message I just end up flashing the entire firmware back when my attempts fail.
edit
New method, tested several times now and now more unwanted texts during testing. (probably great info to clear the data trail of hack attempts on frp lock bypass, usually a modem file "i think?")
**** Please be advised I've never attempted a frp bypess nor do I flash incorrect firmware, only previous but correct versions! still dangerous.
BEFORE flashing back the correct modem firmware...
<under application manager "more+show system apps">
1. Clear data MESSAGES
2. Remove permissions MESSAGES
3. Clear data OMACP
4. Flash back modem file and repeat step 1 through 3 for good measures. Install Google Messenger, now Android Messenger..
Ok I have dirtycow working with PK1. I can patch things like /system/bin/run-as and also /data/tmp/local/* .... However if I try to patch /data/data/app-name/textfile my phone reboots. (not that i need to patch anything there) At this point I don't even know if there are any other PK1 AT&T Note 5 guys left besides me!! So this is just a short snippet 'how to' get dirtycow working on this version. If you need more help speak up.
(I bet you can take this kernel into the next few version but I'm not upgrading to find out.. logcat has some more errors than usual but nothing major, i broke the security update thing look like)
You don't have to use heimdall! ~ I made odin flashable tar.md5 files for this process a few posts down with a bunch of *****asterisk***** so I can find that post myself, laugh. Detailed inside is how I made them which is detailed on this forum very well.
=========> Flash boot.img from N920AUCS3CPJ1 firmware version into your Note 5 with this baseband version: N920AUCS4CPK1 <=============
1. Download heimdal from github and look at the readme under Linux. Near bottom of readme follow instructions including installing the 4 main dependencies.
2. You can use heimdall in the terminal or open a terminal and type: heimdall-frontend for a graphical user interface.
3. REBOOT UBUNTU! In some rare cases we do reboot Ubuntu.
4. Down the files I linked below which are the .pit file for version PK1 and the boot.img from version PJ1.
5. Select 'flash tab' and then browse for .pit file.. Click Add button, then select BOOT.
6. Browse for the boot.img we download then click flash.. Good luck, hope you don't brick!!! so far i'm good but it's been 3 hours only.
PK1 .pit file and PJ1 boot.img file to be used with heimdal for Ubuntu 16.10
https://mega.nz/#!KwlQTSDZ!N-SItLDERCOIE-hFENNQoH3g8SQMDgpa-RajolQhe5Q
Edited in Notes:
logcat clears up after a few minutes and the errors completely stop. I'm not even planning to flash it back to normal!
Is the linked PJ1 boot.img, the stock boot.img extracted from the PJ1 AP file for ODIN?
In my experience with downgrading my device, I can downgrade my build by flashing only the AP file of my chosen build firmware. But the AP file's boot.img containing the kernel must be loadable by the installed bootloader (sboot.bin). I cannot flash thus far an sboot.bin to my device from a firmware based on a binary 2 bootloader. I have a binary 3 lollipop bootloader I can flash to downgrade my system. After doing this it allows me to overwrite it a binary 2 sboot, but I wasn't able to get the tether root to fully reboot without a wipe first. Then I must start back at 3BPH4 and then re-downgrade to attempt a pull again. It's long. And requires 2 stages of flashing, per attempt.
The problem I have is how do I get ODIN to stop instantly denying my chosen file to flash. What check am I not bypassing or getting correct. How do I find the correct checksum or value to edit or spoof to force a mostly official-ish tar. There should be a way somewhere to intercept the communications between the phone, pc, download mode and the modem.
Delgoth said:
Is the linked PJ1 boot.img, the stock boot.img extracted from the PJ1 AP file for ODIN?
Click to expand...
Click to collapse
Yes it is the stock boot.img from a copy of the PJ1 firmware I found from this site somewhere.
Delgoth said:
In my experience with downgrading my device, I can downgrade my build by flashing only the AP file of my chosen build firmware. But the AP file's boot.img containing the kernel must be loadable by the installed bootloader (sboot.bin).
Click to expand...
Click to collapse
I don't have PJ1 sboot.bin because the copies online all have an error in the BL tar.md5. When I read your post I decided to try flashing in recovery.img, it accepted it! In my recovery screen now it reads PJ1, in my About screen reads PK1. I am starting to think I can keep flashing in PK1 stuff until it might let me flash the reset. I would love to find a N920AUCS3CPJ1 with a valid BL_N920AUCS3CPJ1_CL8961126_QB11173364_REV00_user_low_ship.tar.md5 file. (I can try this with PH4 but then I have to setup phone again so I rather wait until I crash it again lol)
Delgoth said:
The problem I have is how do I get ODIN to stop instantly denying my chosen file to flash. What check am I not bypassing or getting correct. How do I find the correct checksum or value to edit or spoof to force a mostly official-ish tar. There should be a way somewhere to intercept the communications between the phone, pc, download mode and the modem.
Click to expand...
Click to collapse
I've seen my recovery.img files getting denied by Odin before, however, I just cleanly flashed in recovery from PJ1 using heimdall. Again if I am not being clear I extract the .img files from the tar.md5 then I use the .pit file from PK1 and that .img file in "heimdall" for Ubuntu 16.10
I'm starting to think we can weasel down because PJ1 is binary 3, PK1 is binary 4. (edited.. wrong, you can flash boot.img, recovery.img, userdata.img and cm.bin, modem.bin crashes modem)
Battery drain less than 1% in 8 hours of screen off time!!
Disabling the AT&T apps with my simple exploit (now with it's own cve code and everything) I had great results finally getting back into the 6% battery drain in 8 hours of sleep. Then I discovered if I disabled almost all of Google Play except Google play itself and video watching stuff I was at approximately 2% drain in 8 hours.
Simply flashing in the previous version boot.img and recovery.img made my battery drain with screen off almost 0!!!! I do have to deal with AT&T Software Update has stopped when I boot, or when I disconnect/reconnect my network. This includes if I lose signal. But it is just an OK message and the phone keeps working even if you don't press OK.
Attached you will see my battery screen showing basically no loss from 2:10am to 10:08am. (edit just realized it says 98% now but it's because I was looking at it and screen capping)
If anyone is interested in a partial downgrade to allow the use of dirtycow here are my files. This was tested to downgrade the N920AUCS4CPK1 kernel to the N920AUCS3CPJ1 kernel by flashing boot.img and recovery.img of the previous baseband. (Oddly allowed? sw rev check fail doesn't apply to these files).. You can also use the userdata.img file which is not well tested, but I'm now using that also.
These are Odin flashable tar.md5 files after you unzip them. IF HAVE NOT tested these in Odin EXCEPT the 1st option, boot.img and recovery.img only.
1. N920AUCS3CPJ1 boot.img and recovery.img to be flashed on top of an already installed/working Note5 w/ N920AUCS4CPK1 installation.
https://mega.nz/#!nwFUVQaC!R3inD-QNEfLKmLGnVnMuAHG10WaMzvivdNn5samhSkA
2. N920AUCS3CPJ1 boot.img and recovery.img with N920AUCS4CPK1 system.img and userdata.img .. (This is for a full setup, use this AP file instead of PK1 AP file)
https://mega.nz/#!XsdxAR7D!RrmYvOgDYdt72MDsV7OmpW-eM5gHqSQu7clwrOIdSQk
3. This is the experimental AP file replacement. N920AUCS3CPJ1 boot.img, recovery.img and userdata.img with N920AUCS4CPK1 system.img. (CAUTION: untested)
https://mega.nz/#!e0ESUZBT!QbLR9Ew0-DFsOpte2wN-wCeRRfWQEATjyKlmuSn8hP8
Note: How I created them is detailed in the zip file.
(Downgrade isn't too likely at the moment I have no earthly idea how I would get rid of sboot.bin "the locked bootloader". The rest of my efforts are just root while preserving knox container)
*
*
*
*
*
*
*
*
**********************************************************************************************
*********************************SEARCH FOR ROOT*****************************************
**********************************************************************************************
****************Note 5 64 bit hacking tools. Readme has links to sources*******************
**********************************************************************************************
No root yet, just the beginning tools right now. (find a way to do something? please share this community needs it!)
Added: dirtycow, applypatch, app_process64, run-as and cowroot (run-as and cowroot don't work, even if cowroot worked it would crash in 20 seconds)
https://mega.nz/#F!wQVggApJ!Zv5wojVW5kiFi2crDDu02g
****************************************************************************************************************************************
Warning: The Note 5 is cool in a way to hack because most things you do will be undone when you reboot. I've altered things in / and /system/bin multiple times without any lasting effects! If you do modify things concerning knox permanently she won't boot. If you install a priv-app twice to make it stop you can also crash the phone out when playing around with knox. (refering to my little trick, see my thread on it. You reinstall a system/priv-app using adb install -rtsd <apk-name-you-adb-pulled-from /system/priv-app/> <=== oddly allowed. On another note patching certain things with dirtycow in /data will cause a sudden reboot.
If you patch app_process64 your phone will go dark, things that are important stop working. I personally do not want my phone in this state for long so I plan out things to try then get out quickly. I have disabler going, but I am not experiencing any cause for concern such as overheating, mass battery draw or odd screen handling. besides it going darker with app_process
Super dangerous expensive game be sure you want to play the entry fee is high. And backup your data you may never see this phone working again.
Project stopped someone else can take over without giving credit. Please don't give credit I don't want my name on this The tools on my github will be left up and I will help you compile any idea but officially I don't need to downgrade, and I wanna buy a unlocked phone
I designed a tool for the purpose of downgrading that I won't have time to test completely, but does work. It allows you to pull every partition from your device that you can see and also write those same partitions back!! This does include BOTA0, BOTA1, BOOT, RECOVERY, SYSTEM. you name it!!
back soon guys, be careful with it.. pulling seems safest if you are new, yeah? have fun!
https://github.com/droidvoider/Android_6.01__DD_Dcow
N920C ?