Here:
问题原因分析：刷民间包（类似update.zip）仅仅是重写了data,cust,system等几个分区数据，都有个版本号
但是官方包（UPDATA.APP）包含了十三个分区的所有数据，刷的时候系统会检查并核对版本信息，通过则全部重写，否则就报错了，这就是问题的关键点。
所以刷官方包出现failed，必然是剩余那些分区的数据有冲突.
既然找到了原因关键点，各位回忆做过那些操作，改变了其他分区的数据，
我发现了一点，51rom工具箱还原imei号时，会重写第5,10,11分区信息，
2.2刷2.3之前大家知道用51ROM备份IMEI号，刷完后串号丢失，再还原
那么这5，10，11分区信息还是2.2的，所以UPDATA.APP升级时检查必然出错。
解决方法：
51rom工具箱还原2.3的IMEI数据，我会提供，稍等发链接
ps：10.img包含了IMEI号，为避免串号大量重复，所我发的是5.img和11.img,大家把自己备份10.img放进去，
然后再还原即可
此时各个分区就正常了，建议先刷4个step降2.2，然后就任意刷吧！
------------------
thanks.
original thread http://bbs.anzhi.com/thread-4821789-2-1.html
cause analysis: flashing customised package (such as update.zip) only rewrites data, cust, system partitions' data, and with version numbers.
but official package (UPDATE.APP) includes data for all 13 partitions, and during flashing the system checks and verifies version information. if pass then rewrites all, if not returns error. this is the key point of the problem.
thus if "failed" appears when flashing official package, it must be caused by conflicts in the other partitions.
since the root cause of the problem is identified, recall what operation you have done that changes those other partitions' data.
i realised one point, when restoring imei with 5irom toolbox, 5,10,11 partitions get rewritten.
everybody knows to back up imei before upgrading from 2.2 to 2.3. after flashing if imei gets nulled, try to restore.
but then the 5,10,11 partition infomation are still from 2.2, therefore when checked by UPDATE.APP during upgrading errors will be returned.
solution:
i shall later provide the link on how to restore imei data of 2.3 using 5irom toobox.
ps: 10.img includes imei, to avoid mass duplicate of the number, i shall provide 5.img and 11.img. you can put in your own backup of 10.img.
then every partition becomes normal. suggest to first flash the "4 step" to downgrade to 2.2, and then flash at will.
---------- Post added at 10:03 AM ---------- Previous post was at 09:57 AM ----------
after reading this article, does it mean that though i have done an imei backup when at 2.2, i need to do another imei backup for my current 2.3?
for the 3 files (5.img, 10.img & 11.img) created from the 5irom toolbox, only 10.img is with the critical imei info and stays the same for both 2.2 and 2.3, while 5.img & 11.img are different for 2.2 and 2.3..
is this understanding correct?
skipped said:
Here:
问题原因分析：刷民间包（类似update.zip）仅仅是重写了data,cust,system等几个分区数据，都有个版本号
但是官方包（UPDATA.APP）包含了十三个分区的所有数据，刷的时候系统会检查并核对版本信息，通过则全部重写，否则就报错了，这就是问题的关键点。
所以刷官方包出现failed，必然是剩余那些分区的数据有冲突.
既然找到了原因关键点，各位回忆做过那些操作，改变了其他分区的数据，
我发现了一点，51rom工具箱还原imei号时，会重写第5,10,11分区信息，
2.2刷2.3之前大家知道用51ROM备份IMEI号，刷完后串号丢失，再还原
那么这5，10，11分区信息还是2.2的，所以UPDATA.APP升级时检查必然出错。
解决方法：
51rom工具箱还原2.3的IMEI数据，我会提供，稍等发链接
ps：10.img包含了IMEI号，为避免串号大量重复，所我发的是5.img和11.img,大家把自己备份10.img放进去，
然后再还原即可
此时各个分区就正常了，建议先刷4个step降2.2，然后就任意刷吧！
------------------
thanks.
original thread http://bbs.anzhi.com/thread-4821789-2-1.html
Click to expand...
Click to collapse
brief translation:
==========================
Reason:
Custom ROMs (such as update.zip) only write data to /data、 /cust、 /system partitions, but official ROM (UPDATE.APP) take care of all 13 partitions. So when flashing official ROM, it will check and verify version information, if passed then flash, otherwise it will report failure, that's the key point.
Now please think about what you've did, maybe some operations changed data of other partitions.
I found that when 51RomToolBox restore IMEI information, it will write partition 5、10、11, so if you backup IMEI before flashing Android 2.3, then restore it back after you flashed Android 2.3, then, the "version" of partition 5、10、11 are still Android 2.2, so UPDATE.APP checking result must be failed.
Solution:
I'll provide IMEI partition data for restore to Android 2.3 version later (then you can flash it back before downgrading).
ps: 10.img contains IMEI, so to avoid duplicated IMEI, i only provide 5.img and 11.img, you can restore your backup of partition 10 (of Android 2.3. Only applied if you've backup before, if not, oops...)
Now the partitions are normal, I suggest you downgrade to 2.2 using 4 steps (I don't know what he means, what 4 steps?), then you can flash other ROMs for free!
==========================
Words with italic font are added by me,
btw, the download link of IMEI data he provided
http://dl.dbank.com/c00ebw0atw
== Edit ==
oops, iamelton is quicker than me
Thank you very much both! A lot better than google haha.
i just did a quick hash check on my 2.2 & 2.3 imei backups..
turned out that all 5.img, 10.img & 11.img files have different hashes in 2.2 & 2.3 backups..
so im confused now.. why did the article suggested to use 10.img from 2.2 backup to mix with 5.img & 11.img from 2.3 backup?
can they be used in mixed mode?
[edit]
i think lovetide got this correct..
the orginal article didnt mention what version the 10.img should be used, and lovetide judged the author meant backup from 2.3, and this seems to be the logical explanation of my doubt..
but then, why would i wanna restore the imei backup for 2.3 before downgrading to 2.2?
cant i just downgrade to 2.2 first, and then restore imei with my imei backup for 2.2?
(that is to say, not everybody realises that imei backup is associated with base android versions..
after backing up imei at 2.2, i might not do another backup at 2.3..
then i cannot follow the article's method..)
Related
Hi, I haven't been lazy I have searched for ages, & Unless I missed it I haven't found information on the misc1-2.img file that has to be flashed, I'm curious as to what it is and what it actually does. I know during the rooting process it replaces the original misc file, some guides I have read tell you to backup the original misc file then reflash it back, other guides don't even mention backup and reflash.
I did backup my misc file but I didn't flash back the backup. My phone is rooted and doesn't seam to have any problems.
any Info would be great, thanks
I think this file allows HBOOT downgrade.
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
hi all, as people are posting tutorial to downgrade from pie to oreo with the help of restoring boot and efs folder uploaded by them,, is it safe to restore from someone's else twrp backup i mean efs folder??
as per my knowledge efs is backup of imei right?
so restoring from someone's else efs won't affect mine imei?
No help here?
??????????????????????????????/
i don't think so people are helpful here or either not expert as nobody is replying lol
No idea. Sorry
taran181 said:
hi all, as people are posting tutorial to downgrade from pie to oreo with the help of restoring boot and efs folder uploaded by them,, is it safe to restore from someone's else twrp backup i mean efs folder??
as per my knowledge efs is backup of imei right?
so restoring from someone's else efs won't affect mine imei?
Click to expand...
Click to collapse
4-6 months back there was thread why we should not restore efs of someone & proper tutorial for people who messed up their mac address with some kernel.
Now this tutorial on downgrading pie to oreo. I have no idea. Someone's efs would mess your IMEI, wifi mac, Bluetooth mac, thats what i think. But there are tutorial how to edit imei using some Qualcomm tool.
Ask @CosmicDan. He's the expert.
Just flash Oreo on fastboot, with full wipe. Why doesn't that work?
I was having an issue since using custom rom with december fw btw.
and I was mistaken flashing november fw back to solve some calling issue, so I ended up with no signal which should be came from I didn't restore dev's efs backup.
So I start from flashing full clean stock november and ended with bootloop on it, which is something I still curious what cause it.
At that times, I'm on locked bootloader and can't even enter edl to reflash the rom and can't unlock bootloader since the rom still not booting to enable oem unlocking option.
I don't remember what I have done to it, but at times my phone can boot with no signal, 0 imei on sim1 and null on sim2.
So I start to rewrite the imei then everything is back to normal.
Downgraded using the method of restoring boot and efs... Nothing changed for me, imei is the same as in the box of my mi a1. ? Maybe people did something before doing the downgrade that messed up something.
CosmicDan said:
Just flash Oreo on fastboot, with full wipe. Why doesn't that work?
Click to expand...
Click to collapse
@CosmicDan no flashing just oreo doesn't help, phone gets stuck in bootloop, so people has posted tutorial about flashing their efs and boot etc through twrp to get out of bootloop.
Eg: https://forum.xda-developers.com/mi-a1/how-to/tutorial-downgrade-9-0-to-8-1-edl-imei-t3879624
fhsd22 said:
Downgraded using the method of restoring boot and efs... Nothing changed for me, imei is the same as in the box of my mi a1. ? Maybe people did something before doing the downgrade that messed up something.
Click to expand...
Click to collapse
but my question why use someone's else efs while downgrading, as efs contains imei and modem backup ..
taran181 said:
@CosmicDan no flashing just oreo doesn't help, phone gets stuck in bootloop, so people has posted tutorial about flashing their efs and boot etc through twrp to get out of bootloop.
Eg: https://forum.xda-developers.com/mi-a1/how-to/tutorial-downgrade-9-0-to-8-1-edl-imei-t3879624
Click to expand...
Click to collapse
Well you can try it I guess, just backup the EFS partition and other stuff with my backup tool and you can always go back if worse comes to worst.
CosmicDan said:
Just flash Oreo on fastboot, with full wipe. Why doesn't that work?
Click to expand...
Click to collapse
Xiaomi put out a message on their forum that after the Pie update, the phone should not be rolled back. Its for all Android one models. When users flash an older roms, bootloops occur.
https://www.fonearena.com/blog/271177/xiaomi-pie-oreo-downgrading-disabled-android-one-devices.html
taran181 said:
but my question why use someone's else efs while downgrading, as efs contains imei and modem backup ..
Click to expand...
Click to collapse
But what he is saying is that he did downgrade EFS, but IMEI didn't change. This suggests that EFS isn't the original source of IMEI after all. Or maybe the bootloader can re-write IMEI and stuff on boot, who knows... Surely others have actually confirmed that EFS cross-flash = IMEI change, right? Not just assumed?
...point is, you can backup your EFS via EDL mode so there should be no risk. If you made a full EDL backup of your own device when you were still on Oreo then you would be golden, as EDL has full access to all partitions.
So now that my phone is recovered I've discovered that its only reading up to 16gb of internal storage. I have a backup of my phone before it was bricked made in twrp and want to know if I can restore that as it was made of an october patch fw and now my phone runs a december patch. Also, will this backup be corrupted or incorrect in any way because I didn't allow system modifications before creating it?
Second, can anyone drop a foolproof rooting guide for Sm-G950FD that does not result in the official binary nightmare or any other bricking horsecrap?
Unbrick-me said:
So now that my phone is recovered I've discovered that its only reading up to 16gb of internal storage. I have a backup of my phone before it was bricked made in twrp and want to know if I can restore that as it was made of an october patch fw and now my phone runs a december patch. Also, will this backup be corrupted or incorrect in any way because I didn't allow system modifications before creating it?
Second, can anyone drop a foolproof rooting guide for Sm-G950FD that does not result in the official binary nightmare or any other bricking horsecrap?
Click to expand...
Click to collapse
If it's showing incorrect storage you will need to flash stock again, you need to use the CSC file not home-csc. The pit file to repartition the device is inside the CSC file. You will need to wipe data also. As for your backup did you backup all partitions or only data? I don't use twrp backups because for some reason after restoring I always run into issues. Hope this helps in some way :good:
Unbrick-me said:
So now that my phone is recovered I've discovered that its only reading up to 16gb of internal storage. I have a backup of my phone before it was bricked made in twrp and want to know if I can restore that as it was made of an october patch fw and now my phone runs a december patch. Also, will this backup be corrupted or incorrect in any way because I didn't allow system modifications before creating it?
Second, can anyone drop a foolproof rooting guide for Sm-G950FD that does not result in the official binary nightmare or any other bricking horsecrap?
Click to expand...
Click to collapse
Some say as simple as a factory reset can fix it but if not for sure what previous poster stated
callumbr1 said:
If it's showing incorrect storage you will need to flash stock again, you need to use the CSC file not home-csc. The pit file to repartition the device is inside the CSC file. You will need to wipe data also. As for your backup did you backup all partitions or only data? I don't use twrp backups because for some reason after restoring I always run into issues. Hope this helps in some way :good:
Click to expand...
Click to collapse
Yes I did backup all partitions, I backed up every option there was, which leads me to a new question. I've read up on TWRP's site https://twrp.me/faq/whattobackup.html that restoring the extra partitions carelessly could result in a brick. Is it safe to take these partitions out of the backup folder and restore everything else? I think it might end up causing issues or something since that would change the hash, hopefully I'm wrong about that tho.
Hello! I've rooted my phone today successfully without ending up in the official binary hell. I did this by following normal S8 rooting procedures but I allowed system modifications everytime TWRP booted and I flashed rmm state bypass mesa, no verity and the latest magisk. In that order. In addition, the required wiping of my device before rooting seemingly fixed my storage issue! Hooray!
Unbrick-me said:
Hello! I've rooted my phone today successfully without ending up in the official binary hell. I did this by following normal S8 rooting procedures but I allowed system modifications everytime TWRP booted and I flashed rmm state bypass mesa, no verity and the latest magisk. In that order. In addition, the required wiping of my device before rooting seemingly fixed my storage issue! Hooray!
Click to expand...
Click to collapse
Hello, that's great news glad it's all sorted for you! Happens often with the storage partition. As for the rmm, you should only have to flash the rmm zip once only then it should work every time.
Hi
I am new to this forum and flashing android devices. Today i just managed to root my T-580 using newest TWRP and Magisk versions. The root-checker says its rooted, SafetyNet passes so eveything seems to be OK.
Before flashing any custom ROM i wanted to backup IMEI and NVRAM but without success.
I have tried different approaches:
1. minimal adb and fastboot - after entering commands i get illegal number of block size
2. platform tools - gives me no such file or directory mesage
3. mtkdroid root tools - device info is not read and backup is grayed out. what is strange that the available free space is succesfully read but not any other info.
Check the attachments for the screenshots.
Could anybody help me how can i backup IMEI and NVRAM data? Without this step i cannot proceed in flashing custom ROM.
Thank you
EDIT: is backing up EFS in TWRP the same procedure as backing up IMEI-NVRAM? so it might be enough to backup EFS to secure IMEI-NVRAM?