Hello,
While i am not new to this forum, due to some reasons I had to create a new user for myself. I am currently using Samsung Galaxy Tab Plus P6200.
From the very beginning, I am frustrated at how android decides to kill my apps on my own. I majorly use web browser with 6-7 tabs open and as soon as I switch applications, the browser gets killed and all tabs are lost.
Thus i wanted to take the matter in my own hands as there is no stable CM for this tablet.
While going through init.rc, I found a block of property setter, which i think are used to kill apps. This is:
Code:
# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.PERCEPTIBLE_APP_ADJ 2
setprop ro.HEAVY_WEIGHT_APP_ADJ 3
setprop ro.SECONDARY_SERVER_ADJ 4
setprop ro.BACKUP_APP_ADJ 5
setprop ro.HOME_APP_ADJ 6
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
# These are currently tuned for tablets with approx 1GB RAM.
setprop ro.FOREGROUND_APP_MEM 8192
setprop ro.VISIBLE_APP_MEM 10240
setprop ro.PERCEPTIBLE_APP_MEM 12288
setprop ro.HEAVY_WEIGHT_APP_MEM 12288
setprop ro.SECONDARY_SERVER_MEM 14336
setprop ro.BACKUP_APP_MEM 14336
setprop ro.HOME_APP_MEM 14336
setprop ro.HIDDEN_APP_MEM 16384
setprop ro.EMPTY_APP_MEM 20480
# Old values for phones. Should probably be adjusted up for the next
# phone version.
#setprop ro.FOREGROUND_APP_MEM 2048
#setprop ro.VISIBLE_APP_MEM 3072
#setprop ro.PERCEPTIBLE_APP_MEM 4096
#setprop ro.HEAVY_WEIGHT_APP_MEM 4096
#setprop ro.SECONDARY_SERVER_MEM 6144
#setprop ro.BACKUP_APP_MEM 6144
#setprop ro.HOME_APP_MEM 6144
#setprop ro.HIDDEN_APP_MEM 7168
#setprop ro.EMPTY_APP_MEM 8192
# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have combined some of
# the classes into the same memory level; the associated processes of higher
# classes will still be killed first.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 8192,10240,12288,14336,16384,20480
So i went forward and changed these to suit myself, for once rebooted, my changes were lost! Searching more, I found that the flash in device is partitioned with hidden partitions as boot and recovery where the master files are placed ( init.rc), which on reboot are copied to device. So now I want to change the content of boot partition.
The device does not have /proc/mtd but mmcdevice is split in many parts. I am unable to recognize which one is boot partition.
So my question is can I use the official image of Samsung (gz file), unzip it, extract the boot partition, edit its content , repack it and flash it via odin?
Also if any simple workaround to stop android killing my apps is known, please do let me know.
init.rc
You need to do a couple things before editing init.rc
1) Unpack your boot.img
2)Find init.rc in ramdisk folder
3) Aha now edit init.rc
4) repack boot.img
5) make a lil flashable zip to load up new boot.img
My guess is you are trying to edit init.rc in /system; problem is ramdisk will overwrite that 'copy' and so your changes are not persistent. Try editing on ramdisk and watch the magic unfold
As for a memory management, after you tweak init.rc, you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon
Rob
I'm no expert, but..
Probably safer than editing your ramdisk is using init.d, sysinit or install_recovery.sh
/system/bin/sysinit & /system/etc/install_recovery.sh are normal shell scripts that run at boot
experiment to see which you prefer & if either get overwritten or removed
In the one that you choose, if you have busybox, insert
Code:
run_parts /system/etc/init.d
otherwise you're going to have to do something much more elaborate like (correct my syntax)
Code:
for F in (/system/etc/init.d/*)
do
if test -x $F
then
source $F > /dev/null 2>&1 &
fi
done
In /system/etc/init.d/ place something like 99my_memory_hack.sh containing your fixes
'setprop' works as you've listed above, but the 'write' command is specific to init.rc
for the single parameter commands use
Code:
echo [parameter] > /proc/[wherever]
for the multi parameter commands I'm not sure, it might work as above or you might need a 'for' loop & post them sequentially (correct my syntax)
Code:
for I in (parameters)
do
echo $I >> /proc/[wherever]
done
---------- Post added at 11:32 AM ---------- Previous post was at 11:14 AM ----------
For every 'setprop' you intend to use, use 'getprop' to find the current value - it might not be what's set in init.rc!
Also look in /system/build.prop & look on the market for 'build.prop editor'
Xposed appsettings and resident ur app. It's the easiest and fastest way.
Gesendet von meinem Xperia SP
After tweaking init.rc
As for a memory management, after you tweak init.rc, you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon
Rob[/QUOTE]
Hi Rob, I found this very helpfull and edited the init.rc file in the boot.img. It worked magically - but just for a few days.
Looking into process statistic I found that there was barely free RAM - even after rebooting. Is it that what you ment with: "you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon "
I have to admit, I don´t no what I would have to do with the init.d scripts, beside of the fact, that I did not found a file with that name in the firmware. Any help or advice would be very much appreciated.
Thanks
Michael
micbin said:
I have to admit, I don´t no what I would have to do with the init.d scripts, beside of the fact, that I did not found a file with that name in the firmware. Any help or advice would be very much appreciated.
Thanks
Michael
Click to expand...
Click to collapse
Init.d is a set of scripts that is executed during the initialisation phase of the phone. So, instead of increasing the size of the tiny boot image by adding a few more lines into init.rc, you can create a script and add it to the init.d folder.
As far as I know, init.d runs after init.rc has completed execution, but still much before Android boots, so you can use it to apply your memory management mods.
From your message above, I feel you haven't understood some things properly. Init.d is not a file but a folder which can contain many number of scripts which are executed one by one in alphabetical order at boot time. It is usually located at /system/etc/init.d or /etc/init.d.
In most of the phones this folder is absent by default because the stock kernel doesn't support init.d.
Refer to this to get init.d support on your phone without having to switch to a new kernel.
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
Disclosure: I'm intentionally editing build.prop to feel out the limits one can tweak it, I'm fully aware I can completely brick these devices doing this.
With that said, ive encountered an issue that replicates on different devices and have no clue as to how or why.
Target Devices:
Samsung S21 (USA-TMB)
Samsung S22 (USA-XAA)
LG V20 (USA-XAA)
LG Velvet (USA-TMB (MTK))
Google Pixel6 Pro
All devices above have been rooted and i have patched bootloader and VBmeta &/or Preloader.
On ALL of the above devices, when i edit the build prop, it simply edits into a blank build.prop. This was replicated using Root Explorer Pro, Rom ToolBox Pro & SmartPack Kernel Manager (F-Droid)
I also tried making a backup before edit, then restore. The system still Bricks upon reboot.
Even if i don't edit the build prop directly, but rather replace it, even with an identical one. The system refuses to read it next boot.
On Most of the listed devices - System is A/B - Also worth noting is the build.prop in /system references importing the build.prop and default.props from /Vendor and /Product. Could that have anything to do with it?
Trouble-Shooting steps taken:
Ensured /System is mounted
Tried Different methods for editing build.prop "on-device"
pull to pc, edit, push back.
Google - XDA Search (duh)
is this DM-Verity? TF am I missing?
So if I understand correctly:
You mount -o rw,remount /system
You adb pull some-text-file
You edit some-text-file
You adb push some-text-file
Did you subsequently adb pull some-text-file to make sure that it was actually changed?
This isn't a super (dynamic partition) with /system /vendor /product all together, is it?
Do:
Code:
dd if=/dev/block/by-name/system of=/sdcard/check skip=big-number
Big number = count of sectors in system partition - 8 // for eMMC
Big number = count of sectors in system partition - 1 // for UFS
You should end up with a file exactly 4096 bytes. If you don't play with the numbers.
Hexedit that file, does it start with fe cf ec fe? Then it has FEC.
Renate said:
So if I understand correctly:
You mount -o rw,remount /system
You adb pull some-text-file
You edit some-text-file
You adb push some-text-file
Did you subsequently adb pull some-text-file to make sure that it was actually changed?
This isn't a super (dynamic partition) with /system /vendor /product all together, is it?
Do:
Code:
dd if=/dev/block/by-name/system of=/sdcard/check skip=big-number
Big number = count of sectors in system partition - 8 // for eMMC
Big number = count of sectors in system partition - 1 // for UFS
You should end up with a file exactly 4096 bytes. If you don't play with the numbers.
Hexedit that file, does it start with fe cf ec fe? Then it has FEC.
Click to expand...
Click to collapse
Super - yes. is this same as system as root? (Sorry if it's an obvious question, I'm learning)
Yes , correct, i ever tried changing Owner and permissions (chmod 777)
Thats the weird part, when i did pull the file from the device it actually came out the other end on my pc intact with all the props - i then proceeded back to device and checked the file in /system and it was blank, as well as the build.bak.
At first thought it was the file explorer (Root Explorer Pro) but when tried manually, same result.
Don't know if its relevant or not to the issue, but i WAS able to use setprop on some props, but only select ones, and I'm not able to figure out the bias as to which one I can or can't.
Persisitent props are stored in /data, so those would work.
Do the dd and tell me if you have FEC. This is for me, your numbers will be different.
Code:
Poke3:/ # dd if=/dev/block/by-name/system of=/sdcard/check skip=6291448
8+0 records in
8+0 records out
4096 bytes (4.0 K) copied, 0.000839 s, 4.6 M/s
Numbers too high will say "Can't skip". Numbers too low will give you a file that's too big.
Do:
Code:
dd if=/dev/block/by-name/system of=/sdcard/check skip=big-number
Big number = count of sectors in system partition - 8 // for eMMC
Big number = count of sectors in system partition - 1 // for UFS
You should end up with a file exactly 4096 bytes. If you don't play with the numbers.
Hexedit that file, does it start with fe cf ec fe? Then it has FEC.
Click to expand...
Click to collapse
Came back weird, does this need to be run as root?
Code:
$ dd if=/dev/block/by-name/system of=/sdcard/check skip=big-number
dd: not integer: big-number
K0mraid3 said:
Came back weird, does this need to be run as root?
Code:
$ dd if=/dev/block/by-name/system of=/sdcard/check skip=big-number
dd: not integer: big-number
Click to expand...
Click to collapse
dumb question lol disregard. same result.
ill go check in /data now
/data is fine. Just check system partition. Using real numbers. Actually integers.
Bump...
I can't edit build prop ,i have rooted my device android 10 , i try to edit my build prop and it doesn't save any change , tried to change premission to rw using root explorer and terminal doesn't change
I tried build prop apk ,it says can't saving !!
What is the problem and how can i slove it!?
build.prop is in /system which is always read-only, probably protected by vbmeta, maybe FEC, possibly packed in super.
So, the question is, what do you actually want to do?
Do you want to change the file just for the fun of it or change a property for some reason?
How did you root your device? With Magisk or without?
Renate said:
build.prop is in /system which is always read-only, probably protected by vbmeta, maybe FEC, possibly packed in super.
So, the question is, what do you actually want to do?
Do you want to change the file just for the fun of it or change a property for some reason?
How did you root your device? With Magisk or without?
Click to expand...
Click to collapse
I want to add line(persist.sys.clipboard.max_items=10)
I have rooted it by Magisk
You can just setprop persist.sys.clipboard.max_items 10
Can't you? One time should do it?
Renate said:
Renate said:
You can just setprop persist.sys.clipboard.max_items 10
Can't you? One time should do it?
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Thank you for your replay
Itjust to increasing the capacity of clipboard of gboard
No i can't add any thing to build prop
It does not save changes
Or doesn't accept to change the permission to read-write
Or even in. Build prop editor it shows error saving build prop
I don't know how to edit or what should i do or where is the problem
Code:
C:\>adb shell
$ su
# setprop persist.sys.clipboard.max_items 10
# getprop persist.sys.clipboard.max_items
10
Renate said:
Code:
C:\>adb shell
$ su
# setprop persist.sys.clipboard.max_items 10
# getprop persist.sys.clipboard.max_items
10
Click to expand...
Click to collapse
Thank you very much I will try it
But there is any way to edit it on my android
Or What is the problem that prevents me from modifying it
rab33h said:
Or what is the problem that prevents me from modifying it?
Click to expand...
Click to collapse
I wouldn't know. You don't actually say anything about what it prints out.
build.prop is a file. You shouldn't care what's in there.
In any case, you haven't demonstrated that persist.sys.clipboard.max_items is actually in there.
Renate said:
I wouldn't know. You don't actually say anything about what it prints out.
build.prop is a file. You shouldn't care what's in there.
In any case, you haven't demonstrated that persist.sys.clipboard.max_items is actually in there.
Click to expand...
Click to collapse
Thank you and orry for the inconvenience
That's what show for me when I try to change the permission using root explorer :
Warning Permissions change was not successful . Please note that some file systems ( e.g. SD card ) do not allow permission changes .
When i try to add code and exit with save then reopen it doesn't change in build prop
And when i edit the file using buildprop editor :
Error Saving build prop
This is in terminal:
:/ $ su
:/ # mount -o rw,remount /system
mount: '/system' not in /proc/mounts
1|:/ #
I don't believe that I advised you to do anything with mounts.
Why don't you just try what I actually did advise?
@rab33h Magisk is a systemless root method. Renate has explained the reason(s) in post #2 already. any questions left?
Renate said:
alecxs said:
@rab33h Magisk is a systemless root method. Renate has explained the reason(s) in post #2 already. any questions left?
Click to expand...
Click to collapse
Click to expand...
Click to collapse
No thank you
for systemless method to change build.prop entries you may interested in Magisk resetprop or more advanced MagiskHidePropsConf module.
the easiest way is to create a startup script yourself and place it in service.d
/data/adb/service.d/script.sh
Code:
#!/system/bin/sh
resetprop ro.build.product dandelion
you can also control the behavior with -n and -p flags (refer to documentation)
alecxs said:
for systemless method to change build.prop entries you may interested in Magisk resetprop or more advanced MagiskHidePropsConf module.
the easiest way is to create a startup script yourself and place it in service.d
/data/adb/service.d/script.sh
Code:
#!/system/bin/sh
resetprop ro.build.product dandelion
you can also control the behavior with -n and -p flags (refer to documentation)
Click to expand...
Click to collapse
Thank you very much
But sorry for this stupid question
In this situation of magisk
Can i change the permission by terminal or termux?
Using this command
mount -o rw,remount /system
first you need to understand /system is a directory inside system partition. the partition is mounted read-only, that has nothing to do with permissions. if you want to remount the partition read-write do it with it's proper mount point / (rootdir) and not with containing directory.
second, android doesn't allow modifications of system files, avb/dm-verity prevents that. you need to disable it in vbmeta partition first.
and third, the file system itself has deduplicated blocks + ro flag to prevent any rw mount attempts. if it is ext4 file system, you can unshare blocks (will expand memory) and remove the ro flag. for other file systems (erofs/f2fs) it needs recreation of the whole partition as ext4.
the usual method for modifying dynamic partitions is offline, means you create your own super.img with lpmake and flash it into device. there exist various helper scripts here to automate this.
it's absolutely possible to do this so you can remount rw afterwards.
but it will break OTA and is not worth the hassle. Magisk is a systemless root solution, system partition is not modified and remain completely stock.
if you want to add/delete/replace files in /system go with the time and use the proper Magisk systemless solution.
https://forum.xda-developers.com/t/4537601
alecxs said:
first you need to understand /system is a directory inside system partition. the partition is mounted read-only, that has nothing to do with permissions. if you want to remount the partition read-write do it with it's proper mount point / (rootdir) and not with containing directory.
second, android doesn't allow modifications of system files, avb/dm-verity prevents that. you need to disable it in vbmeta partition first.
and third, the file system itself has deduplicated blocks + ro flag to prevent any rw mount attempts. if it is ext4 file system, you can unshare blocks (will expand memory) and remove the ro flag. for other file systems (erofs/f2fs) it needs recreation of the whole partition as ext4.
the usual method for modifying dynamic partitions is offline, means you create your own super.img with lpmake and flash it into device. there exist various helper scripts here to automate this.
it's absolutely possible to do this so you can remount rw afterwards.
but it will break OTA and is not worth the hassle. Magisk is a systemless root solution, system partition is not modified and remain completely stock.
if you want to add/delete/replace files in /system go with the time and use the proper Magisk systemless solution.
https://forum.xda-developers.com/t/4537601
Click to expand...
Click to collapse
Thank you very much