Android on Chrome OS rooting shell scripts

Tested on Chrome OS v. 54-72


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.

PREREQUISITES:


A Chromebook with storage space for a ~2GB file in /usr/local/. Exact space usage varies depending on device, but will usually be at least 1.3 GB.

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 sh


Once 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:

curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/01Root.sh | sudo sh

The command to run script 2:

curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/02SEPatch.sh | sudo sh


DESCRIPTIONS:


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.

Tested with SuperSU 2.79 & 2.82



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.19 - Added support for /etc/init/arc-setup-env (present in latest Canary). Added info for patching SELinux policy with SuperSU 2.8x (--sdk=xx)

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). 

336 comments:

  1. 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

    ReplyDelete
  2. i 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??

    ReplyDelete
  3. So 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.

    I 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))

    ReplyDelete
    Replies
    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).

      In 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...

      Delete
    2. This comment has been removed by the author.

      Delete
  4. ok 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.

    ReplyDelete
  5. Sorry 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

    I guess the regular Android container still loads up OK at the moment? (Just run the uninstall script if it doesn't)...

    ReplyDelete
    Replies
    1. 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...

      Delete
    2. Thanks for sharing the images. Unfortunately this info doesn't really shed much light on the situation.

      If 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.

      Delete
  6. What is needed to be done to get this working on Intel Chromebooks?

    ReplyDelete
    Replies
    1. Added an Intel version, you are welcome to try it out and report back whether it works...

      Delete
  7. hey, 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...

    ReplyDelete
  8. A 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.
    If you try it, be sure to run the command to make the system writeable (and then reboot) beforehand.

    ReplyDelete
  9. 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. :)

    ReplyDelete
    Replies
    1. Interesting... 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..

      Delete
  10. the 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

    ReplyDelete
  11. Good 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.

    ReplyDelete
  12. PLEASE HELP. im using asus flip
    i've got stuck in this. don't know what to input.

    chmod +x *scriptname*

    ReplyDelete
    Replies
    1. 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:

      cd /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

      Delete
    2. thanks man. i really appreciate this.
      now im stuck in this step and don't know what to input again

      sh /home/chronos/user/Downloads/04SEPatch.sh

      Delete
    3. this is what happen

      crosh> 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:/ #

      Delete
  13. You should just need to:

    Copy 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

    ReplyDelete
  14. yes i already did that. but after i input command this is what happen. it say not found.. maybe i miss something?
    oh 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

    ReplyDelete
  15. 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.

    Just 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...

    ReplyDelete
    Replies
    1. 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.

      Delete
  16. hey 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!!!

    ReplyDelete
    Replies
    1. well 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

      Delete
    2. ok 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

      Delete
  17. disregard 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!

    ReplyDelete
  18. Chiming 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?

    ReplyDelete
    Replies
    1. Added support for 59. Hope to have a more elegant method presently.

      Delete
    2. Again, many thanks - do you have a donate link?

      Without asking for a deep dive into the technical specifics can you cover what changed in 59 that required a delineation?

      Delete
  19. 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??

    ReplyDelete
    Replies
    1. Hi, 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..

      When 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?

      Delete
  20. 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

    ReplyDelete
    Replies
    1. Which 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').

      Delete
    2. This comment has been removed by the author.

      Delete
  21. This comment has been removed by the author.

    ReplyDelete
  22. Thank you so much for posting these scripts. I had rooted my Asus C100 with it.

    Unfortunately 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!

    ReplyDelete
  23. 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.

    Could 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

    ReplyDelete
    Replies
    1. Ahh, thank you! I restored as you said and used v018 of your script to root again. Phew, have my Chromebook back!

      I 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.~~

      Delete
    2. 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!

      Delete
  24. Will this work for ARMv8 chromebooks, like the Samsung Chromebook Plus?

    ReplyDelete
  25. Yes, 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).

    In 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).

    ReplyDelete
  26. Hey the chrome os version just got updated could you please fix ASAP?! Thank you!! ;)

    ReplyDelete
    Replies
    1. BTW ur the best forgot to say that

      Delete
    2. Working on it. Thanks for the heads-up!

      Delete
    3. hey how long does it usually take you to make a script like this? and is it hard to do? :)

      Delete
    4. To 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.

      It 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...

      Delete
    5. 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

      Delete
    6. in dev mode of course (forgot to add that)

      Delete
    7. btw funniest thing ever to do someones working on a cb push esc+rel+pow aka dev mode they will be like wtf???

      Delete
  27. Hi, just tried your script, and Im getting a "No space left on device" error https://pastebin.com/npW09HL3 . Thanks for help

    ReplyDelete
    Replies
    1. Which device/Chrome OS version? A lot of devices were updated to Nougat lately and I might need to fix the scripts somewhat.

      Could 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/

      Delete
    2. The output is:
      "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

      Delete
    3. before i updated it always worked for me on dev

      Delete
    4. 1.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.

      Sorry, 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...

      Delete
    5. or you can just get us in a hangouts call with screen share!

      Delete
    6. btw i have an intel chromebook

      Delete
    7. for some reason my name on my google account datsaxophonist@gmail.com got changed to Dat Saxophonist... lol

      Delete
    8. also in dev it got updated to 61 not 60

      Delete
    9. Im on Android N, and no, I didnt try the mv thing

      Delete
    10. I'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..

      Yeah, 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..

      Delete
    11. Did any error messages show up on the script?

      Delete
    12. Is this on your Intel Chromebook, or an Arm one?

      Was 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.

      Delete
    13. no superSU said root undetected

      Delete
    14. Can you try this: In a root shell, type android-sh.

      Delete
    15. ...The prompt should change to (something)_cheets

      Delete
    16. Then type/paste:

      ps | grep daemon

      Delete
    17. it puts a 1| before samus_cheets

      Delete
    18. OK, now try:

      daemonsu --auto-daemon

      Delete
    19. What shows up after that?

      Delete
    20. 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...

      Delete
    21. Can you try this: Back in the Chrome OS root shell, enter (all one line:

      vi /opt/google/containers/android/rootfs/root/init.rc

      Delete
    22. Highlight the first 15 lines or so, which will copy them, then paste them in here

      Delete
    23. # Copyright (C) 2012 The Android Open Source Project
      #
      # 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

      Delete
    24. 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?

      vi /opt/google/containers/android/rootfs/root/init.super.rc

      Delete
    25. (It should be just a few lines)

      Delete
    26. The deamonsu --auto-daemon thing worked !

      Delete
    27. And the output of /opt/blahblahblah/init.super.ir

      service daemonsu /system/bin/daemonsu-service.sh service
      class late_start
      user root
      seclabel u:r:init:s0
      oneshot

      Delete
    28. This comment has been removed by the author.

      Delete
    29. So 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...

      Delete
    30. In 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):

      sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config

      Delete
    31. HERE IS THE PROPER FIX:

      Enter 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



      Delete
    32. How should I proceed when updating from v20 -> v21? Just rerun it ?

      Delete
    33. No 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.

      (The formatting looks strange in this comment field but if you paste the command into the shell it'll be normal)

      Delete
    34. (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...

      Delete
    35. Just got an idea: Wouldnt rebooting just the Android subsystem be enough ? Without the need to reboot the whole machine ? (Writing "reboot" in android-sh)

      Delete
    36. Good 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.

      Delete
    37. You mean including the ./make_dev_ssd --remove_rootfs_verification --partition 4 reboot ?

      Delete
    38. I 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

      Delete
    39. Oh, 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?

      If 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.

      Delete
    40. 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 :).

      Delete
    41. K, made a repo on Github, anything I could improve ?
      https://github.com/LufyCZ/ChOS-SetupScript

      Thanks

      Delete
    42. Cool, nice work.

      One 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...

      Delete
    43. 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

      Delete
  28. YEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESSSSSSSSSSSSSSSSSSSSSSSS UUUUUUUUUUU DDDDDDDDDDDDDEEEEEEEEEEEEEEEEEDDDDDDDDDDDDDDDD IIIIIIIIIIITTTTTTTTTTTTTTT!!!! :)

    ReplyDelete
  29. This comment has been removed by the author.

    ReplyDelete
  30. This comment has been removed by the author.

    ReplyDelete
  31. Just 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.

    ReplyDelete
    Replies
    1. You 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.

      After 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.

      Delete
  32. Hello dear OP, I'm in need of help.
    This 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...

    ReplyDelete
    Replies
    1. 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

      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.

      Delete
    2. Thank you in advance, JAke.

      Delete
    3. Maybe just check if libsupol.so is there, first of all, I guess?

      In 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

      Delete
    4. 1|caroline_cheets:/ # ls -alZ /opt/google/containers/android/rootfs/root/system/lib/libsupol.so
      ls: /opt/google/containers/android/rootfs/root/system/lib/libsupol.so: No such file or directory

      Delete
    5. Sorry, I wasn't clear. You need to do it in a root shell in Chrome OS...

      Delete
    6. Sorry for my incompetence!

      chronos@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

      Delete
    7. Some sort of permission error :/

      Delete
    8. No problem. But that's a regular shell in Chrome OS. You also need to enter
      sudo su

      to get into a root shell, then paste the command.

      Delete
    9. Aha! A result.

      localhost / # 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

      Delete
    10. 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.

      Delete
    11. Well, it tells us that the file the script was complaining about does in fact exist, and has the right permissions and contexts..

      Maybe 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?

      Delete
    12. That means it's working...

      You did reboot after running the first script, right?

      Delete
    13. I rebooted after each step, as said :)

      Delete
    14. Hmm, so everything copied across OK, most probably.
      Does

      ps | grep daemon

      in the caroline_cheets shell bring up three lines or so?

      Delete
    15. caroline_cheets:/ # ps | grep daemon
      root 1609 0 84768 7108 __skb_wait 401b83a3 S daemonsu:mount:master
      root 1612 0 84768 6812 __skb_wait 401b83a3 S daemonsu:master



      Yes ?

      Delete
    16. So at this point root should be working, but without patching the SE Linux policy, daemonsu won't start automatically at boot.

      Some 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

      Delete
    17. Test Rooting scripts for Android on Chrome OS

      Version 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:/ #

      Delete
  33. http://imgur.com/a/r15OB

    If this helps.

    ReplyDelete
  34. I got an error this time, hopefully this may show us the error?

    ReplyDelete
  35. I 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:

    export LD_LIBRARY_PATH=/system/lib/

    ...then copy paste the two lines, and see if you still get the error.

    ReplyDelete
    Replies
    1. Used the command you said, friend.
      Unfortunate 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:/ #

      Delete
    2. 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.

      Which 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.

      Delete
    3. Thanks for reply to start with! it is a Samsung Chromebook Pro, Dev Channel, 60.0.3112.52
      "Firmware" : Google_Caroline.7820.300.0
      Channel

      "Platform" : 9592.42.0 (Official Build) beta-channel caroline
      Firmware


      Thanks :D

      Delete
    4. 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).

      If 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.

      Delete
    5. It worked :D Thank you so much! I've now been rooted :DD Much love!

      Delete
    6. Glad 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).

      I'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.

      Delete
    7. So, I messed things up while trying to remove ads with Lucky Patcher, and it broke my apps/playstore.

      So, 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.

      Delete
    8. Kinda got passed it, then it doesn't launch anything xDD, It has like a circle buffer thing?

      Delete
    9. Check 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.

      Then 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.)

      Delete
  36. Does this support Chrome OS 61, and does it still work after chrome os updates or would I need to do this process again?

    ReplyDelete
  37. Yes, it should work fine on v61, at least up to R61-9765.31.0 (current Dev version on my device).

    There 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.

    ReplyDelete
  38. 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.

    Regarding:

    "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.

    ReplyDelete
  39. it just sits there, saying "copying android system files". ???

    ReplyDelete
    Replies
    1. That 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?

      Delete
  40. I 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.

    ReplyDelete
    Replies
    1. Oh, 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?

      I'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

      Delete
  41. 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.


    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.

    ReplyDelete
  42. 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.


    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.

    ReplyDelete
    Replies
    1. 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).

      If 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.

      Delete
    2. I have recovered my system Chrome OS version 61.0.3163.120 (64 bit).

      This 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.

      Delete
    3. 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).

      If 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

      Delete
    4. 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.

      This time I have first unzipped and then ran the latest script.

      Here is the result.

      http://pasted.co/b1204304

      Delete
    5. 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.

      From 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.

      Delete
    6. Platform 9765.81.0

      Should 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

      Delete
    7. 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.

      Delete
    8. http://pasted.co/9adbe281

      Something new.

      Delete
    9. 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.

      Reason 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.

      Delete
    10. 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.

      However, 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.

      Delete
  43. The first script I guess worked successfully,however there is an issue with the second one.

    http://pasted.co/d661eaaa

    ReplyDelete
    Replies
    1. Just seen this comment, Blogger marked it as spam for some reason.

      Just 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?

      Delete
  44. Yes,it shows an arrow.
    However I could not understand what to do with Android shell.

    http://pasted.co/a792fcb1

    ReplyDelete
    Replies
    1. Apologies for the delayed response.

      The 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.

      Delete
  45. my chromebook language is Chinese, when I implement the root script and reboot, the playstore fonts garbled. how to fix it?

    ReplyDelete
    Replies
    1. I have the same problem. After the rooting, all android apps with Chinese characters are no longer visiable.

      Delete
    2. Hello,

      Thanks 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.

      Delete
    3. Thanks for your reply, I am looking forward to a new solution.

      Delete
    4. Hello,

      Sorry 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.

      Delete
  46. I've got a slight problem running the scripts.

    Chrome 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 ?

    ReplyDelete
    Replies
    1. 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)...

      If you go to Settings > About Chrome OS > Detailed build information, does it show an ARC version number listed there?

      Delete
  47. Need help please. Have HP Chromebook Intel script isn't working.

    ReplyDelete
    Replies
    1. When you ran the script, did any error messages show up at all?

      Delete
  48. I ran the combined script and it seemed to have worked fine however it says im not rooted

    ReplyDelete
    Replies
    1. I have tried running the daemon auto daemon and it returns daemonsu not found

      Delete
    2. Which 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..

      Delete
    3. It's a Chromebook Plus running version 63

      Delete
    4. It's a Chrombook Plus running OS 63

      Delete
    5. OK, 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.

      Delete
    6. Yeah, it's still working for me (v64). Some things you could do in the CrOS shell to try and check what's going on:

      Firstly, 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.

      Delete
    7. http://pasted.co/0ab90d21
      This is what im getting and I think is is error free

      Delete
    8. http://pasted.co/dab16d69
      This is the result of the ls -al /opt/google/containers/android/

      Delete
    9. http://pasted.co/3487424a
      This is the SuperSu one

      Delete
    10. Tried resetting the androd but it says no such file or directory when I use the script at the top

      Delete
    11. OK, yeah, in /opt/google/containers/android/ this file

      434548736 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.

      Delete
    12. 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?

      Delete
    13. Neither 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).

      Re: 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

      Delete
    14. Now im getting a error when trying and i tried one of things you told someone else and it also gave a error

      http://pasted.co/f310846e

      Delete
    15. Is there anyway to communicate faster?

      Delete
    16. There probably is, but not really at the moment.

      From 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?

      Delete
    17. When i enter it it doesnt do anything just moves to a new line like i didnt enter anything

      Delete
    18. How about just android-sh. If you do that, does it change to *something*_cheets?

      Delete
    19. In the Android shell, does

      su -h

      return anything?

      Delete
    20. no it just starts a new line

      Delete
    21. Does it say

      /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

      Delete