Hi, Guest! Login / Register
Giveaway: Free Hovatek T-shirts, Hoodies & Cufflinks.. I WANT ONE! (Nov 25, 2017)
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

After flashing repacked system.img phone gets stock on boot, or in inicialization

#31

Hello, I always thought that reading (backup) with Miracle Box 2.27A generated a system.img that was a faithful copy of the official stock system.img, but no, it is not a faithful copy. And it is not because the read is the official with root, because the only differences between both are the modifications made to the installation of root (King Root) plus the installation of the BusyBox, and mora tnah those differences are seen with Beyond Compare. 

So, I do not see this differences as cause and justification for the unpack-repack to fail using system.img from Miracle Read. Anyway, the thing is that as I said, the first tool I tried was this one that you just recommended me today “Auto Tool Unpack Repack .DAT & .IMG V3”, I think u recommended it for the same reason I have used it at first, for being a very complete & proffesional tool. On that occasion I used it, I did the unpack-rapack on a rooted system.img of my cell phone, read with the Miracle Box, and it failed, and I did not try with the unrouted official stock system.img. Subsequently I continued testing with numerous tools, in wich case, with some of them, I dediced to try with the unrouted officcial stock system.img, but the result was that repacked system.img dd not work well neither. In that case, it is possibly it was the tool that fails to do the process well, whatever system.img were used. This completely diverted the attention from me of the type of system.img used as possible cause of the problem, until this test that I just did today, where finally I could unpack-repack system.img with good results, it means, repacked system.img work satisfactorily, but it happened working over stock official, not same way working over system.img obtained with Miracle Read, again. Twice I did the unpack-repack with the system.img obtained with Miracle Read, twice the repacked system.img failed.
 
An important piece of information, sytem img repacked from Miracle Read, reaches the 3rd Screen initialization, where there is a bootanimation, whose sound does not occur, only the animation. This has been a constant with all the tools I probed, whose repacked system.img reached the 3rd screen, after being flashed, whether it was a system.img repacked from the official or from the Miracle Read, bootanimation sounds dessapear, and phone get stuck on that screen, except I repite, in the probe made today, with good results with repacked system.img from stock offiicial. The conclusion I got, it is not recommended make unpack-repack with system.img obtainded by boxes reading.
 
Anyway, I will do more tests with this tool to see if the result is consistent and even with some of the tools which best result I obtained in the past, to verufy if in some of them I did not made the process with the official system.img, and this may have been the cause of the failure.
 
I will investigate further the differences (I have already seen some) between official stock system.img and system.img read with Miracle Box.
 
Concluding, today I have achieved a very important step in my purposes, and I thank you immensely for what your help meant to get to this point.


Reply
#32
(05-18-2017, 09:26 PM)amaury1967 Wrote: Hello, I always thought that reading (backup) with Miracle Box 2.27A generated a system.img that was a faithful copy of the official stock system.img, but no, it is not a faithful copy. And it is not because the read is the official with root, because the only differences between both are the modifications made to the installation of root (King Root) plus the installation of the BusyBox, and mora tnah those differences are seen with Beyond Compare. 

So, I do not see this differences as cause and justification for the unpack-repack to fail using system.img from Miracle Read. Anyway, the thing is that as I said, the first tool I tried was this one that you just recommended me today “Auto Tool Unpack Repack .DAT & .IMG V3”, I think u recommended it for the same reason I have used it at first, for being a very complete & proffesional tool. On that occasion I used it, I did the unpack-rapack on a rooted system.img of my cell phone, read with the Miracle Box, and it failed, and I did not try with the unrouted official stock system.img. Subsequently I continued testing with numerous tools, in wich case, with some of them, I dediced to try with the unrouted officcial stock system.img, but the result was that repacked system.img dd not work well neither. In that case, it is possibly it was the tool that fails to do the process well, whatever system.img were used. This completely diverted the attention from me of the type of system.img used as possible cause of the problem, until this test that I just did today, where finally I could unpack-repack system.img with good results, it means, repacked system.img work satisfactorily, but it happened working over stock official, not same way working over system.img obtained with Miracle Read, again. Twice I did the unpack-repack with the system.img obtained with Miracle Read, twice the repacked system.img failed.
 
