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
Related
With VEGAn 5.11 and Pershoot kernel. I want to do a few things when it boots up. I don't see the usual /etc/init.d kind of structure.
I did find init.rc and even found a link that describes its peculiar syntax. But editing that file (after remounting) doesn't "take" -- I assume it is on initfs and gets copied to a RAM disk on boot.
Is there anywhere easily user writeable where you can stick something in the boot sequence? Seems like that would be a common enough thing to need to do.
Thanks!
The init.rc is in the ramdisk, and the ramdisk is in the boot.img (found in all the stock and modded ROMs).
Here's a good guide on how unpack / repack that file: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
(obviously it's a bit technical) What I can tell you is that you don't need any cmdline options for the boot.img
Here's a real quick breakdown of what I do (Ubuntu user):
Code:
./unpack-bootimg.pl boot.img
go to the extracted ramdisk folder, make my changes and then:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
cd ..
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
"newboot.img" being my new boot.img. That's how the boot.img in all my mods are created.
Thank you and yeah I figured that was it. Technical is not an issue as I sling unix/linux for ages. Salute to you for all your work on this platform.
Well I cheated a little. Here's what I did:
I noticed that you had added to the bottom of /init.rc a one shot service for /system/etc/shuttle_ins.sh.
So I just remounted rw for /system and added the following to the TOP of /system/etc/shuttle_ins.sh:
# added by aaw
if [ -f /system/etc/rc.local ]; then
sh /system/etc/rc.local &
fi
# end aaw
So now I can put what I want in rc.local -- start up sshd or whatever. In this case here's what I actually wanted:
#!/bin/sh
# this is run at the end of the init.rc sequence if it exists
until mount | grep -m1 sdcard2 ; do sleep 5 ; done # wait for sdcard2 mount
mkdir /mnt/sdcard/sdcard2 # make mount point (might fail, but who cares?)
mount -o bind /mnt/sdcard2 /mnt/sdcard/sdcard2
Of course, this assumes I will always have sdcard2 or it spins. Could put a timeout in I guess, but for me this is always the case. Now things like players that only look in /sdcard can find stuff on sdcard2 as well.
A bit of a hack. I wonder if the release DEVs would consider adding an rc.local in user land in a nicer way? Maybe have a system rc.0 that does the -f test for rc.local and that way if you wanted to add an rc.local you could but if you didn't no harm or foul.
Or did I miss a smarter way to do this?
Thanks for the help (and the great releases, of course!).
I found this in the market: https://market.android.com/details?id=os.tools.scriptmanager
Lets you run scripts at boot time. Haven't tried it for that though, but it could work instead of my rc.local fix. A little different since I assume it runs late (after Android is up) unlike the rc.local which runs before Android, unless I'm mistaken.
Hello Gentlemen. Sorry to disturb you with a noob question but I cannot solve it for the life of me and I have tried everything I could find on the forums. I have an Aluratek Cinepad AT107F. I have successfully rooted it. I have full super user permissions and I have no problems deleting any files or folders EXCEPT one directory. Let me explain the situation.
I recently did a firmware update and it included brand new APKs for Youtube, also added Google Play Support, and added Angry Birds.
I am unable to update Youtube to the latest version. It gives a "Package file was not signed correctly. Uninstall the previous copy of the app and try again.".
So I attempted to do just what it had asked. I rooted just to do this. I tried removing it with Titanium Backup, I tried Root Uninstaller, I tried Root Explorer, I tried deleting using the "adb shell rm" command. I still get a "Read-only file system".
Even though I have root and granted root access to Root Explorer, I am unable to change the permissions for this /oem/apps/ directory. It's on the top level of the internal memory. I have no external SD card.
I've spent 10+ hours trying to figure this out and I'm sure someone knows something that I don't and can fix this super easy. I'm asking for your help, you're my only hope!
Your issue is that the update gave you modded files that the OEM doesn't want deleted. Most likely do to them not have permission from Google to do so. You will be hard pressed to find help here as we mainly deal with official releases and apks.
Wayne Tech S-III
zelendel said:
Your issue is that the update gave you modded files that the OEM doesn't want deleted. Most likely do to them not have permission from Google to do so. You will be hard pressed to find help here as we mainly deal with official releases and apks.
Wayne Tech S-III
Click to expand...
Click to collapse
Am I in the wrong sub forum? Is there another forum at XDA-Developers that could help?
Vindicoth said:
Am I in the wrong sub forum? Is there another forum at XDA-Developers that could help?
Click to expand...
Click to collapse
No nowhere on the site really deals with unofficial android versions and knock of devices. Your best bet will be the OEM
Read the error message again. The file is on a read-only filesystem. That is why you cannot delete it. In other words, you lack permission to write to the partition.
System partitions get mounted readonly to prevent modification. To remount /system as read-write,
Adb shell mount -o remount,rw /system
If you get "not permitted" error, your ROM's ro.secure means you cannot execute mount operations passed with adb command. So instead you must first open the shell,
> AdB shell
# mount -o remount,rw /system
Now you can delete:
Adb shell rm /system/file
If it is a directory
Adb shell rm -rf /system/dir
If you accidentally mistype that last command with a space beyween that first forward-slash and "s" you will have a very unworkable device....and that's why it is mounted read-only.
If the file is on a different read only filesystem, identify the partition the file is on and
Adb shell mount -o remount,rw /dev/block/id /LocToMountTo
You may have to specify the type
-t fstype
Adb shell mount
will tell you this
Don't forget to remount it as read-only (ro) when you are done
anotherguy19 said:
Read the error message again. The file is on a read-only filesystem. That is why you cannot delete it. In other words, you lack permission to write to the partition.
System partitions get mounted readonly to prevent modification. To remount /system as read-write,
Adb shell mount -o remount,rw /system
Now you can delete:
Adb shell rm /system/file
If it is a dir
Adb shell rm -rf /system/file
If you accidentally mistype that last command with a space beyween that first forward-slash and "s" you will have a very unworkable device....and that's why it is mounted read-only.
If the file is on a different read only filesystem, identify the partition the file is on and
Adb shell mount -o remount,rw /partition/id /folder
You may have to specify the type
-t fstype
Adb shell mount
will tell you this
Don't forget to remount it as read-only (ro) when you are done
Click to expand...
Click to collapse
Well I can access /system just fine. The problem is the /oem/apps folder is not in the /system folder. It's in the top level folder.
/system and /oem/apps are in the root directory. I can change the permissions on /system just fine using Root Explorer, but when trying to change the permissions using any method possible, /oem wont change.
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Vindicoth said:
Well I can access /system just fine. The problem is the /oem/apps folder is not in the /system folder. It's in the top level folder.
/system and /oem/apps are in the root directory. I can change the permissions on /system just fine using Root Explorer, but when trying to change the permissions using any method possible, /oem wont change.
Click to expand...
Click to collapse
/system and /oem are different partitions then
mount | grep oem
or
adb shell mount | grep oem
Will tell you what /dev/block/xxxx the /oem is on and if it is mounted as read-only (ro)
> adb shell
# mount -o rw,remount /oem
zelendel said:
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Click to expand...
Click to collapse
Ever get the feeling that you're writing in invisible ink lol?.. Eventually he will listen! You have great patience!
zelendel said:
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Click to expand...
Click to collapse
Referencing zelendel's post, the device could fail to boot because it is looking for the removed app in /oem
So you could try to remove it from being referenced by the startup scripts.
Try doing a search for files that could be referencing the apk you want to remove.
> adb shell
# grep -r AppName.apk /system/etc
CtrlAltDelIrl said:
Ever get the feeling that you're writing in invisible ink lol?.. Eventually he will listen! You have great patience!
Click to expand...
Click to collapse
If it bootloops then I'll just flash it again, but its worth a try isn't it? Thanks anyways.
anotherguy19 said:
Referencing zelendel's post, the device could fail to boot because it is looking for the removed app in /oem
So you could try to remove it from being referenced by the startup scripts.
Try doing a search for files that could be referencing the apk you want to remove.
> adb shell
# grep -r AppName.apk /system/etc
Click to expand...
Click to collapse
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Vindicoth said:
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Click to expand...
Click to collapse
So after running mount | grep oem it shows this
[email protected]:/ # mount | grep oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
So is it possible to change this directory to rw? I tried the mount -o rw,remount oem but it doesnt show anything after i input the command
[EDIT]
So it seems that the cramfs file system is read-only.
Vindicoth said:
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Click to expand...
Click to collapse
I love breaking things. It's only then we can figure out how it works.
Busybox is exactly what you need.
grep will search for strings within all files and subdirs of /system/etc; matching whatever you type for "AppName.apk"
It is a case-sensitive search unless you add
-i
So
grep -ri ....
or
grep -r -i....
Both would work.
But you don't even know if you need to be searching for a file to modify.
You may want to go ahead and delete the file and reboot.
If it fails, note the file(s) you deleted and know the system is looking for them and then proceed with seeing if you can identify a file in /system/etc that is looking for it's presence.
---------- Post added at 11:59 PM ---------- Previous post was at 11:53 PM ----------
Vindicoth said:
So after running mount | grep oem it shows this
[email protected]:/ # mount | grep oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
So is it possible to change this directory to rw? I tried the mount -o rw,remount oem but it doesnt show anything after i input the command
[EDIT]
So it seems that the cramfs file system is read-only.
Click to expand...
Click to collapse
Commands that complete "quietly" mean they were successful.
If you type
# mount | grep oem
After
# mount -o rw,remount /oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
Should have changed to
/dev/block/nandi /oem cramfs rw,relatime 0 0
anotherguy19 said:
I love breaking things. It's only then we can figure out how it works.
Busybox is exactly what you need.
grep will search for strings within all files and subdirs of /system/etc; matching whatever you type for "AppName.apk"
It is a case-sensitive search unless you add
-i
So
grep -ri ....
or
grep -r -i....
Both would work.
But you don't even know if you need to be searching for a file to modify.
You may want to go ahead and delete the file and reboot.
If it fails, note the file(s) you deleted and know the system is looking for them and then proceed with seeing if you can identify a file in /system/etc that is looking for it's presence.
---------- Post added at 11:59 PM ---------- Previous post was at 11:53 PM ----------
Commands that complete "quietly" mean they were successful.
If you type
# mount | grep oem
After
# mount -o rw,remount /oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
Should have changed to
/dev/block/nandi /oem cramfs rw,relatime 0 0
Click to expand...
Click to collapse
Followed those steps and its still
/dev/block/nandi /oem cramfs ro,relatime 0 0
Apparently the cramfs is a read only filesystem by design.
Vindicoth said:
Followed those steps and its still
/dev/block/nandi /oem cramfs ro,relatime 0 0
Apparently the cramfs is a read only filesystem by design.
Click to expand...
Click to collapse
You need to create an image of the partition, mount the partition on a system with tools to edit it, extract the contents, and re-create the cramfs.
You would need a linux box or linux virtual machine like Virtualbox, or maybe cygwin has the tools. I would just download and burn a Linux LiveISO and run it from VirtualBox, creating a shared folder to get access to the image file (oem partition).
With debian system, you would do
# apt-get install cramfsprogs fusecram
fusecram allow you to mount the cramfs partition on Linux PC via
# mount -t loop cramfsOEM.partition /mnt/workingdir
However since we cannot simply mount the filesystem on the device by plugging into the usb port of the linux machine and mounting from there, we must first create an image (file) of /dev/block/nandi.
> adb shell
# dd if=/dev/block/nandi of=/nandi.img bs=4k
And then copy it to our pc so we can work with the file.
# exit
> adb pull /nandi.orig.img .
Now we can transfer this file to a machine with the requisite cramfs tools to modify the file.
If you look back, I wrote
# mount -t loop cramfsOEM.partition /mnt/workingdir
replace cramfsOEM.partition for nandi.orig.img, or whatever you named it.
Workingdir needs to exist, so
# mkdir /mnt/workingdir
Now you will have to look up cramfsprogs which will allow you to extract the contents to modify. On the Debian or Ubuntu linux machine "/mnt/workingdir" would be the equivalent of "/oem" on your Android device.
However, all this is could very well be for naught, as it is likely the firmware has marked this partition as "signed" so if we try to write back our modified image, the system will fail to boot since the size will be different. On the other hand, the firmware may very well just check to see the partition size is correct. And since you are decreasing the size, the new cramfs image created with a linux box will (should) fit in the old partition.
Fyi, an image file is like a zip file without the compression.
After you modify the cramfs, you can write it back with something like
> adb push cramfs.mod.img /
> adb shell
Then write over the old partition. However, you shouldn't write over a mounted file system so
# umount /dev/block/nandi
Then write over it.
# dd if=/cramfs.mod.img of=/dev/block/nandi bs=4k
Then reboot
# shutdown -r now
And see what happens.
anotherguy19 said:
You need to create an image of the partition, mount the partition on a system with tools to edit it, extract the contents, and re-create the cramfs.
You would need a linux box or linux virtual machine like Virtualbox, or maybe cygwin has the tools. I would just download and burn a Linux LiveISO and run it from VirtualBox, creating a shared folder to get access to the image file (oem partition).
With debian system, you would do
# apt-get install cramfsprogs fusecram
fusecram allow you to mount the cramfs partition on Linux PC via
# mount -t loop cramfsOEM.partition /mnt/workingdir
However since we cannot simply mount the filesystem on the device by plugging into the usb port of the linux machine and mounting from there, we must first create an image (file) of /dev/block/nandi.
> adb shell
# dd if=/dev/block/nandi of=/nandi.img bs=4k
And then copy it to our pc so we can work with the file.
# exit
> adb pull /nandi.orig.img .
Now we can transfer this file to a machine with the requisite cramfs tools to modify the file.
If you look back, I wrote
# mount -t loop cramfsOEM.partition /mnt/workingdir
replace cramfsOEM.partition for nandi.orig.img, or whatever you named it.
Workingdir needs to exist, so
# mkdir /mnt/workingdir
Now you will have to look up cramfsprogs which will allow you to extract the contents to modify. On the Debian or Ubuntu linux machine "/mnt/workingdir" would be the equivalent of "/oem" on your Android device.
However, all this is could very well be for naught, as it is likely the firmware has marked this partition as "signed" so if we try to write back our modified image, the system will fail to boot since the size will be different. On the other hand, the firmware may very well just check to see the partition size is correct. And since you are decreasing the size, the new cramfs image created with a linux box will (should) fit in the old partition.
Fyi, an image file is like a zip file without the compression.
After you modify the cramfs, you can write it back with something like
> adb push cramfs.mod.img /
> adb shell
Then write over the old partition. However, you shouldn't write over a mounted file system so
# umount /dev/block/nandi
Then write over it.
# dd if=/cramfs.mod.img of=/dev/block/nandi bs=4k
Then reboot
# shutdown -r now
And see what happens.
Click to expand...
Click to collapse
Wow that was very detailed. I thought I might have to do something like that. Thanks so much again. I'll try this in the morning since it's getting very late here. I'll go ahead and download a linux livecd tonight.
Well the script should be working, it is 'ettin.sh' now. To get VNC to work on separate device just change 'eth0' to 'wlan0' or whatever other interface you know how to configure, like usb maybe, in the 'init.sh' script that resides in ~/ on the images you can download from http://linuxonandroid.org/downloads/. Cool. If anyone can help with the usb configuring that would be cool.
Also on the different roms your storage might be different so just change that to what suites your environment,
BAD NEWS, After my first launch and exiting the VNC on my laptop (Ubuntu) My phones home button and a few other functions stopped working, a reboot remounts the root and system partitions and it goes back to normal essentially, I haven't noticed any adverse affects after the reboot.
Good luck.
EDIT: If you can't help me, you probably shouldn't attempt any of this.
I want to connect to backtrack over usb from Ubuntu on my laptop instead of from my phone. Is there a good way of doing this?
The thing is, I didn't chroot, I mounted the image, copied the contents of '/etc/*' and '/sbin/*' to the '*/etc' '*/sbin' dirs of the mounted image. and then mounted it's (the image's) contents to Androids rootfs '/' then I set up a little script to set up the environment and execute '/bin/bash -i init.sh' and again reset PATH to include /system/*.
Then in the init.sh script I want to set up a way to 'vnc' through' usb to backt4acks desktop. How would I do this?
EDIT: I started this script blelow, its not complete, feel free to use it however you like.
If anyone is good with bash I need help with loops in Bash or shell, ksh, or ash. So if you change it at all share those changes here. I haven't tested any of the loops, I wrote this here and need to do some reading on shell scripting, peace out.
Just NOTE that I would not execute this script yet, it is NOT YET COMPLETE.
I will be making minor changes as I learn and test things out, Also this was inspired by the autobootscrip (sp?) that the Linux on Android Installer app uses.
mintberrycrunch revision
I need a little help with the mounting part, "is there anybody out there?"
EDIT: Maybe escape '\' characters...
Maybe this will work? 'if [ ! -d "/$d" -a "$d" \!= "dev" -o "$d \!= "mnt" ]; then ' I want it to test whether the directory does not already exists in / and if it is not named dev or named mnt then mount it. Do you think this is a decent way to do it? Any suggestions?
Sorry, I still haven't tested this script yet, so if you brave and see any changes that will make it work I am not resposible. But it is getting close to when I will run it for the first time. The difference between this and the one I wrote for Kali is this should be a one stop shop so to speak for getting into a non chroot enviroment where you can access Bt's tools from Android directly. Apperently about a year ago someone was trying something similar called "debian installer" or something, I haven't tried it out so maybe that actually works, idk, I am happy with this.
LOL
LMFAO!
I just realized I don't think I needed to worry about testing if the variable $d was named 'dev' or 'mnt' because they should get skipped by already being mounted. If not I guess if it works as is, may be extra precaution.
Done! Almost ;{)-
Uhmm.... hope you can see the screenshot...
its over wifi though, I had to edit the init.sh script just eth0 to wlan0 in 2 lines, duh! where is eth0 on phone?
Check out the filesystem
Bada bing, bada doom, dare ya goes`a for ya.
V-0.021
This should support args, if your using different image or location such as external sdcard or want to mount to a different location
Notes: 'ettin.sh' [/IMAGE/LOCATION] [IMAGENAME] [MOUNT/POINT]'
1) Don't add a trailing forward slash for image location, the first argument. Doing so may conflict with the script.
2) Don't add suffix to image name ( second argument), the script uses a wild card period wild card syntax to account for .iso, .raw, or .img aswell as version numbers, so if its backtrack-v-r5.img all you need is 'backtrack'.
3) Default mount is "/data/local/mnt"
for example:
Code:
ettin.sh /storage/extSdCard/ubuntufolder ubuntu /mnt/myLinux
That ^^^ will use a ubuntu image on the external sdcard and mount it to a folder called "myLinux" within the "/mnt" directory.
The script below...
Code:
#!/system/bin/sh
# ettin.sh v-0.021, "Two heads are better than one."
# Written by 'Edge-Case' @ 'forum.xda-developers.com'
# This version is attempting to use symbolic linking to correct some issues.
## The purpose of ettin.sh is to merge a Linux system with Android
## hopefully allowing both systems to run in synch with each other.
## It is probably best to be ran on devices with multi-core processors.
##"""Notes on Backtrack and Kali Linux Distributions:
##"""1) Postgresql needs to be configured in order for metasploit to connect to
##""" the database. This might be possible within the script. Perhaps
##""" it is simply a matter of configuring SSH? I don't know.
##"""2) The Kernel needs to be patched to allow for packet injection and
##""" monitor mode for an external 'wi-fi' card as the factory hardware
##""" does not support monitor mode, at least on Samsung Galaxy SIII.
#########
# Prep ##
#########
mount -wo remount systemfs /system
mount -wo remount rootfs /
imloc=${1:-"/storage/sdcard0/backtrack"}
imname=${2:-"backtrack"}
subset=${3:-"/data/local/mnt"}
#Check for root!
if [ ! -d "$subset" ]; then mkdir "$subset"; fi
busybox mount -wo loop ${imloc}*/${imname}*.* ${subset}
check_mnt="`echo $?`"
if [ ${check_mnt} != 0 ]; then echo "Something is wrong with mounting, check the situation!" && exit; fi
##################################################
# Copy contents of special directories to image ##
##################################################
if [ ! -f "${imloc}/success.txt" ] ; then cp -ai /sbin/* ${subset}/sbin && echo "Files have been copied on `date`." > ${imloc}/success.txt; fi
if [ -e "/root/*" ]; then cp ai /root/* ${subset}/root; fi
######################################################
# Make directories needed and mount the file-system ##
######################################################
cd ${subset}
for d in `ls` ; do if [ ! -d "/${d}" ] ; then mkdir /${d} && busybox mount --rbind ${subset}/${d} /${d} ; fi ; done
busybox mount --rbind ${subset}/root /root
busybox mount --rbind ${subset}/sbin /sbin
busybox cp -rspi ${subset}/etc/* /etc # We'll try making symbolic links from the image to Android's /etc instead.
# Add any directories as needed.
###############################
# be safe before we continue ##
###############################
mount -ro remount systemfs /system
mount -ro remount rootfs /
######################################
# continue building the environment ##
######################################
export PATH="/system/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/system/xbin:/usr/games"
export TERM=linux
export HOME="/root"
#################################
# further down the rabbit hole ##
#################################
/bin/bash -i ~/init.sh
Pretty happy with it now, so far. Touch FIXED
Well, I am tethered from my phone to my laptop, running ubuntu, this is how I am on the internet, so my phone is doing that...
I ran 'ettin.sh /storage/sdcard0/ubuntu ubuntu' using V-0.022 and only had two files that needed overwriting.
The touch is working....check
adb is working...check
Everything is mounted ...check
Apps like browser and dsploit are working on the phone as usual...check
'apt-get update && apt-get upgrade'....check (over adb, no chroot, as [email protected] using bin/bash)
'which nmap' .....check ("
[email protected]:~# which nmap
/usr/bin/nmap
")
Well **** ya'll looks like this might work... I am now going to consider modifying a stock rom to support users and login that meshes with debian and its "shadow" file etc etc, also I need to work out permissions and enviroment variables...
I'm happy...
Also for pentesting distro's "modifying Android kernel" tutorials would be nice, anybody able to point me to one?
I have a xperia u, which has not external SD card slot..
Data partition is MUCH bigger than what I need (I'm using 500mb of 2gb) and I want to move obb files to data partition to free some space in SD partition..
Is that possible?
You might try to move the file to the data partition and then create a symlink where the file was originally.
From a shell with root access:
# ln -s /your/data/partition/filename.obb /original/place/filename.obb
I'm doing the same moving apk and dalvik-cache but I have the problem that after reboot files are still there but the app is disabled.
You can check it here: http://forum.xda-developers.com/showthread.php?t=2597924
I would suggest to try it on an app that it's not important for the system and I don't assume any responsability
P.S.
partition where you create symlink must be ext2/3/4
I think I understand how this works.. Lets say symlinks are some kind of 'windows direct access' for files that can be recognized by the system.. Am I right?
How can I figure out what format are my partitions?
I want to move /mnt/sdcard/Android/obb/com.package.name/file.obb to /data/data/com.package.name/file.obb
Assuming that partitions are in the correct format, I'll have to move files with a root file browser, then connect phone with debug on and type this:
-adb shell
-su
-ln -s /data/data/com.package.name/file.obb /mnt/sdcard/Android/obb/com.package.name/file.obb
Is that ok?
Yest that's the use, I don't know about "windows direct access" because I'm linux user
To check how is your partition formatted there are different ways from console but I just tried this app and it works:
https://play.google.com/store/apps/details?id=com.cls.partition
If both partitions are ext2/3/4 remember also to set the same user, group and permissions, you can do that copying the file from shell.
The whole sequence should look like this:
Code:
$ adb shell
$ su
# cp -a /mnt/sdcard/Android/obb/com.package.name/file.obb /data/data/com.package.name/file.obb
# rm /mnt/sdcard/Android/obb/com.package.name/file.obb
# ln -s /data/data/com.package.name/file.obb /mnt/sdcard/Android/obb/com.package.name/file.obb
cp - a to copy preserving permissions and rm to remove the file.
/data is ext4.. /mnt/sdcard is vfat D=
No symlink then
I never used it but you can still mount bind folders (not files) in fat, something similar to symlink:
Code:
$ adb shell
$ su
# mkdir /data/data/com.package.name/obb/
# cp -a /mnt/sdcard/Android/obb/com.package.name/* /data/data/com.package.name/[B]obb/[/B]
# rm -r /mnt/sdcard/Android/obb/com.package.name/*
# mount -o bind /data/data/com.package.name/[B]obb/[/B] /mnt/sdcard/Android/obb/com.package.name/
if it works you need to find a way to excute that on boot maybe with a init script.
And if there is not crucial data you could even bind all the obb folder together like:
Code:
# mount -o bind /data/data/com.package.name/[B]obb/[/B] /mnt/sdcard/Android/obb/
You can also check this thread:
http://forum.xda-developers.com/showthread.php?t=1410262
Double check everything because I never tried it
Is it possible to add init.d support to my current rom and execute a sh file from it to initialize bind on boot?
No idea sorry
You can try asking in your phone section: http://forum.xda-developers.com/xperia-u
I found how to add init.d support!
Not sure if it works for any device/rom/kernel, but it worked for my Xperia U with GingerBeanSS v3.5 (Sony GB based)..
If anyone is interested, go to this link: http://forum.xda-developers.com/showthread.php?p=32716432
Now I suppose I can create a "BindOBB.sh" with the script you mentioned before in any place of /system, and make a "bindobb" file in /system/etc/init.d/ to execute that script..
So theoretically binding folders should work on every boot!
I used windows my entire life.. I'm not completely sure about linux scripts..
Sorry about making so much questions!
I really appreciate your help!
No problem I'm glad if I can help.
Init script is usually named starting with two numbers like: 00script, 20script, 99script that should give the order scripts are excuted.
For the script itself you need to follow the sample you donwloaded so it will be something like this:
Code:
#!/system/bin/sh
#Comment
busybox mount -o bind /data/data/obb/ /mnt/sdcard/Android/obb/
This is to mount all obb folder or, if you want to mount only some, you can write them all in the script or keep a list of packages in another file and make the script read that.
Remember to make a backup and you might try first with only one package
Ok, I've understood everything (thanks google! ) and done it..
mount -o bind[...] isn't executed by init script.. Maybe a syntax error as it is my first time doing it..
The same command (without 'busybox' at first, of course) seems to work via ADB, because in SolidExplorer when I go to obb folder BEFORE running the script it is empy, but after running it all packages' folders and files appear!
Now problem is that when running a game that need obb data, it closes by itselfs (no FC nor 'missing data' warning)..
Same problem with a 3rd party TTS engine that needs obb data too..
The first problem could be that when you try to execute the command partitions are not mounted yet. Check 00 script used to test if init is enabled to mount them.
Another solution could be to use a sleep command to make the script wait some seconds but the first one should do the trick.
For the second problem check permissions. You copied files as root so you need to be sure the apps can access those files as well, in fat system there is no use of users, group and permissions but moving to ext you need to check that.
To be sure you can set obb folder and all files an directories inside as 777 (rwx for all)
Let me know if it's working
Sent from my ZP980 using Tapatalk
NeriL said:
I want to move /mnt/sdcard/Android/obb/ to /data/data/
Click to expand...
Click to collapse
you can easy create a directory bind using luckypatcher with the folder with obb and the folder where you would like to put it
remember to reboot or rescan your sd else it wont work
i use it to play asphalt and fifa
MrCrayon said:
The first problem could be that when you try to execute the command partitions are not mounted yet. Check 00 script used to test if init is enabled to mount them.
Another solution could be to use a sleep command to make the script wait some seconds but the first one should do the trick.
For the second problem check permissions. You copied files as root so you need to be sure the apps can access those files as well, in fat system there is no use of users, group and permissions but moving to ext you need to check that.
To be sure you can set obb folder and all files an directories inside as 777 (rwx for all)
Let me know if it's working
Sent from my ZP980 using Tapatalk
Click to expand...
Click to collapse
I deleted my custom init script and wrote following command at the last line of '00test' script:
busybox mount -o bind /data/obb/ /mnt/sdcard/Android/obb/
Mount then worked fine
(By the way, my custom script was named '99bindobb', so it was supposedly executed after everything else)
Also checked permissions: /data/obb/ and com.package.name folders inside it were rwxrwxrwx, but files inside were rw-------!
Changed permission of files to rwxrwxrwx..
Now everything works flawlessly at each boot!
Thank you so much! =D =D
You saved about 500Mb of my 4Gb!
And also I learned a lot about linux scripts, busybox and file system permissions!
You are welcome
For the 99 script that only define the order between the user init scripts so it still depends when they are called during boot.
Enjoy the power of Linux
Sent from my ZP980 using Tapatalk
Hi MrCrayon..! I'm here again
I changed rom and did the same as before to use /data insted of /mnt/sdcard for apps files..
This is exactly what I did:
I copied the script I used to sd (my edited 00test), changed rom (switched from Sony based GB rom to Sony Stock ICS rom), added init.d support (/data/Test.log indicates that it works), copied script to /system/etc/init.d/, changed script permissions to 777, created folders /data/AndroidData/ and /data/obb/ with 777 permissions and moved files from sd folders to custom folders in /data..
Finally updated busybox just in case
Script doesn't work, but executing 'mount -o bind' commands from ADB does! How can I fix that?
This is my init script:
#!/system/bin/sh
#Init.d Test
if [ -e /data/Test.log ]; then
rm /data/Test.log
fi
echo Ryuinferno @ XDA 2013 > /data/Test.log
echo Init.d is working !!! >> /data/Test.log
busybox mount -o bind /data/obb/ /mnt/sdcard/Android/obb/
busybox mount -o bind /data/AndroidData/ /mnt/sdcard/Android/data/
busybox set_perm_recursive(0, 0, 0777, 0777, /data/AndroidData, /data/obb)
Hi, friends.
I'd really appreciate your help.
My phone is suffering from consequences of kernel flash, which was obviously not a very successful :silly:
Short <intro>, if I may:
I have been using Cyanogenmod 12.1 nightlies (lollipop 5.1.1) for a long time. Everything was great.
One day I decided to try out Dorimanx kernel for lollipop, compatible with CM, of course. Big mistake.
After the flash (wiped Cache, Dalvik, System before the flash) I lost /eMMC, since Dori is lacking ext4 support for /eMMC, which I wasn't aware of.
Tried to flash my previous rom back (wiped Cache, Dalvik, System before the flash), but I got even more processes failing, probably due to different SELinux policies (Dori - permissive, stock CM - enforcing).
While I had Dori on board, I managed to backup /eMMC(copy-paste over MTP bridge to Windows PC) and /data(as binary image and TWRP-backup).
Now, even when I restore those two (eMMC or /data) under new clean ROM installation - I keep getting errors.
</intro>
/emmc issue example:
Code:
[ 12-20 22:20:42.885 8856: 9388 E/CacheManager ]
Cannot instantiate cache!
java.io.FileNotFoundException: /storage/sdcard0/Android/data/com.android.gallery3d/cache/imgcache.idx: open failed: EACCES (Permission denied)
at libcore.io.IoBridge.open(IoBridge.java:456)
...
[ 12-20 22:20:42.923 8856: 9388 W/Worker ]
Exception in running a job
java.lang.NullPointerException: Null pointer exception during instruction 'monitor-enter v6'
at com.android.gallery3d.data.ImageCacheService.getIm ageData(ImageCacheService.java:65)
/data issue example:
Code:
[ 12-14 17:03:07.745 6350: 6350 W/com.google.android.gms ]
type=1400 audit(0.0:2308): avc: denied { lock } for comm=4173796E635461736B202331 path="/data/data/com.google.android.gms/databases/reminders.db" dev=mmcblk0p10 ino=123233 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
What I've tried so far:
e2fsck (/emmc)
twrp - fix permissions (/data)
twrp format partition + copy paste from PC (/emmc)
find /emmc/Android/data/ -type d -exec chmod 775 {} ';' (/emmc)
find /emmc/Android/data/ -type f -exec chmod 664 {} ';' (/emmc)
restorecon -FR (/emmc)
install Kitkat-permissive rom on top of broken /data
Unfortunately, nothing helps.
I really want to keep my old /data partition, what's why I spent on this around 2 weeks, and I'll keep trying.
Can you please guide me from the technical perspective?
P.S. The /emmc issue was a dumb thing that I always forget:
Code:
[email protected]:/mnt/media_rw # find sdcard0 -type d -exec chmod 775 {} ';'
[email protected]:/mnt/media_rw # find sdcard0 -type f -exec chmod 664 {} ';'
[email protected]:/mnt/media_rw # chown -R media_rw:media_rw sdcard0
But the 2nd issue with /data is still unsolved.
Please assist!
If you need to restore your data only, you could manually mount the /data image on your PC (if you're not using Linux as your desktop OS, you can install Ubuntu or Mint under a virtual machine like VMware Player, which is free - if you need help with that, or mounting the image, PM me), wipe your device and copy over data for any apps you need to the new file system. Then, reapply proper permissions for copied data. Titanium Backup Pro can do that for you with a GUI, but requires a CWM backup if I remember correctly and won't talk with TWRP/raw images (I might be wrong).
Now, this all looks nice and all, but that "reapply proper permissions" part is a bit messy. It's because Android creates a new Linux user and group for every individual Android app you install. There are some special users/apps sharing certain details, but regular apps will have a new account like "u0_a47" or something like that created for them. If you just copy and paste any data to your new filesystem, you'll get hit with access errors (pretty much exactly what you've described). Reinstall all apps from .apks (if you have bare .apks backed up somewhere, or have extracted them from your /data, you can reinstall them all en masse with adb), then in terminal (as root, otherwise you won't be able to peek inside /data/data): ls -la /data/data > /storage/sdcard0/applist.txt, pull /storage/sdcard0/applist.txt to your computer (with adb), and then the messy part: Copy over any data you want, and reapply proper permissions for any app you've restored with chown -R uX_aY /data/data/org.your.app, where uX_aY is your app's user/group (listed in applist.txt), and org.your.app is your app identifier (also listed in applist.txt).
This is messy as hell, but it works.
Thank you for the answer! Can you confirm, please, if I'm getting this right?
1. Install from google play all the needed apps under clean rom (to get list of proper permissions)
2. Save output of ls -al from clean rom in a text file (proper permissions)
3. Extract apps from backed up /data image
4. Push them into /data of the clean rom
5. Run chown on each of the restored folders, using ouput of ls -al
6. Reboot
Now, the point where I extract apps from image is also tricky... afaik, single app is scattered between multiple directories under /data. Do you know any explanatory article on this subject? What's app structure under /data etc?
Extract apps and data from /data image, but yeah, everything else looks good. Under Android 6.0 (older versions aren't that different if I remember correctly), with a single user, you have two folders: /data/app which contains installed .apks, and /data/data which contains your app's data - everything else is system-specific and will get generated automatically if needed, regular apps can't touch these at all. Simply extract these two folders and you're good to go.
Cool! I will try that during the weekend. If this works - it may become a very useful article.
Are those changes persistent? I did chown for some /emmc files under TWRP recovery, reinstalled rom, and i can tell that root explorer& terminal do not show my changes at all... :-/
Yes, they should be as long as your file system is mounted R/W. Did you chown -R (recursively)?
Unfortunately, your solution is missing something... still getting errors... [ 12-26 19:53:38.802 4124: 4124 W/com.socialnmobile.dictapps.notepad.color.note ]
type=1400 audit(0.0:197): avc: denied { lock } for comm=4173796E635461736B202331 path="/data/data/com.socialnmobile.dictapps.notepad.color.note/databases/colornote.db" dev=mmcblk0p10 ino=123103 scontext=u:r:untrusted_app:s0 tcontext=ubject_r:system_data_file:s0 tclass=file
[ 12-26 19:53:38.802 4124: 4124 W/com.socialnmobile.dictapps.notepad.color.note ]
type=1400 audit(0.0:198): avc: denied { lock } for comm=4173796E635461736B202331 path="/data/data/com.socialnmobile.dictapps.notepad.color.note/databases/colornote.db" dev=mmcblk0p10 ino=123103 scontext=u:r:untrusted_app:s0 tcontext=ubject_r:system_data_file:s0 tclass=file
[ 12-26 19:53:38.802 3821: 4125 E/FlurryAgent ]
java.io.FileNotFoundException: /data/data/com.socialnmobile.dictapps.notepad.color.note/files/.flurrydatasenderblock.ba285603-75ea-4129-84cd-8ac36726fb02: open failed: EACCES (Permission denied)
at libcore.io.IoBridge.open(IoBridge.java:456)
Ummm, looks like SELinux is set to restrictive and prevents app from touching what is not exactly theirs. Unfortunately I can't help you with this, I don't know how to configure SELinux properly :/
Is it possible to replace only the 'databases/colornote.db' file?
I don't know how to copy it over and set correct permissions to make it work with restrictive SELinux policies, but you can use a database viewer/editor or sqlite3 binary on the device to export/import the data inside.
1. Copy your colornote.db with data somewhere accessible (not /data/....). Wipe the app's data completely, then start it once. It should regenerate all required files. Connect your phone to PC, and fire up adb shell. (You can do this with the terminal on the device directly too.) Get root access with "su".
2. "cd" to the folder with your colornote.db (which you want to use). Then (as root) do this on your device: https://stackoverflow.com/questions/4389930/exporting-data-from-sqlite-3#4390636 - sqlite3 and any text editor (vi, most likely) should be available in your ROM (if not, install Busybox). You should now end up with 2 .sql files in the same folder.
3. Still as root: "sqlite3 /data/data/com.socialnmobile.dictapps.notepad.color.note/databases/colornote.db", then ".schema" (there's a dot before "schema"). It'll write out a few statements like "CREATE TABLE foo". There shouldn't be too many, you'll have to "DROP TABLE foo;" for every single one of them, then ".read schema.sql", followed by ".read inserts.sql" - both files created in step 2, you'll have to supply full paths to be read. Then ".exit", and you're done.
(And someone will probably come and tell me all of this can be done in a few seconds with two-three commands I didn't know about before. )
Thanks for your time, mate. I will probably try to dig into CM sources of SELinux implementation, or to read a really detailed book on the subject. I guess it's the only way to fix my backed up /data.
Dragoon Aethis, tell me one more thing, please: if I grab/push single application, as you suggested, getting bad selinux feedback, then MOVING app to sdcard (built-in function of CM rom), and moving back? Should it restore proper permissions, what do you say? Of course, I'll try that on the weekend, since my i9100 is a daily driver, I cannot experiment during the week I thought of this, because most of the time sdcard has different filesystem than /data, which makes impossible to keep permissions there.
Weeeell, you can format /sdcard as ext4 and your problems are gone, but so are proper Android permissions for that it thinks should be on /sdcard Moving it might work, but moving apps to SD is hit and miss most of the time anyways, so you'd have to try.
Ok, I'll try. My /emmc is ext4 anyway. Not sure if this is a good thing, since I'm expecting the transferred application to lose permissions and selinux properties during move & restore. It is the only way to trigger creation of the proper properties. Otherwise it's only copy-paste of the same broken properties, as well as the files themselves. Of course I haven't seen the implementation on the github, but I will try that on weekend, and reply back.