Database Users

Can't update to 4.1.1. Please Help!!!

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.

[Q] status 7 error when trying to update to 4.4.2 from 4.4 SOLVED

Hey all. I am getting an error when trying to sideload the update. I was having trouble with my drivers for a while, and just now got around to fixing them, so I thought that I would update, since I have TWRP, and the OTA obviously doesn't install with that. So anyway, here I am, using the Nexus Root Toolkit to sideload, and everything went well. Until the Nexus was verifying the current systen. Here is the error:
"EMC:/dev/block/platform/sdkci-tegra.3/by-name/LNX:5109760:c804e149ffe2595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35" has unexpected contents.
E:Error in /tmp/update.zip
(status 7)
Installization aborted.
Any help would be great. Thanks

LNX is the boot partition.
You could experience that problem if you
- installed a custom kernel
- modifed your ramdisk (and then repacked the boot image)
- anything else that would alter a single byte in the boot image
the solution is to re-install the stock boot image.
The OTA will probably affect your ROM root (usually by changing the setuid permissions on the "su" binary), so be prepared to resolve that.
In general, OTAs are not intended for updating modified devices.

bftb0 said:
LNX is the boot partition.
You could experience that problem if you
- installed a custom kernel
<b>- modifed your ramdisk (and then repacked the boot image)</b>
- anything else that would alter a single byte in the boot image
the solution is to re-install the stock boot image.
...
In general, OTAs are not intended for updating modified devices.
Click to expand...
Click to collapse
Thanks. I forgot to mention that I am just unlocked and rooted running stock. The only thing that is different is that I have MultiRom installed also. I imagine that is what the issue is. I was thinking of trying out the official CM11, but I didn't want that as my primary. Is there a way to leave MultiRom installed and still update?

jma9454 said:
Is there a way to leave MultiRom installed and still update?
Click to expand...
Click to collapse
Sure. You can always unpack the OTA zip file, remove the parts you don't like ( in the command script META-INF/com/google/android/updater-script ), zip the whole shebang back up and flash it. Neither of the custom recoveries seem to give a $hit whether or not the .zips are signed.
Probably a good idea to make a nandroid backup before you begin.
good luck

bftb0 said:
Sure. You can always unpack the OTA zip file, remove the parts you don't like ( in the command script META-INF/com/google/android/updater-script ), zip the whole shebang back up and flash it. Neither of the custom recoveries seem to give a $hit whether or not the .zips are signed.
Probably a good idea to make a nandroid backup before you begin.
good luck
Click to expand...
Click to collapse
so can I take out this whole part?
apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35") || abort("\"EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35\" has unexpected contents.");
set_progress(1.000000);
(Just to let you know, this comes from almost exactly halfway into the updater-script)
thanks for your help

jma9454 said:
so can I take out this whole part?
apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35") || abort("\"EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35\" has unexpected contents.");
set_progress(1.000000);
(Just to let you know, this comes from almost exactly halfway into the updater-script)
thanks for your help
Click to expand...
Click to collapse
There are TWO such lines. (First, the check and then later on the actual patching operation)
The OTAs always run through 100% of the checks before a single file is modified. If a single check fails, the OTA stops immediately ... without anything being touched. It has been the convention in OTAs that the very last thing to be checked is the boot image (if it is getting updated)... that's why you are finding that apply_patch_check() about halfway through the file; you will notice that the actual patching of files starts shortly after that, and each file is patched in series in the same order that they were checked.
So, towards the very end of the file you will find the matching patch operation of the LNX (boot) partition; you should remove that line as well because that patching operation will cetainly not produce correct results. (And the boot partition is kinda important, no?)
To anybody else besides the OP who is reading this: for arbitrarily modified ROMs, this approach is not recommended (trying to take only PART of an OTA) as there may be components in an OTA update which are interdependant across multiple files. For an OTA that fails only due to a single modified file, it might be acceptable - but you accept all the risks of fooling with things this way.
EVERYONE should take a Nandroid backup before attempting such mods.