An important piece of information, sytem img repacked from Miracle Read, reaches the 3rd Screen initialization, where there is a bootanimation, whose sound does not occur, only the animation. This has been a constant with all the tools I probed, whose repacked system.img reached the 3rd screen, after being flashed, whether it was a system.img repacked from the official or from the Miracle Read, bootanimation sounds dessapear, and phone get stuck on that screen, except I repite, in the probe made today, with good results with repacked system.img from stock offiicial. The conclusion I got, it is not recommended make unpack-repack with system.img obtainded by boxes reading.
 
Anyway, I will do more tests with this tool to see if the result is consistent and even with some of the tools which best result I obtained in the past, to verufy if in some of them I did not made the process with the official system.img, and this may have been the cause of the failure.
 
I will investigate further the differences (I have already seen some) between official stock system.img and system.img read with Miracle Box.
 
Concluding, today I have achieved a very important step in my purposes, and I thank you immensely for what your help meant to get to this point.

I've actually used a system.img dump from Miracle Box for Auto Tool unpack -repack and it worked fine. That was on an MTK Marshmallow , i'm currently on Marshmallow Spreadtrum. I'll try to repeat the steps on the MTK when next I have access to it just to double-check.
In the mean time, I'll keep working on this SPD and keep you posted
Need further assistance? Speak with a Hovatek Representative:
Working Hours: Mondays - Saturdays ; 09:00 - 18:00 (GMT +1:00)
Reply
#33
OK, thank you very much, yes, I already tried and the problem is not the reading with the Miracle Box as last night at home I flashed an Stock Rom Official, and without touching it, without doing anything else, I did a reading with Miracle Box 2.27A, and over this red system.img I did an uppack-repack with the Auto Tool V3 and everything went well, the repacked system.img worked perfectly. After that I went back to try to do an unpack-repack with my modified system.img (rooted with Kingo Root, installed BusyBox, mounted as writing and unmounted, TWRP itself allows doing this, etc, etc) and consistently repacked system.img fails again. Conclusion, the problem is, as you have highlighted, in the system.img used, no doubt, my system.img with the above mentioned modifications, fails to repackage properly, which I honestly do not know why.  I don´t think being rooted and with installed busybox was the problem, more posiibilities have the process of system mount and unmount, Or even some other case that may have changed without having noticed, for example something that is modified on the background. One question, unrouted bootloader may have to see something ?, I think not, but I would like to hear your opinion.
 
Then I will do a test to get out of doubt, I will flash an official system.img, I will root, and install the busybox, no more than that, and I will read it with the Miracle, and on that reading I will do an unpack-repack, and if all goes well, without a doubt, the problem will be in mount as writing and unmount, or other thing I don´t know.
 
I remark that there are undoubtedly tools that fail independently of the system.img I used, because what I can assure is that with some I worked with the official system.img stock, repack did not work either. Regrettably apparently when I first used the Auto Tool V3, I only worked with my modified system.img. However, I insist, I do not understand why the mentioned modifications of my system.img cause this failure when repacking, that is pending investigation.
 
Well, having a tool running consistently, this Auto Tool V3, my next step will be to try to do a porting with some CM 13, or even, I do not know that you opine to do it with some Android 6 or 7 of cellular with same chipset that the one on my cell phone, MT6580.
 
I hope that despite my error of having worked with my system.img that was at the end the cause of the problem, and that led to requesting your help, it has been worth for you as for me, all this research. I hope I did not waste your time. What if it has become clear to me that for any process of unpack-repack, and porting img must be from factory originals, the stock oficial files.
Reply
#34
Hello, reviewing in detail the writing I made, when exactly one month ago I tried this tool for the first time, I have remembered a doubt that arose at that time.
 
