Related
This used to work under Android 4.0, 4.1, 4.2.... but I can't get it to work under the new 4.3.
I have had a Google Nexus 10 tablet for months, worked great. I installed the new Android 4.3 mantaray-jwr66v image onto it, worked great. I then tried to root it by unpacking the boot.img file, making changes to the default.prop file, and flashing this boot_new.img file to the device. My default.prop file now looks like:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
ro.adb.secure=0
I have tried various different combinations of the above (e.g. just changing the ro.secure line), but nothing I try gives me the # prompt like I used to get under 4.2. I just get "[email protected]:/ $". At the shell prompt, when I try "cat /default.prop" I get the lines shown above (which confirms the boot_new.img file is formatted correctly).
I am perplexed. Does anyone know why this is the case? Did something change?
Note that I am aware there are other rooting methods available, and I am sure many of you will suggest I try one of those routes. Thank you in advance, but I would prefer to use this method... my rooting is part of a bigger deployment picture, and the existing system is written to root and unroot with changed boot.img files.
So my question in a nutshell: has anything changed in the (standard?) procedure for rooting a tablet with ro.secure=0 with Android 4.3?
If you have used this method successfully, I would appreciate hearing about that as well, as it would indicate my process is faulty somehow.
This is my first post to XDA, I did read the rules, and I hope I included enough info.
Thanks a lot!
...Bruce
LeftTwin said:
This used to work under Android 4.0, 4.1, 4.2.... but I can't get it to work under the new 4.3.
I have had a Google Nexus 10 tablet for months, worked great. I installed the new Android 4.3 mantaray-jwr66v image onto it, worked great. I then tried to root it by unpacking the boot.img file, making changes to the default.prop file, and flashing this boot_new.img file to the device. My default.prop file now looks like:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
ro.adb.secure=0
I have tried various different combinations of the above (e.g. just changing the ro.secure line), but nothing I try gives me the # prompt like I used to get under 4.2. I just get "[email protected]:/ $". At the shell prompt, when I try "cat /default.prop" I get the lines shown above (which confirms the boot_new.img file is formatted correctly).
I am perplexed. Does anyone know why this is the case? Did something change?
Note that I am aware there are other rooting methods available, and I am sure many of you will suggest I try one of those routes. Thank you in advance, but I would prefer to use this method... my rooting is part of a bigger deployment picture, and the existing system is written to root and unroot with changed boot.img files.
So my question in a nutshell: has anything changed in the (standard?) procedure for rooting a tablet with ro.secure=0 with Android 4.3?
If you have used this method successfully, I would appreciate hearing about that as well, as it would indicate my process is faulty somehow.
This is my first post to XDA, I did read the rules, and I hope I included enough info.
Thanks a lot!
...Bruce
Click to expand...
Click to collapse
You are not alone in this. I encountered the same problem recently and was also confused. I decided to contact the kernel dev Imoseyon to see if he knew what was up. When I first told him I had the problem he originally suspected it was related to SELinux, but upon actual review of the decompiled 4.3 boot.img he found the culprit.
The restriction is apparently due to the new adbd binary [located in the sbin directory]. If you swap that adbd binary out for the 4.2.* version, and make the same changes you made above [in the OP] to the default.prop, then walla! You will have a successfully modified boot.img that allows running privileged commands.
I kept finding this unanswered thread whenever I was Googling for clues, so it only seemed right to report back here now that I got figured out.
Cheers.
{{ WugFresh }}
WugFresh said:
You are not alone in this. I encountered the same problem recently and was also confused. I decided to contact the kernel dev Imoseyon to see if he knew what was up. When I first told him I had the problem he originally suspected it was related to SELinux, but upon actual review of the decompiled 4.3 boot.img he found the culprit.
The restriction is apparently due to the new adbd binary [located in the sbin directory]. If you swap that adbd binary out for the 4.2.* version, and make the same changes you made above [in the OP] to the default.prop, then walla! You will have a successfully modified boot.img that allows running privileged commands.
I kept finding this unanswered thread whenever I was Googling for clues, so it only seemed right to report back here now that I got figured out.
Cheers.
{{ WugFresh }}
Click to expand...
Click to collapse
I replaced the sbin/adbd with 4.2.2's, and modified the default.prop, but why i still can't run privileged commands?
How can i disable adb ?
Hi,
i have a baseline android kitkat and i want to disable root acces to adb .
Can you help me please
labiba
I'm trying to get a script to execute via init.d or even in the terminal ... sh ./script but am running into issues that I'm not sure why or what is happening. I can't get the script to even execute via command line with the terminal app...so I need to figure that out first then maybe init.d will work. I can however execute the command in the script just fine, so I am not sure what is going on. It should be a simple script that I've seen posted on XDA. I started a thread over on the blaze dev section buy have been told it would fit here better so I'm posting a link to what I've already done.
http://forum.xda-developers.com/showthread.php?p=45042841#post45042841
As you can see from that link and the screenshot the execution of the script fails but I can echo that string in just fine. I'd like to get this scripted to it will work on boot and hopefully find a way to make it run before apps start starting so the sd card will prepare faster and the files I have apps linked to will be present when there requested...which is a problem.
Thanks!
Hi
I've installed CM10.2 (last update) (http://forum.xda-developers.com/showthread.php?t=2499796) on my Archos 80G9. It also runs the SDE firmware from Archos (http://forum.xda-developers.com/showthread.php?t=1653566). So far, so good, it runs quite nicely, all things concerned. Here's a screenshot to the system info: https://www.dropbox.com/s/0ri8n4jb6gyrfz7/Screenshot_2014-11-17-20-56-01.png?dl=0
Now I'm trying to install X-posed Framework, but this won't work. When I try, I get an error that tells me /system can't be mounted. (Screenshot: https://www.dropbox.com/s/ryaryqkie023sl4/Screenshot_2014-11-17-20-40-16.png?dl=0 )
When I take a look is ES3 if the folder is mounted, it looks like this: https://www.dropbox.com/s/4kwv0ja16qz52tq/Screenshot_2014-11-17-20-49-21.png?dl=0 . I can't tick the other boxes here, I get the message "sorry, operation failed" when I try.
I've already tried to use the "mount -o remount,rw /" command, to no avail...
I have no idea how I have to fix this problem and if it's even fixable.
Does anyone have any idea? Thanks in advance!
Same here...
No solution for that yet.
Before you type the mount command did you type "su" first (without the quotes)?
Just opening up terminal gives you regular user permissions which will not let you run the mount command. You need to become root/superuser first and that's what su does.
Yes I did ... Terminal emulator gives a notification that It's been granted superuser permission, but it still doesn 't Work.
Sent from my Ascend Y300 using XDA Free mobile app
Can you send a screenshot of the "mount" comand and response?
Did the prompt change from $ to #? What was the output of "mount"?
If terminal doesn't work try with superuser adb (allow superuser not only from applications, but from adb). Connect to the device with "adb shell" and issue this command.
Hi, thanks for your response. Here are two screenshots: the first is of the mount command in Terminal Emulator, the second of the same via abd shell. No results.
Very strange, since filesystem seems to be remounted rw Ok.
In fact, I've installed xposed some two days ago on 101g9/cm10.2, so this should work.
Let's try to sort it out.
1) What version of xposed do you try to install? I've used latest stable (2.6 IIRC).
2) Do you use "standard" installation mode in xposed settings (just under the popup window on your screenshot)?
3) Try to issue the following commands in shell after remounting "/" (terminal or adb - doesn't matter)
# touch /system/bin/mytest.tmp
# ls -la /system/bin/mytest.tmp
If the file is created Ok, then the filesystem is mounted read-write correctly.
You can delete this file afterwards with
# rm /system/bin/mytest.tmp
4) Did you grant permanent or one-time superuser permission for xposed? If one-time, try permanent: it can be so, that "cp" fails due to lack of superuser permission.
Bor-ka said:
Very strange, since filesystem seems to be remounted rw Ok.
In fact, I've installed xposed some two days ago on 101g9/cm10.2, so this should work.
Let's try to sort it out.
1) What version of xposed do you try to install? I've used latest stable (2.6 IIRC).
2) Do you use "standard" installation mode in xposed settings (just under the popup window on your screenshot)?
3) Try to issue the following commands in shell after remounting "/" (terminal or adb - doesn't matter)
# touch /system/bin/mytest.tmp
# ls -la /system/bin/mytest.tmp
If the file is created Ok, then the filesystem is mounted read-write correctly.
You can delete this file afterwards with
# rm /system/bin/mytest.tmp
4) Did you grant permanent or one-time superuser permission for xposed? If one-time, try permanent: it can be so, that "cp" fails due to lack of superuser permission.
Click to expand...
Click to collapse
1) I had 2.7 Experimental, so I uninstalled it and installed 2.6 Stable instead.
2) I do indeed use the "classical" option for installing Xposed.
3) Tried it, gave the following result: the file is created in /System/bin, so I guess /sytem is mounted okay. (see screenshots)
4) I use SuperSU, XPosed had root acces (see screenshot)
Seems to me /system is mounted fine, but Xposed just doesn't know it...
Ok.
The problem is with xposed, obviously.
For me, it complained that it can not remount /system (obviously), but then installed Ok.
So, what I would do
1) Check the filesystem mounts. May be, for some reason, you have /system mount (quite improbably, but nonetheless). Try in the terminal
# mount
It will show a list of all active mounts with the following format
[what is mounted] [where mounted] [blah-blah and stuff]
For example, from anothe device
/dev/block/platform/hi_mci.1/by-name/system /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
You can see that something is mounted at "/system" readonly ("ro" attribute)
2) Check if the /system/bin/app_process.orig already exists
# ls -la /system/bin/app_process.orig
3) Try to use logcat to obtain info. That is tricky
a) On the PC issue command "adb logcat > logcat.txt"
b) Start xposed installer, try to install, get an error
c) on PC press Ctrl-C
Bor-ka said:
Ok.
The problem is with xposed, obviously.
For me, it complained that it can not remount /system (obviously), but then installed Ok.
So, what I would do
1) Check the filesystem mounts. May be, for some reason, you have /system mount (quite improbably, but nonetheless). Try in the terminal
# mount
It will show a list of all active mounts with the following format
[what is mounted] [where mounted] [blah-blah and stuff]
For example, from anothe device
/dev/block/platform/hi_mci.1/by-name/system /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
You can see that something is mounted at "/system" readonly ("ro" attribute)
2) Check if the /system/bin/app_process.orig already exists
# ls -la /system/bin/app_process.orig
3) Try to use logcat to obtain info. That is tricky
a) On the PC issue command "adb logcat > logcat.txt"
b) Start xposed installer, try to install, get an error
c) on PC press Ctrl-C
Click to expand...
Click to collapse
Alright, did all of it.
1) Don't fully understand what is listed here, but in the first screenshot is the list of mounts.
2) Checked it, doesn't seem to exist, see second screenshot.
3) Logcat is attached.
Ok, it appears that I got the problem. Need a little time to think how to solve this.
The problem is rather technical. In newer androids supersu has isolated filesystem mounts for different processes.
It means that if you remount filesystem rw in one process, it (read-write-ness) is not accessible to the other process.
I have a little older cm10.2 build (for low-memory devices), perhaps, this was enforced later.
http://su.chainfire.eu/#how-mount (3.5)
So you're saying there's a good chance that if I install version 22_12_2013-13_29_20 (which i was planning anyway), instead of the latest one, the problem could be fixed?
Hmm, I installed the previous version of CM10.2, the problem seems to be persisting...
I noticed something today. I can create and remove files in /system using the emulator. I can't however do this using ES3 file explorer, even though it has root access. I was trying to edit the build.prop file, but it wouldn't let me save my changes.
I then tried to copy a file to /system in es3, this didn't work. Creating a tmp file using emulator did work. Seems I do have rw access to /system, but not with all apps...
I noticed something today. I can create and remove files in /system using the emulator. I can't however do this using ES3 file explorer, even though it has root access. I was trying to edit the build.prop file, but it wouldn't let me save my changes.
I then tried to copy a file to /system in es3, this didn't work. Creating a tmp file using emulator did work (permission denied). Seems I do have rw access to /system, but not with all apps...
Well, it seems like what I've said, filesystem mount encapsulation.
I've noticed one thing - you are using the standalone supersu application. And for me superuser mode is integrated in the system settings near the developer options. May be this is the case, internal superuser is patched already.
Alright, I'll uninstall superSU for now, give it a go with the built-in superuser app. I'll let you know!
Supersu application, theoretically, could have replaced libsuperuser and other stuff integrated in the CM.
So, if just uninstalling does not work, perhaps it will make sense to reinstall CM itself.
P.S. I have mixed feelings with CM. On the one hand it is definitely more fluid, than 3.* or 4.* stock ROMs. On the other hand deep sleep works, well, strange, and the tablet sometimes freezes in the sleep or turns off by itself.
Yes, I have enabled deep sleep, but the battery drains definitely faster in the sleep. For me it is essential, since I mostly use it as a amazon kindle / google books / pdf reader terminal. And most of the time it just sleeps.
Bor-ka said:
Supersu application, theoretically, could have replaced libsuperuser and other stuff integrated in the CM.
So, if just uninstalling does not work, perhaps it will make sense to reinstall CM itself..
Click to expand...
Click to collapse
Eureka! I re-installed CM, issued the mount-command i used earlier and installed X-posed! I used the built-in superuser app, no such problems as before. I did have to issue the mount-command, but that isn't a problem Is it normal I have to re-issue the mount-command each time I want to access /system rw?
Thanks a million! I can't believe it was something this trivial But I'm so glad it's solved, thanks!
Bor-ka said:
P.S. I have mixed feelings with CM. On the one hand it is definitely more fluid, than 3.* or 4.* stock ROMs. On the other hand deep sleep works, well, strange, and the tablet sometimes freezes in the sleep or turns off by itself.
Yes, I have enabled deep sleep, but the battery drains definitely faster in the sleep. For me it is essential, since I mostly use it as a amazon kindle / google books / pdf reader terminal. And most of the time it just sleeps.
Click to expand...
Click to collapse
I don't use the deepsleep-option. I do use Greenify to ensure certain apps (like Youtube or Chrome) aren't active in the background. Boot manager to be sure only essential apps boot in the first place. This seems to save me some battery life. Airplane mode as well.
I got this tablet from my dad because it was so slow he couldn't work with it. Even after factory reset, it very quickly became sluggish again. With CM, it feels like it's a new tablet. So no doubts about CM for me
I do have another issue: My pc won't show the tablet in explorer. I can access it via ADB, but I can't access the storage via explorer... I suppose I best start a new topic for that...
Glad the issue was solved. I wonder why the superuser application didn't work.. Deepsleep - it allowed the tablet to lose, say, 10-15% charge during a week sleep. Very handy if the tablet is used not often - really miss it.
Explorer connection - if I remeber correctly, you should go to settings -> storage (where the size of apps/pictures etc is shown). Then press the three dots in the upper right corner, select "usb computer connection" and select MTP.
P.S. I wonder also if CM12/Android 5.0 in the "development" section is worth a try...
Hello there, it's been a while since I've been here, I had a Samsung Galaxy S2 last time I posted. Anyway...
I was trying to enable the Camera2 API, so I unlocked my bootloader for it. I followed a guide that explained how to do the API thing without installing a custom recovery or rooting, however while everything went well (no errors during the procedure), the API wasn't actually enabled. And I confirmed it by reading the build.prop file, finding out that the "persist.camera.HAL3.enabled=1" line was not in it.
The guide I followed consisted in booting the TWRP recovery from fastboot, and pushing commands through adb shell that way; "setprop persist.camera.HAL3.enabled=1", to be precise. It didn't work though.
So naturally, I searched for another way, and found one that uses a different way of adding that line to the build.prop file, by pulling said file from the system partition, editing it on the PC running adb, pushing it back to /system, and setting the permissions through the following commands:
Code:
adb pull /system/build.prop
Then, after editing the file through notepad++, adding the "persist.camera.HAL3.enabled=1" line
Code:
adb push build.prop /system
to put it back, edited, and then to set the permissions
Code:
adb shell
cd system
chmod 644 build.prop
My question is: can this second method be mixed with the frist one? Essentially, can I do the pull/edit/push/chmod series of commands off of a TWRP that I'm temporarily running via fastboot? Or does it have to be installed?
I know that you might wonder "why don't you just flash it, making your life easier?", but now it's a matter of principle, I need to know if this can be done without doing it. Plus, since I don't plan on doing anything else that needs it, it's kind of a waste of time having to then go back to the original recovery.
Hope someone can help me with this doubt, thanks in advance to anyone who will!
First time posting and I wanted to say thank you to all the excellent talent here on XDA! None of this would have been done without the work of so many people.
I have a Moto G Play (2021) (XT2093-4) that I recently purchased (Best Buy - $159 US/Carrier Unlocked) and I wanted to document my adventure in to rooting, making '/system' RW, and fixing the missing LED notification light (hint: I used the charging light) (hint^2: It's not required to make '/system' RW in order to fix the LED notification light - I just wanted more control over my phone).
First, "OEM unlocking" was greyed out for me, but became available after several days of having the phone online with a SIM card.
I followed the instructions here to unlock the bootloader and root with Magisk (Non-TWRP). Along with these instructions.
Once bootloader is unlocked, you will need the 'boot.img' file from your stock firmware. I used the "Rescue and Smart Assistant" utility to grab a copy of the stock firmware (GUAMNA_RETAIL_QZAS30.Q4_39_35_9_subsidy_DEFAULT_regulatory_DEFAULT_CFC.xml) and extracted the "boot.img" file for the next steps.
Continue installing Magisk (Filenames may be different! Don't just copy and paste.):
Code:
adb install Magisk-v23.0.apk
adb push boot.img /sdcard/Download
(Follow the instruction on your phone to patch 'boot.img' in Magisk)
adb pull /sdcard/Download/magisk_patched-23000_aKKMt.img
adb reboot bootloader
fastboot flash boot_a magisk_patched-23000_aKKMt.img
fastboot flash boot_b magisk_patched-23000_aKKMt.img
You should now have a working, rooted Moto G Play. You can just stop here and have fun with your phone, but I noticed that even with root, the system partition was not RW.
I followed these instructions to make '/system' writable (Note: you will need the 'sysrw_repair.zip' that's included in the bundle and a Linux system):
Code:
adb push systemrw_1.32_flashable.zip /data/local/tmp/
adb shell
su
cd /data/local/tmp/
unzip systemrw_1.32_flashable.zip
cd systemrw_1.32/
chmod +x systemrw.sh
./systemrw.sh in=`ls -l /dev/block/by-name/super | awk '{print $NF}'` out=/data/local/tmp/systemrw_1.32/img/super_original.bin size=50
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
(On another Linux terminal)
Code:
cd /path/to/unzipped/sysrw_repair/dir/
chmod +x sysrw_repair.sh
./sysrw_repair.sh
This results in a new folder (img) with a rather large bin file (super_original.bin).
(Back on the phone adb)
Code:
exit # Exit root
exit # Exit adb
adb reboot bootloader
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
You should be able to login and have a writable '/system':
Code:
adb shell
su
mount -o rw,remount /
No errors should appear.
Last, I like having an LED indicator that tells me that I have an SMS/MMS notification waiting. Motorola thought it would be wise to eliminate that feature altogether instead of having the option to enable it. So, I forced it back on using a startup script that dumps the notifications and greps for some key words. And, if it finds something, it "breaths" the charging LED. The script loops until the notification is gone, then keeps checking for new notifications every 30 seconds. (Note: the "/data/adb/service.d/" directory is used by Magisk like an INIT service):
(Still root on the phones adb)
Code:
cd /data/adb/service.d/
cat <<EOF > ledfix.sh
#!/bin/sh
while true; do
if dumpsys notification | egrep NotificationRecord | egrep sms > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) == 0 ]]
then
echo 1 > /sys/class/leds/charging/breath
sleep 2
continue
else
sleep 2
continue
fi
elif egrep 'Charging' /sys/class/power_supply/battery/status > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) -ne 0 && $(cat /sys/class/leds/charging/brightness) -ne 0 ]]
then
echo 0 > /sys/class/leds/charging/breath
echo 255 > /sys/class/leds/charging/brightness
elif [[ $(cat /sys/class/leds/charging/breath) == 0 && $(cat /sys/class/leds/charging/brightness) == 0 ]]
then
echo 255 > /sys/class/leds/charging/brightness
else
continue
fi
else
echo 0 > /sys/class/leds/charging/breath
echo 0 > /sys/class/leds/charging/brightness
fi
sleep 30
done
EOF
chown 0.0 ledfix.sh
chmod 0755 ledfix.sh
reboot
Now, the charging light will fade off and on about every 2 seconds if there's an SMS/MMS notification waiting. And will check for notifications every 30 seconds. I'm sure someone can come up with a better way of doing this, but this was a nice quick-and-dirty way to get what I wanted.
Hope this helps!
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
PROFSLM said:
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
Click to expand...
Click to collapse
You can also get the firmware from
Lolinet Mirrors
https://t.me/MotoUpdatesTracker
Search for Firmware by codename, software channel, Software Version, and build #
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
mario0318 said:
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
Click to expand...
Click to collapse
I know!
I don't know what triggers that light to come on. I even waited until the battery was at 6% and the light still never came on.
So, I updated the script above to make the light go full brightness if the battery is charging. The order matters, so if a notification comes in while charging, it'll "breath" the LED. Also, if the battery is full, then the light will turn off. Kind of telling you that it's time to unplug.
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
jorduino said:
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
Click to expand...
Click to collapse
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
mario0318 said:
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
Click to expand...
Click to collapse
Im not completely sure how to get the right file, but I think the first time it was the wrong one, but then when i got what i thought was the right one, it just didn't work at all and I had to recovery flash it. I had just updated so maybe the correct image wasn't available yet. Im going to try again though
Oh! Hello @latentspork. Thanks for your interest in my SystemRW project. I just came across this thread randomly...
I'm happy you got my script to work on your Motorola device by using the included sysrw_repair script
Please feel free to send me your log files from script folder. Thanks. It's useful for further development of the script
latentspork said:
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
Click to expand...
Click to collapse
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Yes that's true the included sysrw_repair script (Linux only) pulls the image files from the phone to your computer and attempts to run the same lpmake command with the same arguments that just failed with error 73 on the phone itself and now all of a sudden it just works in Linux. Go figure.
latentspork said:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Click to expand...
Click to collapse
Why would you delete the super_original.bin ? That's your stock read-only super image which by default is automatically dumped by script for backup purposes in case you ever get a bootloop.
And if you launch the script by specifying a custom input value (in=x) like in your example above then you won't even have a super_original.bin file to begin with because script will skip the whole dumping of original super image process.
latentspork said:
This results in a new folder (img) with a rather large bin file (super_original.bin).
Click to expand...
Click to collapse
I think you mean super_fixed.bin
latentspork said:
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
Click to expand...
Click to collapse
Here in your instructions you are manually flashing the wrong file. Shouldn't you be flashing super_fixed.bin to your super partition?
Usually I only flash the super_original.bin to get back out of a bootloop...
latentspork said:
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
Click to expand...
Click to collapse
See that's why I included that automatic flash() function in the repair script. Then you don't have to worry about manually flashing the wrong file to your super partition
Enjoy a fully read/write-able device!
Great news! New SystemRW version coming soon!
@lebigmac
I really appreciate the reply and the tool! It did work really well on my model (XT2093-4).
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Click to expand...
Click to collapse
I only assumed that "Error 73" was caused by insufficient space, because the phone really did run out of space. I noticed that the phone was out of space because I got a home screen notification warning, asking me to free up space. I confirmed it with a "df -h" at the shell. Apparently, the OS takes up almost 15GB. When you add the ".img" files, there's only about 5GB left. There wasn't enough room to complete the ".bin" file. Maybe I could have used an SD card or something.
You're probably correct in that "Error 70" is the correct error for that, but on my phone, I never saw that error. I did notice that the tool was still trying to write data as the phone ran out of space, then it would throw the "Error 73". Maybe it didn't register the lack of space, or just an oddity with my model? No idea.
Why would you delete the super_original.bin ?
Click to expand...
Click to collapse
This is the file that was created when I initially ran the "./systemrw.sh" command on the phone. The result of running the command on the phone were several ".img" files and a very large "super_original.bin", but it was incomplete because the command threw an "Error 73". I was following your instructions, and I noticed that the output name of the file was "original" instead of "fixed". I probably could of outputted it to a new name to reduce confusion, but I didn't really care too much about the name as long as I had a working file.
I think you mean super_fixed.bin
...
Shouldn't you be flashing super_fixed.bin...
Click to expand...
Click to collapse
Normally, yes. But the Linux script also outputted the filename "super_original.bin". Again, as long as it worked, I was okay with it. The commands I used above were the exact commands that I ran at the time. I copied them from the terminal consoles I was using. So I don't know why it wasn't outputting the correct filename (again, I was following your instructions and was a little confused that the names came out differently - I just figured I was doing something wrong like not use the proper output command or something).
Then you don't have to worry about manually flashing the wrong file to your super partition...
Click to expand...
Click to collapse
I was really just being cautious because my previous phone broke and I didn't have a fallback.
But, at no point were there two bin files (original and fixed), so there wasn't much confusion. Where I originally had just ".img" files before running the script, I now had a single ".bin" file. I knew that was the file I needed.
But again, thank you for all the hard work on this tool! I was reading that it's worked on lots of different model phones, and it's always good to see the open source community doing things that help all kinds of people.
For moto notification for this phone at least use https://play.google.com/store/apps/details?id=br.com.itsmeton.motoledreborn or moto led reborn from the play store it just works
Hi, sorry. This can be removed. I put it in place because I was having issues with the xda app. For whatever reason, every time I tried to share this particular post, it would share a link for the post which I used originally, rather than the current post. I knew that if I commented I could get back here easily on my PC.
So what is the place holder for