• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root I got it! I got it! I don't got it.

First, thanks for all the great root info. It worked perfectly, right up to the point where it all went horribly wrong (I'm exaggerating. At least the phone still works).

I used the one click root and it seemed to go very well. I didn't have Superuser installed BEFORE using it, but upon installing it after the fact, everything looked good. I added BusyBox and things were still good.

Within a minute, however, I was prompted to update the SU binary, and, not knowing at the time that this was a BAD thing, I did so.

Now I've gone through several levels of removing all this software in an attempt to start from the beginning, up to and including a hard reset of the phone. ...not happenin'. Each time I try to run the one click, I get something similar to this:

failed to copy 'su' to '/system/xbin/su': No space left on device
Unable to chmod /system/xbin/su: No such file or directory
link failed File exists

Sometimes there's also mention of "read only".

BusyBox won't run because it says it can't find the SU binary, SuperUser can't update itself out of this hole for the same reason. I'm able to see the SU file using a root browser, but can't do anything with it. Conclusion - The only way to fix the problem is for the problem to already be fixed.

I guess the questions at the end of this long winded backstory are:
1. Any suggestions on how to get over this speed bump?
2. If I do nothing and pretend it never happened, has anything been changed in this process that will be a problem later for normal operation?
3. What's the atomic weight of Beryllium?

Thanks to anyone reading this for your time and any wonderfulness you may pass my way.
@Exile - Installing from the Market is what got it working for the short time it worked. For each subsequent attempt, I've made sure it was in place BEFORE running the One Click. It's made no difference.

@Mmazz - I was a little concerned about the update fixer as I saw reviews saying it made the problem worse. I just tried it, though, and in my case it says there is no problem detected. I forced the fix anyway, and it hangs at "getting root access". Backing out of the app leaves me right where I was.

Thanks to you both for trying.
Upvote 0
That was one I tried before posting.

I was wrong about the SU binary, though. The one I'm seeing is in /bin, not /xbin, which (I think) means it's the symlink, not the actual binary (adb shell "ln -s /system/xbin/su /system/bin/su"). Still, it seems to confirm that the original process was sucessful, cuz ya can't link to something that wasn't there.

I recall seeing a post regarding a permissions fix, but can't find it now. It may have nothing to do with my problems, but it sure has the feel of it. Any thoughts on that?


Moving away from the permissions theory - My /xbin is chock full of files (presumably all BusyBox related) and the memory shows only 24k free. Since the SU binary is 26k, the "No space left on device" message is dead on, not just some "Oh, you can ignore that." thing. It seems that the failed update removed the old file but never replaced it with a new one. Everything else is still exactly where it needs to be, or at least WILL need to be. For now, I need to get at least one of those files to go away to make room for SU. So, the problem as I now see it is, I can't clear out those BB files without root, I can't get root without the SU binary, and I can't push the binary without removing a BB file. Isn't circular logic just the funnest thing?

I still don't get why the update fixer says everything's fine, but that's now the only thing that doesn't fit. ...at least until someone jumps in and tells me my theory is completely wrong. I await that moment patiently.

The new question in the mix - Is there a less restricted folder of useless crap in internal memory from which I can delete something just to make the room I need?
Upvote 0
I have progress to report.

By editing the original Run.bat in the One Click Root, I was able to pull, modify permissions on, and then delete a file in the /System/Apps folder. I chose Metro's "MyExtras.apk" because it wouldn't be missed or get in the way of upcoming steps. It can always be pushed back to the phone later by the same process, even without root, which becomes important (to me anyway) later because my intention now is to unroot. My only reason for wanting root to begin with was so I could put ringtones into internal memory, and I can accomplish that with ADB from this point on.

Next I ran the One Click to push the SU binary back to the phone. Since I had a Market copy of SuperUser already in place at this point, I edited out that portion of the Run.bat before use. This has left me with a properly rooted phone.

I've uninstalled BusyBox, both through the Market AND through App Management. This may be unique to my case due to the fact that I installed both through the Market and via a local .apk on the SD card at different points. It may also be why I still have what looks like a bunch of BB files in the /bin folder, and I'll be dealing with them using the pull>chmod>delete process used above once I compare with my wife's untouched phone to see what really belongs in there.
---edit: This was coincidental. The files in bin were identical between rooted and untouched phones, with the exception of the SU binary symlink.

Once all that is cleaned, I can move on to the final step and do the same thing to the SU binary and the symlink that goes with it (just as soon as I learn how to remove a symlink using ADB ...Anybody?)
---edit: Exactly the same way as removing a file, though if you leave in the pull command, you'll get an error telling you it's not a file or folder. It doesn't keep the deletion from working.

This takes a bit of patience, but the end result is a clean, unrooted phone WITHOUT using Odin (no yellow exclamation point).

Too many thanks to list to posts in this forum for providing pieces for this puzzle, most notibly to those who found the exploit that makes the rest of this possible, to Exile1975 and Mmazz for trying to help me here in this thread, and also to this post
Unrooting is rather easy. Use root explorer and delete superuser.apk from the /system/app folder. Go to the Android market and download and install super user. Use root explorer again and delete su from /system/bin. Go to the market and uninstall super user. Now you are unrooted.
in the Esteem forums for the idea that it was possible to step backward rather than making even bigger changes to get back to stock and end up with a new set of problems.

I gotta say, though, there were a few brick walls, too. I'd find someone asking the same questions I had, then they'd pop back in and say, "Oh, now I've got it!", and leave everyone else hanging. The only class I ever failed in school was my first year of Algebra, because I'd always get the right answer, but I'd never show the work that got me there. At the time, I didn't understand why that was a problem. I'm not trying to pick on anyone. This is more a justification of why my posts are so long.

Throughout this adventure, I've been using Root Browser Lite by jRummy16 to get a look at whether what I've done has worked. Root Explorer didn't work properly during the time when I didn't have root. This did.
Upvote 0
BTW - Here's the contents of the .bat I used:

@echo off
cd "%~dp0"

adb wait-for-device

echo "
[*] Triggering core dump..."
adb shell "rm /data/log/dumpState_app_native.log 2>/dev/null"
adb shell "ln -s /data/local.prop /data/log/dumpState_app_native.log 2>/dev/null"
adb shell "app_process /dev/null"

adb shell "echo "ro.kernel.qemu=1" > /data/local.prop 2>/dev/null"
adb reboot

echo "
[*] Rebooting phone. It may buzz a lot and loop on boot. Don't panic."
adb wait-for-device

adb shell "rm /data/local.prop 2>/dev/null"
adb shell "rm /data/log/dumpState_app_native.log 2>/dev/null"

adb remount
adb pull /system/app/MyExtras.apk MyExtras.apk
adb shell "chmod 777 /system/app/MyExtras.apk"
adb shell "rm /system/app/MyExtras.apk"

echo "
[*] File(s) should now be gone"
adb reboot

echo Press any key to exit the script.
adb kill-server

Everything up to and including "adb remount" is left untouched from the original in the One Click. It's the reason it works. The "adb pull" line is only necessary if you want to make sure the file is available to put back later. Obviously, the path and file name get changed to whatever you're trying to remove at the time, which brings us to the disclaimer:

Take a look through these forums for the stories of people who have deleted files without knowing the full extent to which they were needed by the system. Make sure it's safe to remove BEFORE you remove it.
  • Like
Reactions: Mmazz
Upvote 0


We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.