At the moment of repacking, this tool prompts you to enter the size in bytes of the system.img from which it starts, before unpacking. But if after unpacking, in the Porting process, one make modifications to the System Folder and its size grows extensively, the original size could stay below the new size acquired. So, what file size should be introduced in this case? ...
Reply
#35
Test done, I flashed the official stock system.img, I rooted the phone with Kingo root from Internet, and installed busybox, no more than that. Then I red system.img with the Miracle Box. Over this reading I did unpack-repack with Auto Tool V3, and the result was that the repacked system.img fails.
 
So without doubt, root the phone and install busybox invalidates the system.img to be unpacked-repacked. I think that more than the Busybox, is the Root process, which surely modifies properties of the system which invalidate it. Could be the root I use, maybe with another do not pass, but I'm afraid it would happen the same.
 
Have a great weekend
Reply
#36
(05-19-2017, 05:45 PM)amaury1967 Wrote: Test done, I flashed the official stock system.img, I rooted the phone with Kingo root from Internet, and installed busybox, no more than that. Then I red system.img with the Miracle Box. Over this reading I did unpack-repack with Auto Tool V3, and the result was that the repacked system.img fails.
 
So without doubt, root the phone and install busybox invalidates the system.img to be unpacked-repacked. I think that more than the Busybox, is the Root process, which surely modifies properties of the system which invalidate it. Could be the root I use, maybe with another do not pass, but I'm afraid it would happen the same.
 
Have a great weekend

This is exactly what I noticed. In my case, it was with deodexing the system apps. Anyway, its too early for me to say but its certain (as you've said) that /system modifications causes Auto Tool repacking to fail
Need further assistance? Speak with a Hovatek Representative:
Working Hours: Mondays - Saturdays ; 09:00 - 18:00 (GMT +1:00)
Reply
#37
Hi, here we are back from the weekend. A whole set of tests I did this weekend and the result was that of the 11 different tools I had downloaded, only four worked: the Auto Tool Unpack Repack .DAT & .IMG V2 Update y V3, the Tool Unpack Repack System.new.dat V1 y V2, the Android System Unpack Repack adithyan25, and finally, the powerful and very useful, ASSAYYED_KITCHEN_V1.82_STABLE. With the latter I made some of the modifications to System that it allows to do: install Root , Busybox, etc, and everything worked flawlessly. Of course, what we know, all the previous tools work well starting from a system.img of Stock ROM Official, if part of a custom system.img, just rooted and with busybox installed, like the one I had on my cellphone, the Tools fail, the same that happens to you deodexing the system apps, and it's something I do not know why happens, it´s something to investigate.
 
But for example, with Assayyed Kitchen I did root and installed busybox, only those two operations, flash back to cellphone, and everything was fine. But one detail, the root was not included in the system.img, but in the ZIP Flasheable there was a file system.img, but also a a supersu folder containing a supersu.zip file, and then in the Updater Script first system.img is flashed, and then, after that is when supersu is installed . Here is the Updater Script:
 
# AUTO GENERATED BY ASSAYYED KITCHEN
ui_print("INSTALLING Prueba Assayed + (Root y BusyBox) ROM STARTED");
ui_print("-- Preparing partitions");
package_extract_dir("META-INF/SCRIPTS", "/tmp");
ifelse(is_mounted("/system"), unmount("/system"));
ui_print("-- Flashing system image");
package_extract_file("system.img", "/dev/block/platform/mtk-msdc.0/by-name/system");
mount("ext4", "EMMC", "/dev/block/platform/mtk-msdc.0/by-name/system", "/system", "");
run_program("/system/xbin/busybox", "--install", "-s", "/system/xbin");
ui_print("-- Flashing kernel image");
package_extract_file("boot.img", "/tmp/boot.img");
set_metadata("/tmp/flash_kernel.sh", "uid", 0, "gid", 0, "mode", 0777);
run_program("/tmp/flash_kernel.sh");
ui_print("-- Rooting rom with supersu");
package_extract_dir("supersu", "/tmp/supersu");
run_program("/sbin/busybox", "unzip", "/tmp/supersu/supersu.zip", "META-INF/com/google/android/update-binary", "-d", "/tmp/supersu");
run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/supersu/supersu.zip");
ifelse(is_mounted("/system"), unmount("/system"));
ui_print("INSTALLING Prueba Assayed + (Root y BusyBox) ROM FINISHED");
 
Aftert that, I reopened the Assayyed Kitchen, executed new actions, and in the new Zip, there is again a system.img file plus a supersu folder, and the Updater Script is again identical to the previous one. That is, the new things I included in the system folder remain in system.img, but the root continious being installed separatelly. This is how they handle it in the Assayed Kitchen.
 
IMPORTANT:  It is a doubt I have already mentioned you before. The ASSAYYED_KITCHEN asks for the data of the size of the System folder, it never mentions of the file system.img, but also, it has option to look for that data in the cellphone, which I used, and what the tool obtained as data, was the TOTAL size of the cellphone System Partition. This is something in my doubts, about what size to give the tool after the contents of the System Folder have been manipulated, no longer through a tool like ASSAYYED_KITCHEN, if not through a Porting process, such as those described by some Tutorials on the Internet, the one I want to do with my cellphone, as I have told you before. Same question arises with the File_Contexts that these tools use, so after a Porting process, this file would no longer coincide with the contents of the System Partition, I think, and in this case what would happen?
 
Well, these are my final results on this topic. What I will dedicate next is to study how to port the Android 6 or 7 on my cellphone. I have already downloaded a group of tutorials on the subject, and I have realized that it is a complex and very detailed process, anyway, I will try, because as I said I have not been able to find a ROM, Official or Modified (Custom) with Android 6 or 7, for my cellphone. Wish me louck, ;o).
 
