Related
Ok, so I must admit I am still learning stuff. I have a deodexed KA5 that I would like to post but have been unable to add root to it. I have the su binary in /system/bin and the superuser.apk in /system/app, but when I flash the rom in recovery I get an su symlink error and the installation aborts. Any help would be appreciated. Thank you.
I may not be able to help, but if you post it... we can download and look in there.
I think I might have got it figured out. It has to do with how the update-script is set up and they weren't matching up. Gonna try repacking this and giving it another go. Really want to get this out to ppl.
Yay it boots!
is it odexed or deodexed?
Also, you need the su binary in /system/bin but it also needs to symlink to /system/xbin.
If you're doing an odexed rom, the recent releases haven't had enough room to add root and install busy box and keep everything the same. So you'll need to remove some bloat from the system file (which you can add to the data file) in order to have root with busy box.
So i Have been working on my new rom, now i Have it all AOSP as i can, and just have sense stuff we need, but now i have no root access, none of my root apps will work, i need help becuase i need root access to run a lot of helpful programs, i think i deleted someth ing in the sy stem folder that was important to root.
rtbluver said:
So i Have been working on my new rom, now i Have it all AOSP as i can, and just have sense stuff we need, but now i have no root access, none of my root apps will work, i need help becuase i need root access to run a lot of helpful programs, i think i deleted someth ing in the sy stem folder that was important to root.
Click to expand...
Click to collapse
my app root check, for free on the market, when run in advanced mode will give the technical details as to which files might be missing or configured incorrectly.
easiest solution is to download superuser.apk from the market or flash the superuser install .zip from recovery which should reconfigure the complete root setup.
hopefully that works, if not, let us know!
joeykrim said:
my app root check, for free on the market, when run in advanced mode will give the technical details as to which files might be missing or configured incorrectly.
easiest solution is to download superuser.apk from the market or flash the superuser install .zip from recovery which should reconfigure the complete root setup.
hopefully that works, if not, let us know!
Click to expand...
Click to collapse
Doin it all now, but it looks like i deleted something good, because my wifi is giving me errors too. So I mightve deleted some framework. Hmmm
rtbluver said:
Doin it all now, but it looks like i deleted something good, because my wifi is giving me errors too. So I mightve deleted some framework. Hmmm
Click to expand...
Click to collapse
Root Access is not properly configured or was not granted.
Superuser.apk - com.noshufou.android.su - version 2.3.6.3 is installed!
Standard su binary location: ls -l /system/bin/su:
null
Standard su binary location: ls -l /system/xbin/su:
null
Alternate su binary location: ls -l /sbin/su:
null
SU binary not found or not operating properly
Results provided by Root Checker version 3.4 from joeykrim in the Android Market - http://goo.gl/GgWae
Root checker stats when i run the advanced check, I just flashed su zip too. Is there something in the framework for editing root, becuase wifi is error too, hmm more flashing and checking.
rtbluver said:
Root Access is not properly configured or was not granted.
Superuser.apk - com.noshufou.android.su - version 2.3.6.3 is installed!
Standard su binary location: ls -l /system/bin/su:
null
Standard su binary location: ls -l /system/xbin/su:
null
Alternate su binary location: ls -l /sbin/su:
null
SU binary not found or not operating properly
Results provided by Root Checker version 3.4 from joeykrim in the Android Market - http://goo.gl/GgWae
Root checker stats when i run the advanced check, I just flashed su zip too. Is there something in the framework for editing root, becuase wifi is error too, hmm more flashing and checking.
Click to expand...
Click to collapse
i've never seen null in the results ... and you say you have a wifi error.
i would suggest reflashing whatever ROM you're currently on. when you flash a ROM, they generally wipe your /system and reload a full /system.
if you're on a custom kernel, i'd also reflash the kernel (kernel .zip files will include its required modules) as the kernel and modules, including wifi, in /system/lib/modules have to match.
as long as you flash the same ROM you're currently running, you *shouldn't* have to wipe data.
i'm not sure what you might have erased but making a nandroid backup for you venture into modifying system files is generally a good practice!
edit: i see in your signature you're running your own ROM. assuming you have more knowledge/experience than average, if you'd prefer not to flash over your current ROM and lose whatever changes you've made that you do want to keep, you could try swapping individual files from the original ROM back onto your current system as see if that fixes the issues.
although for the wifi issue, since your signature shows silverneedle, i'd just flash silverneedle and that should guarantee the wifi modules match up with the kernel and clear the wifi issue. if the wifi issue isnt cleared, then something else in /system might have been modified and you're back to swapping individual files from the known working rom.
hope that helps!
joeykrim said:
i've never seen null in the results ... and you say you have a wifi error.
i would suggest reflashing whatever ROM you're currently on. when you flash a ROM, they generally wipe your /system and reload a full /system.
if you're on a custom kernel, i'd also reflash the kernel (kernel .zip files will include its required modules) as the kernel and modules, including wifi, in /system/lib/modules have to match.
as long as you flash the same ROM you're currently running, you *shouldn't* have to wipe data.
i'm not sure what you might have erased but making a nandroid backup for you venture into modifying system files is generally a good practice!
edit: i see in your signature you're running your own ROM. assuming you have more knowledge/experience than average, if you'd prefer not to flash over your current ROM and lose whatever changes you've made that you do want to keep, you could try swapping individual files from the original ROM back onto your current system as see if that fixes the issues.
although for the wifi issue, since your signature shows silverneedle, i'd just flash silverneedle and that should guarantee the wifi modules match up with the kernel and clear the wifi issue. if the wifi issue isnt cleared, then something else in /system might have been modified and you're back to swapping individual files from the known working rom.
hope that helps!
Click to expand...
Click to collapse
Yah, Im trying files out, updated busybox, but my wifi problem may lie in the kernel change with the ROM, because i changed my ROMs kernels to RCmix and now im getting the wifi error, but Im trying to go into the rom system, to see what i screwed up, i will report back.
rtbluver said:
Yah, Im trying files out, updated busybox, but my wifi problem may lie in the kernel change with the ROM, because i changed my ROMs kernels to RCmix and now im getting the wifi error, but Im trying to go into the rom system, to see what i screwed up, i will report back.
Click to expand...
Click to collapse
Placed Busybox in wrong directory! Im all good now, thanks!
Im running ICS SlimROM 1.6 and (was) loving it. But:
Titanium Backup Pro prompted for an update, which I ran, then it barfed and told me to install BusyBox from the market
Installed BusyBox, which got TB to run
uninstalled WiFi tether ( not working, another issue.....)
Next full reboot of phone, its stuck at the Google Gears
Then:
I went into recovery, wiped cache, Dalvik and ran fix permissions
Reboot, stuck at Google Gears
Mounted SD in Recovery, copied my PH98img file to SD, fastboot and ran update
Still stuck at Google Gears
I need to get the file off of SD to get into Recovery again, but when I do, what next ? Full wipe ? Reflash ROM ?
Only thing I can think of is BusyBox broke the ROM......am I wrong ?
I was stuck doing a full reflash of the rom, fixes, updates etc.......only thing I can figure is that the supersu was gorked...... Superuser (chainsdd) from the market ended up on my phone after the busy box install and didn't want to work or be removed until reflash.
Sent from my ADR6425LVW using xda app-developers app
archalon said:
Im running ICS SlimROM 1.6 and (was) loving it. But:
Titanium Backup Pro prompted for an update, which I ran, then it barfed and told me to install BusyBox from the market
Installed BusyBox, which got TB to run
uninstalled WiFi tether ( not working, another issue.....)
Next full reboot of phone, its stuck at the Google Gears
Then:
I went into recovery, wiped cache, Dalvik and ran fix permissions
Reboot, stuck at Google Gears
Mounted SD in Recovery, copied my PH98img file to SD, fastboot and ran update
Still stuck at Google Gears
I need to get the file off of SD to get into Recovery again, but when I do, what next ? Full wipe ? Reflash ROM ?
Only thing I can think of is BusyBox broke the ROM......am I wrong ?
Click to expand...
Click to collapse
Most likely, you installed busybox to the /system/bin/ directory.
Uninstall it, restart your phone, then re-run the busybox installer, except this time make sure you select /system/xbin/ as the install path.
a.mcdear said:
Most likely, you installed busybox to the /system/bin/ directory.
Uninstall it, restart your phone, then re-run the busybox installer, except this time make sure you select /system/xbin/ as the install path.
Click to expand...
Click to collapse
I'm on CleanRom 4.4 and it runs fine. I have the BusyBox install app from the market. I currently have BusyBox 1.20.2 installed and it's installed in /system/bin. That's where it wanted to install it, so i let it. I have had no problems with it being there. Should I move it? What is the pros and cons of it being in /system/bin vs /system/xbin??
Thanks.
derek4484 said:
I'm on CleanRom 4.4 and it runs fine. I have the BusyBox install app from the market. I currently have BusyBox 1.20.2 installed and it's installed in /system/bin. That's where it wanted to install it, so i let it. I have had no problems with it being there. Should I move it? What is the pros and cons of it being in /system/bin vs /system/xbin??
Thanks.
Click to expand...
Click to collapse
If its working at /system/bin/ then its probably not an issue for you.
I have init.d scripts, and my init.rc calls for busybox to be located at /system/xbin/. If I accidentally installed busybox to /system/bin/, busybox and thus also my init.d scripts fail to load because the init.rc file still tries to load it all from /system/xbin/.
but, since its likely you didn't build your ROM yourself, you may not know exactly where its supposed to be installed. You could look at the original update script in the zip file that installed your ROM, because usually there will be an install path and associated symlinks in that script which you can then use to determine where busybox is supposed to be installed on your particular device. Or, if your ROM has init.d support, you can look in the /init.rc file for the lines where busybox is called to enable init.d support. Your install path for busybox should mimic whatever path is called in this file, meaning if its attempting to load busybox from /system/xbin/, then that is where you need to have busybox installed, and not /system/bin/.
a.mcdear said:
If its working at /system/bin/ then its probably not an issue for you.
I have init.d scripts, and my init.rc calls for busybox to be located at /system/xbin/. If I accidentally installed busybox to /system/bin/, busybox and thus also my init.d scripts fail to load because the init.rc file still tries to load it all from /system/xbin/.
but, since its likely you didn't build your ROM yourself, you may not know exactly where its supposed to be installed. You could look at the original update script in the zip file that installed your ROM, because usually there will be an install path and associated symlinks in that script which you can then use to determine where busybox is supposed to be installed on your particular device. Or, if your ROM has init.d support, you can look in the /init.rc file for the lines where busybox is called to enable init.d support. Your install path for busybox should mimic whatever path is called in this file, meaning if its attempting to load busybox from /system/xbin/, then that is where you need to have busybox installed, and not /system/bin/.
Click to expand...
Click to collapse
I'm running Scott's CleanRom 4.4. I've looked in the updater-script file inside the zip.
I see the line: symlink("/system/xbin/busybox","/system/bin/busybox");
So, I am assuming that it can be installed in either location. When I installed busybox using the busybox install app from the market, it has "Smart Install", it scans system memory and then recommends where to install everything so I just let it do that.
derek4484 said:
I'm running Scott's CleanRom 4.4. I've looked in the updater-script file inside the zip.
I see the line: symlink("/system/xbin/busybox","/system/bin/busybox");
So, I am assuming that it can be installed in either location. When I installed busybox using the busybox install app from the market, it has "Smart Install", it scans system memory and then recommends where to install everything so I just let it do that.
Click to expand...
Click to collapse
So, according to that symlink, the actual location of busybox should be in /system/xbin/, but has created a symbolic link to /system/bin/ because some applications look for it in that location as well.
on a linux system, the physical location is the first listed path, the symbolic link is created by the second path, which essentially allows you to run busybox from either location even though it is actually located in /system/xbin/ and not /system/bin/
make sense?
I am able to build android from source for the Nexus 7. The OTA package I generate is flashable on the device with success. It is a completely empty image, only about 10 apps.
We require to install something as a system app on boot. So this brings up two questions:
- Is it possible/how to build android ota package that is already rooted?
- Is it possible/how to include a system app in android as it builds?
Thanks!
halsafar said:
I am able to build android from source for the Nexus 7. The OTA package I generate is flashable on the device with success. It is a completely empty image, only about 10 apps.
We require to install something as a system app on boot. So this brings up two questions:
- Is it possible/how to build android ota package that is already rooted?
- Is it possible/how to include a system app in android as it builds?
Thanks!
Click to expand...
Click to collapse
I think you just add the files to the source or/to the appropriate out folders...
For apps I believe (never done or attempted) you have to add it in a folder called prebuilts, you then have to edit some mk files to include everything in the prebuilt/where it goes in the out folder...again I've never done it or attempted, just what I think needs to be done
Root is acquired by Su and super user...so add a rooted Su to working/system/core/xbin I think...not positive ill double check when I get home...
Sent from my HTC PH39100 using Tapatalk 2
I figured out adding apps.
Need to create an Android.mk for the compiled APK, see here:
http://www.kandroid.org/online-pdk/guide/build_cookbook.html#prebuiltAPK
Place the Android.mk and compiled APK into packages/apps/SOMEDIR/
Modify build/target/product/core.mk to include your packages LOCAL_MODULE name under PRODUCT_PACKAGES.
Similar approach for SuperUser I imagine. Problem is manually copying su in as part of the build.
halsafar said:
I figured out adding apps.
Need to create an Android.mk for the compiled APK, see here:
http://www.kandroid.org/online-pdk/guide/build_cookbook.html#prebuiltAPK
Place the Android.mk and compiled APK into packages/apps/SOMEDIR/
Modify build/target/product/core.mk to include your packages LOCAL_MODULE name under PRODUCT_PACKAGES.
Similar approach for SuperUser I imagine. Problem is manually copying su in as part of the build.
Click to expand...
Click to collapse
You can replace the su folder that is built in with the chainsDD superuser files from github. This will compile the correct su right in your build. Should make everything work for you.
blazingwolf said:
You can replace the su folder that is built in with the chainsDD superuser files from github. This will compile the correct su right in your build. Should make everything work for you.
Click to expand...
Click to collapse
This seemed to work to gain access to su. However apps like busybox still don't think the device is rooted even though I can su via adb shell and modify things.
I placed the chainsDD repo into /system/extras/su during my build.
halsafar said:
This seemed to work to gain access to su. However apps like busybox still don't think the device is rooted even though I can su via adb shell and modify things.
Click to expand...
Click to collapse
Did you add the Superuser.apk as well?
blazingwolf said:
Did you add the Superuser.apk as well?
Click to expand...
Click to collapse
Okay now I have Superuser.apk installed in /packages/apps and chainsDD in /system/su, then I rebuild the ROM.
They both install, su works via adb shell.
Superuser is in the app list, opens fine.
Busybox still thinks it is not rooted and the "grant, deny" dialog window from Superuser does not open as I would have expected.
halsafar said:
Okay now I have Superuser.apk installed in /packages/apps and chainsDD in /system/su, then I rebuild the ROM.
They both install, su works via adb shell.
Superuser is in the app list, opens fine.
Busybox still thinks it is not rooted and the "grant, deny" dialog window from Superuser does not open as I would have expected.
Click to expand...
Click to collapse
Does your updater-script give the right permissions to su? set_perm(0, 0, 06755, "/system/xbin/su"); (This assumes su is in the xbin folder).
blazingwolf said:
Does your updater-script give the right permissions to su? set_perm(0, 0, 06755, "/system/xbin/su"); (This assumes su is in the xbin folder).
Click to expand...
Click to collapse
When I look at the otapackage.zip I can find inside the updater-script:
set_perm(0, 0, 06755, "/system/xbin/su");
I verified that is the correct location of su.
Hmm. Your boot.img is set for secure = 0?
I don't believe I changed that, likely it is whatever default value comes down in AOSP.
Where can I check? I grepped the repo and turned up a ton of secure ='s
AOSP has su, it is just not enabled for non debug builds. You can adjust its makefile so it is built into release build ROMS. This works to get su.
Like I said I adb shell, su, and run whatever commands I want as root. That works fine. I can write to /data/ for example.
The Superuser.apk appears to be the issue. It is being built into the OTA. It installs fine, appears in the app screen. However no apps can seem to figure out they can ask for root. TitaniumBackup is a good one to test. It appears the Superuser grant, allow window not popping up is what concerns me most.
halsafar said:
I don't believe I changed that, likely it is whatever default value comes down in AOSP.
Where can I check? I grepped the repo and turned up a ton of secure ='s
AOSP has su, it is just not enabled for non debug builds. You can adjust its makefile so it is built into release build ROMS. This works to get su.
Like I said I adb shell, su, and run whatever commands I want as root. That works fine. I can write to /data/ for example.
The Superuser.apk appears to be the issue. It is being built into the OTA. It installs fine, appears in the app screen. However no apps can seem to figure out they can ask for root. TitaniumBackup is a good one to test. It appears the Superuser grant, allow window not popping up is what concerns me most.
Click to expand...
Click to collapse
You need a modified su binary. Get the cm su to use SuperUser or SuperSu su. Either way you can't use stock su.
Sent from my Galaxy Nexus using xda premium
lithid-cm said:
You need a modified su binary. Get the cm su to use SuperUser or SuperSu su. Either way you can't use stock su.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
He added the chainsDD su code to his build. So it should be a modified one.
blazingwolf said:
He added the chainsDD su code to his build. So it should be a modified one.
Click to expand...
Click to collapse
Then he is doing something else wrong. In my aosp build I replaced su. That's it. Installed supersu and everything worked.
Sent from my Galaxy Nexus using xda premium
lithid-cm said:
Then he is doing something else wrong. In my aosp build I replaced su. That's it. Installed supersu and everything worked.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Agreed. Just trying to figure out what.
blazingwolf said:
Agreed. Just trying to figure out what.
Click to expand...
Click to collapse
Could be 1/1000s of things. If its not working the correct way it should. Then need to back track some changes.
Sent from my Galaxy Nexus using xda premium
I did this
https://github.com/GeekRom/android_system_extras/commit/9bd296ad4f674d30712f000560df47109dbc420c
https://github.com/GeekRom/android_vendor_geek/commit/e5d5a1f379b8dfc4b6a4868855b225ce3bc1df35
You can check the repo. Nothing else done for su.
Sent from my Galaxy Nexus using xda premium
lithid-cm said:
I did this
https://github.com/GeekRom/android_system_extras/commit/9bd296ad4f674d30712f000560df47109dbc420c
https://github.com/GeekRom/android_vendor_geek/commit/e5d5a1f379b8dfc4b6a4868855b225ce3bc1df35
You can check the repo. Nothing else done for su.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
OK. So that is a prebuilt module. Why not build su as you build the ROM.
blazingwolf said:
He added the chainsDD su code to his build. So it should be a modified one.
Click to expand...
Click to collapse
In regards to using chainDD's build I learned as I was back tracking that it was not building properly into the system, or so it appeared it wasn't. The 'su' I had was still the stock AOSP 'su'. All I did to add chainDD to the build was replace /system/extras/su with the contents of that repo.
lithid-cm said:
You need a modified su binary. Get the cm su to use SuperUser or SuperSu su. Either way you can't use stock su.
Click to expand...
Click to collapse
I manually copied in to the build the 'su' binary from Superuser.
Now I definitely see Superuser apk pop up when I 'su' under adb shell. Superuser logged the attempt, excellent.
All other apps get instant denied when attempting to ask for root (BusyBox, TitaniumBackup).
blazingwolf said:
OK. So that is a prebuilt module. Why not build su as you build the ROM.
Click to expand...
Click to collapse
SuperSu didn't release source for it.
Sent from my Galaxy Nexus using xda premium
This should be applicable to any ROM on devices which share internal storage for applications and the internal "sdcard" (Note II, SGS3, probably others). Symptoms may include inability to take screenshots and other failures, and will usually show a "Permission denied" in logcat for files under /data/media/. The underlying problem is that permission is denied to the filesystem, even by the root user when the ROM is booted (this is strange and I still don't understand why). Running "Fix permissions" did not fix this issue for me (that script doesn't change any permissions on the sdcard).
When booted into recovery (ClockworkMod was tested in my case), root has the ability to reset the permissions properly. To fix the problem, connect with adb while booted in recovery and run the following commands to correct the permissions:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
UPDATE (Credit to @Quinny899) If that does not work, you may also want to reset the SELinux contexts for the media partition with this command:
Code:
restorecon -FR /data/media/
Hope this helps! :victory:
I recently restored a Nandroid backup of my old Nexus 7 on a replacement Nexus 7. Most everything worked okay, but screenshots, deleting certain files and directories, and other basic operations weren't really working, and "Fix permissions" didn't help.
Running the commands here worked like a charm! I used TWRP and I have JellyBeer 4 on my Nexus 7. Thanks!
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
xak944 said:
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
Click to expand...
Click to collapse
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Yeah it's kinda funny. I had that script posted up in the ADBsync thread back in February because I noticed things could start acting funny when I restored an entire sdcard backup to one of my devices. But hey, great minds think alike! Good work all around!
Thanks @TheByteSmasher for bringing another use for the zip to my attention! I didn't know those things had a tendency to go awry on their own as well!
Edit:
Here's the edify script equivalent of the above, plus the proper original perms for /data/media itself, and the special perms that CWM likes its subfolder to have (root + all). TWRP keeps its backups under the primary user subfolder (/data/media/0) and doesn't seem to care as much.
cwm-sdcard.Fix.Permissions.zip/META-INF/com/google/android/updater-script:
Code:
ui_print("");
ui_print("sdcard Fix Permissions Script");
ui_print("by osm0sis @ xda-developers");
show_progress(1.34, 0);
ui_print("");
ui_print("Mounting...");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.2);
ui_print("");
ui_print("Setting /data/media to media_rw and fixing...");
set_perm_recursive(1023, 1023, 0775, 0664, "/data/media");
set_perm(1023, 1023, 0770, "/data/media");
set_progress(0.8);
ui_print("");
ui_print("Setting /data/media/clockworkmod perms...");
set_perm_recursive(0, 0, 0775, 0777, "/data/media/clockworkmod");
set_progress(1.0);
ui_print("");
ui_print("Unmounting...");
unmount("/data");
set_progress(1.2);
ui_print("");
ui_print("Done!");
set_progress(1.34);
Available over in my Odds and Ends thread as TheByteSmasher mentioned before.
Nice. Good to know this is a well known issue, I thought I was nearly alone (and it drove me up the wall for a while until I figured it out).
Does anyone know what is technically causing even the root user not to be able to write? I'm curious.
Probably because even root apps only run root commands when they need to, so for simple stuff could run into the same issue. Just a guess, but makes sense.
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
xak944 said:
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
Click to expand...
Click to collapse
Osm0sis actually states in the description of his zip, that when you use ADB push to put some stuff on the SD it can mess with the permissions... that's what did it for me.. but I guess a nandroid restore can cause it too depending on how it performs the action.
Sent from my Nexus 4 using Tapatalk 4 Beta
I'm ditching the idea of editing fix_permissions. The way they do all the system files is extremely intelligent and done on-the-fly based on the contents of certain system files to trace through. Adding something specifically for internal sdcards, even with the appropriate checks, would be a hack compared to all the really great work they've done to make the script device-nonspecific.
Deleted
1990mustafa said:
Deleted
Click to expand...
Click to collapse
Could somebody point me in the direction of how to do this for the Note 3 SM-9005 please?
I have an internal SD permissions issue and the flashable zip doesn't work, I presume because the directories are located slightly differently.
Many thanks
i m also stuck in same boat as none of scripts work for note 3... need some help / guidance here ..
You saved me, i was playing with ubuntu touch and i forgot that symbolic links and chown always modify the original directory and twrp could not fix the permissions!
Thank you! Works like a charm! :highfive:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
[email protected] said:
use for fixing access
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Worked a dream, might be useful for anyone else
Quinny899 said:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
Worked a dream, might be useful for anyone else
Click to expand...
Click to collapse
worked perfectly!
Hey, big THANKS to everyone who contributed to this thread. I restored by SD a different way than I used to do it and had this issue. I figured it was a permissions issue but couldn't get the 'Fix Permissions' function in TWRP or ROM Manager to fix it (now I know why). This saved me, much appreciated!
Quinny899 said:
Code:
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Oh man, so it was SELinux causing these issues all along!? I wonder why my original fix worked then since it didn't reset the SELinux context... Oh well, good to know.
Thanks @TheByteSmasher for leading me to the right solution
TheByteSmasher said:
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Click to expand...
Click to collapse
Thanks again
osm0sis said:
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc.
General Information
In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller scripts and zips I've created that I don't think merrit their own separate threads. This is partially for my own sanity and will hopefully make it easier for others to find some things as well. A lot of the stuff here was developed with the GN or N7 (my devices) and Windows in mind, but could generally be applicable to most devices either out-of-the-box or with some slight modification. If you see something that inspires you, go ahead and mod it, just let me know and give me some credit somewhere. If anyone would like to know the specifics of what's in a particular script that I haven't already linked to more information on, just let me know and I'll post that in here as well. Thanks!
Misc./Batch Tools
AnyKernel 2.0 (many devices) - link
AnyKernel was a simple template for an update.zip that could apply any kernel to any ROM, regardless of ramdisk to reduce the chance of any issues arising from the custom kernel pairing. The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. AnyKernel 2.0 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the install experience.
Android Image Kitchen (many devices) - link
A collection of Windows/Android ports of the necessary Linux utilities for Android image (kernel+recovery) mod work, and my own automation script to unpack, edit and repack the ramdisk. Other guides/scripts exist but none of them are universal for target device, compression and/or developed for Windows/Android. Now also Linux builds to bring my improved featureset back to where it came from. Has been extremely useful for me in my messing around with kernel ramdisks.
ADB Screenshot (all devices) - attached
Take screenshots while in recovery. Useful for development of recovery apps or error reporting. Original method had lots of different threads around with the general method for various devices but I figured out a couple tricks required for getting it working on the Galaxy Nexus and then automated the process. Tested and confirmed working with both pixel formats of CWM and TWRP. More information in this GN Q&A FFmpeg thread. New method uses fb2png and should work on all devices.
ADBsync sdcard Backup (many devices) - attached
Backs up the entire sdcard so that you can have a complete snapshot of your device when you make periodic backups, and be able to restore things exactly as they were. Automates the sync process of Renate NST's great ADBsync utility which makes only newer files get pulled, significantly decreasing backup time for the sdcard compared to "adb pull". Original version posted in the old ADBsync thread. Defaults for devices with /data/media/ internal sdcards (Nexus devices, etc.), but is easily customizable to backup other mountpoints.
Flashable Zips
Nexus BootUnlocker script (GN, N4, N5, N7 '13, N10) - attached
I don't know about everyone else but sometimes I find I've rebooted into the bootloader only to realize I've forgotten to unlock it in segv11's excellent BootUnlocker App beforehand. Well, I decided to make a BootUnlocker Script for my Galaxy Nexus so I could just boot to recovery quickly, unlock, then adb reboot-bootloader (or use my Reboot To Bootloader script below) to get back without having to fully boot the OS to make the change. Also extremely useful in the case you aren't able to boot. As with the app there is no data loss like there would be with fastboot, allowing you to relock for safety. Originally posted in the GN EDIFY Scripting thread. Modified for the newer Nexus devices and combined into a single Nexus BootUnlocker zip with tamperbit reset support added using information from the BootUnlocker App Dev thread.
N7 BootUnlocker script (N7 '12) [creation guide] - link
The Nexus 7 2012 is a special case. Per-device encryption of an entire partition makes it impossible to support the N7 '12 in a simple root app, or flashable zip as above, however using my guide and included script you can now create a working BootUnlocker Script Zip for your specific device. As with the above scripts there is no data loss like there would be with fastboot, allowing you to relock for safety.
Flashify script (many devices) - attached
This script zip makes flashing boot.img (kernel), recovery.img, and radio.img/modem.img (baseband) files via recovery simple. Inspired by cgollner's powerful and visually stunning Flashify App, it aims to save the average user the hassle of repacking their own image zip, or using the command-line or fastboot to flash it. Place an appropriately named file in the same directory as the zip and flash away! Should work on all emmc devices with normal partition naming ("boot", "recovery" and "radio" or "modem") which accept Android standards-compliant images. Extremely handy when used with amarullz' brilliant AROMA Filemanager, and/or my Android Image Kitchen: Mobile Edition (linked above).
Kernel Emergency Reset script (many devices) - link
Basically a go-to cure-all for custom kernel users experiencing issues after an upgrade due to old settings left over in a kernel control app (eg. franco.Kernel updater, Trickster, etc.), or problematic init.d/userinit.d scripts. It's also useful if you just want to make sure you're running clean defaults without conflicts.
Reboot To Bootloader script (all devices) - attached
Those who prefer using CWM may have noticed a couple of things missing that the other popular custom recovery, TWRP, has built-in. One of these is a file explorer/manager, which is answered by amarullz' brilliant AROMA Filemanager. Another thing I found myself wanting is a way to reboot back to the bootloader once I'm in recovery, so I created this very very simple flashable zip script. (No longer required on CWM >=6.0.3.5). Note: Once in the bootloader, "Start" will boot you back to recovery. Not sure why, but it's not a big deal, just reboot normally from recovery at that point.
sdcard Fix Permissions script (many devices) - attached
A little flashable zip script to fix ownership and permissions of files and directories on the sdcard to what they would be if Android OS had put them there itself, since some apps can't access pushed files that have root.root as owner/group. This is useful when restoring to your sdcard backup, as with my ADBsync sdcard Backup batch script above, since generally, pushed files get root.root from adb shell and higher permissions than usual. Also a solution for a bug where sdcard files get lower permissions somehow, resulting in similar access problems. Currently written for devices with /data/media/ internal sdcards (Nexus devices, etc.), but could easily be modified for other mountpoints.
nano Terminal Editor v2.2.6 Installer (all devices) - attached
A simple installer to push bgcngm's great Android port of the nano editor binary to /system/xbin/ along with the required files in /system/etc/terminfo/. It can then be used from Terminal while booted from that point on. Each time you flash it also temporarily enables use in recovery by pushing a script to /sbin/nano with the required environment variables, so you can then trigger it from recovery shell or the console in amarullz' brilliant AROMA Filemanager. Makes it extremely easy and worry-free to tweak and mod on the go, knowing you can edit the faulty build.prop or init.d script if something goes wrong. This script could also be added to recovery to make the functionality permanent.
odex Script Installer (all devices) - attached
Based on the great work and binaries from this thread, a simple installer to push my odex script along with the required dexopt-wrapper and zip binaries to /system/xbin and set the appropriate permissions. Automates the procedure to odex any apk or jar from the commandline to potentially improve performance. Dalvik runtime only. Also uses cut from busybox.
Kernel init.d Support Injector (many devices) - attached
Following from great ideas by Captain_Throwback in my AnyKernel2 thread and using script from my Flashify script above, this AK2 zip will inject basic init.d bootscript support into any kernel ramdisk on any emmc device with normal partition naming and using the Android bootable image standard, without having to bloat a ramdisk using a busybox binary. This zip is also signed, so could potentially be used with stock recovery on a locked bootloader, but that depends on the stock recovery supporting grep, etc. for the zip script to perform the required file changes.
Dev Team init.d Pack Installer (all devices) [see "950iosettings, etc." below] - link
A simple installer I wrote to create the /system/etc/init.d/ directory, extract the latest init.d scripts as published by the "Franco's Dev Team" tuning collective (of which I'm a member), then set correct owner, group and permissions to the entire init.d directory. Link points to my Dev-Host since these may still be subject to change from time to time. If you are a developer and would like to include these tunables/scripts in your kernel or ROM please provide credit. A lot of time and effort has gone into this project and that's all we ask.
Credits & Thanks: All authors of any included binaries and libraries for their amazing work. Anyone who's helped me with these projects along the way.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
XDA:DevDB Information
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc., Tool/Utility for the Android General
Contributors
osm0sis
Version Information
Status: Stable
Created 2013-11-13
Last Updated 2015-03-30
Click to expand...
Click to collapse