NOTE (Nov '18):
The scripts have been updated (to version 0.27) to address a few recent minor changes in Chrome OS.
If anyone is experiencing issues (such as unable to write to /system) on recent Chrome OS versions, even after trying the latest version of the script, I'd appreciate it if you leave a comment on the blog, or on this related issue report on github, noting your device model and Chrome OS version.
If anyone is experiencing issues (such as unable to write to /system) on recent Chrome OS versions, even after trying the latest version of the script, I'd appreciate it if you leave a comment on the blog, or on this related issue report on github, noting your device model and Chrome OS version.
PREREQUISITES:
The Chrome OS system partition needs to have been made writable.
A straightforward way to enable this is usually to enter the following command in the shell, then reboot:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))INSTRUCTIONS:
I recommend trying the latest combined script first, which will attempt to auto-download and extract the required files.
The combined script may be run by copy/pasting the following into the Chrome OS shell prompt:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo shOnce the script has finished, check its output for any error messages and - assuming success - after a reboot, the Android subsystem should be rooted and fully working.
If any errors are experienced with the combined script, the following method may be tried:
1. Manually download the SuperSU 2.82-SR5 zip
2. Extract/copy the folders from inside the SuperSU zip to 'Downloads'
3. Run the script(s) - either the combined version (above) which is recommended, or the more widely tested version with separate scripts to root and patch SE Linux (a little further down the page).
IMPORTANT: If you powerwash after running the scripts (without also updating the OS), the Play Store/Android apps may no longer work. If you experience this, the easiest way to fix it is usually to restore the original Android system image by running the following command (then rebooting):
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
The combined script, after creating a writable ext4 container and adding SuperSU, attempts to bind mount certain directories within the Android container in order to patch the SE Linux policy file without having to reboot first. In case of any problem with this, the rooting and SE Linux patching scripts may be ran one by one, by pasting the following two commands in the Chrome OS shell. With this method, a reboot is required after running the first script, and again after running the second.
The command to run script 1:
The command to run script 2:
The command to run script 1:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/01Root.sh | sudo shThe command to run script 2:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/02SEPatch.sh | sudo shDESCRIPTIONS:
RootandSEPatch.sh
Combines the actions from the two scripts listed below, by completing the actions of the first script, then bind mounting files from SuperSU to a location on the (unrooted) container's $PATH, thus being able to patch the SE Linux policy file (the second script) without having to reboot first.
01Root.sh
Creates & formats a ~2GB sparse filesystem image in /usr/local/Android_Images, and copies Android system files therein. Modifies Chrome OS system files: either /usr/share/arc-setup/config.json, /etc/init/arc-setup-env or /etc/init/arc-system-mount.conf and /etc/init/arc-setup.conf (as per CrOS version) - changing the ro.debuggable and mount-as-read-only flags. Renames the original Android filesystem image to *.bk & replaces it with a symlink to the newly-created image. Mounts the newly created image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary. Copies BusyBox to the mounted image and installs its symlinks in the Android system/xbin directory.
02SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location.Backup copies of the original policy.30 are saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old.
Unroot.sh
If a backup Android image is present in the original location, removes the symlink and restores the backup. Failing this, if a backup is present in in 'Downloads', replaces the modified image with the backup. Attempts to revert the debuggable and mount-as-read-only flags to their original state.
KNOWN ISSUES:
- There is an issue with certain recent Chrome OS versions wherein the Android root filesystem can only be mounted as read-only at runtime. This first occurred on CrOS versions 65. In CrOS versions 68-70, it appears to be necessary to change a line in Android's init.rc in order to enable the expected behaviour (allowing writing to /system in Android, once the relevant environment variable string has been set).
- After rooting with this script, certain non English fonts may no longer display properly in Android apps. This can be fixed/worked around by copying the relevant NotoSans fonts over from Chrome OS to Android's /system/fonts/chromeos folder. Further details can be found at this issue report on github. If this affects you, feel free to leave a comment below, (This appears to no longer be an issue on Chrome OS version 66 and newer).
- At present, updates to Chrome OS will usually overwrite any rootfs customizations, including those carried out by this script. In theory it is possible to keep a watcher script running which, when an OS update is detected, can re-apply the customizations to the updated partition. In practice there are certain issues with this (for instance, if the background script detects that an update has been downloaded and proceeds to re-root the updated Android system, Android apps will stop working until the system has been rebooted). In addition, the OS seems to be subject to constant development and improvement, hence there is no guarantee that what works now will continue to work in future. If anyone has any thoughts to share regarding this topic, feel free to comment below.
- The current version of the script replaces the original Android system image with a symlink. In order to revert to the original (unrooted) image if required, it will be necessary to either manually restore the backup (easiest), force an update e.g. with a channel change, or restore from USB.
- After a powerwash, modified system files may remain modified, and /usr/local may be empty. Again, either manually restoring the backup image, channel changing, or restoring from USB will be necessary in order to have a functioning Android subsystem.
- Updating the su binary from within the SuperSU GUI app may not work.
- Stability may be an issue. This remains to be seen. A few OS crashes have been noted. Likely unrelated, though - it seems to crash occasionally in any case (Dev/Canary channels).
- The modified system image takes up a fair amount of space in /usr/local/. Storing the image in certain other places doesn't seem to work, probably due to mount timings.
PARTIAL CHANGELOG:
v 0.27 - Modified rootfs writable check, which broke due to a CrOS change. Add check if writable container and debug flags are in "/usr/share/arc-setup/config.json" Added fix for ro system in init.rc (substituted '|mount rootfs rootfs / remount bind rw' for '|mount rootfs rootfs / remount bind ro').
v 0.26 - Fixed adding BusyBox to Android system/xbin. Changed SuperSU version used from 2.82SR3 to 2.82SR5. Removed duplicate function in combined script.
v 0.25 - Rooted container is now a sparse file, which takes up only as much disk space as is necessary. (thanks @hall757 on GitHub for suggesting this). Minor tidying up of combined script.
v 0.24 - Combined scripts 01Root and 02SEpatch into a single script.
v 0.23 - Minor changes to support CrOS v62. Patched SE Linux policy is now also copied to /sepolicy inside the Android container, SuperSU apk is now installed in /system/priv-app in the container, and font sharing between Chrome OS and Android is disabled in CrOS in /etc/init/arc-setup-env.
v 0.22 - Unified arm and Intel versions into a single script. Added functionality to auto-download /extract required files. Removed necessity for additional user interaction in script 2.
v 0.21 - Fixed context of init daemon to properly support launching at boot.
v 0.20 - Added support for 7.1.1 Nougat. Daemon now launched as init service rather than app_process hijack.
v 0.18 - Added support for Chrome v. 59/60 (changed mounting method to mount via symlink. Fixed backing-up of original image file. Added search for extra backup image paths (e.g. when re-running script).
PLEASE HELP. i did everything(i think correctly) im using the test version on the acer R13 mediatek64. and when i get to the execute script part, it keeps saying "sh: Can't open 01Androidroot.sh" i dont know whats going on
ReplyDeletei tried again and failed after first script. says my system isnt writable even though i did that first string of commands. and when i reboot to do the second script it tells me to copy and paste these two commands in and when i do it comes back with "not found"... i am at a lost.. are there ANY other methods available to root this thing that you are aware of??
ReplyDeleteSo it sounds like the rooted system image is being created successfully, but, as the system isn't writeable, the original system image is still being booted and so the the second script fails as SuperSU isn't present in the Android system image.
ReplyDeleteI would suggest running the first string of commands again without --partitions 2 and seeing what it says - perhaps you need --partitions 4.
i.e.(one line):
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
Alternatively, the following command should force it (one line):
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
Regarding other rooting methods, other than variations of the above, I haven't come across or thought of any. I haven't read of anyone else gaining root on the Android container yet, although it's fairly straightforward (no exploit needed).
DeleteIn particular, I don't know of any method which doesn't require making Chrome OS files writeable. I suppose something might be able to be done with bind mounts, like how the method of forcing files on the SD card to be visible to Android apps works by bind mounting certain folders. Bind mounts don't persist across reboots though, so that would be a bit of a hassle...
This comment has been removed by the author.
Deleteok it failed yet again.. this time i tried every string to start with and the one that seemed to actually work with promising results was the one that i required me to force it. it gave me a result that said i was on my own which was scary but.. then i still got a bunch of failed messages. and a bunch of the same results i took pics of before and after of my screen (i hit the tab key after rebooting before and after applying the scripts) I just dont know how to get them to this blog post so you can take a look at them.
ReplyDeleteSorry to hear that it's still not working... you could upload the images to a hosting site such as postimage.org or imgur.com and leave the URL; or you can try to upload them here: https://goo.gl/1jyg6W
ReplyDeleteI guess the regular Android container still loads up OK at the moment? (Just run the uninstall script if it doesn't)...
I did a powerwash and and ran my recovery disc everything looks to be ok and back to my regular dev status..im gonna try uploading the pics i have.. not like they will help any but ..hey maybe they can steer me in a direction...
DeleteThanks for sharing the images. Unfortunately this info doesn't really shed much light on the situation.
DeleteIf you want to take another look at the rooting script, please feel free to open it up in a text editor (if you haven't already done so), to see what it's trying to do. If you do run the script (or parts of it) again, or try to modify it at all then run it, you could copy the output/error messages from the shell terminal and paste them in here.
Other than that, not sure what else to suggest.
It would be good to know where the error is occurring; whether it's the system still not being made writeable, or something else.
What is needed to be done to get this working on Intel Chromebooks?
ReplyDeleteAdded an Intel version, you are welcome to try it out and report back whether it works...
Deletehey, its good to see this post is still active cause I seriously want to root my AcerR13 CB5-312T (mediatek board) Since I never suceeeded the first bunch of times back when i first got it, im hoping some more info has been gained since my last attempt. But if you wouldnt mind helping me out. Cause i could never get these scripts to root it or do anything. IDK...
ReplyDeleteA few things were changed in the latest version (014) so if you haven't already tried it you could give this version a go. If it gives error messages, you can double click on the screen to copy the output (you might need to zoom out with Ctrl++ first). You can paste the messages in here.
ReplyDeleteIf you try it, be sure to run the command to make the system writeable (and then reboot) beforehand.
HELL YA I GOT IT!! Finally after months of re-visiting. I have the AcerR13 with the mediatek and flip and everything. I assumed and thought from what i found out during reserch, everyone was saying the mediatek is 64 but it has to be 32bit and i did buy the 32gig so i tried the tested version for the 32bit version and bam!! it work, one success after the other, I just installed root checker pro and there it is clear as day "your device is rooted" thank you so much nolirium for all your help you are the best! now i must go play with this thing now. :)
ReplyDeleteInteresting... Having now had a chance to take a look at the /system folder of the R13 and some of the other (Arm) devices, it appears that all of them are in fact using a 32 bit Android container at present..
Deletethe original version with the 1-3sh script worked great for me. no errors just good ole' rooting. thank you so much Nolirum for all your help with this. Now incase of a powerwash i would just run the scripts again?? Oh and for anyone else Im on the AcerR13 meditek CB
ReplyDeleteGood to hear that you got it working! Yes, you can just run the scripts again after a powerwash; sometimes it might also be necessary to re-root after a Chrome OS auto-update.
ReplyDeletePLEASE HELP. im using asus flip
ReplyDeletei've got stuck in this. don't know what to input.
chmod +x *scriptname*
You just have to go into a root shell (Ctrl+Alt+T, type shell, type sudo su), then navigate to the folder where you extracted the scripts - if you extracted them to the 'Downloads' folder for instance you would enter:
Deletecd /home/chronos/user/Downloads
Once you're in the folder with the scripts then you enter the command to make them executable:
chmod +x 1-3.sh
chmod +x 04SEpatch.sh
Then you run the scripts.
NB You don't actually have to cd to the folder to run the scripts, it's just easier to explain it that way. For instance if you have already extracted the scripts to 'Downloads' you could skip the cd part and in a root shell just enter:
chmod +x /home/chronos/user/Downloads/1-3.sh
chmod +x /home/chronos/user/Downloads/04SEPatch.sh
sh /home/chronos/user/Downloads/1-3.sh
reboot
sh /home/chronos/user/Downloads/04SEPatch.sh
reboot
thanks man. i really appreciate this.
Deletenow im stuck in this step and don't know what to input again
sh /home/chronos/user/Downloads/04SEPatch.sh
this is what happen
Deletecrosh> shell
chronos@localhost / $ sudo su
localhost / # sh /home/chronos/user/Downloads/04SEPatch.sh
Test Rooting scripts for Android on Chrome OS
Unofficial scripts to copy SuperSu files to an Android system image on Chrome OS
Part 4 of 4
There is an SEpolicy file located at /etc/selinux/arc/policy/policy.30, which can be patched with SuperSU's patching tool.
This script assists with the process.
Backing up policy.30 to /etc/selinux/arc/policy/policy.30.old, and to /usr/local/Backup/policy.30.old
cp: cannot create regular file ‘/etc/selinux/arc/policy/policy.30.old’: Read-only file system
Copying policy.30 to /home/chronos/user/Downloads/policy.30 to allow Android access to the file.
Opening an Android shell.
Copy and paste the following two commands into the Android shell.
Hit Enter after each one.
If SuperSU is present, the second command should patch the file and display a message indicating this.
su -c supolicy --file /var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
su -c chmod 0644 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
After copy/pasting the commands, leave the Android shell by typing:
exit
root@minnie_cheets:/ #
You should just need to:
ReplyDeleteCopy the first command exactly as one line (In the shell, just highlight it to automatically copy)
Paste (with right click/doubletap) after the #
Hit Enter
do the same with the second command (copy,paste,enter)
then type exit
then reboot.
First command:
su -c supolicy --file /var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
Second command:
su -c chmod 0644 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
yes i already did that. but after i input command this is what happen. it say not found.. maybe i miss something?
ReplyDeleteoh yeah thanks again for your help
root@minnie_cheets:/ # su -c supolicy --file /var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
/system/bin/sh: su: not found
So it looks like su is not present in the image... Did you definitely copy the armv7 and common folders from inside the SuperSU zip to 'Downloads'? Because the first script is supposed to use these folders to add su and its system files to the Android container. If the folders aren't in 'Downloads' it will cause an error. Another possible reason would be if rootfs verification hasn't been switched off.
ReplyDeleteJust to ensure that the command to switch off rootfs verification has been run, you can paste the following into the shell (all one line) then reboot:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
Otherwise, maybe try running the first script again, and check its output for any error messages...
real quick question. the scripts worked great but how many of those files do i need to keep in my DL folder if any. I know i should keep the main scripts but what about all like 20 of the super su folders. just trying to clean up and im not sure what i can and cant get rid of.
Deletehey nolirium, having a problem here ..again. So when i updated my chrome i lost root which is fine but i want to re-run the scripts. i navigate to my downloads folder no problem but for some reason when i try to go into the aroc-015-armv7 folder it says "no such file or directory" but it is clearly there.. any ideas would really help. I may try just taking the scripts out of the folder and see what happens. will it let me run the scripts from my download folder directly. THANKS so much if you can guide me thru this. been two days and its a pain in the ass. but i want my ROOT back!!!
ReplyDeletewell the scripts ran after taking them out of the folder but when i have to copy and paste the commands it says su not found
Deleteok so im trying it all over again.. at least this time it got me into the aroc folder.. wish me luck.. although i dont know if anyone is reading these.lol
Deletedisregard previous comments! i got it done on my own. I just had to erase my previous supersu stuff and re-downloaded it. then everything went smoothly.. your scripts are the best!
ReplyDeleteChiming in to say thanks for your work on this. Huge help. The post mentioned that support for 59 would be coming soon, do you have an update on the status with it?
ReplyDeleteAdded support for 59. Hope to have a more elegant method presently.
DeleteAgain, many thanks - do you have a donate link?
DeleteWithout asking for a deep dive into the technical specifics can you cover what changed in 59 that required a delineation?
Defiantly thanks from me too on these rooting scripts, but i have a couple questions.. 1 is are there any folders i can delete after a successful rooting. Mainly from the supersu download. Is it ok if i delete all the folders except the ArmV7 and common..cause i already did it and everything seems fine. My next question is when i check the rooting status using root checker pro, everything looks good except the red area that says supersu Binary files have not been installed. How can i install them is it doable??
ReplyDeleteHi, regarding your first point: yes, you only need the two folders from the zip in the first place - you can safely delete the rest. You can delete everything else after running the script if you want, or move the folders to an SD card or USB stick - they're just needed when the script runs..
DeleteWhen you open Root Checker Pro and check for root, does the pop-up from SuperSU requesting root authorisation appear? How about any other apps which require root? (for example Ad-Away, Root Explorer) If not, it sounds like there might have been a problem with script 1-3.sh this time around. Which version of Chrome OS are you on?
Interested in your effort to get root in Chrome OS. I'm trying to used the script, but find that "/usr/local/Android_Images/system.raw.expanded.img" is not in the system. Could it be the change of OS update? My current version is: 58.0.3029.51 beta
ReplyDeleteWhich Chromebook are you using? I just tried the script on my Flip C100 on v.58.0.3029.68 beta and it works for me. Do you see any error messages on the script output when you run it? (an example error message: 'sed : cannot open temporary file').
DeleteThis comment has been removed by the author.
DeleteThis comment has been removed by the author.
ReplyDeleteThank you so much for posting these scripts. I had rooted my Asus C100 with it.
ReplyDeleteUnfortunately I ran into an issue where I had to powerwash (beware of Android apps that create screen overlay) and now when I try to open the Google Play store I get a mysterious "unknown error" and nothing else.
So I think I need to start again from a fresh Android image. I do have a backup of the system.raw.img but I don't know how to restore it.
Please help!
Ah yes, the infamous 'Unknown Error'. So descriptive! What I think is happening is a consequence of the changes I have made to the script to support Chrome OS v59 and higher - ChrOS expects the unmodified system.raw.img, but the script has renamed it to system.raw.img.bk.
ReplyDeleteCould you please try running the following version of the script - it should fix it..
https://drive.google.com/open?id=0B-OEkALjx_5Uc3g0SFpPb3VvYXc
Alternatively, if you would like to restore the vanilla unmodified image, pasting the following into the shell should work (all one line):
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Ahh, thank you! I restored as you said and used v018 of your script to root again. Phew, have my Chromebook back!
DeleteI don't know if it is relevant, but before the powerwash I tried to fix the rogue Android app by disabling and reenabling the Play store after a reboot. I recall trying to run the v017 root scripts again but there were some errors (I don't recall the exact messages).
Anyway, everything working fine.~~
Good to hear that you got it working again! I think I'll put the restoration command up at the top & in the readme.txt in case anyone else ends up with the same issue... Yeah, it might be relevant, I couldn't replicate any error myself by disabling/re-enabling the Play Store, but I changed a couple of things in v018 to hopefully minimize the chance of errors... Anyway, thanks for letting me know!
DeleteWill this work for ARMv8 chromebooks, like the Samsung Chromebook Plus?
ReplyDeleteYes, it should work; I checked the (stable) recovery image for KEVIN and it's a 32-bit Android install, same as the rest I've seen. (ro.product.cpu.abilist64 is blank in build.prop; no 64-bit libs).
ReplyDeleteIn addition, while I haven't had any feedback regarding the Chromebook Plus, Keith Kaaos reported success with his R13, which sports a similar processor (armv8 M8173C).
Hey the chrome os version just got updated could you please fix ASAP?! Thank you!! ;)
ReplyDeleteBTW ur the best forgot to say that
DeleteWorking on it. Thanks for the heads-up!
DeleteNo Problem! :D
Deletehey how long does it usually take you to make a script like this? and is it hard to do? :)
DeleteTo make the rooting scripts? It took a looong time. But that was mostly just the first time around - getting to know my way around Chrome OS: file locations, shell commands and so on.
DeleteIt wasn't really hard work as such (though I did have to read around a little on xda, chromium.org). Mainly just used Chainfire's update-binary as a guide (it's in the SuperSU zip in the folder /META-INFO/com/google/android/update-binary), took out all the boot image stuff since we don't need it for CrOS), put the commands we do need into the right format, and added in a few CrOS-specific things to the script (formatting a blank container, checking /etc/init/ and a couple of other bits and pieces).
There used to be an easier way, a few Chrome version numbers ago, but they keep changing things around slightly as the Android compatibility layer "improves".
In theory, most of the work should be done already, and updating the scripts with the OS auto-updates hasn't been too hard so far, but this one isn't booting yet so...
thanks! Damn do u have like a phd in computer coding or something i mean im 13 and ive poked around several chromebooks and i still dont know how to do this kind of stuff thanks for your hard work man so we can have fun P.S. im getting a bt controller tomorrow so i can beast mode at Modern Combat 5! and of course hack it to my advantage... if i can
Deletein dev mode of course (forgot to add that)
Deletebtw funniest thing ever to do someones working on a cb push esc+rel+pow aka dev mode they will be like wtf???
DeleteHi, just tried your script, and Im getting a "No space left on device" error https://pastebin.com/npW09HL3 . Thanks for help
ReplyDeleteWhich device/Chrome OS version? A lot of devices were updated to Nougat lately and I might need to fix the scripts somewhat.
DeleteCould you do me a favour - paste the following command into a root shell, and let me know the output?
du -sh /opt/google/containers/android/rootfs/root/
The output is:
Delete"1.3G /opt/google/containers/android/rootfs/root/"
Also, after running your script, my Android Apps were broken, so I did a ChromeOS recovery... Im on 60.0.3112.34 BETA. Device: LARS
before i updated it always worked for me on dev
Delete1.3G... I see... Thanks. That's the size your rooted Android image will need to be, then. (plus a few MB for SuperSU). The script was using something slightly smaller.
DeleteSorry, no ETA on a new version of the script right now, but if you want to give it a try yourself you can open the 01Root.sh in a text editor (I use Caret), Ctrl+F "count=1024000" change it to "count=1384000", Ctrl S, and run the script again...
It probably still won't work, but you never know. I don't know if Android 7.1.1 has rolled out on CrOSv60 beta on your device yet but if it hasn't, and you are still on Android 6, then it *might* work.
I need to get a hold of a few of these various Intel Chromebooks so I can test out if anything else is up. Something else might need customizing in the scripts.
You mention that the Android Apps were broken after trying the script - did you get a chance to run the command highlighted in grey at the top of this post before doing the recovery? The one that starts off "sudo mv ..." That's the command that *usually* fixes the broken Android apps...
or you can just get us in a hangouts call with screen share!
Deletebtw i have an intel chromebook
Deletefor some reason my name on my google account datsaxophonist@gmail.com got changed to Dat Saxophonist... lol
Deletealso in dev it got updated to 61 not 60
DeleteIm on Android N, and no, I didnt try the mv thing
DeleteI've uploaded a new version, which works for me on Android N. If you try it, and it works... that's great... If you try it and still get any errors, it would be good if you could report back..
DeleteYeah, the mv thing should restore the original, unrooted, Android filesystem. In case of any errors, copying that line into the shell and then rebooting should return the Android system to how it was before running the scripts..
it didnt root:(
Deleteyeah its not working
DeleteArm or Intel?
DeleteDid any error messages show up on the script?
Deleteno
DeleteIs this on your Intel Chromebook, or an Arm one?
DeleteWas it the case that Android would boot after running the scripts, but was not rooted, or was it Android broken (i.e. apps not loading at all)?
BTW - as you know - if it's broken, the easiest way to get it up and running is the mv command, you'd also need to reboot before doing anything like re-trying the scripts.
no superSU said root undetected
Deleteintel
DeleteCan you try this: In a root shell, type android-sh.
Delete...The prompt should change to (something)_cheets
DeleteThen type/paste:
Deleteps | grep daemon
Does anything show up?
Deleteit puts a 1| before samus_cheets
DeleteOK, now try:
Deletedaemonsu --auto-daemon
What shows up after that?
DeleteYAASSSS
Deletety
Interesting.. So it seems that the only thing that's not working in the scripts is the very last part of the first script, where I changed the method of autoloading daemonsu from hijacking app_process to injecting a line into init.rc...
DeleteCan you try this: Back in the Chrome OS root shell, enter (all one line:
Deletevi /opt/google/containers/android/rootfs/root/init.rc
Highlight the first 15 lines or so, which will copy them, then paste them in here
Delete# Copyright (C) 2012 The Android Open Source Project
Delete#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.super.rc
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.usb.configfs.rc
import /init.${ro.zygote}.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Disable sysrq from keyboard
write /proc/sys/kernel/sysrq 0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
# Set the security context of /postinstall if present.
restorecon /postinstall
on init
sysclktz 0
# Mix device-specific information into the entropy pool
copy /proc/cmdline /dev/urandom
copy /default.prop /dev/urandom
# Backward compatibility.
"/opt/google/containers/android/rootfs/root/init.rc" 660 lines, 25030 characters
OK cool. That's as it's supposed to be. Now can you do the same again but with init.super.rc (the file we created in the script?
Deletevi /opt/google/containers/android/rootfs/root/init.super.rc
(It should be just a few lines)
DeleteThe deamonsu --auto-daemon thing worked !
DeleteAnd the output of /opt/blahblahblah/init.super.ir
Deleteservice daemonsu /system/bin/daemonsu-service.sh service
class late_start
user root
seclabel u:r:init:s0
oneshot
This comment has been removed by the author.
DeleteSo yeah, the daemon's not getting started at boot... I'm looking into it now, will post the fix here once I get it sorted...
DeleteIn the meantime, as a workaround, if you want, you can set SE Linux to 'Permissive', which should let the daemon get launched at boot. To do this, either manually edit /etc/selinux/config, replacing the word "enforcing" with "permissive", or alternatively, the following command will do this automatically, if you run it in a root shell (all one line):
Deletesed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config
HERE IS THE PROPER FIX:
DeleteEnter the following into the Chrome OS root shell (all one line), then reboot:
sed -i 's/u:r:init:s0/u:r:supersu:s0/g' /opt/google/containers/android/rootfs/root/init.super.rc
How should I proceed when updating from v20 -> v21? Just rerun it ?
DeleteNo need! Literally the only difference is the fix in my post just above. You can just paste that one-liner into a root shell, and reboot, and everything should be sorted.
Delete(The formatting looks strange in this comment field but if you paste the command into the shell it'll be normal)
(Although if you do want to re-run it, it would be best to do the mv command, then reboot, then re-run). But, like I say, there should be no need...
DeleteJust got an idea: Wouldnt rebooting just the Android subsystem be enough ? Without the need to reboot the whole machine ? (Writing "reboot" in android-sh)
DeleteGood point! I guess you might have tried it already but yeah, that seems to work in this case. It would be good if we could figure out a way to do the whole rooting process without having to reboot the Chromebook - as far as I can tell at the moment though that doesn't seem to be possible.
DeleteYou mean including the ./make_dev_ssd --remove_rootfs_verification --partition 4 reboot ?
DeleteI just created this script to help me with setting up my CB shell after an update/powerwash: https://drive.google.com/open?id=0B61hm4T5zshYN1h4Yk1lTHJpMFE . Does it look good ? Thanks
DeleteOh, hey. I missed your comment before. Just took a quick look at your script - nice idea to setup stuff automatically. I'm not sure if the rooting scripts are going to cope with being run from within another script as-is, but it would be cool if they are. Does it work for you?
DeleteIf you do any more work on it you might consider putting it on github maybe, so people could send pull requests etc if they have any ideas. I'm probably going to put my aroc scripts up there sometime soon, after I take another look and see if I can clean them up/improve them at all first.
RE: the previous comment. No, the verification removal will always require a reboot, I think. I just meant the two scripts (rooting and patching script). Actually, I've been thinking I'd like to figure out an alternative way to do the whole process, if possible. Maybe just overlaying certain folders rather than making a whole second copy of /system. Not sure at the moment, though.
The rooting scripts work fine, got an update after finishing it, so I could test it out. It is a lot of fun to write something and then watch it how its working :).
DeleteK, made a repo on Github, anything I could improve ?
Deletehttps://github.com/LufyCZ/ChOS-SetupScript
Thanks
Cool, nice work.
DeleteOne thing I noticed:
The rootfs verification command - I think the active kernel varies, AFAIK it can be either partition 2 or 4. Might be better to use something like
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
I can't remember what else I thought it might be good to add now - it's been quite a while since I last powerwashed, but I expect I'll have to do it sooner or later, and then I'll most likely notice what I'm missing...
Will let you know if I notice/think of anything else, anyway...
I finally got around to cleaning up my scripts a bit and put them up here:
https://github.com/nolirium/aroc
The only major improvement from the previous version is that the patching command is now automated via printf and a pipe | to android-sh, avoiding the need to copy/paste.
I also integrated both the armv7 and Intel versions into one, although I haven't tested on an Intel Chromebook so am not 100% sure if the new version works OK on Intel - it's possible I may have introduced a bug/error/typo somewhere along the line...
Thanks. I used your command and replaced the links to point at your github. You have to use it even if you update, not only after a powerwash
DeleteYEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESSSSSSSSSSSSSSSSSSSSSSSS UUUUUUUUUUU DDDDDDDDDDDDDEEEEEEEEEEEEEEEEEDDDDDDDDDDDDDDDD IIIIIIIIIIITTTTTTTTTTTTTTT!!!! :)
ReplyDeletesorry i got exited
DeleteYAAASSSS
DeleteThis comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteJust wondering, what happens whens there's an update for chrome os? Will it stay rooted or will I only have to through the process again if they just make changes to the android system.
ReplyDeleteYou would most likely have to re-do the whole process (including removing rootfs verification) after the first update, as Chrome OS keeps two copies of its kernel and rootfs on the device - one pair which it boots from, and another pair to which OS updates are applied. If you type 'rootdev' into the shell, and it returns, for instance, '/dev/mmcblk0p5', your current Chrome OS rootfs is on partition 5, so the next update will get applied to the 'spare' rootfs (on partition 3), which will then be the new 'current' rootfs after a reboot.
DeleteAfter the first update, though, it should depend on what files get updated. The Android system seems to be under pretty active development, though, so (and in my experience), more often than not, the scripts would need to be rerun after an OS update. While Android userdata etc doesn't get affected, a few Android system settings (e.g. whether Developer options are enabled) do get reset during the process.
Of course, the frequency that updates occur will depend on which release channel you are running on the device; Canary channel being the most frequently updated, and Stable the least.
Hello dear OP, I'm in need of help.
ReplyDeleteThis is what it says at 01Root.sh.
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Moving original rootfs image to /opt/google/containers/android/system.raw.img.bk
Creating symlink to /usr/local/Android_Images/system.raw.expanded.img
Copying /etc/init/arc-setup.conf and /etc/init/arc-system-mount.conf to /usr/local/Backup
Setting 'env WRITABLE_MOUNT=1' in /etc/init/arc-setup.conf and /etc/init/arc-system-mount.conf
Setting 'env ANDROID_DEBUGGABLE=1' in arc-setup.conf
Make sure the armv7 and common folders from the SuperSU zip have been extracted to 'Downloads'
Now placing SuperSU files. Locations as indicated by the SuperSU update-binary script.
Creating SuperSU directory in system/app/, copying SuperSU apk, and setting its permissions and contexts
Copying su binaries to system/xbin/ and setting permissions and contexts
Creating directory system/bin/.ext/.su
Copying su to system/bin/.ext/.su and setting permissions and contexts
Copying supolicy to system/xbin, libsupol to system/lib and setting permissions and contexts
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
Symlinking system/bin/install-recovery.sh to system/etc/install-recovery.sh
Adding system/bin/daemonsu-service.sh
Creating file init.super.rc in Android rootfs
Adding daemonsu service to init.super.rc
Adding 'import /init.super.rc' to existing init.rc
And when I do the next part, it says...
Copy and paste the following two su commands into the Android shell.
DeleteHit Enter after each one.
If SuperSU is present, the first command should patch the file and display a message indicating this.
NOTE: If you are still running Android 6.0.1 (Marshmallow), change --sdk=25 to --sdk=23 at to the end of the first command.
su -c supolicy --file /var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25
su -c chmod 0644 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
After copy/pasting the commands, leave the Android shell by typing:
exit
d/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
CANNOT LINK EXECUTABLE "supolicy": library "libsupol.so" not found
Aborted (core dumped)
/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
CANNOT LINK EXECUTABLE "supolicy": library "libsupol.so" not found
Aborted (core dumped)
134|caroline_cheets:/ # daemonsu --auto-daemon
ownload/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
1|caroline_cheets:/ # su -c chmod 0644 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
1|caroline_cheets:/ # exit
Error!
Patched SE policy file not found! Unable to complete the procedure.
You may need to retry script 01Root.sh and check its output for any errors.
Thank you in advance, JAke.
DeleteMaybe just check if libsupol.so is there, first of all, I guess?
DeleteIn a root shell, can you enter the following (all one line), then paste the output in here
ls -alZ /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
1|caroline_cheets:/ # ls -alZ /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
Deletels: /opt/google/containers/android/rootfs/root/system/lib/libsupol.so: No such file or directory
Sorry, I wasn't clear. You need to do it in a root shell in Chrome OS...
DeleteSorry for my incompetence!
Deletechronos@localhost / $ ls -alZ /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
ls: cannot access /opt/google/containers/android/rootfs/root/system/lib/libsupol.so: Permission denied
Some sort of permission error :/
DeleteNo problem. But that's a regular shell in Chrome OS. You also need to enter
Deletesudo su
to get into a root shell, then paste the command.
Aha! A result.
Deletelocalhost / # ls -alZ /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
-rw-r--r--. 1 root root u:object_r:system_file:s0 203236 Jul 16 20:28 /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
Note: If you didn't do sudo, or sudo su before running the scripts (i.e. if you ran them as chronos@localhost), you'll need to start over, anyway.
DeleteDoes this help you?
DeleteWell, it tells us that the file the script was complaining about does in fact exist, and has the right permissions and contexts..
DeleteMaybe try this:
In the CrOS root shell (localhost / #):
Open a fresh caroline_cheets shell with
android-sh
Then try
daemonsu --auto-daemon
Does it bring you back to an identical command prompt, or does a 1| appear at the far left?
Identical
DeleteThat means it's working...
DeleteYou did reboot after running the first script, right?
I rebooted after each step, as said :)
DeleteHmm, so everything copied across OK, most probably.
DeleteDoes
ps | grep daemon
in the caroline_cheets shell bring up three lines or so?
caroline_cheets:/ # ps | grep daemon
Deleteroot 1609 0 84768 7108 __skb_wait 401b83a3 S daemonsu:mount:master
root 1612 0 84768 6812 __skb_wait 401b83a3 S daemonsu:master
Yes ?
So at this point root should be working, but without patching the SE Linux policy, daemonsu won't start automatically at boot.
DeleteSome of the output of script 02 that you pasted in above has been cut off. Can you try running it again, in a Chrome OS root shell, then paste it in here again, but before you do so, enter the following into the CrOS root shell:
setenforce 0
Test Rooting scripts for Android on Chrome OS
DeleteVersion 0.21
Unofficial scripts to copy SuperSU files to an Android system image on Chrome OS
Part 2 of 2
There is an SE Linux policy file located at /etc/selinux/arc/policy/policy.30, which can be patched with SuperSU's patching tool.
This script assists with the process.
Backing up policy.30 to /etc/selinux/arc/policy/policy.30.old, and to /usr/local/Backup/policy.30.old
Copying policy.30 to /home/chronos/user/Downloads/policy.30 to allow Android access to the file.
Opening an Android shell.
Copy and paste the following two su commands into the Android shell.
Hit Enter after each one.
If SuperSU is present, the first command should patch the file and display a message indicating this.
NOTE: If you are still running Android 6.0.1 (Marshmallow), change --sdk=25 to --sdk=23 at to the end of the first command.
su -c supolicy --file /var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25
su -c chmod 0644 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out
After copy/pasting the commands, leave the Android shell by typing:
exit
/var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
CANNOT LINK EXECUTABLE "supolicy": library "libsupol.so" not found
Aborted (core dumped)
ownload/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
CANNOT LINK EXECUTABLE "supolicy": library "libsupol.so" not found
Aborted (core dumped)
134|caroline_cheets:/ #
http://imgur.com/a/r15OB
ReplyDeleteIf this helps.
I got an error this time, hopefully this may show us the error?
ReplyDeleteI haven't come across this issue before, tbh. One thing you can try, is to run this script again, but before you copy and paste the two lines, try to set the library path manually with:
ReplyDeleteexport LD_LIBRARY_PATH=/system/lib/
...then copy paste the two lines, and see if you still get the error.
Used the command you said, friend.
DeleteUnfortunate we don't know of this error :/
134|caroline_cheets:/ # export LD_LIBRARY_PATH=/system/lib/
ownload/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out --sdk=25 <
CANNOT LINK EXECUTABLE "su": "/system/lib/libstdc++.so" has unexpected e_machine: 3
Aborted (core dumped)
134|caroline_cheets:/ #
Interesting that you get a different error now. I'm now wondering if the latest Android system for Caroline (that's the Chromebook Pro, right?) could have been customized/updated specifically for that device. This seems unlikely, though.
DeleteWhich Chrome OS version are you running? And which channel?
I'll probably have time tomorrow to examine the recovery image for Caroline (stable channel). If there's any change, relative to other devices, I'll know then.
By the way, are you running these commands in a small window, or with large fonts or something? (if so, ctrl and minus is the shortcut to decrease text size in the shell, same as in the regular browser) ...Not that this would cause an error; it's just that some of the output that you've pasted in again appears to have been cut off at the left hand side, making it hard to know for certain what's going on.
Thanks for reply to start with! it is a Samsung Chromebook Pro, Dev Channel, 60.0.3112.52
Delete"Firmware" : Google_Caroline.7820.300.0
Channel
"Platform" : 9592.42.0 (Official Build) beta-channel caroline
Firmware
Thanks :D
In the meantime a workaround to avoid the necessity of patching SE Linux would be to simply switch off the enforcing mode of SE Linux completely (switch it to permissive instead of enforcing).
DeleteIf you would like to do this, one way of doing so is entering the following command into a (localhost / #) Chrome OS root shell (all one line):
sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config
Assuming everything went O.K. with copying the files across etc in the first place, entering the above then rebooting should negate the necessity to patch SE Linux at all, allowing daemonsu to launch at boot, and root apps, root checker etc, should then work.
It worked :D Thank you so much! I've now been rooted :DD Much love!
DeleteGlad you got it sorted! Bear in mind that since you're on the beta channel, CrOS will auto-update sooner or later, and you'll have to re-run the first script, and the above command, to gain root again (you wont lose any data by doing so).
DeleteI'll look into the SE Linux issue when I have time, and once I find out what's up with that, I'll post back here. It shouldn't be an issue at all to keep SE Linux in 'permissive' mode for the time being, though.
So, I messed things up while trying to remove ads with Lucky Patcher, and it broke my apps/playstore.
DeleteSo, I decided to powerwash. All's well, did the SU stuff again, follow our previous convosation.
I come to enter the second command again, after he 02RE thing, and it says:
"/var/run/arc/sdcard/default/emulated/0/Download/policy.30 /var/run/arc/sdcard/default/emulated/0/Download/policy.30_out <
CANNOT LINK EXECUTABLE "supolicy": library "libsupol.so" not found"
Sorry to be annoying XD Thanks, JAke.
Kinda got passed it, then it doesn't launch anything xDD, It has like a circle buffer thing?
DeleteCheck the note up at the very top of this page. The best thing to do when you want to start afresh is to run the command highlighted in grey at the top of the page (sudo mv...), which will restore the unrooted Android system.
DeleteThen reboot. After that, open the Play store (or an Android app) to check it's working, and then you can run script 01 again. Since script 02 wasn't working for you last time, you can use the
sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config
command that I mentioned previously instead of script 02.
By the way, I'd recommend just using a hosts-based solution such as Ad-away for adblocking (although it won't block *all* in-app ads, it does seem to block most of them.)
Does this support Chrome OS 61, and does it still work after chrome os updates or would I need to do this process again?
ReplyDeleteYes, it should work fine on v61, at least up to R61-9765.31.0 (current Dev version on my device).
ReplyDeleteThere might be a problem with CrOS v62 at the moment though; v62 is in Canary on my device, and root does *not* work properly. It's a bit tricky testing against Canary, as it can be somewhat buggy anyway, but hopefully further investigation will reveal the issue soon.
In general, Chrome OS updates (aside from component updates e.g. flash player) tend to overwrite the CrOS rootfs with a fresh version, rendering it necessary to re-do at least the SE Linux patching, and the creation of a symlink between the rooted Android system image in /usr/local, and the original file path at /opt/google/containers/android/system.raw.img.
The Android subsystem seems to be under constant development, however, so it would probably be best to re-do the entire procedure after a CrOS update, as there would most likely have been changes made to the Android rootfs image.
Recently I was toying with the idea of trying to set up a persistent rootfs patcher, at least for myself, but that could potentially create more issues than it solves, especially since the Android subsystem is something of a moving target, in terms of potential for modding.
So I made a few minor changes to the scripts which seem to have fixed things on v62 platform 98xx, and on v62 platform 9904 (which is the most recent OS version pushed to my device). Possibly also any issues which may have been occurring on older CrOS versions may now have been fixed, although it's hard to know exactly which OS changes get merged into which version.
ReplyDeleteRegarding:
"Error!
Patched SE policy file not found! Unable to complete the procedure."
If you are getting this error, you can try entering
printf "su -c supolicy" | android-sh
into a (CrOS) root shell. Some info from SuperSU/supolicy should be displayed. If nothing happens, it might be worth running the updated version of the scripts if you haven't already done so, or trying to force a CrOS update then retrying.
it just sits there, saying "copying android system files". ???
ReplyDeleteThat part of the script does take a while, but it should be no longer than 2-3 minutes. If it's taking longer than 5 minutes, then something's not right. If that's the case, can you post which device you're using, and which OS version/platform (from chrome://version), and release channel?
DeleteI did this on v63 on my samsung chromebook plus, and it no longer would boot. :( I had a recovery sd card ready and most things were backed up though.
ReplyDeleteOh, that's unfortunate. I wonder what happened, exactly. Did you run the most recent combined script, from the top of this page? When running the script, did you happen to notice if any error messages were shown in the output?
DeleteI'm guessing you were on the Dev release channel - I don't suppose you might have noticed, at the time you ran the scripts, whether or not you may have had an update waiting to be applied post-reboot (update icon in the system tray)?
After you ran the rooting script, I'm guessing that you rebooted the Chromebook - what happened next... i.e. did the OS partially boot, and if so, how far did it get?
Sometimes it is possible to get into a VT when the first parts of the OS load up (directly after the white Ctrl+D screen), then switch the rootfs partition priorities from there with cgpt, thus avoiding having to recover the OS.
Having said this, I haven't had any other reports of issues, or experienced any issues myself, with booting a device after running the rooting scripts, up to and including CrOS v64), although I have experienced boot failures after experimenting with other OS modifications and, once or twice, after OS updates.
In any case, sorry to hear that you experienced this issue, and thanks for the report
Part 2 of 2
ReplyDeleteThere is an SE Linux policy file located at /etc/selinux/arc/policy/policy.30, which can be patched with SuperSU's patching tool.
This script assists with the process.
Checking for the presence of SuperSU...
Error!
SU binary not found! Unable to continue.
Need to fix this issue.
I have 64 bit system with Intel.
Thank you.
Part 2 of 2
ReplyDeleteThere is an SE Linux policy file located at /etc/selinux/arc/policy/policy.30, which can be patched with SuperSU's patching tool.
This script assists with the process.
Checking for the presence of SuperSU...
Error!
SU binary not found! Unable to continue.
Need to fix this issue.
I have 64 bit system with Intel.
Thank you.
It looks like you are using the two separate scripts, is that correct? If so, I suggest trying the new combined script from the top of this page. You might need to restore the original Android container first before re-trying the rooting script, which you can do with "sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img" (which is also mentioned near the top of the page).
DeleteIf you still get error messages from the combined script, you may post them here again (also post which CrOS version & platform number you're on), and we can see if we can figure it out.
I have recovered my system Chrome OS version 61.0.3163.120 (64 bit).
DeleteThis time I have tried one script which should suit both Intel and ARM.
I have used this script
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
then rebooted.
After removing rootfs verification I have just entered main script.
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
Eventually,it started downloading
busybox 100% (I guess successfully)
SuperSU.zip 100% (Also successfully)
From this point "Unzipping SuperSU zip" errors started to appear.
/usr/local/bin/busybox: 1: Syntax error: word unexpected (expecting ")")
Unzipping SuperSU zip, and copying required directories to ~/Downloads.
and a lot of
/opt/google/containers/android/rootfs/android-data/data/adb/su/bin/su No such file or directory
Checking for the presence of SuperSU...
Error!
SU binary not found! Unable to continue.
Interesting. A problem with BusyBox unzipping the file? I shall investigate to see if I can find any reason for this. Perhaps a download integrity check for Busybox (e.g. a checksum or filesize check) should be added to the script (there's a basic filesize check for the SuperSU zip, but nothing to verify the BusyBox download at the moment).
DeleteIf you still have the screen showing the output from the script, it might be helpful if you could copy this and paste it to somewhere like pastebin and provide the link.
Otherwise, something you could try, which might help to narrow down the issue, is to manually download the SuperSU zip and extract its contents to the Downloads folder, then try running the script again.
Just for clarity, please be advised that normally in case of error, it shouldn't be necessary to recover the entire Chrome OS system or powerwash the device. If the script fails, restoring the original Android container if necessary (and rebooting the device), should be sufficient. (you may have done just this, I can't tell from your post).
So, anyway, if you would like to help to try to narrow the issue down, the steps would be:
1. Restore original Android container if necessary with the following command (all one line)
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
2. Download SuperSU 2.82 SR3 zip from
https://download.chainfire.eu/1122/SuperSU/SR3-SuperSU-v2.82-SR3-20170813133244.zip
3. Unzip/copy subfolders from above into ~/Downloads
4. Run latest script again, and see if you still get errors
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
Unfortunately,script which restore original Android container does not help me,I think it makes his command but it does not fix broken Android Apps and Market,so I have to recover each time.
DeleteThis time I have first unzipped and then ran the latest script.
Here is the result.
http://pasted.co/b1204304
I should have mentioned in my previous comments that it is necessary to reboot the Chromebook after restoring the original container. However, it sounds like you might have tried that without success, anyway.
DeleteFrom looking at your paste, it seems that the issue now is not related to BusyBox at all Rather, the issue now appears to be with patching the SE linux policy files. I am curious which platform number your Chrome OS version is on (if you go to chrome://version you should be able to see the platform number on the 3rd line down). Reason I am curious is that I am aware there were some issues around platform ~9900 which I was unable to bisect to a specific change, but no longer occurred on ~9904 and higher (I am currently on platform 10049)
If you have not yet restored the OS again, you could try to run
printf "su -c supolicy " | android-sh
and see if anything happens.
Platform 9765.81.0
DeleteShould I insert "printf" command straight after shell command?
printf "su -c supolicy " | android-sh
bash: android-sh: command not found
bash: printf: write error: Broken pipe
Oh, sorry, I neglected to mention that you need to be in a root shell to run that last command, so you'll need to do sudo su first.
Deletehttp://pasted.co/9adbe281
DeleteSomething new.
Just briefly, if your system is in the same state as when you posted the above, you could try rebooting and running the separate SE linux patching script at this point.
DeleteReason being, those errors are just regarding the SE Linux policy patching part of the script, for some reason it is saying that there is insufficient space under /opt/google/containers/android/rootfs/android-data/data/adb/su/lib to temporarily copy the /lib directory from the Android container in order to bind mount it.
If the android-sh command is returning
"Container PID file not found, is the container running"
either when running it on its own (which should bring you into a command prompt within the Android namespace environment), or with piped commands like
"printf "su -c supolicy " | android-sh", then it could be useful to check a couple of the Chrome OS Android setup logs,
tail /var/log/arc-setup.log
more /var/log/arc-system-mount.log
... or such similar.
I have made some small changes to the combined script today, when I have some time I intend to go back through the current release channels, testing the script for any possible bugs or incompatibilities on each one, as it has been a little while since I last did this, and certain parts of the OS keep getting changed slightly with updates.
I just powerwashed and downgraded to 61.0.3163.123 (32-Bit); platform 9765.85.0, and on this OS version the rooting process completed successfully for me. So it seems we can probably rule out any (security-related, or other) changes to the OS itself.
DeleteHowever, I am using an arm device to test it out, and some parts of the script differ slightly when it's executed on an Intel device. I do know it was working fine on Intel at least until fairly recently, though.
The first script I guess worked successfully,however there is an issue with the second one.
ReplyDeletehttp://pasted.co/d661eaaa
Just seen this comment, Blogger marked it as spam for some reason.
DeleteJust to check, if you do
ls -al /opt/google/containers/android/system.raw.img
does it show as a symlink (arrow pointing) to /usr/local/Android_Images/system.raw.expanded.img?
Can you get into the Android shell with
sudo android-sh
and if so, if you do
ls /system/xbin/
within the Android shell, do su and daemonsu show up there?
Yes,it shows an arrow.
ReplyDeleteHowever I could not understand what to do with Android shell.
http://pasted.co/a792fcb1
Apologies for the delayed response.
DeleteThe Android shell stuff was just to check if the container was running at that point and, if so, to try and check if the su files had been copied successfully.
I was wondering if you managed to resolve the issue at all, or maybe were still stuck at the SE policy patching part of the proceedings?
If you didn't manage to resolve the issue already, perhaps Chrome OS has been updated in the meantime. If CrOS has been updated since you tried last, I might suggest trying the script again, and seeing if the policy patching works at all this time.
my chromebook language is Chinese, when I implement the root script and reboot, the playstore fonts garbled. how to fix it?
ReplyDeleteI have the same problem. After the rooting, all android apps with Chinese characters are no longer visiable.
Delete：（
DeleteHello,
DeleteThanks for the reports, and I apologise for the delayed response.
I just installed some apps with Chinese fonts to check it out, and can see exactly what you mean.
Unfortunately this is due to a recent implementation of font sharing between Chrome OS and the Android subsystem (via a shared mount). This, for some reason, seems to break supersu when enabled. I noticed this a while ago, thus the script makes the following change in CrOS:
In /etc/init/arc-setup-env:
export SHARE_FONTS=1
is changed to
export SHARE_FONTS=0
The above change fixes supersu, but, as per your reports, stops certain fonts being displayed correctly in Android.
Now that I am aware that this issue is impacting people, I will try to further investigate a possible fix.
To be honest, I think the current shared fonts implementation seems like a temporary workaround on the part of the CrOS developers. I mean, who wants the output of the "mount" command polluted by hundreds of lines of fonts names! Hopefully a more elegant implementation is in the works.
It's very inconvenient, so not really a workaround, but it is possible to switch shared fonts back on (which will break root) with something like the following
sed -i 's/export SHARE_FONTS=0/export SHARE_FONTS=1/g' /etc/init/arc-setup-env
After a reboot, shared fonts should work (but supersu will not work). Then, to reverse the process,
sed -i 's/export SHARE_FONTS=1/export SHARE_FONTS=0/g' /etc/init/arc-setup-env
In any case, I apologise for the inconvenience, and please be assured that I hope to find a proper fix for this issue soon.
Thanks for your reply, I am looking forward to a new solution.
DeleteHello,
DeleteSorry about the delay in resolving this. Please see my post on github for a workaround to (hopefully) resolve this issue.
https://github.com/nolirium/aroc/issues/1#issuecomment-360870279
In short, we can copy the font NotoSansCJK-Regular.ttc (and any other required fonts, space permitting) from Chrome OS to the location where Android expects it (e.g. copy from /usr/share/fonts/notocjk/NotoSansCJK-Regular.ttc in CrOS to /system/fonts/chromeos/notocjk/NotoSansCJK-Regular.ttc within the Android container).
Once we do this (and reboot), the characters which were previously missing in Android apps should now be visible.
I've got a slight problem running the scripts.
ReplyDeleteChrome OS Version 62.0.3202.97
board is a rikku.
Attempting to run the scripts (first of the seperate, or the combined one) both have the same results:
Copying /etc/init/arc-setup.conf and /etc/init/arc-system-mount.conf to /usr/local/Backup
Setting 'env WRITABLE_MOUNT=1' in /etc/init/arc-setup.conf and /etc/init/arc-system-mount.conf
cp: cannot stat '/etc/init/arc-system-mount.conf': No such file or directory
cp: cannot stat '/etc/init/arc-system-mount.conf': No such file or directory
cp: cannot stat '/etc/init/arc-setup.conf': No such file or directory
cp: cannot stat '/etc/init/arc-setup.conf': No such file or directory
sed: can't read /etc/init/arc-setup.conf: No such file or directory
sed: can't read /etc/init/arc-system-mount.conf: No such file or directory
Setting 'env ANDROID_DEBUGGABLE=1' in arc-setup.conf
sed: can't read /etc/init/arc-setup.conf: No such file or directory
Error!
System.raw.img not found
I've made sure to use the command:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 2
and just to be sure, also the other variant. Any pointers you could give me ?
That's a Chromebox, right? You said version 62... Does the device actually have Android app support at all on CrOS v62? I see the Chromeboxes are still listed as "planned" on Google's site (which may not be 100% up to date)...
DeleteIf you go to Settings > About Chrome OS > Detailed build information, does it show an ARC version number listed there?
Need help please. Have HP Chromebook Intel script isn't working.
ReplyDeleteWhen you ran the script, did any error messages show up at all?
DeleteI ran the combined script and it seemed to have worked fine however it says im not rooted
ReplyDeleteI have tried running the daemon auto daemon and it returns daemonsu not found
DeleteWhich device/ Chrome OS version are you trying the script on? If it's a Pixelbook, the size of the created container apparently needs to be increased a bit. If it's another device, it might be a different issue, though..
DeleteIt's a Chromebook Plus running version 63
DeleteIt's a Chrombook Plus running OS 63
DeleteOK, well, it definitely should work then. Bear with me, I'll test it out on my arm device shortly; it's possible that something might have changed in Chrome OS in recent weeks (for instance, a security update), which could have broken the scripts. I'll post back with results later today.
DeleteAlright
DeleteYeah, it's still working for me (v64). Some things you could do in the CrOS shell to try and check what's going on:
DeleteFirstly, to make sure that the symlinked rooted container is in place you could do
sudo su
ls -al /opt/google/containers/android/
If the symlink's in place you should see system.raw.img in blue text with an arrow pointing to the rooted container in /usr/local, i.e. you should see
system.raw.img -> /usr/local/Android_Images/system.raw.expanded.img
If that's the case then, assuming that the SuperSU apk's installed (i.e. as long as you can see the SuperSU app in the Chrome OS launcher app list), another thing you might try is to see what the SuperSU app is saying via logcat
sudo su
printf "logcat | grep SuperSU" | android-sh
You should see a bunch of messages from the SuperSU apk showing at the bottom, you can highlight, copy and paste them in here, or take a screenshot and post the link here.
http://pasted.co/0ab90d21
DeleteThis is what im getting and I think is is error free
http://pasted.co/dab16d69
DeleteThis is the result of the ls -al /opt/google/containers/android/
http://pasted.co/3487424a
DeleteThis is the SuperSu one
Tried resetting the androd but it says no such file or directory when I use the script at the top
DeleteOK, yeah, in /opt/google/containers/android/ this file
Delete434548736 Jan 22 22:52 system.raw.img
is the original unrooted container, but it should be a symlink to the rooted one. That'll be why the daemon's not running at boot (hence why it says you're not rooted). You're gonna have to try running the script again, I think.
As to the reason for this: if the script worked fine the first time, one possible reason why you're not seeing the expected result would be if you happened to have an OS update waiting to be applied in the background. Due to the way Chrome OS updates itself, it keeps two (normally identical) copies of itself on partitions 3 and 5, one active, and one 'spare', and usually switches between them every OS update. (aside: If you do 'rootdev' in the shell it'll tell you which partition you're currently running from).
It's possible that due to the timing, the partition that was active when you ran the script, is now the 'spare' one...
So, anyway, I'd suggest retrying the script. It might be worth copying the script's output into a note as well, just in case.
So i went to powerwash and rollback my Chromebook and it said i was misssing some parts of chrome would that be the problem? Also im running chrome 65 that may also be a problem?
DeleteNeither of those things sounds like a problem. The "Chrome OS is missing or damaged" screen is normal at a certain point, and I just updated to CrOS v66 (canary channel) and root is working fine (I'll update the post at the top to indicate this).
DeleteRe: your post at 25 January 2018 at 14:05
"Tried resetting the androd but it says no such file or directory when I use the script at the top"
I think it was just saying that because it was trying to restore the original file from the backup, but in your case it seems like the script didn't get as far as making a backup, as the original file was already in place. Nothing to worry about there, anyway.
As I say, the recommended course of action at this point would be to try it again, but keep a copy of what the script says (the output might be quite long, but you can zoom right out by pressing Ctrl and - to make the text tiny, then select all of it to copy).
Make sure you do the rootfs removal command and then reboot first, too. The script should prompt you about that if necessary, anyway. It'll either be
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 2
or
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4
Now im getting a error when trying and i tried one of things you told someone else and it also gave a error
Deletehttp://pasted.co/f310846e
Is there anyway to communicate faster?
DeleteThere probably is, but not really at the moment.
DeleteFrom the log you posted, everything seems to be OK there until the last part, the SE Linux policy file patching. So that's something.
That last error you got with the last thing you tried probably doesn't mean anything in this case. It's probably just giving an error due to the way the script tries to bind mount a couple of the dirs in order to patch the file without rebooting, which is what the script warns about a few lines above that where it says
"Any Android apps currently running may stop working now and may not function correctly until this script has completed and the system has been rebooted."
So that shouldn't be anything to worry about.
If you reboot, though, then try the same command
printf "su -c supolicy" | android-sh
in a fresh root shell, what happens?
When i enter it it doesnt do anything just moves to a new line like i didnt enter anything
DeleteHow about just android-sh. If you do that, does it change to *something*_cheets?
Deleteyeah it does
DeleteIn the Android shell, does
Deletesu -h
return anything?
no it just starts a new line
DeleteDoes it say
Delete/system/bin/sh: su: not found
as well as starting a new line?
Also, can you do
exit
ls -al /opt/google/containers/android/system.raw.img
and paste in the whole line it returns, just to check if that symlink is present again