bftb0 said:
There are TWO such lines. (First, the check and then later on the actual patching operation)
The OTAs always run through 100% of the checks before a single file is modified. If a single check fails, the OTA stops immediately ... without anything being touched. It has been the convention in OTAs that the very last thing to be checked is the boot image (if it is getting updated)... that's why you are finding that apply_patch_check() about halfway through the file; you will notice that the actual patching of files starts shortly after that, and each file is patched in series in the same order that they were checked.
So, towards the very end of the file you will find the matching patch operation of the LNX (boot) partition; you should remove that line as well because that patching operation will cetainly not produce correct results. (And the boot partition is kinda important, no?)
...
Click to expand...
Click to collapse
so do I remove this whole part or just everything until the delete script?
ui_print("Patching boot image...");
apply_patch("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35",
"-", 40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35, 5111808,
c804e149ffe3595235595a35a25096d53e1c5ea2, package_extract_file("patch/boot.img.p"));
set_progress(0.999993);
delete("/system/recovery-from-boot.p",
"/system/etc/install-recovery.sh");

Well, I just read your sig
That file is an extremely simple programming language (barely even that as it has no loops, conditionals or jumps). It just executes each "line" in turn one after another unless there is an error; and in that case it just stops.
Like most programming languages, things like balanced parentheses and line termination characters (e.g. semicolons) are significant.
So have a hard look at those lines above, make a decision about what you think is correct... and move forward knowing that if you make a mistake you will have a Nandroid backup waiting to put you back where you were. (To be super sure of that, get a copy of it off your tablet before you start flashing.)
If that makes you uncomfortable, then don't do anything. From here on out, *you* are in charge.
good luck.

Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.

