Related
Okay, I got sick of typing
Code:
mount -o remount,rw /dev/block/mmcblk0p12 /system
or
Code:
busybox mount -o remount,rw /system
to mount the /system partition in RW mode so I created two very simple scripts that you can run through Script Manager to Mount RW and Mount RO.
I do quite a bit from ADB and I just found it more convenient to tap a shortcut on my home screen to mount the /system partition.
With the help of imchairmanm, I have fixed the scripts to be available globally, so all you have to do is type "mountrw" (without the quotation marks) to mount the /system partition in Read/Write mode, and type "mountro" (again, without the quotation marks) to mount the /system partition in Read Only mode.
So, now it can be run both ways!
Installation:
1. You must be rooted. (See my HowTo: Root your Motorola Droid X2 tutorial.)
2. You must have Busybox installed. If you are rooted, you have busybox installed. I've tested the scripts on BB 1.18.2, 1.19.2 and 1.19.3.
3. Download the mounts.zip file and extract it to a folder on your SDCard (internal or external, it doesn't matter). I use /mnt/sdcard/Scripts/Mounts/.
3. Download Script Manager from the market.
4. Open the Script Manager app and navigate to the folder you put the mount scripts in.
5. Tap the first mount script (mountro).
6. Tap the star and the Android superuser icon next to it. This configures the script as a favorite and to run the script as root.
7. Tap SAVE.
8. Repeat steps 5 through 7 for the second mount script (mountrw)
9. Now you can run each script from within Script Manager, or create shortcuts to them on your home screen.
To create the shortcuts, do the following:
1. Long press a blank area on your home screen and select Widget.
2. In the Choose Widget popup, scroll down to Script Manager Ads (if you have the free version) and tap it.
3. In the list, tap the mountro script. This will place the shortcut on your home screen.
4. Repeat steps 1-3 for the mountrw script.
Now, when you need to mount /system as RW all you need to do is tap the mountrw script, then when you are done, either reboot, or tap the mountro script.
The following is the code for each of the scripts:
mountro:
Code:
#!/system/bin/sh
# This mounts the /system file system as Read Only which is the default when
# Android is booted.
echo "Mounting /system in Read Only mode!"
busybox mount -o remount,ro / 2>/dev/null
busybox mount -o remount,ro rootfs 2>/dev/null
busybox mount -o remount,ro /system 2>/dev/null
echo "Done!"
mountrw:
Code:
#!/system/bin/sh
# This mounts the /system file system as Read Write in order to modify or add
# files to the /system file system.
echo "Mounting /system in Write mode!"
busybox mount -o remount,rw / 2>/dev/null
busybox mount -o remount,rw rootfs 2>/dev/null
busybox mount -o remount,rw /system 2>/dev/null
echo "Done!"
It's simple and no frills... The way I like it.
Alternative install:
I didn't realize it, but, I had already made a flashable zip. Just download mount_rw_ro-V1.1.zip and boot into the BSR and flash it from there.
If anyone has any suggestions, I'm open to them! Let me know!
Ciao!
Hm, I was curious since you said you couldn't get your scripts to run globally, so I tried them out by putting them in /system/xbin. After adjusting permissions and making sure owner and group were root, they ran fine and globally as-is. I wonder if the simpler version you started with would have worked or not?
imchairmanm said:
Hm, I was curious since you said you couldn't get your scripts to run globally, so I tried them out by putting them in /system/xbin. After adjusting permissions and making sure owner and group were root, they ran fine and globally as-is. I wonder if the simpler version you started with would have worked or not?
Click to expand...
Click to collapse
did you run them from /system/xbin? I put them in /system/xbin and then cd / to get back to root and tried to run them. They are not found.
Code:
# cd /system/xbin
cd /system/xbin
# pwd
pwd
/system/xbin
# ls -l mount*
ls -l mount*
lrwxrwxrwx root root 2011-12-05 13:08 mount -> /system/xbin/busybox
lrwxrwxrwx root root 2011-12-05 13:08 mountpoint -> /system/xbin/busybox
-rwxrwxrwx root root 316 2011-11-06 19:04 mountro
-rwxrwxrwx root root 328 2011-11-06 19:04 mountrw
# cd /
cd /
# pwd
pwd
/
# mountro
mountro
mountro: not found
# sh mountro
sh mountro
sh: Can't open mountro
#
That was the problem I was running into. I even tried sh mountro. The error "Can't open mountro" essentially means it can't find it.
If this is what you did, and you had different results, I would love to find out why. Thanks!
Ciao!
Yeah, that's what I meant by they are available globally. I can run them from anywhere in the filesystem. I'm not sure what the difference is. Mine have owner and group set to root and the applicable permissions set as well.
It runs through the script correctly, I get all of the echo messages, and if I cd to system afterwards, everything is rw or ro as it should be. I don't know what other information would be helpful for you, but I'll answer whatever other questions you might have. I don't quite understand why it'd ever have a problem with your scripts in the first place. It seems like a strange thing to happen.
Edit: I just ran through and ran the same commands as you did and they were all successful. It sounds like maybe something isn't right in your $PATH? That's the only thing I can think of. What does it say when you type "echo $PATH"? Either that or something with your terminal emulator or rom? Have you tried a different terminal? It shouldn't matter but you never know.
imchairmanm said:
Yeah, that's what I meant by they are available globally. I can run them from anywhere in the filesystem. I'm not sure what the difference is. Mine have owner and group set to root and the applicable permissions set as well.
It runs through the script correctly, I get all of the echo messages, and if I cd to system afterwards, everything is rw or ro as it should be. I don't know what other information would be helpful for you, but I'll answer whatever other questions you might have. I don't quite understand why it'd ever have a problem with your scripts in the first place. It seems like a strange thing to happen.
Edit: I just ran through and ran the same commands as you did and they were all successful. It sounds like maybe something isn't right in your $PATH? That's the only thing I can think of. What does it say when you type "echo $PATH"? Either that or something with your terminal emulator or rom? Have you tried a different terminal? It shouldn't matter but you never know.
Click to expand...
Click to collapse
I dunno what is going on. My path shows /system/xbin. Oh, I'm on Eclipse 1.3 (but that shouldn't matter)... Oh well.
Code:
# echo $PATH
echo $PATH
/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
It happens from the adb shell and from the terminal program on my DX2.
Hm. My $PATH is the same except it also includes /data/local/bin. That shouldn't matter. I'm on eclipse too and running the commands from the terminal in eclipse parts. I don't know why something in the path wouldn't execute. Does "which mountrw" find it? I had a problem earlier where I thought it wasn't finding a script I wrote, but it actually was failing at the first line because I had the wrong path to sh listed. If which finds your scripts I'd say it's more likely something with the script rather than the system. I'd also try writing a little hello world script and seeing if you can get that to execute globally too.
imchairmanm said:
Hm. My $PATH is the same except it also includes /data/local/bin. That shouldn't matter. I'm on eclipse too and running the commands from the terminal in eclipse parts. I don't know why something in the path wouldn't execute. Does "which mountrw" find it? I had a problem earlier where I thought it wasn't finding a script I wrote, but it actually was failing at the first line because I had the wrong path to sh listed. If which finds your scripts I'd say it's more likely something with the script rather than the system. I'd also try writing a little hello world script and seeing if you can get that to execute globally too.
Click to expand...
Click to collapse
Aw, CRAP! I've run into this problem when I develop on a Windows machine and try to run it on a linux box... ARGH! Thank GOD I use gvim. I was able to change the file format from DOS to UNIX, then save it and push it back out to /system/xbin. chmod'd it to 777 and ran mountrw/mountro and they work now... How can I be so friggin' dense... I know better than that...
Oh, to answer your question on the which command, yes, which finds them both.
What clued me in was you saying that the problem might be with the script. Thanks! It FINALLY works! I've updated the OP with the corrected files.
Also, does anyone want me to make this a flashable zip? Let me know.
Ciao!
Background: On a rooted device, I installed busybox via the BusyBox Pro app, with the "symlinks" option checked. Afterwards, wifi stopped working, root stopped working, adb stopped working, and a lot of tasks started failing with "sh: applet not found".
The problem: BusyBox Pro 8.0 replaces /system/bin/ash with a symlink to busybox. This was problematic on my device, where /system/bin/sh was a symlink to ash, so now 'sh' is actually calling busybox, and this particular compilation of busybox didn't have 'sh' support compiled in, hence the "sh: applet not found" error everytime anything tried to call sh, which as it happens, is a lot! The bug was fixed quickly with a 8.1 release, but due to suspected caching policies on the Google Store, a lot of people still got the old release even after this was fixed!
Here's how I fixed this:
Prerequisite: You'll need a replacement sh binary. On another device, which was also an ARM device, sh was symlinked to 'mksh', and I just took this. You might want to verify that the binary works on your broken device before completing the final steps below.
Initial Wifi
It's only DHCP that is failing (on the "Obtaining IP address..." step), so go into your Wifi Settings, forget the network, add it again, and change DHCP to "static", manually fill in the appropriate IP info for your network, and you'll be good to go (encrypted network is fine).
Getting a Root terminal
Download KBOX from http://kevinboone.net/kbox.html
In KBox, menu -> more -> preferences, change shell -> "command line" to "/system/bin/ash"
su -s /system/bin/ash
Remounting /system as RW
In theory, all you should need to do is: busybox mount -o remount,rw /system
This didn't work for me, and I got a "permission denied (are you root)" error, I guess because the system was no longer booting properly. I had to redo some of the steps involved in rooting my device, in my case:
On phone:
mkdir /data/local/lib
echo ro.kernel.qemu=1 > /data/local.prop
reboot
(wait for reboot, and get into a root terminal again as per the above)
On PC (from previous files used for rooting my device):
adb push lsm_disabler.ko /data/local/lib/
Oh phone:
insmod /data/local/lib/lsm_disabler.ko
rm /data/local/lib/lsm_disabler.ko
cat > /data/local.prop
From this point, I was able to remount successfully:
mount -o remount,rw /system
Fixing sh
Now on your PC, push the replacement binary to /system/bin, in my case:
adb push mksh /system/bin
On phone:
cd /system/bin
busybox ln -sf sh mksh
Verify now that "./sh" gives you a working terminal.
If all is good:
mount -o remount,ro /system
reboot
All done! Wow, this saved me sending my device back to Japan, since it's still using the stock bootloader and there are now available update.zip's out there. Good luck everyone, feel free to ask questions :>
P.S. I'm going to contact BusyBox Pro's author now with some suggestions to prevent these kind of problems happening in the future.
Deleted.
Deleted.
I rant into the same problem on my Galaxy Tab. Thanks for this, it saved my day!
A little correction to this little thing:
Kinslayer81 said:
On phone:
cd /system/bin
busybox ln -sf sh mksh
Click to expand...
Click to collapse
This worked for me:
cd /system/bin
ln -sf mksh sh
chmod 755 sh
Thank you
Just want to say thanks.
Your Posting helped me out with the Problems on my htc flyer.
I installed BusyBox Pro by Stephen (Stericson) to fix a missing symlinks problem that I had after installing JRummy's Busy Box. I then encountered the applet not found problem and then just reinstalled JRummy's version and it fixed it without having to do anything else.
Kinslayer81 said:
Background: On a rooted device, I installed busybox via the BusyBox Pro app, with the "symlinks" option checked. Afterwards, wifi stopped working, root stopped working, adb stopped working, and a lot of tasks started failing with "sh: applet not found".
The problem: BusyBox Pro 8.0 replaces /system/bin/ash with a symlink to busybox. This was problematic on my device, where /system/bin/sh was a symlink to ash, so now 'sh' is actually calling busybox, and this particular compilation of busybox didn't have 'sh' support compiled in, hence the "sh: applet not found" error everytime anything tried to call sh, which as it happens, is a lot! The bug was fixed quickly with a 8.1 release, but due to suspected caching policies on the Google Store, a lot of people still got the old release even after this was fixed!
Here's how I fixed this:
Prerequisite: You'll need a replacement sh binary. On another device, which was also an ARM device, sh was symlinked to 'mksh', and I just took this. You might want to verify that the binary works on your broken device before completing the final steps below.
Initial Wifi
It's only DHCP that is failing (on the "Obtaining IP address..." step), so go into your Wifi Settings, forget the network, add it again, and change DHCP to "static", manually fill in the appropriate IP info for your network, and you'll be good to go (encrypted network is fine).
Getting a Root terminal
Download KBOX from http://kevinboone.net/kbox.html
In KBox, menu -> more -> preferences, change shell -> "command line" to "/system/bin/ash"
su -s /system/bin/ash
Remounting /system as RW
In theory, all you should need to do is: busybox mount -o remount,rw /system
This didn't work for me, and I got a "permission denied (are you root)" error, I guess because the system was no longer booting properly. I had to redo some of the steps involved in rooting my device, in my case:
On phone:
mkdir /data/local/lib
echo ro.kernel.qemu=1 > /data/local.prop
reboot
(wait for reboot, and get into a root terminal again as per the above)
On PC (from previous files used for rooting my device):
adb push lsm_disabler.ko /data/local/lib/
Oh phone:
insmod /data/local/lib/lsm_disabler.ko
rm /data/local/lib/lsm_disabler.ko
cat > /data/local.prop
From this point, I was able to remount successfully:
mount -o remount,rw /system
Fixing sh
Now on your PC, push the replacement binary to /system/bin, in my case:
adb push mksh /system/bin
On phone:
cd /system/bin
busybox ln -sf sh mksh
Verify now that "./sh" gives you a working terminal.
If all is good:
mount -o remount,ro /system
reboot
All done! Wow, this saved me sending my device back to Japan, since it's still using the stock bootloader and there are now available update.zip's out there. Good luck everyone, feel free to ask questions :>
P.S. I'm going to contact BusyBox Pro's author now with some suggestions to prevent these kind of problems happening in the future.
Click to expand...
Click to collapse
This helped get my wifi back after flashing a kernel.
Hey there,
I've got the same problem.
After reinstalling the ROM everything works fine,
but when I try to install busybox, I get the same failure everytimes.
How can I prevent it?
Do I have to follow the steps above?
And where do I get the sh binary from?
Sorry guys, I'm a little confused and hope you may help me..
Thanks!!
Kbox not open in my ics when I open it its automatically closed
And i want to ask the script su -s /system/bin/ash where i put this script
I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
bsimpson1 said:
I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
Click to expand...
Click to collapse
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
edit: CWM's su actually isn't used in TWRP; a supersu package is used
7175 said:
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
Click to expand...
Click to collapse
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
bsimpson1 said:
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
Click to expand...
Click to collapse
Man I'm right there with you. lol yeah my 1MB of cursor-fix bashrc and mksh edits are now resting in peace, blasted that tar.gz coffin out to space with my "working-key-signal" su'd ssh terminal the other day like Spock in The Wrath of Khan, oh yeah. I'm glad to know I wasn't the only person who cared about this so much.
I recently upgraded from my S2, to the S4. I'm enjoying the snappiness, and as are we all, a bit disappointed by the locked down nature of it. One of the things I liked about my old phone was the ability to have an encrypted container for sensitive files. In particular, I was using LUKS Manager to mount encrypted folders and it worked perfectly. However the stock kernel on the S4 appears to lack the dm-crypt module, and I am therefore unable to use it on the new phone.
I've tried a few other things as well, including Cryptonite and EDS Lite (as well as the paid version), but ran into similar problems. With EDS paid version there is source available for the required kernel module, but it hasn't been built for the S4 yet, it seems.
I'm willing to get into some of the nitty gritty details, but I was wondering if anyone else had any success building dm-crypt or the eds module for the s4 yet. Or if anyone would have some resources that might be a good starting point so I could build them on my own.
Thanks!
(MJ7, rooted)
Edit:
After a bit more digging I found the LUKS Guardian project, which looks promising. (I can't post links yet, but google "android cryptsetup luksopen" and it should be the first result). Their binary is throwing a segfault when i try it, but I'll pull it down and play with it tonight at home to see if I can get anywhere.
I think our kernel may in fact have DM-CRYPT available, but for some reason it's simply not working. In LUKS when I attempt to mount a file, it thinks it successfully mounts (and creates a folder) but it when I unmount, anything I copied over is still there. I find it telling though that it will only "mount" a file with the correct password. So the encryption may be working, while the mounting is not. I'm very comfortable in linux so I'll poke around and see if there's anything I can glean from the terminal.
One step closer, but not quite there yet. I SSH'd in and started playing with the LUKS Manager app and have come to the conclusion that it's really the mounting that is causing problems.
LUKS Manager creates a shell script over in /system/bin/luks. I pulled this off and looked over it a bit, and managed to run the pieces one by one until I came to failure. Essentially what is happening is it's using busybox to do the following:
mknod
losetup
/system/bin/lm.cryptsetup luksOpen #Yay, I don't need to compile LUKS Guardian!
mkdir ${mount_path}
chmod 777 ${mount_path} # THIS FAILS
mount the mapper to the mount path
chmod 777 ${mount_path} # THIS FAILS
chmod 777 -R ${mount_path} # THIS FAILS
So what you're left with is an encrypted volume which mounts just fine, but is only readable by root. Permissions on ${mount_path} are 700 and neither busybox chmod nor standard chmod will change them. I've also tried mounting the mapper with the busybox mount as well as the builtin. Same result. Further, it looks like I'm unable to (as root) chmod pretty much anything.;
Frustrating, because I can clearly see that the data is there when I'm in a root terminal, but none of the apps can access it.
Anyone have any ideas on why I can't chmod? Or how to get mount to grant 777 in the first place?
spdqbr said:
One step closer, but not quite there yet. I SSH'd in and started playing with the LUKS Manager app and have come to the conclusion that it's really the mounting that is causing problems.
LUKS Manager creates a shell script over in /system/bin/luks. I pulled this off and looked over it a bit, and managed to run the pieces one by one until I came to failure. Essentially what is happening is it's using busybox to do the following:
mknod
losetup
/system/bin/lm.cryptsetup luksOpen #Yay, I don't need to compile LUKS Guardian!
mkdir ${mount_path}
chmod 777 ${mount_path} # THIS FAILS
mount the mapper to the mount path
chmod 777 ${mount_path} # THIS FAILS
chmod 777 -R ${mount_path} # THIS FAILS
So what you're left with is an encrypted volume which mounts just fine, but is only readable by root. Permissions on ${mount_path} are 700 and neither busybox chmod nor standard chmod will change them. I've also tried mounting the mapper with the busybox mount as well as the builtin. Same result. Further, it looks like I'm unable to (as root) chmod pretty much anything.;
Frustrating, because I can clearly see that the data is there when I'm in a root terminal, but none of the apps can access it.
Anyone have any ideas on why I can't chmod? Or how to get mount to grant 777 in the first place?
Click to expand...
Click to collapse
Since you're on MJ7, it's probably SELinux doing that to you.
You might try using chmod 555 (read + execute) to see if that's allowed.
What is the mount point that you're trying to use? Perhaps that's also being blocked by SELinux.
Thanks for the suggestions. I've poked around a bit at selinux, but with no hope of disabling it I'm not sure if I'll make it through the last hurdle. I've tried a few different mount points and a few different chmod permissions to no avail. I *did* however have one breakthrough, but now I'm just flat out puzzled.
I mounted it via the luks script I mentioned earlier, and then do a busybox umount on it (leaving the mapper in place). I then checked the mount options for my external sd card, since both it and the LUKS volume are vfat. I remounted the mapper using
busybox mount /dev/mapper/test /storage/extSdCard/test -o rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,iocharset=iso8859-1,shortname=mixed,utf8
This mounts the drive with user, group, and permissions all set exactly like other file in the external SD card. However es file explorer and all other apps show the mount point as simply empty. If I'm not on command line, I can't see anything in it, which is utterly baffling to me.
From the terminal I can copy files out to another location (this is a luks volume I created on the old phone, so it already had data in it) and access them just fine via esfile explorer and various text editors.
The data is there, it's decrypted, it's accessible through command line, but all my apps simply refuse to acknowledge it.
Edit:
I'm not the only one experiencing this mounting phenomena... https://groups.google.com/forum/#!topic/android-kernel/JeY_u-pHcxQ
Edit:
According to this, android 4.2 made is so that application-created mount points are not globally accessible. They suggest a few workarounds which I have not yet had a chance to try. This certainly explains the problem though!
I've had the Samsung Chromebook Plus for about 2 weeks now, and I love it! Chrome OS is pretty good at handling itself for notetaking with the stylus, and the gorgeous screen is great for high res stuff (although Chrome OS is in desperate need of DPI scaling). It even runs Android apps out of the box! So far, I only have 2 major gripes about Chrome OS:
-It cannot do multitasking on anything (Android or Chrome app) when in tablet mode (buttons disappear, window drags are disabled) even on the beta branch
-Android cannot be rooted on the Chrome OS (so I think).
That second one is the one I'd like help with. Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Nilithium said:
Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Click to expand...
Click to collapse
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
On a general basis, running scripts from random strangers on the Internet is a bad thing. But I'll take it!
I've encountered an ID10T error though: I set the debugging password during setup, and I THOUGHT that was the sudo password to run your script. Problem is, that's not true, and I've no idea what it is.
Tried Google Account password, no dice.
Tried Chromebook PIN, no dice.
Tried Debug Pass set in Setup, no dice.
Tried password, no dice.
Tried null password (no input), no dice.
What is the sudo password? Did I miss something?
Nilithium said:
What is the sudo password? Did I miss something?
Click to expand...
Click to collapse
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Nolirum said:
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Click to expand...
Click to collapse
DELETE
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Anyone tried it on Pixelbook?
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
holy cow, script works flawlessly! (Samsung Chromebook Plus)
Anyone know why my Tivo app and Sirius XM don't work on my new Samsung Chromebook Plus V2? They install and than don't open and crash any other workable apks that anyone knows about? Sirius I can do online Tivo won't play all my recorded shows online just some and I really bought this Chromebook to use the Tivo app to watch shows when not at home or sitting outside. I know this thread is about rooting but I thought someone here may be able to help me. I also posted in the Tivo Community Forum also and am waiting for a response. Thanks!
MsWadera said:
Anyone tried it on Pixelbook?
Click to expand...
Click to collapse
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
phonefreedom said:
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
Click to expand...
Click to collapse
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
phonefreedom said:
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
Click to expand...
Click to collapse
When you say it was unusable, did Android (apps) appear to fail to load up completely, just the icon spinning? Or something else?
Did you happen to notice if any errors were shown on the script's output at all?
For example, there was this issue reported on github when the Pixelbook was first released, in which the Android rootfs container created by the script turned out to be a bit smaller than required, and so errors occurred when copying files to the new rooted /system. The user was able to successfully continue after manually editing the script so it created a container that was slightly bigger.
The script has been updated since then to reflect the increased space requirements, so that particular problem should no longer occur. Other potential sources of error might include if there could have been a problem downloading the required files (SuperSU, BusyBox), a problem patching SE Linux (in which case there is a separate script to do this part) , or maybe something else, possibly due to Chrome OS changes/updates.
In the case of the script rendering Android unusable, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Entering the above will restore the original read-only squashfs unrooted rootfs, which, after a reboot, should then load up as normal.
I think I'll edit my earlier post in this thread to add the command to restore from backup. Apologies for failing to mention it here initially. I might add an explicit message in the script itself regarding this, as well.
Flashing zips
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
do-tim said:
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
Click to expand...
Click to collapse
Depends what you want to flash, probably.
You might be able to rewrite the relevant edify commands in the update-binary that you want to flash into an equivalent shell script for the Chrome OS shell.
However, by default the Android rootfs container is in a read-only squashfs format, so normally cannot be modified directly. One way to modify it is to make a writable copy of the container in /usr/local, then replace the original file pathname with a symbolic link to the R/W copy. This works fine for the most part (but does takes up extra disk space, and needs to be re-done after an OS update).
For instance, here is part of the rooting script mentioned upthread, which makes a writable copy of the Android container, copies the files from the original container therein, renames the original to .bk, replaces the original file pathname with a symlink to the copy and, at the end, changes a couple of relevant envs in CrOS's /etc/init/arc-setup-env file.
Code:
#!/bin/sh
# Detect CPU architecture
case "$ARCH" in
x86 | i?86) ANDROID_ARCH="x86";;
x86_64 | amd64) ANDROID_ARCH="x86";;
armel) ANDROID_ARCH="armel";;
arm64 | aarch64) ANDROID_ARCH="armv7";;
arm*) ANDROID_ARCH="armv7";;
*) error 2 "Invalid architecture '$ARCH'.";;
esac
# Make some working dirs
mkdir -p /usr/local/Android_Images
mkdir -p /usr/local/Android_Images/Mounted
mkdir -p /usr/local/Android_Images/Original
# Create container image file. Intel devices need a slightly larger file.
if [ $ANDROID_ARCH=armv7 ]; then
cd /usr/local/Android_Images
fallocate -l 1.7G /usr/local/Android_Images/system.raw.expanded.img
else
if [ $ANDROID_ARCH=x86 ]; then
cd /usr/local/Android_Images
fallocate -l 2.2G /usr/local/Android_Images/system.raw.expanded.img
# Format the .img file.
mkfs ext4 -F /usr/local/Android_Images/system.raw.expanded.img 2>/dev/null
# Set SELinux to permissive.
setenforce 0
# Check that the stock Android container exists and is not already a symlink.
# If this is the case, mount it in order to copy files.
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
if [ -e /opt/google/containers/android/system.raw.img ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
# If the stock container's missing, check if there is a backup.
if [ -e /opt/google/containers/android/system.raw.img.bk ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img.bk /usr/local/Android_Images/Original 2>/dev/null
else
# If there's no backup in the expected location, check in ~/Downloads, too.
# NOTE: We can also use a container from a different device/other OS versions by putting it in ~/Downloads.
# To use a different container, we just need to rename any existing containers in /opt/google/containers/android/
# e.g. rename /opt/google/containers/android/system.raw.img.bk to /opt/google/containers/android/system.raw.img.bk.bk
# Containers from different devices/OS versions are unlikely to boot, however.
if [ -e /home/chronos/user/Downloads/system.raw.img ]; then
echo "Mounting /home/chronos/user/Downloads/system.raw.img and copying files"
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /home/chronos/user/Downloads/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
echo
echo "Error!"
echo "System.raw.img not found"
echo
exit 1
fi
fi
fi
fi
ANDROID_ROOTFS=/usr/local/Android_Images/Original
# Mount the new .img.
mount -o loop,rw,sync /usr/local/Android_Images/system.raw.expanded.img /usr/local/Android_Images/Mounted
# Copy the files.
cp -a -r $ANDROID_ROOTFS/. /usr/local/Android_Images/Mounted
# Rename the original container to .bk.
if [ -e /opt/google/containers/android/system.raw.img ]; then
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
echo "Moving original Android rootfs image to /opt/google/containers/android/system.raw.img.bk"
mv /opt/google/containers/android/system.raw.img /opt/google/containers/android/system.raw.img.bk
# Make the symlink from the original pathname to our writeable rootfs image.
echo "Replacing original Android rootfs image path with symlink to /usr/local/Android_Images/system.raw.expanded.img"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
else
if [ -e /usr/local/Android_Images/system.raw.expanded.img ]; then
echo "Creating symlink to /usr/local/Android_Images/system.raw.expanded.img at original Android rootfs image file path"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
fi
# Change the envs for writeable mount and debuggable in CrOS's /etc/init.
sed -i 's/export WRITABLE_MOUNT=0/export WRITABLE_MOUNT=1/g' /etc/init/arc-setup-env 2>/dev/null
sed -i 's/export ANDROID_DEBUGGABLE=0/export ANDROID_DEBUGGABLE=1/g' /etc/init/arc-setup-env 2>/dev/null
The rooting script is basically just the above, with the addition of a couple of other bits, including the relevant commands from the update-binary script in the SuperSU zip, slightly rearranged from Edify to regular shell script for the CrOS shell. That part of the script can be seen here.
So you could maybe do a similar script, with the files you want to flash. Also, once you have a R/W Android rootfs, it may be possible to update files from directly within Android, although, as mentioned in the last few posts in this thread, on some recent CrOS builds, some people have been running into an issue with the rootfs still getting mounted RO within Android, even with a writable container. This does not occur on all devices though, and should be just a temporary issue.
It would probably also be possible to set up a sort of overlay configuration, somewhat similar to Magisk in effect, but due to the somewhat convoluted mount configuration of the container based system, and the almost constant changes/updates (to the container, its config, and so on) that have been occurring with each update to Chrome OS, this would likely require quite a bit of work to implement and maintain.
Corrective measures to run the script...
Spoke too quickly - all installed but no root detected in SuperSU...
Yes, thanks, it seems to work.
I wonder why the script cannot handle downloading SuperSU & busybox on its own, some corrections are needed.
justqt said:
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Click to expand...
Click to collapse
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Davestar2000 said:
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Click to expand...
Click to collapse
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Click to expand...
Click to collapse
If it says no android system detected, I downloaded it in 2 parts from here: ( github(dot)com/nolirium/aroc ), followed the instructions, and then it worked for me.
Nolirum said:
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Click to expand...
Click to collapse
thanks for all the help. I have chromebook plus v1,I am on chrome osversion 74. I tried to follow the instruction
but my android apps did not start after restarting. I tried doing it manually but i got stuck at remounting file system as read only. Please help if possible. Thanks again.
Hi,
I'm having problems with this. I have an HP Chromebook with an Intel cpu, Chrome OS Version 75.0.3770.144 (Official Build) (64-bit). When I run the scripts this is the output:
Setting 'ANDROID_DEBUGGABLE: true' and 'WRITABLE_MOUNT: true' in /usr/share/arc-setup/config.json
The file at /opt/google/containers/android/system.raw.img is already a symlink!
Removing symlink
Using /opt/google/containers/android/system.raw.img.bk
Creating new Android system image at /usr/local/Android_Images/system.raw.expanded.img
1814633472 bytes (1.8 GB, 1.7 GiB) copied, 13 s, 140 MB/s
1800000+0 records in
1800000+0 records out
1843200000 bytes (1.8 GB, 1.7 GiB) copied, 25.2601 s, 73.0 MB/s
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Creating symlink to /usr/local/Android_Images/system.raw.expanded.img
SuperSU files not found in ~/Downloads! Attempting to download BusyBox and SuperSU now...
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5810 100 5810 0 0 5624 0 0:00:01 0:00:01 --:--:-- 9078
Unexpected file size. Trying again...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
50 6756k 50 3407k 0 0 305k 0 0:00:22 0:00:11 0:00:11 311k
Unzipping SuperSU zip, and copying required directories to ~/Downloads.
/usr/local/bin/busybox: 1: /usr/local/bin/busybox: Syntax error: word unexpected (expecting ")")
cp: cannot stat 'common': No such file or directory
cp: cannot stat 'armv7': No such file or directory
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6756k 100 6756k 0 0 328k 0 0:00:20 0:00:20 --:--:-- 351k
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
Copying sh from system/bin/sh to system/xbin/sugote-mksh and setting permissions and contexts
Adding extra files system/etc/.installed_su_daemon and system/etc/install-recovery.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
Symlinking system/bin/install-recovery.sh to system/etc/install-recovery.sh
Adding system/bin/daemonsu-service.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
Creating file init.super.rc in Android rootfs
Adding daemonsu service to init.super.rc
Adding 'import /init.super.rc' to existing init.rc
Substituting '|mount rootfs rootfs / remount bind rw' for '|mount rootfs rootfs / remount bind ro' in existing init.rc
A backup of init.rc will be stored as init.rc.old
sed: can't read /../init.rc: No such file or directory
Removing temporary files
Done!
Please check the output of this script for any errors.
Please reboot now, then run script 02SEPatch.sh.
[email protected] / $
Any help would be very much appreciated. I've done a good bit of searching and so far have been unable to figure what the problem is. Thanks alot, guys.
JR