Related
cannot edit build.prop. i get an error when trying to edit it with es file explorer (there was an error when trying to save this file.)
any help? ive edited it before, but i dont know how. im pretty sure i did it this way but im not sure why its not saving properly this time.
running calk+clemsyn rom/kernel combo.
thanks!
Copy it to another folder edit the copy and then move the edited file in the correct folder.
tried that already, didnt work. got another error
I use Root Explorer to do any editing.
Any other suggestions? I'd rather not have to pay for it
joshtb86 said:
cannot edit build.prop. i get an error when trying to edit it with es file explorer (there was an error when trying to save this file.)
any help? ive edited it before, but i dont know how. im pretty sure i did it this way but im not sure why its not saving properly this time.
running calk+clemsyn rom/kernel combo.
thanks!
Click to expand...
Click to collapse
If the build.prop you want to edit is in /system, then you'll have to mount /system read-write before you can modify any files there:
Code:
$ su [I]Become superuser. Prompt will change to '#'.[/I]
# /system/xbin/mount -w -o remount /system
[I]Edit the file[/I]
# /system/xbin/mount -r -o remount /system
You must have the Superuser app from Market and busybox installed on the gTablet for the commands to work. If you can't edit the file in ES File Explorer because of permission errors, copy the file into /mnt/sdcard via the command line, edit it there (or on the PC after removing the card), then move it back into place in /system and restore the old permissions:
Code:
$ cp /system/build.prop /mnt/sdcard/.
[I]a) The build.prop file in /mnt/sdcard should be editable now in ES File Explorer.
Edit the file, then do:
OR
b) Unmount the SD card via Settings > Storage, then remove the SD card and
edit the file elsewhere. Plug it back in, and, after it mounts do:[/I]
$ su
# /system/xbin/mount -w -o remount /system
# /system/xbin/mv /mnt/sdcard/build.prop /system/build.prop
# chown root.root /system/build.prop
# chmod 644 /system/build.prop
# /system/xbin/mount -r -o remount /system
All this is much easier through adb if you have that setup.
Note: Do not type the prompts--the '$' and '#' characters--in; they're just there to tell you what the Terminal screen should look like.
joshtb86 said:
Any other suggestions? I'd rather not have to pay for it
Click to expand...
Click to collapse
Did you have ES file explorer in Root mode?
In Es file explorer
Settings->Root Options -> both boxes checked, (HiAPK mode for first box)
I usually copy the file to sdcard and modify it, get ES explorer in root mode and copy it back. Do a backup before, in case you mess it up.
I usually use a terminal in su mode for editiing/copying, but that might not be needed.
cbay said:
Did you have ES file explorer in Root mode?
In Es file explorer
Settings->Root Options -> both boxes checked, (HiAPK mode for first box)
I usually copy the file to sdcard and modify it, get ES explorer in root mode and copy it back. Do a backup before, in case you mess it up.
I usually use a terminal in su mode for editiing/copying, but that might not be needed.
Click to expand...
Click to collapse
if i use CM Mod, i cant see any files. if i use HiAPK, all the files have -rw and a lot of stuff before it and i cant read anything, but it does mount. CW had problems mounting the drive. im gonna try out the terminal commands
rajeevvp said:
If the build.prop you want to edit is in /system, then you'll have to mount /system read-write before you can modify any files there:
Code:
$ su [I]Become superuser. Prompt will change to '#'.[/I]
# /system/xbin/mount -w -o remount /system
[I]Edit the file[/I]
# /system/xbin/mount -r -o remount /system
You must have the Superuser app from Market and busybox installed on the gTablet for the commands to work. If you can't edit the file in ES File Explorer because of permission errors, copy the file into /mnt/sdcard via the command line, edit it there (or on the PC after removing the card), then move it back into place in /system and restore the old permissions:
Code:
$ cp /system/build.prop /mnt/sdcard/.
[I]a) The build.prop file in /mnt/sdcard should be editable now in ES File Explorer.
Edit the file, then do:
OR
b) Unmount the SD card via Settings > Storage, then remove the SD card and
edit the file elsewhere. Plug it back in, and, after it mounts do:[/I]
$ su
# /system/xbin/mount -w -o remount /system
# mv /mnt/sdcard/build.prop /system/build.prop
# chown root.root /system/build.prop
# chmod 644 /system/build.prop
# /system/xbin/mount -r -o remount /system
All this is much easier through adb if you have that setup.
Note: Do not type the prompts--the '$' and '#' characters--in; they're just there to tell you what the Terminal screen should look like.
Click to expand...
Click to collapse
when i tried the mv command to move it back, i still got errors in moving it and was not able to
joshtb86 said:
when i tried the mv command to move it back, i still got errors in moving it and was not able to
Click to expand...
Click to collapse
Try
Code:
/system/xbin/mv /mnt/sdcard/build.prop /system/build.prop
instead of plain 'mv'. The default Android mv command is idiotically implemented. (See this post if you're interested in the details):
http://forum.xda-developers.com/showpost.php?p=13956585&postcount=4
Using 'cp' command instead of 'mv' should also work; this way, you'll also have a backup of build.prop in /mnt/sdcard/.
rajeevvp said:
Try
Code:
/system/xbin/mv /mnt/sdcard/build.prop /system/build.prop
instead of plain 'mv'. The default Android mv command is idiotically implemented. (See this post if you're interested in the details):
http://forum.xda-developers.com/showpost.php?p=13956585&postcount=4
Using 'cp' command instead of 'mv' should also work; this way, you'll also have a backup of build.prop in /mnt/sdcard/.
Click to expand...
Click to collapse
thanks so much again. i finally got it to work, but i just wanted to get netflix to work, and it still doesnt. after all that work. ugh.
JoTeC said:
I use Root Explorer to do any editing.
Click to expand...
Click to collapse
Thanks, I tried two other applications and they didn't work. Was able to edit with Root Explorer. didnt fix the Netflix playback. Bummer.
***** changing the Nexus S to HTC Vision and samsung to HTC did the trick.
Root explorer will work, and is a great app. Worht the money.
Also, ADB from a PC will work as well. Just install the android sdk and use ADB.
From windows cmd prompts the commands are just adb remount (to remount as root) then "adb pull /system/build.prop" (this will pull it to the sdk platform-tools folder that adb.exe is in) and then edit to your hearts delite.
"adb push build.prop /system/build.prop" to send it back.
I was able to use ES File System by unchecking the Mount File System option in the Root options menu and then rechecking it. I imagine that it forced a remount of the file system in a writable mode.
This worked on our nabi big tab hd24
We now have true multiuser, where everyone has their own login, files, emails, bookmarks, web history, etc; as it should be.
I first did a factory reset, then installed kingo root, then another reset, did the build prop edit this suggested (es file explorer did not work) but build prop editor did....
We now have the nabi big tab hd 24 running as our primary desktop workstation computer...
No we just wish for a room update to be made available with the latest version of Android.
4.4.2 is getting old, and as is common little manufacturer long term support...
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
Hello everybody,
I have a "problem" with /system/bin/ and bin folders (however, the phone works just fine, hence those quotation marks :angel.
Let's stick with /system/bin/: Inside I have the files that should be there, but there is also another bin folder with exactly the same files inside and another bin folder inside ... and so on, about 20 times/levels(?) nested.
Not sure what it is ... some hardlink problem?
The same is in /bin/ folder.
ES File Explorer says that there are about 7000 files/ 230 MB in the first nested bin subfolder.
I tried the following:
1. Delete the nested bin folders from ES File Explorer (root access granted) - unsuccessful ("can't delete ...")
2. From CWM: format /system/ + Factory reset + wipe + ROM reflash
3. Search the forum for this issue - maybe I can't search properly, but found nothing ... sorry
As I said, the phone works fine. But I think that it is not good to have such a mess inside the system folders.
I didn't try complete reflash (ftf file) ... I'm trying to avoid doing everything from scratch .
Can you help me, please?
Thanks a lot,
J.
Phone: Sony Ericsson Live With Walkman WT19i, unlocked bootloader (the Sony way), MESA Kernel 3.6 stock, Real ICS lite r4.
Update: It's a chain of symlinks. The depth of the chain is 40 (counted in DroidExplorer).
What else didn't work:
mount /system in TWRP, then starting file editor, deleting bin (even with chmod)
All attempts to delete the symlink via PC file managers (e.g. Droid Commander)
Solution {rooted phone):
It was a symlink in system/bin pointing to self,
1. Install Android Terminal Emulator (free at Google Play)
2. Start it
3. Then
Code:
# su
(allow root access)
Code:
# mount -o remount, rw /system
# cd /system/bin
# rm bin
That's it
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