It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
I checked for sirkay 587c and 587d and for fly-kernel 0.8 as the latest of their breed, quite sure nobody has ever cared about this quirk.
The duplicate execution could be tracked back to the init.rc entries:
Code:
[COLOR=SeaGreen]#DooMLoRD: init.d scripts support
start sysinitsupport
class_start core
class_start main
#DooMLoRD: new init.d scripts support
service sysinitsupport /sbin/sysinitsupport.sh
class main
disabled
oneshot[/COLOR]
Which does:
Code:
#!/sbin/sh
# DooMLoRD: init.d support script (v1)
# [START] setting up
echo "[START] remounting system" > /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mount -o remount,rw /system >> /data/local/tmp/sysinitsupportlog.txt
# make init.d directory
echo "
[*] make init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mkdir -p /system/etc/init.d >> /data/local/tmp/sysinitsupportlog.txt
# correcting permissions of files in init.d directory
echo "
[*] correcting permissions of files in init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox chmod 777 /system/etc/init.d/*
# [COLOR=DarkOrchid]make [/COLOR]init.d directory
echo "
[*] [COLOR=DarkOrchid]make [/COLOR]init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /system/etc/init.d[/COLOR]
# [DONE] all done exiting
echo "[DONE] all done exiting" >> /data/local/tmp/sysinitsupportlog.txt
And later also in init.rc:
Code:
[COLOR=SeaGreen]#DooMLoRD: run my mods
service mymods /sbin/execute_mods.sh
class main
oneshot[/COLOR]
Which then does:
Code:
#!/sbin/sh
# starting
echo "[ START ]" > /data/local/tmp/log_doom-mods.log
echo "" >> /data/local/tmp/log_doom-mods.log
[COLOR=Red]# execute tweaks
/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
# execute FPS limit remove
/sbin/mount -t debugfs debugfs /sys/kernel/debug
/sbin/echo '0' > /sys/kernel/debug/msm_fb/0/vsync_enable
/sbin/umount /sys/kernel/debug
echo "FPS limit successfully removed " >> /data/local/tmp/log_doom-mods.log
# DONE
echo "" >> /data/local/tmp/log_doom-mods.log
echo "[ DONE ]" >> /data/local/tmp/log_doom-mods.log
You see that the execution of
Code:
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
is actually done twice - from sysinitsupport.sh first and then again from execute_mods.sh
Also mind that the log-entry in the first is leading in the wrong direction (copy error from above). It should better read "execute init.d directory"
The related logs are found in \data\local\tmp.
You can check yourself with this little script in \etc\init.d:
Code:
#!/system/bin/sh
echo [] > /data/local/tmp/$PPID-exec-done
echo $PPID "init.d executed" >> /data/local/tmp/$PPID-exec-done
date >> /data/local/tmp/$PPID-exec-done
Mind the $PPID which is the parent PID of the executing command (the busybox "run-parts"). Per boot you should just get 1 file <PPID>-exec-done containing the timestamp if you get 2 then you know why...
I have attached the script wrapped in a zip file. Unpack it, copy to \etc\init.d (or if not sym-linked to \system\etc\init.d) and change attributes to "777". Reboot and look what you get in \data\local\tmp.
Once you know, remove the script again and delete the created files in \data\local\tmp.
Mind that the scripts referenced from init.rc are copied over again from the kernel part so any change of the scripts in the \system\sbin folder is useless. The kernel has to fix that, no way out here.
I've been looking into this issue as well with the help of dk_zero_cool (mounts2sd amongst other things) as no matter what I tried I could not get m2sd to run in anything other than Safe Mode because init.d was being run as a service and not being executed in full before the init continued. So far I have edited init.rc to remove the second instance you quote above, and edited the first instance to:
Code:
exec /sbin/sysinitsupport.sh
so it executes rather than running a service. I then edited sysinitsupport.sh to contain just this:
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper busybox run-parts /system/etc/init.d
and also removed the line in execute_mods.sh that relates to init.d, so now theoretically the only thing that should happen in relation to init.d is that the exec command runs sysinitsupport.sh which in turn runs the init.d scripts before anything else in init.rc happens. IN THEORY!!! Because even with all of that done (and I have searched through the whole ramdisk, plus looked at the git for the init binary used in the Lupus ICS kernel I am using to make sure I haven't missed anything) the m2sd init.d script is still running in Safe Mode because it is detecting /system/bin/servicemanager running at the point it tries to execute. So something somewhere is still starting before the execution of init.d. I even tried with the init binary from the latest CM9 build for the Ray to rule out something wrong in there too.
I have sent all my files to dk_zero_cool to see if he can shed any further light on what else may be wrong. I have checked four different Ray kernels and they all use the same DoomLord methods so I doubt whether there are any Ray kernels that are running init.d correctly. It would be great to find a fix for this. Hope more people chip in!
Thanks for opening the discussion
As I understood, you have made some changes in the kernel assembly (not the code) to circumvent the effects you have outlined. I admit that I have not fully understood YOUR concern - but for my double execution of the "run-parts" the deactivation of the relevant line in either of the 2 scripts should do it, or not?
Is your concern related to the situation that init.d cannot do "everything" at the time it is executing and so it cannot achieve what some scripts intend to?
I am far too little educated in the details of kernel execution privileges so cannot further comment on that
Yeah, pretty much - to avoid possible issues with the m2sd script moving stuff around while something else is trying to make use of it the first thing it does is check if servicemanager is running, and if it is it disables the ability to move things like /data and dalvik-cache to sd-ext. The changes that we made in the scripts SHOULD have changed the init.d implementation from it running as a service whilst the rest of the init process carried on, to being executed as a command allowing any init.d scripts to be executed prior to any other service being started - as I understand it this is how init.d was intended to be used (ie the user scripts in /etc/init.d are run fully before anything else). However as I said, even with these changes and everything else relating to init.d having been removed something is still starting servicemanager, and until the source of that can be isolated scripts like m2sd cannot run fully/safely.
I guess the strategy to check on servicemanager is not right here. This is a process that starts several services and should not depend on anything in the init.d. So if you say that the boot sequence would have init.d completed BEFORE any service is started via servicemanager - THEN this could be a flaw in the kernel.
However is that really true? Is there no option to check if certain "dangerous" (for your move purposes) services are active already instead of checking on the servicemanager? I had found a nice overview on the Linux boot process here and I think that somewhere as part of the various init.x excuted scripts the servicemanager simply MUST be started - init.d is just a part of init - and for sure not the first part of it.
Off Topic:
I wonder where I can get some more insight in the Xperia Kernels and how they are assembled - especially which trace of that is noticeable in the filesystem. I noticed that the ICS Kernel have roughly 340MB for the user space while the JB Kernel has 360MB. Device should have 512 MB RAM, then some MB go away for radio and possibly video buffer, but his should be the same for all (accross ICS/JB). So what kind of memory tweaking makes this 20MB difference? I have not found a good place to discuss this - where could I go to?
tobbbie said:
It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
Click to expand...
Click to collapse
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
frogerra said:
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
Click to expand...
Click to collapse
Just try out (see the guide on 01test.zip) - nothing you can harm doing that.
kernel behaviour trick
I noticed some kernels (GB and ICS) do overwrite settings from /etc/init.d ....
So if you make an init.d script with specific cpu values, or VM settings...some kernel overwrite these with their compiled/preferred values "after" init.d scripts are executed. This way it looks as if your script is not completely accepted by the rom...but the truth is that the kernel applies its own preferred values afterwards.
Thats why my init.d script contains a wait of 60 seconds in the beginning of the scripts......how ? add:
sleep 60
So your script looks like this (example):
#!/system/bin/sh
# this init.d script is for when you apply doomlord kernel supplied with repack 2013
sleep 60
That will run your init.d goodies after one minute.
As you see I'm working on a revived repack4pda 2013 (GB) , which will be released soon in repack4pda thread.
Br.
Michel
I guess that these kernels may be doing the same what you are proposing - just sleep the shell process before action starts. So you need to lookup the call tree from the init process along the various init.*.rc scripts if this is the case. For duplicate execution of init.d content any timed scripts willl not help - the duplicate execution will just happen later as the same script will pause the same amount of time.
Not sure if the init process script execution is synchronous or not - so if you create scripts which sleep, the final signal for "boot completed" may just also delay and the whole boot process may take longer by that sleep time. As well would you just stack the delays after each other and so nothing is gained finally. Synchronous execution would make it impossible that a part of the init process could postpone beyond boot completed.
It may differ if you run the scripts via the "exec" command or let it execute via the servicemanager. I guess the latter may run them asynchronously - not sure here as well.
Hi,
I'm trying to run a custom init.d script on my HTC One (m7) which is running on Cyanogemod 12.1 (The problem existed already in 12.0). The problem is that none of the scripts are executed at boot time.
Looking at the "init.cm.rc" script i found the following snippets that look like the "sysinit" command should be triggered at boot time.
Code:
[...]
on post-fs-data
[...]
# Run sysinit
start sysinit
[...]
# sysinit (/system/etc/init.d)
service sysinit /system/bin/sysinit
user root
oneshot
disabled
I even tried removing the "disabled" parameter but the "sysinit" command is still not executed at boot time.
If I run the "sysinit" command on a root shell the scripts are executed as the should.
Anybody an idea what I'm missing?
Thanks in advance!
Hi.
I am also running CM12.1 on a w7dsn device, and init.d wasn't working. I was able to get it running by using the init.sh script as described here:
http://techtrickz.com/how-to/fix-xposed-framework-installation-issue-on-nexus-6/
I've just downloaded the script and run it from my sdcard, no other steps are necessary.
lfom said:
Hi.
I am also running CM12.1 on a w7dsn device, and init.d wasn't working. I was able to get it running by using the init.sh script as described here:
http://techtrickz.com/how-to/fix-xposed-framework-installation-issue-on-nexus-6/
I've just downloaded the script and run it from my sdcard, no other steps are necessary.
Click to expand...
Click to collapse
I am trying to get init.d working on d2vzw, and no luck. The script you linked to works by replacing /system/etc/install-recovery.sh, but my build has no such file. What a drag with CM...
galets said:
I am trying to get init.d working on d2vzw, and no luck. The script you linked to works by replacing /system/etc/install-recovery.sh, but my build has no such file. What a drag with CM...
Click to expand...
Click to collapse
Mine didn't have either, but after installing the script (and creating install-recovery.sh) then my scripts in init.d started to be run after every boot.
You must turn off selinux in order for init.d to work
Sent from my LG-LS980 using XDA Free mobile app
I'm using CyanogenMod 12.1 ROM on my phone, to enable the init.d you have to remove the /system/bin/sysinit then recreate the similar filename with the same content and permissions (755, root, shell).
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
run-parts /system/etc/init.d
Was it the init.rc from the boot.img initrd, or the one from the rootfs /boot.img?
Just change the permissions of all files in /etc/init.d folder to 755.
Also if you use the /data/local/userinit.sh change that to 755.
Leave the /system/bin/sysinit file as it is.
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
for i in /system/etc/init.d/*; do
if [ -x $i ]; then
/system/bin/log -t sysinit Running $i
$i
fi
done
Cheers
I've had the Samsung Chromebook Plus for about 2 weeks now, and I love it! Chrome OS is pretty good at handling itself for notetaking with the stylus, and the gorgeous screen is great for high res stuff (although Chrome OS is in desperate need of DPI scaling). It even runs Android apps out of the box! So far, I only have 2 major gripes about Chrome OS:
-It cannot do multitasking on anything (Android or Chrome app) when in tablet mode (buttons disappear, window drags are disabled) even on the beta branch
-Android cannot be rooted on the Chrome OS (so I think).
That second one is the one I'd like help with. Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Nilithium said:
Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Click to expand...
Click to collapse
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
On a general basis, running scripts from random strangers on the Internet is a bad thing. But I'll take it!
I've encountered an ID10T error though: I set the debugging password during setup, and I THOUGHT that was the sudo password to run your script. Problem is, that's not true, and I've no idea what it is.
Tried Google Account password, no dice.
Tried Chromebook PIN, no dice.
Tried Debug Pass set in Setup, no dice.
Tried password, no dice.
Tried null password (no input), no dice.
What is the sudo password? Did I miss something?
Nilithium said:
What is the sudo password? Did I miss something?
Click to expand...
Click to collapse
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Nolirum said:
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Click to expand...
Click to collapse
DELETE
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Anyone tried it on Pixelbook?
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
holy cow, script works flawlessly! (Samsung Chromebook Plus)
Anyone know why my Tivo app and Sirius XM don't work on my new Samsung Chromebook Plus V2? They install and than don't open and crash any other workable apks that anyone knows about? Sirius I can do online Tivo won't play all my recorded shows online just some and I really bought this Chromebook to use the Tivo app to watch shows when not at home or sitting outside. I know this thread is about rooting but I thought someone here may be able to help me. I also posted in the Tivo Community Forum also and am waiting for a response. Thanks!
MsWadera said:
Anyone tried it on Pixelbook?
Click to expand...
Click to collapse
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
phonefreedom said:
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
Click to expand...
Click to collapse
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
phonefreedom said:
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
Click to expand...
Click to collapse
When you say it was unusable, did Android (apps) appear to fail to load up completely, just the icon spinning? Or something else?
Did you happen to notice if any errors were shown on the script's output at all?
For example, there was this issue reported on github when the Pixelbook was first released, in which the Android rootfs container created by the script turned out to be a bit smaller than required, and so errors occurred when copying files to the new rooted /system. The user was able to successfully continue after manually editing the script so it created a container that was slightly bigger.
The script has been updated since then to reflect the increased space requirements, so that particular problem should no longer occur. Other potential sources of error might include if there could have been a problem downloading the required files (SuperSU, BusyBox), a problem patching SE Linux (in which case there is a separate script to do this part) , or maybe something else, possibly due to Chrome OS changes/updates.
In the case of the script rendering Android unusable, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Entering the above will restore the original read-only squashfs unrooted rootfs, which, after a reboot, should then load up as normal.
I think I'll edit my earlier post in this thread to add the command to restore from backup. Apologies for failing to mention it here initially. I might add an explicit message in the script itself regarding this, as well.
Flashing zips
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
do-tim said:
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
Click to expand...
Click to collapse
Depends what you want to flash, probably.
You might be able to rewrite the relevant edify commands in the update-binary that you want to flash into an equivalent shell script for the Chrome OS shell.
However, by default the Android rootfs container is in a read-only squashfs format, so normally cannot be modified directly. One way to modify it is to make a writable copy of the container in /usr/local, then replace the original file pathname with a symbolic link to the R/W copy. This works fine for the most part (but does takes up extra disk space, and needs to be re-done after an OS update).
For instance, here is part of the rooting script mentioned upthread, which makes a writable copy of the Android container, copies the files from the original container therein, renames the original to .bk, replaces the original file pathname with a symlink to the copy and, at the end, changes a couple of relevant envs in CrOS's /etc/init/arc-setup-env file.
Code:
#!/bin/sh
# Detect CPU architecture
case "$ARCH" in
x86 | i?86) ANDROID_ARCH="x86";;
x86_64 | amd64) ANDROID_ARCH="x86";;
armel) ANDROID_ARCH="armel";;
arm64 | aarch64) ANDROID_ARCH="armv7";;
arm*) ANDROID_ARCH="armv7";;
*) error 2 "Invalid architecture '$ARCH'.";;
esac
# Make some working dirs
mkdir -p /usr/local/Android_Images
mkdir -p /usr/local/Android_Images/Mounted
mkdir -p /usr/local/Android_Images/Original
# Create container image file. Intel devices need a slightly larger file.
if [ $ANDROID_ARCH=armv7 ]; then
cd /usr/local/Android_Images
fallocate -l 1.7G /usr/local/Android_Images/system.raw.expanded.img
else
if [ $ANDROID_ARCH=x86 ]; then
cd /usr/local/Android_Images
fallocate -l 2.2G /usr/local/Android_Images/system.raw.expanded.img
# Format the .img file.
mkfs ext4 -F /usr/local/Android_Images/system.raw.expanded.img 2>/dev/null
# Set SELinux to permissive.
setenforce 0
# Check that the stock Android container exists and is not already a symlink.
# If this is the case, mount it in order to copy files.
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
if [ -e /opt/google/containers/android/system.raw.img ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
# If the stock container's missing, check if there is a backup.
if [ -e /opt/google/containers/android/system.raw.img.bk ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img.bk /usr/local/Android_Images/Original 2>/dev/null
else
# If there's no backup in the expected location, check in ~/Downloads, too.
# NOTE: We can also use a container from a different device/other OS versions by putting it in ~/Downloads.
# To use a different container, we just need to rename any existing containers in /opt/google/containers/android/
# e.g. rename /opt/google/containers/android/system.raw.img.bk to /opt/google/containers/android/system.raw.img.bk.bk
# Containers from different devices/OS versions are unlikely to boot, however.
if [ -e /home/chronos/user/Downloads/system.raw.img ]; then
echo "Mounting /home/chronos/user/Downloads/system.raw.img and copying files"
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /home/chronos/user/Downloads/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
echo
echo "Error!"
echo "System.raw.img not found"
echo
exit 1
fi
fi
fi
fi
ANDROID_ROOTFS=/usr/local/Android_Images/Original
# Mount the new .img.
mount -o loop,rw,sync /usr/local/Android_Images/system.raw.expanded.img /usr/local/Android_Images/Mounted
# Copy the files.
cp -a -r $ANDROID_ROOTFS/. /usr/local/Android_Images/Mounted
# Rename the original container to .bk.
if [ -e /opt/google/containers/android/system.raw.img ]; then
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
echo "Moving original Android rootfs image to /opt/google/containers/android/system.raw.img.bk"
mv /opt/google/containers/android/system.raw.img /opt/google/containers/android/system.raw.img.bk
# Make the symlink from the original pathname to our writeable rootfs image.
echo "Replacing original Android rootfs image path with symlink to /usr/local/Android_Images/system.raw.expanded.img"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
else
if [ -e /usr/local/Android_Images/system.raw.expanded.img ]; then
echo "Creating symlink to /usr/local/Android_Images/system.raw.expanded.img at original Android rootfs image file path"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
fi
# Change the envs for writeable mount and debuggable in CrOS's /etc/init.
sed -i 's/export WRITABLE_MOUNT=0/export WRITABLE_MOUNT=1/g' /etc/init/arc-setup-env 2>/dev/null
sed -i 's/export ANDROID_DEBUGGABLE=0/export ANDROID_DEBUGGABLE=1/g' /etc/init/arc-setup-env 2>/dev/null
The rooting script is basically just the above, with the addition of a couple of other bits, including the relevant commands from the update-binary script in the SuperSU zip, slightly rearranged from Edify to regular shell script for the CrOS shell. That part of the script can be seen here.
So you could maybe do a similar script, with the files you want to flash. Also, once you have a R/W Android rootfs, it may be possible to update files from directly within Android, although, as mentioned in the last few posts in this thread, on some recent CrOS builds, some people have been running into an issue with the rootfs still getting mounted RO within Android, even with a writable container. This does not occur on all devices though, and should be just a temporary issue.
It would probably also be possible to set up a sort of overlay configuration, somewhat similar to Magisk in effect, but due to the somewhat convoluted mount configuration of the container based system, and the almost constant changes/updates (to the container, its config, and so on) that have been occurring with each update to Chrome OS, this would likely require quite a bit of work to implement and maintain.
Corrective measures to run the script...
Spoke too quickly - all installed but no root detected in SuperSU...
Yes, thanks, it seems to work.
I wonder why the script cannot handle downloading SuperSU & busybox on its own, some corrections are needed.
justqt said:
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Click to expand...
Click to collapse
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Davestar2000 said:
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Click to expand...
Click to collapse
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Click to expand...
Click to collapse
If it says no android system detected, I downloaded it in 2 parts from here: ( github(dot)com/nolirium/aroc ), followed the instructions, and then it worked for me.
Nolirum said:
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Click to expand...
Click to collapse
thanks for all the help. I have chromebook plus v1,I am on chrome osversion 74. I tried to follow the instruction
but my android apps did not start after restarting. I tried doing it manually but i got stuck at remounting file system as read only. Please help if possible. Thanks again.
Hi,
I'm having problems with this. I have an HP Chromebook with an Intel cpu, Chrome OS Version 75.0.3770.144 (Official Build) (64-bit). When I run the scripts this is the output:
Setting 'ANDROID_DEBUGGABLE: true' and 'WRITABLE_MOUNT: true' in /usr/share/arc-setup/config.json
The file at /opt/google/containers/android/system.raw.img is already a symlink!
Removing symlink
Using /opt/google/containers/android/system.raw.img.bk
Creating new Android system image at /usr/local/Android_Images/system.raw.expanded.img
1814633472 bytes (1.8 GB, 1.7 GiB) copied, 13 s, 140 MB/s
1800000+0 records in
1800000+0 records out
1843200000 bytes (1.8 GB, 1.7 GiB) copied, 25.2601 s, 73.0 MB/s
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Creating symlink to /usr/local/Android_Images/system.raw.expanded.img
SuperSU files not found in ~/Downloads! Attempting to download BusyBox and SuperSU now...
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5810 100 5810 0 0 5624 0 0:00:01 0:00:01 --:--:-- 9078
Unexpected file size. Trying again...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
50 6756k 50 3407k 0 0 305k 0 0:00:22 0:00:11 0:00:11 311k
Unzipping SuperSU zip, and copying required directories to ~/Downloads.
/usr/local/bin/busybox: 1: /usr/local/bin/busybox: Syntax error: word unexpected (expecting ")")
cp: cannot stat 'common': No such file or directory
cp: cannot stat 'armv7': No such file or directory
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6756k 100 6756k 0 0 328k 0 0:00:20 0:00:20 --:--:-- 351k
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
Copying sh from system/bin/sh to system/xbin/sugote-mksh and setting permissions and contexts
Adding extra files system/etc/.installed_su_daemon and system/etc/install-recovery.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
Symlinking system/bin/install-recovery.sh to system/etc/install-recovery.sh
Adding system/bin/daemonsu-service.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
Creating file init.super.rc in Android rootfs
Adding daemonsu service to init.super.rc
Adding 'import /init.super.rc' to existing init.rc
Substituting '|mount rootfs rootfs / remount bind rw' for '|mount rootfs rootfs / remount bind ro' in existing init.rc
A backup of init.rc will be stored as init.rc.old
sed: can't read /../init.rc: No such file or directory
Removing temporary files
Done!
Please check the output of this script for any errors.
Please reboot now, then run script 02SEPatch.sh.
[email protected] / $
Any help would be very much appreciated. I've done a good bit of searching and so far have been unable to figure what the problem is. Thanks alot, guys.
JR