Thank you for all your valuable help. I wish you a great week.
Reply
#38
Hi, maybe this is not the right Thread, but the last one treated here is that after being able of unpackin / repacking system folder properly, I would devote myself to try to Port Android 6 or 7 to my phone, since there is no ROM availability with these operating systems on the Internet for my cell phone. 

Unfortunately after some attempts, I have not been successful with this.

Please, someone from this prestigious Forum could help me with this? Has anyone found a way to properly carry Android 6 or 7 for Alcatel Pop Star TCL 5022D ?. This cell phone has a processor MT6580, kernel 3.10.72, and Android 5.1 LolliPop. If needed more specifications I can give u them, but on the Internet there is where to know everything about this cell phone,wich  like many others, has been painfully left to the abandonment by its manufacturers.

Greetings and thanks in advance.
Reply
#39
(06-06-2017, 03:40 PM)amaury1967 Wrote: Hi, maybe this is not the right Thread, but the last one treated here is that after being able of unpackin / repacking system folder properly, I would devote myself to try to Port Android 6 or 7 to my phone, since there is no ROM availability with these operating systems on the Internet for my cell phone. 

Unfortunately after some attempts, I have not been successful with this.

Please, someone from this prestigious Forum could help me with this? Has anyone found a way to properly carry Android 6 or 7 for Alcatel Pop Star TCL 5022D ?. This cell phone has a processor MT6580, kernel 3.10.72, and Android 5.1 LolliPop. If needed more specifications I can give u them, but on the Internet there is where to know everything about this cell phone,wich  like many others, has been painfully left to the abandonment by its manufacturers.

Greetings and thanks in advance.

I think a new thread would be better

Sent from my Infinix X510 using Hovatek Forum
Reply










Users browsing this thread:
1 Guest(s)