Related
I currently have a rooted HD 7 with TWRP Loaded on the device. If I try to boot into the main OS, My device hangs at the Amazon logo. Is there any way to resture from the Kindle Update file available on the Amazon site, or can anyone help me out with an Image that I can recover from? Nothing I have tried so far has worked, so just looking for some insight/help with the issue
cskimbrell said:
I currently have a rooted HD 7 with TWRP Loaded on the device. If I try to boot into the main OS, My device hangs at the Amazon logo. Is there any way to resture from the Kindle Update file available on the Amazon site, or can anyone help me out with an Image that I can recover from? Nothing I have tried so far has worked, so just looking for some insight/help with the issue
Click to expand...
Click to collapse
What did you do to screw things up? build.prop again? The good thing is that I think it should be very fixable.
In any event, grab 4.5.3 :
https://kindle-fire-updates.s3.amazonaws.com/update-kindle-20.4.5.3_user_453011120.bin
If you know which file you screwed up, restore it in TWRP from the above bin (rename to zip, unpack). Replace the file you screwed up with the correct one.
2nd option is to give TWRP this 4.5.3 update zip, and then you can start from Kingroot, and all the fun
3rd option is to be more surgical, in which case you need to disable these 4 lines in updater-script, and delete /recovery in the update zip.
Important!!! if you are editing updater-script in Windows, make sure you are using something like Notepad++ and have your EOL set to Unix type (Edit/EOL conversion).
OK, edit this: 20-4.5.3/META-INF/com/google/android/updater-script
delete
package_extract_dir("recovery", "/system");
package_extract_file("boot.img", "/dev/block/platform/mtk-msdc.0/by-name/boot");
package_extract_file("images/lk.bin", "/dev/block/platform/mtk-msdc.0/by-name/UBOOT");
package_extract_file("images/tz.img", "/dev/block/platform/mtk-msdc.0/by-name/TEE1");
Re-zip, and give it to TWRP. Hopefully this will keep your unlocked bootloader, and TWRP. TWRP should give you an option to install "su", and you are in business.
bibikalka said:
What did you do to screw things up? build.prop again? The good thing is that I think it should be very fixable.
In any event, grab 4.5.3 :
https://kindle-fire-updates.s3.amazonaws.com/update-kindle-20.4.5.3_user_453011120.bin
If you know which file you screwed up, restore it in TWRP from the above bin (rename to zip, unpack). Replace the file you screwed up with the correct one.
2nd option is to give TWRP this 4.5.3 update zip, and then you can start from Kingroot, and all the fun
3rd option is to be more surgical, in which case you need to disable these 4 lines in updater-script, and delete /recovery in the update zip:
this file: 20-4.5.3/META-INF/com/google/android/updater-script
delete
package_extract_dir("recovery", "/system");
package_extract_file("boot.img", "/dev/block/platform/mtk-msdc.0/by-name/boot");
package_extract_file("images/lk.bin", "/dev/block/platform/mtk-msdc.0/by-name/UBOOT");
package_extract_file("images/tz.img", "/dev/block/platform/mtk-msdc.0/by-name/TEE1");
Re-zip, and give it to TWRP. Hopefully this will keep your unlocked bootloader, and TWRP. TWRP should give you an option to install "su", and you are in business.
Click to expand...
Click to collapse
Un-related, but thanks for this. Been looking for a way to restore things a bit without breaking everything
To make things easier, these are some more specific instructions. Download 20-4.5.3 update, unpack it. Replace the script in 20-4.5.3/META-INF/com/google/android/updater-script with my attachment. You can compare the original with my version in Notepad++ (install plugin "compare"), in Linux it's even more trivial.
In addition, delete the following directories/files :
20-4.5.3/recovery
20-4.5.3/images
20-4.5.3/system/priv-app/com.amazon.weather.apk
20-4.5.3/system/priv-app/moffice_6.0.1_default_en00105_multidex_195423.apk
20-4.5.3/system/priv-app/DeviceSoftwareOTA.apk
20-4.5.3/system/priv-app/com.amazon.geo.client.maps.apk
(could delete a few more apk's here to make room in /system )
Zip everything, making sure the paths are the same as in the original Amazon bin. Boot TWRP, and give it this zipped update. It should install in /system, while keeping /data intact. If there are problems, copy the log to SDCard, and post your questions here.
As long as we are not touching the key partitions (recovery, UBOOT, TEE1), things should be safe, and simple to recover in case there are problems. TWRP should let you install "su", then install SuperSu, GAPPS, etc.
At some point we should repackage the known working gapps as a flashable zip file.
Hello guys, I'm actually going through a similar situation but I do not have TWRP installed and cannot pass further recovery since I am in a loop.
Am I able to install TWRP only with recovery access? thanks
bibikalka said:
To make things easier, these are some more specific instructions. Download 20-4.5.3 update, unpack it. Replace the script in 20-4.5.3/META-INF/com/google/android/updater-script with my attachment. You can compare the original with my version in Notepad++ (install plugin "compare"), in Linux it's even more trivial.
In addition, delete the following directories/files :
20-4.5.3/recovery
20-4.5.3/images
20-4.5.3/system/priv-app/com.amazon.weather.apk
20-4.5.3/system/priv-app/moffice_6.0.1_default_en00105_multidex_195423.apk
20-4.5.3/system/priv-app/DeviceSoftwareOTA.apk
20-4.5.3/system/priv-app/com.amazon.geo.client.maps.apk
(could delete a few more apk's here to make room in /system )
Zip everything, making sure the paths are the same as in the original Amazon bin. Boot TWRP, and give it this zipped update. It should install in /system, while keeping /data intact. If there are problems, copy the log to SDCard, and post your questions here.
As long as we are not touching the key partitions (recovery, UBOOT, TEE1), things should be safe, and simple to recover in case there are problems. TWRP should let you install "su", then install SuperSu, GAPPS, etc.
At some point we should repackage the known working gapps as a flashable zip file.
Click to expand...
Click to collapse
Alright. so I followed all your instructions, Copied the created Update.zip file to my Kindle. I go in TWRP and hit Install, and choose the zip inthe /sdcard folder. The Install fails and this is all the log says:
I:Set overlay: ''
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
Iperation_start: 'Flashing'
Installing '/sdcard/Update.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
Error flashing zip '/sdcard/Update.zip'
Updating partition details...
Iata backup size is 0MB, free: 11823MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
Any IDea what or why or any other info I can provide?
cskimbrell said:
Alright. so I followed all your instructions, Copied the created Update.zip file to my Kindle. I go in TWRP and hit Install, and choose the zip inthe /sdcard folder. The Install fails and this is all the log says:
Any IDea what or why or any other info I can provide?
Click to expand...
Click to collapse
Not sure what you are doing wrong, but I just did this yesterday, and everything worked smoothly. I wonder if you are editing the updater script as a Unix file.
In any event, go grab the latest 20-4.5.4 update, and replace the attached "updater-script" in 20-4.5.4/META-INF/com/google/android/updater-script (which worked for me). There is nothing scary about 4.5.4, so might as well restore to this one. My USB drive was UDF (TWRP did not see that), so I had to copy the *zip to the internal storage first. Can this be a source of a problem for you?
In addition, delete the following directories/files :
20-4.5.4/recovery
20-4.5.4/images
20-4.5.4/system/priv-app/com.amazon.weather.apk
20-4.5.4/system/priv-app/moffice_6.0.1_default_en00105_multidex_195423.apk
20-4.5.4/system/priv-app/com.amazon.geo.client.maps.apk
Rename (just in case):
20-4.5.4/system/priv-app/DeviceSoftwareOTA.apk to *apk_
Have jmz tool handy (downloaded), and SuperSu flashable zip (for TWRP). Once your 4.5.4 is up and running, you should flash SuperSu, and then use jmz tool to get GAPPS.
Important: If you have anything other than 4.5.3, I recommend that you flash the 4.5.3 bootloaders separately first before doing any updating business. I've attached the flashable zip with 4.5.3 bootloader as well (uboot*zip).
bibikalka said:
Not sure what you are doing wrong, but I just did this yesterday, and everything worked smoothly. I wonder if you are editing the updater script as a Unix file.
In any event, go grab the latest 20-4.5.4 update, and replace the attached "updater-script" in 20-4.5.4/META-INF/com/google/android/updater-script (which worked for me). There is nothing scary about 4.5.4, so might as well restore to this one. My USB drive was UDF (TWRP did not see that), so I had to copy the *zip to the internal storage first. Can this be a source of a problem for you?
In addition, delete the following directories/files :
20-4.5.4/recovery
20-4.5.4/images
20-4.5.4/system/priv-app/com.amazon.weather.apk
20-4.5.4/system/priv-app/moffice_6.0.1_default_en00105_multidex_195423.apk
20-4.5.4/system/priv-app/com.amazon.geo.client.maps.apk
Rename (just in case):
20-4.5.4/system/priv-app/DeviceSoftwareOTA.apk to *apk_
Have jmz tool handy (downloaded), and SuperSu flashable zip (for TWRP). Once your 4.5.4 is up and running, you should flash SuperSu, and then use jmz tool to get GAPPS.
Important: If you have anything other than 4.5.3, I recommend that you flash the 4.5.3 bootloaders separately first before doing any updating business. I've attached the flashable zip with 4.5.3 bootloader as well (uboot*zip).
Click to expand...
Click to collapse
I am also getting the flash failed message with 4.5.3. Where were you able to grab a copy of 4.5.4?
bibikalka said:
Not sure what you are doing wrong, but I just did this yesterday, and everything worked smoothly. I wonder if you are editing the updater script as a Unix file.
In any event, go grab the latest 20-4.5.4 update, and replace the attached "updater-script" in 20-4.5.4/META-INF/com/google/android/updater-script (which worked for me). There is nothing scary about 4.5.4, so might as well restore to this one. My USB drive was UDF (TWRP did not see that), so I had to copy the *zip to the internal storage first. Can this be a source of a problem for you?
In addition, delete the following directories/files :
20-4.5.4/recovery
20-4.5.4/images
20-4.5.4/system/priv-app/com.amazon.weather.apk
20-4.5.4/system/priv-app/moffice_6.0.1_default_en00105_multidex_195423.apk
20-4.5.4/system/priv-app/com.amazon.geo.client.maps.apk
Rename (just in case):
20-4.5.4/system/priv-app/DeviceSoftwareOTA.apk to *apk_
Have jmz tool handy (downloaded), and SuperSu flashable zip (for TWRP). Once your 4.5.4 is up and running, you should flash SuperSu, and then use jmz tool to get GAPPS.
Important: If you have anything other than 4.5.3, I recommend that you flash the 4.5.3 bootloaders separately first before doing any updating business. I've attached the flashable zip with 4.5.3 bootloader as well (uboot*zip).
Click to expand...
Click to collapse
Tried with the 4.5.4 Update as well. Unfortunately I get the same issue. Log file says
Installing '/sdcard/update-kindle-20.4.5.4_user_454006120.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
Error flashing zip '/sdcard/update-kindle-20.4.5.4_user_454006120.zip'
Updating partition details...
Iata backup size is 0MB, free: 11822MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
Click to expand...
Click to collapse
TO make sure I'm doing this right.. I just boot into TWRP, Select Install, Select the update fie in my sdcard folder, Then Swipe to Confirm flash.. Right?
Another weird thing i noticed. If I go to Advanced, then Fix Permissions I get "Can't Check Permissions after Factory Reset. Please boot rom and try again after you reboot into recovery" This remains this way any time I reboot into recovery. And of course I cannot do a normal boot as my device hangs at the Amazon Logo when trying a normal boot.
cskimbrell said:
Alright. so I followed all your instructions, Copied the created Update.zip file to my Kindle. I go in TWRP and hit Install, and choose the zip inthe /sdcard folder. The Install fails and this is all the log says:
I:Set overlay: ''
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
Iperation_start: 'Flashing'
Installing '/sdcard/Update.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
Error flashing zip '/sdcard/Update.zip'
Updating partition details...
Iata backup size is 0MB, free: 11823MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
Any IDea what or why or any other info I can provide?
Click to expand...
Click to collapse
cskimbrell said:
Tried with the 4.5.4 Update as well. Unfortunately I get the same issue. Log file says
TO make sure I'm doing this right.. I just boot into TWRP, Select Install, Select the update fie in my sdcard folder, Then Swipe to Confirm flash.. Right?
Another weird thing i noticed. If I go to Advanced, then Fix Permissions I get "Can't Check Permissions after Factory Reset. Please boot rom and try again after you reboot into recovery" This remains this way any time I reboot into recovery. And of course I cannot do a normal boot as my device hangs at the Amazon Logo when trying a normal boot.
Click to expand...
Click to collapse
I kind of think that perhaps your /data partition is screwed up. "sdcard" sits somewhere there as well. Do you have an OTG cable? If you don't, it can be tricky, since you have no way to send files to the TWRP. Otherwise you could just reformat /data in TWRP, and make sure that /media or whatever is also reformatted. I reformatted /data yesterday, and did recall some weird messages, but my OS was fine. So I just blasted through, and it re-created stuff in /data.
bibikalka said:
I kind of think that perhaps your /data partition is screwed up. "sdcard" sits somewhere there as well. Do you have an OTG cable? If you don't, it can be tricky, since you have no way to send files to the TWRP. Otherwise you could just reformat /data in TWRP, and make sure that /media or whatever is also reformatted. I reformatted /data yesterday, and did recall some weird messages, but my OS was fine. So I just blasted through, and it re-created stuff in /data.
Click to expand...
Click to collapse
I'll give a try to formatting those partitions. I assume using the "Wipe" command on them formats them? (Forgive my ignorance.. Im still new to using TWRP and such.. I work on computers for a living and this ordeal is driving me nuts.. hah)
I do not have an OTG Cable, So far I have been pushing files directly to the Kindle from my laptop with the Android File Manager, and then moving them around on the device from the advanced File Manager on TWRP. Would an OTG Cable do anything different than what I am already doing other than simplify it?
Im just not sure if I have files in the right place when I go about flashing them, or if that even matters.
cskimbrell said:
I'll give a try to formatting those partitions. I assume using the "Wipe" command on them formats them? (Forgive my ignorance.. Im still new to using TWRP and such.. I work on computers for a living and this ordeal is driving me nuts.. hah)
I do not have an OTG Cable, So far I have been pushing files directly to the Kindle from my laptop with the Android File Manager, and then moving them around on the device from the advanced File Manager on TWRP. Would an OTG Cable do anything different than what I am already doing other than simplify it?
Im just not sure if I have files in the right place when I go about flashing them, or if that even matters.
Click to expand...
Click to collapse
Indeed, explore TWRP a bit. I guess you can sideload with TWRP, so it does not matter. But notice the update will wipe /system, so you cannot have your zip there. Otherwise it won't care too much, it'll just unpack it into its destination. As long as you are not touching your recovery, and the bootloader, you should be fairly safe.
bibikalka said:
Indeed, explore TWRP a bit. I guess you can sideload with TWRP, so it does not matter. But notice the update will wipe /system, so you cannot have your zip there. Otherwise it won't care too much, it'll just unpack it into its destination. As long as you are not touching your recovery, and the bootloader, you should be fairly safe.
Click to expand...
Click to collapse
..................... Well... I figured out my problem.......
Like a moron.. I was zipping up the Folder all the update files were in.. and not the actual collection of files.....
Sigh...... I know better than this.... haha...
So here you come. To read and perform this tutorial, you obviously need a first hand experience on flashing a ROM and/or kernels. Otherwise this tutorial and my efforts to get you a device with two OSes running might end up giving you a bricked device. So, if you're hearing the terms "flashing" or 'kernels' for the first time and thinking it's kinda good food, then bro, just go and taste those first.
Something's to remind before we gonna dig deep into this tutorial->
1> Noone but you will be responsible for what you end up with.
2> The warranty of your device will be voided after this if it isn't already after rooting. For MI users, the good news is that you can reclaim it by just flashing the fastboot ROM for your device.
Enough lectures. Bro let's get to work.
This you'll be needing =>
1> One working Windows PC(because I doesn't know any replacement of bootimg.exe on any other OS. If you know, then let me).
2> A class 10 memory card ( I recommend 32GB for the spaces)
3> A custom ROM and kernel for your phone(the second os)
4> Any custom CWM based recovery installed.(since TWRP is most popular, I will demonstrate using it. You can use any other you want overall process will be the same)
5> ADB, fastboot and the device drivers (easily found in XDA)
PART 1: MODIFYING THE BOOT
At first, how does your device boots up? What are the partitions called /data and /system? The answer is quite simple. It's your kernel that points out the location from where the OS should be picked up. So for booting into the second OS we need some modifications to it at first.
Search and download bootimg.exe on XDA, I'll post a link later. Create two folders. Name them "Internal OS" and "External OS" respectively. Put the zip file of the OS you're currently using to the first one and the OS you're gonna use on the external storage to the second one. Rename the second OS to originalExternalOS.zip. Extract originalExternalOS.zip. Pick the boot.img file from the root of the extracted folder and move it to a new folder named "boot2". Extract the IMG using bootimg.exe. Navigate to the initrd folder and you will get a file named 'fstab".
Basically it's the file that tells the kernel which partition does the OS resides in.
Open the file in your favourite text editor.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
Save the file without giving any extension to it. Repack it using the same tool. You'll have boot-new.img and boot-old.img. Rename boot-new.img to boot.img and replace the one in the root folder with this. Basically what we're doing here is replacing the old boot.img with the modified one.
For your knowledge, blocks are the partitions of any storage you have on your device. For example, your internal storage is partitioned to near about 30 different blocks each starting with prefix "mmcblk0p". We here just told the kernel to load the OS from the blocks mentioned. We'll be creating these blocks in the external SD card next.
PART 2: PARTITIONING THE SD CARD
Connect your device with the memory card inserted to your PC. If you haven't installed fastboot, ADB, and the drivers, do it now.
READ THE FOLLOWING CAREFULLY
Reboot the device to recovery mode. Type the commands in cmd:
Code:
adb shell
parted
unit MB
print
quit
umount external_sd
Read and store the minimum and maximum capacity of your card. Since different cards will have different capacities I will point it as variable MIN_SIZE and MAX_SIZE. You'll need to calculate and put the values in the commands. Now type the following commands on cmd:
Code:
parted /dev/block/mmcblk1
rm 1
//START_BLOCK = MAX_SIZE - 5000
mkpartfs primary fat32 MIN_SIZE START_BLOCK
//SYS_START = START_BLOCK+1
//SYS_END = SYS_START + 1200
mkpartfs primary ext2 SYS_START SYS_END
//DATA_START = SYS_END+1
//DATA_END = DATA_START + 3500
mkpartfs primary ext2 DATA_START DATA_END
//CACHE_START = DATA_END + 1
mkpartfs primary ext2 CACHE_START MAX_SIZE
//We have partitioned the memory card. Let's format them. Ignore all "Do you wish to continue" question in the next commands as we're already mentioning yes.
mkfs yes 1 fat32
mkfs yes 2 ext2
mkfs yes 3 ext2
mkfs yes 4 ext2
quit
//Now they are almost ready. Just make the newly created blocks readable by the OS.
make_ext4fs /dev/block/mmcblk1p2
make_ext4fs /dev/block/mmcblk1p3
make_ext4fs /dev/block/mmcblk1p4
//Now you get where does the blocks come in the kernel right?
exit
//You've covered up the hardest part. Let's get some coffee and cheeerssss.
PART 3: MODIFYING THE NEW OS
You've left the OS extracted in the "External OS" folder right? It's time to do some magic in it. We're gonna tell the OS to be installed in the blocks we created just like the kernel. But wait, where does the OS know before installing where it should get installed? Well, the answer hides in the updater-script in the folder META-INF > com > google > android. Navigate yourself in it. Open the updater-script file in your favourite editor ( I use notepad++ ) and modify it in the same way as the kernel.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
Leave the /dev/block/bootdevice/by-name/boot as it's the fundamental block and we can't replicate it. Don't think for the /cache partition as we've already done that in the boot.img file. Now navigate to the root of the folder where you extracted the External OS. Select all files, add them to a zip file using WinRAR. Name the file to newOS.zip. Open newOs.zip and originalExternalOS.zip with WinRAR and compare them if you find any change in the folder tree. They must and they should be exactly the same. You're 80% done.
PART 4: MODIFYING THE RECOVERY
We often flash many zips including very popular Xposed and other mods to our OS right? They also look for the /system partition. So what are we gonna do? Modifying each of them? Nah. Let's modify where they get which one the /system is. The recovery. Extract the img of the recovery you're using with the same bootimg.exe. Modify exactly the same things. I.e.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
in the following files : initrd/fstab.qcom
initrd/etc/recovery.fstab
initrd/etc/twrp.fstab(For TWRP only)
Save them. Repack. And you got your recovery-new.img and recovery-old.img. Put recovery-new.img and newOS.zip in the same folder. Now wake up, it's time for some action.
PART 5 : INSTALLING THE OS
Open cmd in the folder where newOS.zip resides. Reboot the devixe in fastboot mode. Type the following commands:
Code:
adb push newOS.zip external_sd
fastboot flash recovery recovery-new.img
fastboot boot recovery
Now your device should boot up in recovery mode. To check if everything has gone fine mount system using TWRP. Use twrp's built in file manager and navigate to system folder. It's empty? Yup. You've done a great job. Now flash the newOS.zip using TWRP and your device should boot up in the new OS. To cross check again remove the SD card and try to boot. If you're headed towards recovery or bootloop after that then it's a win. Put the SD card back again and watch the new OS to boot.
PART 6: SWITCHING BETWEEN THE TWO
Extract the boot.img from the "Internal OS" zip file and put it together with recovery-old.img. To check if your old system is untouched type the following commands in fastboot mode:
Code:
fastboot flash recovery recovery-old.img
fastboot flash boot boot.img
fastboot boot system
Your device should take you back to the old one. Surprised? Now let's make a switch between the two. There are two methods.
METHOD 1: USING FLASHIFY
Create two folders in your SD card. Put boot.img and recovery-old.img to one and boot-new.img and recovery-new.img to the other. To switch to the external OS, just flash boot-new.img as boot and recovery-new.img using flashify. Ignore reboot now dialog and reboot directly to the system. To go back, first install flashify in the new OS and flash boot.img and recovery-old.img. Easy right?
METHOD 2: USING ZIPS
I'm gonna tell you that tomorrow as I can write no more today.
More to come....
CREDITS:
justzzshadz from MIUI forum for this revolutionary concept. @iamsubhranil for adding TWRP support and rewriting the tutorial.
Unnecessary
Continuation2
........
reserved
For future posts.
reserved
For future posts
"External" is spelled wrong in the title.
God of War™ said:
"External" is spelled wrong in the title.
Click to expand...
Click to collapse
If you read the whole tutorial, then that just doesn't matter
God of War™ said:
"External" is spelled wrong in the title.
Click to expand...
Click to collapse
Have you tried it?
bootimg.exe
"bootimg.exe on any other OS. If you know, then let me)."
please, send bootimg.exe
tim241 said:
Thanks!!
Click to expand...
Click to collapse
Why you quoted the whole post only to say thanks? That thank you button under the post isn't enough?
tim241 said:
Thanks!!
Click to expand...
Click to collapse
Tried?
fstab not found there is a file named fstab.qcom??????
keerten said:
fstab not found there is a file named fstab.qcom??????
Click to expand...
Click to collapse
Try MultiROM man
iamsubhranil said:
Try MultiROM man
Click to expand...
Click to collapse
Ok Bro
iamsubhranil said:
Try MultiROM man
Click to expand...
Click to collapse
Bro, you are working on EFIDROID. Can you give us update that project
abhianand123 said:
Bro, you are working on EFIDROID. Can you give us update that project
Click to expand...
Click to collapse
I've already told it to some people. The project is currently stun for some complications. Will resume.
Pretty useful. Thanks a lot.
Am I right, that when the memory chip on the motheboard holding /system and /userdata partitions died, I can boot the phone from sdcard using this method? I have HM2014813 variant of Redmi 2.
EDIT: I tried this method but I need to use fastboot boot modified.img to boot my phone. Any ideas how to avoid this step?
tulen_kobi said:
Am I right, that when the memory chip on the motheboard holding /system and /userdata partitions died, I can boot the phone from sdcard using this method? I have HM2014813 variant of Redmi 2.
EDIT: I tried this method but I need to use fastboot boot modified.img to boot my phone. Any ideas how to avoid this step?
Click to expand...
Click to collapse
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
---------- Post added at 03:49 PM ---------- Previous post was at 03:43 PM ----------
warrenlobo said:
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
Click to expand...
Click to collapse
they are missing i guess
warrenlobo said:
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
---------- Post added at 03:49 PM ---------- Previous post was at 03:43 PM ----------
they are missing i guess
Click to expand...
Click to collapse
There is no parted on the device anymore, you need to preparation your sdcard on your computer. Do you use Windows or Linux on your pc?
If Windows try to use: FWUL to partition your sdcard.
Just had a little nasty experience with this file.
Initially to install the new beta update of Remix OS I rooted system.img with RMXtools v1.5 but it was pointed out by developer imadlatch that initrd.img prevented write permissions for this system partition, so I used the one he attached to his OP (it's the one that comes with alpha version) and could therefore set up root correctly, etc, after I was done and decided I didn't care for write permissions anymore to the system partition I restored the initrd.img that came with beta and can confirm it doesn't break root but it won't let you make any changes or write anything whatsoever inside /system.
The next day I found something else to do in this partition so I swapped the initrd file again, when I finally settled for the initrd.img from beta I couldn't get Remix OS to boot, so I hard rebooted the PC, even worse, grub was asking for files. Got into Windows and found that the RemixOS folder was "corrupted and inaccesible" (properties gave me 0 bytes for this folder) which I could thankfully resolve with a simple chkdsk command. Now I'm putting this out there. If you're going to root your beta Remix system make sure to copy over the old alpha initrd.img (also on the RMXtools thread) to your "RemixOS" folder that lets you write to system and don't fiddle with it anymore. Recommended for the first boot of Remix to be unrooted so that the data.img created (also seems to be dictated by initrd) is 8 GB and not 4.
You_KS said:
Just had a little nasty experience with this file.
Initially to install the new beta update of Remix OS I rooted system.img with RMXtools v1.5 but it was pointed out by developer imadlatch that initrd.img prevented write permissions for this system partition, so I used the one he attached to his OP (it's the one that comes with alpha version) and could therefore set up root correctly, etc, after I was done and decided I didn't care for write permissions anymore to the system partition I restored the initrd.img that came with beta and can confirm it doesn't break root but it won't let you make any changes or write anything whatsoever inside /system.
The next day I found something else to do in this partition so I swapped the initrd file again, when I finally settled for the initrd.img from beta I couldn't get Remix OS to boot, so I hard rebooted the PC, even worse, grub was asking for files. Got into Windows and found that the RemixOS folder was "corrupted and inaccesible" (properties gave me 0 bytes for this folder) which I could thankfully resolve with a simple chkdsk command. Now I'm putting this out there. If you're going to root your beta Remix system make sure to copy over the old alpha initrd.img (also on the RMXtools thread) to your "RemixOS" folder that lets you write to system and don't fiddle with it anymore. Recommended for the first boot of Remix to be unrooted so that the data.img created (also seems to be dictated by initrd) is 8 GB and not 4.
Click to expand...
Click to collapse
Check your grub entire. I bet initrd was missing from the bottom of the entire.
You_KS said:
Just had a little nasty experience with this file.
Initially to install the new beta update of Remix OS I rooted system.img with RMXtools v1.5 but it was pointed out by developer imadlatch that initrd.img prevented write permissions for this system partition, so I used the one he attached to his OP (it's the one that comes with alpha version) and could therefore set up root correctly, etc, after I was done and decided I didn't care for write permissions anymore to the system partition I restored the initrd.img that came with beta and can confirm it doesn't break root but it won't let you make any changes or write anything whatsoever inside /system.
The next day I found something else to do in this partition so I swapped the initrd file again, when I finally settled for the initrd.img from beta I couldn't get Remix OS to boot, so I hard rebooted the PC, even worse, grub was asking for files. Got into Windows and found that the RemixOS folder was "corrupted and inaccesible" (properties gave me 0 bytes for this folder) which I could thankfully resolve with a simple chkdsk command. Now I'm putting this out there. If you're going to root your beta Remix system make sure to copy over the old alpha initrd.img (also on the RMXtools thread) to your "RemixOS" folder that lets you write to system and don't fiddle with it anymore. Recommended for the first boot of Remix to be unrooted so that the data.img created (also seems to be dictated by initrd) is 8 GB and not 4.
Click to expand...
Click to collapse
Might be a bit overkill to go back to alpha initrd -- attached is beta initrd with ro's removed.
I had the corrupted folder with alpha as well (fixed with chkdsk), it's essentially caused by ntfs being dirty mounted/unmounted and an fsck (ntfsfix) not being run before it's mounted.
HypoTurtle said:
Might be a bit overkill to go back to alpha initrd -- attached is beta initrd with ro's removed.
I had the corrupted folder with alpha as well (fixed with chkdsk), it's essentially caused by ntfs being dirty mounted/unmounted and an fsck (ntfsfix) not being run before it's mounted.
Click to expand...
Click to collapse
Oh, yes! That makes sense and thank you, gonna use this.
UPDATED 2016-08-12 I HIGHLY RECOMMEND A BETTER METHOD FOUND HERE:
http://forum.xda-developers.com/remix/remix-os/guide-using-jides-remountrw1-method-to-t3431595
FEWER CHANCES OF ERROR :laugh:
UPDATED 2016-08-09 TO INCLUDE 32 BIT DIRECTIONS MANY THANKS TO @ireMaN FOR INPUT
THIS IS MODIFIED NOW FOR BOTH 32 AND 64 BIT!
THIS IS ALSO ONLY FOR HDD INSTALLATIONS
Fellow Remixers:
As many have found out, version 3 of RemixOS doesn't allow changes to the system. This is because instead of a system.img it now uses a system.sfs. For most of us there is no advantage to this, and it makes it impossible to perform even simple mods to the build.prop.
So we must convert that pesky system.sfs to a system.img and substitute a modified initrd.img.
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it. EDIT 2016-08-03: WORKS FOR 3.0.102 ALSO
EDIT: 2016-08-09 WORKS FOR 3.0.103 ALSO
Here it goes:
ALL OF THIS IS DONE FROM WINDOWS. From File Explorer, navigate to your partition with RemixOS folder. Note the drive letter; mine was d:
1 Open the RemixOS folder on that drive; you should see a system.sfs file.
2 First you need to download the correct (32 or 64) modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
3 Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_(32 or 64)_rw_3.0.101.img
4 Copy that file into the RemixOS folder on the drive where you installed Remix.
5 Open the RemixOS folder; you should see both the original initrd.img and the new initrd_(32 or 64)_rw_3.0.101.img
6 Rename the initrd.img to oldinitrd.img to save it in case you need it
7 Rename the initrd_(32 or 64)_rw_3.0.101.img to initrd.img
8 Next convert that system.sfs file to a system.img file
9 Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
10 Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip. (EDIT: You may need 7zip to extract it)
11 Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
12 Open a command window by using shift&right mouse button and selecting the Open command window here
13 Assuming that your RemixOS folder is on drive c: type unsquashfs.exe -d c:\temp c:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for c: (EDIT: Do not change the -d as it is part of the command)
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
14 Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
15 Copy it into the RemixOS folder
16 Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
17 Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
NOTE: TO TAKE OTA UPDATE YOU NEED TO DO THE Following FROM WINDOWS:
A In File Explorer, navigate to the RemixOS folder
B Find and rename the initrd.img to initrd_(32 or 64)_rw_3.0.101.img depending on your version
C Find and delete system.img
D Rename oldsystem.sfs to system.sfs
E Reboot ti RemixOS and download the update and select the Reboot option.
F After the OTA is installed and you are at the desktop you need to repeat steps 6 through 17 above
Any suggestions to make this easier please let me know. Please PM me and I will answer your questions.
Thanks a lot... Will try and reply you soon.... But I'm sure it works
Sent from my S II using XDA Labs
changing orientation
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
lollyjay said:
Fellow Remixers:
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it.
Here it goes:
All of this is done from Windows. From File Explorer, navigate to your partition with RemixOS directory. Note the drive letter; mine was d:
Open the RemixOS folder on that drive; you should see a system.sfs file.
First you need to download a modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_rw_3.0.101.img
Copy that file into the RemixOS folder on the drive where you installed Remix.
Open the RemixOS folder; you should see both the original initrd.img and the new initrd_rw_3.0.101.img
Rename the initrd.img to oldinitrd.img to save it in case you need it
Rename the initrd_rw_3.0.101.img to initrd.img
Next convert that system.sfs file to a system.img file
Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip.
Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
Open a command window by using shift&right mouse button and selecting the Open command window here
Assuming that your RemixOS folder is on drive d: type
unsquashfs.exe -d d:\temp d:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for d:
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
Copy it into the RemixOS folder
Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
Rename the initrd_rw_3.0.101.img to initrd.img
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
Some Question
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
rajnallan said:
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
Click to expand...
Click to collapse
Thank you for the compliment. My knowledge does not extend to that area; perhaps @HypoTurtle can help?
asuduakali said:
Any suggestions to make this easier please let me know.
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
Click to expand...
Click to collapse
I wish I knew...
Edit: I suspect that they locked access to speed up the system by disabling disk i/o
lollyjay said:
I wish I knew...
Edit: I suspect that they locked access to speed up the system by disabling disk i/o
Click to expand...
Click to collapse
I succeed to do it using stickmount after i copied these imgs .
just check usbstorage folder with file explorer ( i'm using ES)
lollyjay said:
Fellow Remixers:
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it.
Here it goes:
All of this is done from Windows. From File Explorer, navigate to your partition with RemixOS directory. Note the drive letter; mine was d:
Open the RemixOS folder on that drive; you should see a system.sfs file.
First you need to download a modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_rw_3.0.101.img
Copy that file into the RemixOS folder on the drive where you installed Remix.
Open the RemixOS folder; you should see both the original initrd.img and the new initrd_rw_3.0.101.img
Rename the initrd.img to oldinitrd.img to save it in case you need it
Rename the initrd_rw_3.0.101.img to initrd.img
Next convert that system.sfs file to a system.img file
Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip.
Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
Open a command window by using shift&right mouse button and selecting the Open command window here
Assuming that your RemixOS folder is on drive d: type
unsquashfs.exe -d d:\temp d:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for d:
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
Copy it into the RemixOS folder
Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
Rename the initrd_rw_3.0.101.img to initrd.img
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
Tried it now. Worked like a charm. killing the thanks button
Everything working fine... I'd clean install replacing both files, thank you very much, and also i installed SuperSU for better root magement and besides.. with this one StickMount works perfectly...
doing this Adaway can work?
dark8899 said:
doing this Adaway can work?
Click to expand...
Click to collapse
Yes, of course
asuduakali said:
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
Click to expand...
Click to collapse
Try changing ro.remixos.scan_all_parts=false
rajnallan said:
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
Click to expand...
Click to collapse
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
xSilverLight said:
Everything working fine... I'd clean install replacing both files, thank you very much, and also i installed SuperSU for better root magement and besides.. with this one StickMount works perfectly...
Click to expand...
Click to collapse
Yea, stickmount seems to need the [updated] superSU su binary; so either system.img rw or systemless root would do [also the build.prop edit mentioned above might be an alternative to stickmount but editing build.prop needs system rw anyway].
Addendum; if anyone is using my 32bit su.img; you need to make a /su/xbin_bind folder and reboot before SuperSU will update the binary
HypoTurtle said:
Yea, stickmount seems to need the [updated] superSU su binary; so either system.img rw or systemless root would do [also the build.prop edit mentioned above might be an alternative to stickmount but editing build.prop needs system rw anyway].
Addendum; if anyone is using my 32bit su.img; you need to make a /su/xbin_bind folder and reboot before SuperSU will update the binary
Click to expand...
Click to collapse
Exactly, also I'll try that you mention and thanks for the info..
And also.. thanks for all your contributions
HypoTurtle said:
Try changing ro.remixos.scan_all_parts=false
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
IT is already showing ro.remixos.has_adjust_display =false
The latest remix OS based on Marshmallow carries all these changes.
Click to expand...
Click to collapse
Thanks. Now I can use stick mount and access my hdd.
hhaiwzz said:
Thanks. Now I can use stick mount and access my hdd.
Click to expand...
Click to collapse
You're very welcome my pleasure
I'm at a loss as to how to get this working on a USB install on my system. Are people using hard drive installs or USB flash drive ones? I'm using a 64gb Sandisk Extreme flash drive.
1st off - using the Windows tool that comes in the installer from Jide's website (downloaded file I have is Remix_OS_for_PC_Android_M_64bit_B2016072603.zip ) to "install" RemixOS onto the flash drive works flawlessly but after that I'm unable to see any other volumes other than one called REMIX_OS which is not a system volume. I've formatted the flash drive 4 times already and redid the installation each time. Each time the install is perfectly bootable but in terms of being able to boot into windows and brows the RemixOS folder to modify system files there is no change, I'm unable to see all volumes on the flash drive. I only see one volume while in windows and that one appears to be an SD CARD (It's called REMIX_OS and only has an Android and Lost folder in it) rather than the system volume for Android.
If I insert the flash drive into my Macbook I'm able to see two volumes, the volume called REMIX_OS I referred to earlier and another volume called REMIXOSSYS which does have the system files in it (with the initrd.img and system.sfs that need to be replaced) . .
So after using the RMXTools on my Windows machine to create a system.img file (which ends up ballooning to 2.6gb, is that the right size?) and downloading the requisite initrd_rw_3.0.101.img and renaming both original files on the REMIXOSSYS volume (using my Mac) and copying the new ones onto the flash drive volume I'm able to boot into RemixOS on my PC normally.
Everything works fine until I actually try to edit build prop as a test at which point I'm unable to. The system itself operates just fine otherwise but system still isn't writeable.
I'm not quite sure why others are easily able to do everything they need to do on their PC's using windows explorer to modify the system files and I'm not. I tried it on both my home and work PCs and the result is the same. Nonetheless I'm thinking that since all that is supposed to be required to make system writeable is to replace the initrd.img and system.sfs with the modified initrd.img and a system.img file then it really shouldn't matter if I do it using a Mac or a PC . . i'm confused at this point lol.
Any thoughts?
rajnallan said:
HypoTurtle said:
Try changing ro.remixos.scan_all_parts=false
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
IT is already showing ro.remixos.has_adjust_display =false
The latest remix OS based on Marshmallow carries all these changes.
Click to expand...
Click to collapse
Yea; I said change it. i.e. to true
Click to expand...
Click to collapse
muzzy996 said:
I'm at a loss as to how to get this working on a USB install on my system. Are people using hard drive installs or USB flash drive ones? I'm using a 64gb Sandisk Extreme flash drive.
1st off - using the Windows tool that comes in the installer from Jide's website (downloaded file I have is Remix_OS_for_PC_Android_M_64bit_B2016072603.zip ) to "install" RemixOS onto the flash drive works flawlessly but after that I'm unable to see any other volumes other than one called REMIX_OS which is not a system volume. I've formatted the flash drive 4 times already and redid the installation each time. Each time the install is perfectly bootable but in terms of being able to boot into windows and brows the RemixOS folder to modify system files there is no change, I'm unable to see all volumes on the flash drive. I only see one volume while in windows and that one appears to be an SD CARD (It's called REMIX_OS and only has an Android and Lost folder in it) rather than the system volume for Android.
If I insert the flash drive into my Macbook I'm able to see two volumes, the volume called REMIX_OS I referred to earlier and another volume called REMIXOSSYS which does have the system files in it (with the initrd.img and system.sfs that need to be replaced) . .
So after using the RMXTools on my Windows machine to create a system.img file (which ends up ballooning to 2.6gb, is that the right size?) and downloading the requisite initrd_rw_3.0.101.img and renaming both original files on the REMIXOSSYS volume (using my Mac) and copying the new ones onto the flash drive volume I'm able to boot into RemixOS on my PC normally.
Everything works fine until I actually try to edit build prop as a test at which point I'm unable to. The system itself operates just fine otherwise but system still isn't writeable.
I'm not quite sure why others are easily able to do everything they need to do on their PC's using windows explorer to modify the system files and I'm not. I tried it on both my home and work PCs and the result is the same. Nonetheless I'm thinking that since all that is supposed to be required to make system writeable is to replace the initrd.img and system.sfs with the modified initrd.img and a system.img file then it really shouldn't matter if I do it using a Mac or a PC . . i'm confused at this point lol.
Any thoughts?
Click to expand...
Click to collapse
Method works only for hdd installations afaik
wow thanks for this, now since we have an open system, can we install xposed framework?
I try to update my RemixOS but suddenly power off I wait about half hour then power back my PC then I can't boot to RrmixOS. I dual boot with Lubuntu 16.X with HP ProBook 4410
Sent from my HM NOTE 1LTEW using Tapatalk
@itsAril Since the system crashed whilst updating, the /system partition probably got corrupted. If you have a recent Remix OS installation .iso file, then you can open it and extract system.sfs file into the directory where you installed RemixOS (replace the old one). Then reboot to check if it helped.
Most likely your storage medium also got affected - it may have badblocks in the filesystem. To make sure that's not the case do the following from Windows:
Start cmd.exe as administrator.
Run this command but change X: to drive where RemixOS is installed:
Code:
chkdsk X: /f /r /x
Once it's done, make a screenshot/picture or save the contents of the console in notepad to show results to us.
Reboot into Remix and check if it helped.
If that doesn't help, then next thing you can do is:
Backup the data.img file onto your other partition.
Uninstall Remix
Install it again, but don't reboot.
Restore the data.img file.
Reboot to test.
If that also doesn't help, then use this guide. But ommit/do NOT perform command “resize2fs data.img 16G”.
Vioner said:
@itsAril Since the system crashed whilst updating, the /system partition probably got corrupted. If you have a recent Remix OS installation .iso file, then you can open it and extract system.sfs file into the directory where you installed RemixOS (replace the old one). Then reboot to check if it helped.
Most likely your storage medium also got affected - it may have badblocks in the filesystem. To make sure that's not the case do the following from Windows:
Start cmd.exe as administrator.
Run this command but change X: to drive where RemixOS is installed:
Code:
chkdsk X: /f /r /x
Once it's done, make a screenshot/picture or save the contents of the console in notepad to show results to us.
Reboot into Remix and check if it helped.
If that doesn't help, then next thing you can do is:
Backup the data.img file onto your other partition.
Uninstall Remix
Install it again, but don't reboot.
Restore the data.img file.
Reboot to test.
If that also doesn't help, then use this guide. But ommit/do NOT perform command “resize2fs data.img 16G”.
Click to expand...
Click to collapse
Thanks you very much it work now..
Sent from my HM NOTE 1LTEW using Tapatalk
@itsAril That's great! Can you share with us how far did you have to go with these tips? After what did it start to work?
It's useful info for others with the issue.
I just uninstall and install backup data.img I have to do twice fist try doesn't work. I got video coming I will post here when done editing. Maybe will help someone got same problem like me
Sent from my HM NOTE 1LTEW using Tapatalk