I have same issue. After returning to stock 4.4.2 I had difficulties in rooting. Good thing that I managed to install CMW (using Wug's toolkit) and flash a SU to root my device (I searched in help forum).
After having stock 4.4.2, rooted (tested and verified by deleting system APK) and custom recovery, I cannot flash a custom ROM. Let us know if someone can actually solve this!
jma9454 said:
Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.
Click to expand...
Click to collapse

* As per link below, TWRP will skip the below asset check (resulting to status 7 error).
* Using Wug's Tool, restore tablet to stock 4.4.2
* I found out that file in "D:\nexus7\data\Recovery_Custom\TWRP" is less than 7.58 MB. So I downloaded TWRP manually in below link. Save this in same location and install TWRP using Wug's tool. You can root as well at the same time (I forgot this step)
* Copy the ROM & GAPPS in tablet and rebooted to TWRP (using Wug's tool).
* Wipe option in TWRP
* Install ROM successfully , then install GAPPS
* Since I forgot to root, TWRP option asked to root my device... I selected root.
Finished...
asset check link: http://highonandroid.com/android-rom...ooted-android/
TWRP link: http://techerrata.com/browse/twrp2/grouper
Wug's Tool: http://forum.xda-developers.com/showthread.php?t=1766475
austin_dreq said:
I have same issue. After returning to stock 4.4.2 I had difficulties in rooting. Good thing that I managed to install CMW (using Wug's toolkit) and flash a SU to root my device (I searched in help forum).
After having stock 4.4.2, rooted (tested and verified by deleting system APK) and custom recovery, I cannot flash a custom ROM. Let us know if someone can actually solve this!
Click to expand...
Click to collapse

jma9454 said:
Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.
Click to expand...
Click to collapse
Good job man.
These lines in the updater-script
Code:
set_metadata_recursive("/system/bin", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata_recursive("/system/xbin", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
are what cause the loss of root.
The "su" binary is still present in the ROM ... but the *recursive* (all files underneath the directory given) change of permissions alters the "setuid" nature of the "su" binary so it no longer runs with root identity. (depending on which version of root kit you have, the "su" binary could be in either /system/bin or /system/xbin)
note there is also a non-recursive version of "set_metadata" for dealing with individual files.
You can't just delete the recursive call as it manipulates lots of files other than the one you are trying to protect ("su").
But *after* that recursive mode-setting is done, you could certainly add an instance of set_metadata on the su binary in order to restore the ownership and file modes that the su binary needs to work correctly.
And then you would have - ta-da! - your own customized version of the OTA that skips the stuff that cause failures, and doesn't stomp on root.
Figuring out the correct selinux syntax is left as an exercise for the reader.

[ROOT]Lenovo Vibe Z (K910)

This is a build at a really early stage so take care !
Ok, so the method I propose is absolutely non intrusive. You might want to flash the recovery you'll find here-under but I personally haven't done it so feel free to go first Flashing back the original recovery shouldn't be a big deal anyway.
Prerequisite
You should have installed:
K910 ADB Driver (available on the CD that appear when you connect the device)
ADB
Fastboot
Rooting
So the method is pretty easy:
Download the latest SuperSU update.zip and put it at the root of your Internal SD Card
(Optional) Download Google Apps for Android 4.2.2 (thanks to TeamAndroid) and put it at the root of your Internal SD Card
Download the recovery.img (build 140205)
un-7zip it
Restart your device in the bootloader:
Code:
adb reboot-bootloader
Boot your phone into the ClockworkMod recovery:
Code:
fastboot boot cwm_recovery_custom.img
Install zip, wipe partition, backup/restore, adb sideload, ...
Reboot
The phone is left untouched except for the zip you flashed.
Update on the 6th of February (Build 140205):
Bigger font
/sdcard mounted on the first user's internal storage (= symlink /sdcard /data/media/0)
Makes use of the latest kernel
The old recovery.img stays available.
For those who would be stuck on K910_SS_S_2_040_0039_131101, I posted the official update.zip here
How to build my own recovery
If you are curious about building the recovery, I'll post here a few tips.
First of all, you'll need a good tutorial like the one on XDA University. The steps are the following:
Prepare your OS to receive a cyanogenmod repository. I would advice an Ubuntu so you can following this guide. Note that this is for a plain Android so you need to stop following it when they issue the first repo command
Then you need to carefully read this guide on porting CyanogenMod ROM. You don't need to build the full system (which is a completely other story) but only the recovery. I prepared the vendor directory for you (base on LG Optimus and a lot of research).
The building happens according to this guide.
You could be done by now if it wasn't for the dtb. If you try to boot your recovery as is, fastboot will complain about it. You'll find other people having the same issue, just follow their solution.

csu333 said:
This is a build at a really early stage so take care !
Ok, so the method I propose is absolutely non intrusive. You might want to flash the recovery you'll find here-under but I personally haven't done it so feel free to go first Flashing back the original recovery shouldn't be a big deal anyway.
So the method is pretty easy:
Download the recovery.img
un-7zip it
Restart your device in the bootloader:
Code:
adb reboot-bootloader
Boot your phone into the ClockworkMod recovery:
Code:
fastboot boot recovery-clockwork-6.0.4.6-kiton.img
Install zip, wipe partition, backup/restore, adb sideload, ...
Reboot
The phone is left untouched except for the zip you flashed.
More precisions to come in a next edit.
Click to expand...
Click to collapse
Yess!!! Thanks!!!

creating boot image...
creating boot image - 4493312 bytes
downloading 'boot.img'...
OKAY [ 0.142s]
booting...
FAILED (remote: dtb not found)
finished. total time: 0.155s
What rom version did you have when boot .img?
cwm (loki) .img from lg g2 says ok afterall, but phone restarts after showing me a nice blue line .
take a look https://gitlab.com/itsmikeramsay/mkbootimg/tree/master and this http://looollll.doorblog.jp/archives/29337755.html and this http://forum.xda-developers.com/showthread.php?t=2469510
I believe this really may be helpful to you http://forum.xda-developers.com/showthread.php?t=2073775

katalinscrob said:
creating boot image...
creating boot image - 4493312 bytes
downloading 'boot.img'...
OKAY [ 0.142s]
booting...
FAILED (remote: dtb not found)
finished. total time: 0.155s
QUOTE]
Same result for me too.
Click to expand...
Click to collapse

katalinscrob said:
creating boot image...
creating boot image - 4493312 bytes
downloading 'boot.img'...
OKAY [ 0.142s]
booting...
FAILED (remote: dtb not found)
finished. total time: 0.155s
What rom version did you have when boot .img?
cwm (loki) .img from lg g2 says ok afterall, but phone restarts after showing me a nice blue line .
take a look https://gitlab.com/itsmikeramsay/mkbootimg/tree/master and this http://looollll.doorblog.jp/archives/29337755.html and this http://forum.xda-developers.com/showthread.php?t=2469510
I believe this really may be helpful to you http://forum.xda-developers.com/showthread.php?t=2073775
Click to expand...
Click to collapse
I have K910_SS_S_2_040_0109_131226 but it shouldn't be an issue anyway. This sounds like I uploaded the wrong recovery (I have so many) because "dtb not found" is the message you receive when, well, the DTB doesn't appear in the recovery. Adding the DTB is the very last step to build the recovery.
Try this one instead.
Just for your information, note that following the guide I mentioned earlier did work but I have to add a custom init.rc because there was no backlight on the screen.

csu333 said:
I have K910_SS_S_2_040_0109_131226 but it shouldn't be an issue anyway. This sounds like I uploaded the wrong recovery (I have so many) because "dtb not found" is the message you receive when, well, the DTB doesn't appear in the recovery. Adding the DTB is the very last step to build the recovery.
Try this one instead.
Just for your information, note that following the guide I mentioned earlier did work but I have to add a custom init.rc because there was no backlight on the screen.
Click to expand...
Click to collapse
Other possible root???
http://lenovobbs.cnmo.com/thread-14620407-1-1.html

sakilxda said:
Other possible root???
http://lenovobbs.cnmo.com/thread-14620407-1-1.html
Click to expand...
Click to collapse
I honestly doubt it: all the 1 click root I've seen until know are based on a bug in the backup mechanism that have been fixed for a while now. But since it seems pretty recent, anything is possible. I can't confirm since I'm rooted now

Right now with this method, and when I get my Lenovo steps that I can do?
Update first and then use this method to root?
I do not understand English, use google translate, and as I see there seems to be no problems?
Still it take at least 2 weeks to receive it and I'm sure there will be changes and improvements ...
Thanks again for sharing your experiences.

Big thanks button should be available too...
Managed to boot in cwm, root from cwm (btw very nice option ), Gapps full reinstall and finally a backup. EVRIKA! YOU DID IT ! Respect man ! permanent img flash would be next step I assume...

sakilxda said:
Right now with this method, and when I get my Lenovo steps that I can do?
Update first and then use this method to root?
I do not understand English, use google translate, and as I see there seems to be no problems?
Still it take at least 2 weeks to receive it and I'm sure there will be changes and improvements ...
Thanks again for sharing your experiences.
Click to expand...
Click to collapse
You're right: best method is to upgrade then root with this method. If it seems difficult to get the upgrades, I can post the zip files (it took me more than a week to get the first one).

katalinscrob said:
Big thanks button should be available too...
Managed to boot in cwm, root from cwm (btw very nice option ), Gapps full reinstall and finally a backup. EVRIKA! YOU DID IT ! Respect man ! permanent img flash would be next step I assume...
Click to expand...
Click to collapse
You're very welcome
Well, actually, there should be no problem flashing this recovery, it's just that it could break the OTA process (and that I haven't tested it myself yet)
So next step after testing is to find a way to make this menu readable. I mean, I almost need a magnifying glass to read it :laugh:

It isn't really an issue, maybe to correct the dafult push backup folder to internal sdcard clockworkmod instead of root folder (mnt...). I suppose that until seriously modded ROM's will appear it's best to mantain non flashed anyway for the OTA capability IMHO. Anyway, very nice job, put a paypal to receive some beers from us.

I still cannot install zips (SuperSU / gapps) from recovery, though recovery.img was flashed without any error. Am I missing anything?

Hello friends, you have seen this guide?
http://lenovo-forums.ru/topic/4131-...-lenovo-vibe-z-k910-пока-только-wcdma-версия/

sakilxda said:
Hello friends, you have seen this guide?
http://lenovo-forums.ru/topic/4131-...-lenovo-vibe-z-k910-пока-только-wcdma-версия/
Click to expand...
Click to collapse
It is based on csu333's work. I linked thid thread to russian fellows.

katalinscrob said:
It is based on csu333's work. I linked thid thread to russian fellows.
Click to expand...
Click to collapse
Ok, just thought it was a copy

nlohani said:
I still cannot install zips (SuperSU / gapps) from recovery, though recovery.img was flashed without any error. Am I missing anything?
Click to expand...
Click to collapse
Are you sure you are in the custom recovery? The Lenovo one look similar but doesn't have the clockwork mod logo in the background. It lets you install zip...as long as they are signed by Lenovo.

csu333 said:
Are you sure you are in the custom recovery? The Lenovo one look similar but doesn't have the clockwork mod logo in the background. It lets you install zip...as long as they are signed by Lenovo.
Click to expand...
Click to collapse
You are right, after re-flashing your recovery I was able to install SuperSU.zip, but still couldn't find it in the device.
Just to share further-
1. Titanium backup still fails to get root access
2. One root checker application says my device is rooted, but 'rescue root checker' says it is not

katalinscrob said:
It isn't really an issue, maybe to correct the dafult push backup folder to internal sdcard clockworkmod instead of root folder (mnt...). I suppose that until seriously modded ROM's will appear it's best to mantain non flashed anyway for the OTA capability IMHO. Anyway, very nice job, put a paypal to receive some beers from us.
Click to expand...
Click to collapse
Good suggestions. I'll take a look.
Now that I know what it takes to build a recovery, I'll think twice before starting a project of a really modded ROM

nlohani said:
You are right, after re-flashing your recovery I was able to install SuperSU.zip, but still couldn't find it in the device.
Just to share further-
1. Titanium backup still fails to get root access
2. One root checker application says my device is rooted, but 'rescue root checker' says it is not
Click to expand...
Click to collapse
I 've had the same behavior with the oldest ROM. This is why I provided a custom ROM with busybox installed even if I knew most people wouldn't need it. It was just impossible to install it afterwards. It might then be version related. Which version are you running?

New tool!!! Forced downgrade of AT&T using Dirtycow exploit 5195

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 ?

Question about custom recoveries and bootloader relocking

Hello!
I have unlocked the bootloader of my Mate 10 lite and proceeded to flash TWRP and Magisk onto the device. But in doing so, I get an awful looking screen when I boot the device, so I thought I should relock the bootloader, now that TWRP has been flashed.
...I immediately regretted relocking the bootloader, as the system was inaccessible until I re-unlocked the bootloader and was able to access TWRP and the system again. So my question is, can you lock the bootloader with TWRP installed and still access the system?
Also, if I want to go back to full-stock, I have to download a stock ROM for the system from firmwarefinder and flash it with some tool, correct?

Tsun_Pooka said:
So my question is, can you lock the bootloader with TWRP installed and still access the system?
Click to expand...
Click to collapse
Unfortunately, it's impossible...
You can flash Stock ROM for the system from firmwarefinder (fullOTA-MF only!) using HwOTA, HuRupdater, Huawei Multi-tool (RUFI).
If You want to go back to full-stock with locked bootloader (not re-locked) , You have to flash Service ROM from dload (this process will erase all the data from your device!).

Tsun_Pooka said:
Hello!
I have unlocked the bootloader of my Mate 10 lite and proceeded to flash TWRP and Magisk onto the device. But in doing so, I get an awful looking screen when I boot the device, so I thought I should relock the bootloader, now that TWRP has been flashed.
...I immediately regretted relocking the bootloader, as the system was inaccessible until I re-unlocked the bootloader and was able to access TWRP and the system again. So my question is, can you lock the bootloader with TWRP installed and still access the system?
Also, if I want to go back to full-stock, I have to download a stock ROM for the system from firmwarefinder and flash it with some tool, correct?
Click to expand...
Click to collapse
How you unlock the bootloader?

bozka1 said:
Unfortunately, it's impossible... If You want to go back to full-stock with locked bootloader (not re-locked) , You have to flash Service ROM from dload (this process will erase all the data from your device!).
Click to expand...
Click to collapse
Thanks for the tips! By the way, what is dload? If it's a website, I cant find it (the fact that dload is short of "download" doesn't really help). I am now in need of that full-stock ROM.

Tsun_Pooka said:
By the way, what is dload?
Click to expand...
Click to collapse
https://forum.xda-developers.com/mate-10/help/formatting-dload-method-t3815949/page2

Whew. I got the bootloader AND FRP locked on me, and now I don't have a usable system. So now, I have to rely on eRecovery to download a 3GBs package and hope all things go well...the problem is, I'd need to find a place that offers fast WiFi...my internet is terrible.
EDIT: Got the system back up thanks to eRecovery. I'm not sure if I want to root or install a custom recovery on the Lite. I've realized even more that I should cherish my older phone, my Samsung Galaxy Win. At least this one isn't complicated or protected by Fort KNOX.

When u play with custom roms, u appreciate the customization/optimizations offered by developers, thanks to them. But with the time, u always feel stock ROM was best for this n that reasons. Recent 2/3 times I was able to use Huru Updater to get back to Stock ROM and it worked well (needs TWRP installed, and you may need to switch to other TWRP if u get error from existing)
You seem to be a beginner, so I would suggest to get help from some friends who can do it for you. Or obviously u can try ur self again and again, and learn good things until something finally works for u. You were able to relock bootloader so it means u have the code for ur device for locking/unlocking, save this code on at least 2 different places (email, google drive, dropbox etc.). Then u can easily unlock ur device again, and install Stock ROM etc.

usman400 said:
When u play with custom roms, u appreciate the customization/optimizations offered by developers, thanks to them. But with the time, u always feel stock ROM was best for this n that reasons. Recent 2/3 times I was able to use Huru Updater to get back to Stock ROM and it worked well (needs TWRP installed, and you may need to switch to other TWRP if u get error from existing)
You seem to be a beginner, so I would suggest to get help from some friends who can do it for you. Or obviously u can try ur self again and again, and learn good things until something finally works for u. You were able to relock bootloader so it means u have the code for ur device for locking/unlocking, save this code on at least 2 different places (email, google drive, dropbox etc.). Then u can easily unlock ur device again, and install Stock ROM etc.
Click to expand...
Click to collapse
Custom ROMs are the best thing to happen to the Galaxy Win, even if the available choices all have their compromises. But with the M10 lite, I think it's better to stick with stock and mod it. And I'm not exactly a beginner, but rooting the Galaxy Win and modifying it was no hard ordeal. Or the Galaxy Grand for that matter, which I changed its ROM entirely. The Mate 10 lite however, oh dear (wipes sweat).
I've got the system back up and re-fitted it with TWRP and installed Magisk. And yet, when I try backing up the data partition with TWRP, I meet a peculiar error. Excerpt from recovery.log:
Code:
I:addFile '/data/misc/bluedroid' including root: 1
==> set selinux context: u:object_r:bluetooth_data_file:s0
found policy '/data/misc/bluedroid' - '1DK' - '3c2755a577289547'
I:addFile '/data/misc/bluedroid/K+hpne9pCUEHa,R422fJJA' including root: 1
==> set selinux context: u:object_r:bluetooth_data_file:s0
I:Error adding file '/data/misc/bluedroid/K+hpne9pCUEHa,R422fJJA' to '/external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/data.f2fs.win000'
Error creating backup.
I:ERROR tarList for thread ID 0
Error creating backup.
I:InfoManager saving '/external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/data.info'
createTarFork() process ended with ERROR: 255
Backup Failed. Cleaning Backup Folder.
I:Copying file /tmp/recovery.log to /external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/recovery.log
I:Set page: 'action_complete'
I:operation_end - status=1
Searching on the internet, I found the solution was to delete the file that stops the operation from finishing. However, using MiXplorer with full root permissions, I...couldn't find the file...? There's only bt_config.bak, bt_config.conf and macbt. Nothing else. What the heck is up with all that?
I'd appreciate a solution to this.

Tsun_Pooka said:
Custom ROMs are the best thing to happen to the Galaxy Win, even if the available choices all have their compromises. But with the M10 lite, I think it's better to stick with stock and mod it. And I'm not exactly a beginner, but rooting the Galaxy Win and modifying it was no hard ordeal. Or the Galaxy Grand for that matter, which I changed its ROM entirely. The Mate 10 lite however, oh dear (wipes sweat).
I've got the system back up and re-fitted it with TWRP and installed Magisk. And yet, when I try backing up the data partition with TWRP, I meet a peculiar error. Excerpt from recovery.log:
Code:
I:addFile '/data/misc/bluedroid' including root: 1
==> set selinux context: u:object_r:bluetooth_data_file:s0
found policy '/data/misc/bluedroid' - '1DK' - '3c2755a577289547'
I:addFile '/data/misc/bluedroid/K+hpne9pCUEHa,R422fJJA' including root: 1
==> set selinux context: u:object_r:bluetooth_data_file:s0
I:Error adding file '/data/misc/bluedroid/K+hpne9pCUEHa,R422fJJA' to '/external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/data.f2fs.win000'
Error creating backup.
I:ERROR tarList for thread ID 0
Error creating backup.
I:InfoManager saving '/external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/data.info'
createTarFork() process ended with ERROR: 255
Backup Failed. Cleaning Backup Folder.
I:Copying file /tmp/recovery.log to /external_sd/TWRP/BACKUPS/FFY5T18328016218/2019-06-08--20-21-17/recovery.log
I:Set page: 'action_complete'
I:operation_end - status=1
Searching on the internet, I found the solution was to delete the file that stops the operation from finishing. However, using MiXplorer with full root permissions, I...couldn't find the file...? There's only bt_config.bak, bt_config.conf and macbt. Nothing else. What the heck is up with all that?
I'd appreciate a solution to this.
Click to expand...
Click to collapse
I am certainly not up to what u r indicating so cant suggest a solution, earlier in my reply, I was only
indicating my experience with custom ROMs. I havent yet come across a single custom ROM for mate 10
lite that has no problems. Earlier Galaxy S4 Mini, there was custom ROM which was awsome, not a single issue
But for mate 10 lite camera problem is most common. Stock camera app often doesnt work or partially
works, restart of the app etc. You can install open camera, but it does not give u best shots, and filters.
Other issues are already discussed in every custom ROM thread, so I had to come back to Stock ROM
with magisk to remove any system apps that I dont need plus other goodies that magisk offers u (modules)

Alright, so I am supposed to install 347, but I uhh...can't, because I don't think TWRP is able to do it. What am I supposed to do in order to carry out the update successfully?

Tsun_Pooka said:
Alright, so I am supposed to install 347, but I uhh...can't, because I don't think TWRP is able to do it. What am I supposed to do in order to carry out the update successfully?
Click to expand...
Click to collapse
Flash the stock erecovery whenever i root my phone i always stick with stock recovery not custom recovery(TWRP)
Theres another method to flash the stock recovery but... This is my method on how to flash stock recovery(erecovery)
PC ONLY!!! and MAKE SURE TO HAVE UNLOCKED BOOTLOADER AND FRP!!!
1.Download MultiTool from https://pro-teammt.ru/en/multi-tool-huawei-honor/
2.Make sure to install Huawei driver from the MultiTool
3.Download This File i provided Here https://mega.nz/#!nZxl2AwZ!6qRIIRbLK4Ub80dPMae4HQQ7e-O49_f2BZ8PhbuZTYM
4.Go to MultiTool and go to recovey Section an select file that you download earlier
5.Make sure to CONNECT USB CABLE TO YOR PC now Reboot your device into Bootloader mode by PRESSING VOLUME DOWN BUTTON and CONNECT THE CABLE TO YOUR PHONE
6.Now on the MultiTool click on Flash Recovery_Ramdisk andlet it flash...,
7.Now You Have The Stock Recovery Installed Now You Can Install Offical Firmware Update On Your Phone
8.All Done
I Hope I Help You

I will follow your guide later today or tomorrow! Thank you for the help!

Tsun_Pooka said:
I will follow your guide later today or tomorrow! Thank you for the help!
Click to expand...
Click to collapse
Np

LoneWolfz said:
Np
Click to expand...
Click to collapse
I just did your instructions today. All was going well up until installation of the new update. The first time, it rebooted when the progress bar was at 6%, then it rebooted again to the recovery, went up to 6% again before showing this screen:
Code:
Software install failed!
Failed to check the update files
Please download the package again
> Reboot system now
So I'm back to square one basically.
Also, I can't install updates to the built-in Huawei apps for some reason, even after flashing the stock recovery. I'm not sure what to do with both issues now...

Tsun_Pooka said:
I just did your instructions today. All was going well up until installation of the new update. The first time, it rebooted when the progress bar was at 6%, then it rebooted again to the recovery, went up to 6% again before showing this screen:
So I'm back to square one basically.
Also, I can't install updates to the built-in Huawei apps for some reason, even after flashing the stock recovery. I'm not sure what to do with both issues now...
Click to expand...
Click to collapse
Try to download the update again
Usually when i tried to install new update(100+Mb) i will ended up what the code said but downloading a Full Update(3.49Gb) Fixed the problem
Just refresh the update in setting and install it

bozka1 said:
Unfortunately, it's impossible...
You can flash Stock ROM for the system from firmwarefinder (fullOTA-MF only!) using HwOTA, HuRupdater, Huawei Multi-tool (RUFI).
If You want to go back to full-stock with locked bootloader (not re-locked) , You have to flash Service ROM from dload (this process will erase all the data from your device!).
Click to expand...
Click to collapse
But can you unlock the bootloader later on with the same code if you wanted or is this it?

Deathecho said:
But can you unlock the bootloader later on with the same code if you wanted or is this it?
Click to expand...
Click to collapse
Yes you can use the same unlock code again.

LoneWolfz said:
Try to download the update again
Usually when i tried to install new update(100+Mb) i will ended up what the code said but downloading a Full Update(3.49Gb) Fixed the problem
Just refresh the update in setting and install it
Click to expand...
Click to collapse
The full update actually installed. Thanks for the tip!
I just still can't update my built-in Huawei apps.

Tsun_Pooka said:
The full update actually installed. Thanks for the tip!
I just still can't update my built-in Huawei apps.
Click to expand...
Click to collapse
Np