Hi all,
im working on making a ROM for the Asus Transformer and im struggling a bit. im totall new to Linux, using mint and just getting used to it.
Basically im just trying to take a stock ROM and add root but adding superuser.apk and SU binary but im running into problems.
Asus Roms are a bit unusual, packed into blob files, ive unpacked that no problem, the system image is called blob.APP but its just the same as system.img just the name as i understand it.
ok so what ive done:
Code:
mkdir system
sudo mount -t ext4 -o loop blob.APP system/
so this mounts the ext4 fs as a loop device and allows me to copy the contents out
Code:
sudo cp -ar system new_system
then ive copied superuser.apk to /app and SU binary to /dev with drop and drag.
then make the filesystem image
Code:
sudo ./make_ext4fs -l 512m -a system blob.APP new_system/system
then just pack it up and flash it, flashing works fine, no errors but when i go to reboot it warns that theres no OS so somethings not worked. ive tried everything i can find googeling!
i just started learning linux on weds so go easy on me
any advice or help would be really great. thanks!
mkdir system here you will mount the old system
mkdir system_new here you will mount the new system
we now create the actual image
dd if=/dev/zero of=system_new.img bs=4k count=60000
bs=4k is the block size
count=60000 the number of blocks of 4kb size
so is something like 60000*4= 240000 which is actually 240 Mb
so it depends to you how big you want the image.
now we format the system.img in ext4
mkfs.ext4 system_new.img
Proceed anyway? (y,n) y
now we override the filesystem check
tune2fs -c0 -i0 system_new.img
Now we mount the the 2 directories that we created in the first step
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Now we copy the contet of the old image to the new one with all the perimissions
cp -v -r -p system/* system_new/
We sinc the files
sync
We unmount the partitions
umount system_new/
umount system/
And voila, the system.img in ext4 is created.
Tips: you will need superuser acces.
if you will copy new files besides the ones from the old system you will have to set by hand all the permissions.
If you are using ubuntu just type
sudo su
and you will be root and no more sudo at each command.
Thank u so much for your guide this is exactly what I'm looking for so massive thanks!
So to add root I.can drop and drag superuser.apk and the binary into the new image?
Also do I need to worry about the android mountpoint?
Sent from my HTC Sensation Z710e using xda premium
yes you can do that, as long as you set the permissions right. (you can google for them)
and from what i remeber you will have to set also the ownership of the su, and superusers files
you need to do tests first, and then try
the mountpoint should be ok as it is now.
globula_neagra said:
mkdir system here you will mount the old system
mkdir system_new here you will mount the new system
we now create the actual image
dd if=/dev/zero of=system_new.img bs=4k count=60000
bs=4k is the block size
count=60000 the number of blocks of 4kb size
so is something like 60000*4= 240000 which is actually 240 Mb
so it depends to you how big you want the image.
now we format the system.img in ext4
mkfs.ext4 system_new.img
Proceed anyway? (y,n) y
now we override the filesystem check
tune2fs -c0 -i0 system_new.img
Now we mount the the 2 directories that we created in the first step
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Now we copy the contet of the old image to the new one with all the perimissions
cp -v -r -p system/* system_new/
We sinc the files
sync
We unmount the partitions
umount system_new/
umount system/
And voila, the system.img in ext4 is created.
Tips: you will need superuser acces.
if you will copy new files besides the ones from the old system you will have to set by hand all the permissions.
If you are using ubuntu just type
sudo su
and you will be root and no more sudo at each command.
Click to expand...
Click to collapse
U said, we have to set permissions by ourselves. So what are the permissions that needs to be set when I add a new folder with an APK in it?
Sudo chmod 777 filepath/filename.apk
Sudo chmod a-rwx filepatch/filename.apk.
This is what I remember from top of my head. Google it a bit if it does not work from the first try as I have not used this like in 5 years.
If you allready have root you can you a file manager and just copy the file/folder where you want and set the permissions via thw file manager or using terminal commanda or via adb.
From what remember you can t make a folder in the apk folder as you won t be able to run the apk.
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
So the best and easy way to solve the unsquashing problem is to download squashfs-tools source and building it with lz4 support.
Here the steps:
1- We' are going to build squashfs with full support for every available compress method (lzo,lz4,lzma,gzip) so we need dev packages, just run:
Code:
sudo apt-get install liblzo2-dev liblzma-dev liblz4-dev
2- Create a working folder and download squashfs-tools source
3- Open terminal go to working folder and uncompress source:
Code:
tar -zxvf squashfs4.3.tar.gz
NOTE: if they release a new version you need to replace "4.3"
4- Go to source folder and open makefile for editing:
Code:
cd squashfs4.3/squashfs-tools
gedit Makefile
NOTE: if they release a new version you need to replace "4.3"
5- In te Makefile uncomment (erase "#") in the following lines:
#XZ_SUPPORT = 1
#LZO_SUPPORT = 1
#LZ4_SUPPORT = 1
#LZMA_XZ_SUPPORT = 1
6- Compile and Install:
Code:
make
sudo make install
If everything goes right you can now open a new terminal and unsquash every squashfs file you can find and of course new LZ4 compressed from RemixOS. I hope this result helpfull for anyone!
NOTE: If you are not interested in having some un/compress type you can avoid installing xxx-dev corresponding package and DO NOT comment corresponding line on Makefile.
what about on elementary Os?
lukss12 said:
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
So the best and easy way to solve the unsquashing problem is to download squashfs-tools source and building it with lz4 support.
Here the steps:
1- We' are going to build squashfs with full support for every available compress method (lzo,lz4,lzma,gzip) so we need dev packages, just run:
Code:
sudo apt-get install liblzo2-dev liblzma-dev liblz4-dev
2- Create a working folder and download squashfs-tools source
3- Open terminal go to working folder and uncompress source:
Code:
tar -zxvf squashfs4.3.tar.gz
NOTE: if they release a new version you need to replace "4.3"
4- Go to source folder and open makefile for editing:
Code:
cd squashfs4.3/squashfs-tools
gedit Makefile
NOTE: if they release a new version you need to replace "4.3"
5- In te Makefile uncomment (erase "#") in the following lines:
#XZ_SUPPORT = 1
#LZO_SUPPORT = 1
#LZ4_SUPPORT = 1
#LZMA_XZ_SUPPORT = 1
6- Compile and Install:
Code:
make
sudo make install
If everything goes right you can now open a new terminal and unsquash every squashfs file you can find and of course new LZ4 compressed from RemixOS. I hope this result helpfull for anyone!
NOTE: If you are not interested in having some un/compress type you can avoid installing xxx-dev corresponding package and DO NOT comment corresponding line on Makefile.
Click to expand...
Click to collapse
Could you upload the system.img?
kabelon said:
what about on elementary Os?
Click to expand...
Click to collapse
I have never used it, if you're asking if it will work to do the installation steps for RemixOS, well as it is Ubuntu based I think the answer probably is yes.
Orion116 said:
Could you upload the system.img?
Click to expand...
Click to collapse
I'm on a 1Mbit connection and system.img is 2,7GB so I'm not able to upload it. If you are on windows try to find squash-tools for windows with LZ4 support. If you're running Ubuntu do the steps I have mentioned it's easy an it takes no more than 15 minutes.
lukss12 said:
I'm on a 1Mbit connection and system.img is 2,7GB so I'm not able to upload it. If you are on windows try to find squash-tools for windows with LZ4 support. If you're running Ubuntu do the steps I have mentioned it's easy an it takes no more than 15 minutes.
Click to expand...
Click to collapse
The issue is I am on Manjaro, an arch based OS. I'll try something similar on manjaro
Orion116 said:
The issue is I am on Manjaro, an arch based OS. I'll try something similar on manjaro
Click to expand...
Click to collapse
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
lukss12 said:
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
Click to expand...
Click to collapse
Seems I didn't have to install the packages
---------- Post added at 11:22 PM ---------- Previous post was at 11:17 PM ----------
lukss12 said:
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
Click to expand...
Click to collapse
I got a system.img :good: Now to remember how to set up the grub for it:cyclops:
Orion116 said:
Seems I didn't have to install the packages
---------- Post added at 11:22 PM ---------- Previous post was at 11:17 PM ----------
I got a system.img :good: Now to remember how to set up the grub for it:cyclops:
Click to expand...
Click to collapse
Great.
Add this to custom file in /etc/grub.d
Code:
menuentry "Remix-OS" {
set root='(hdx,y)'
linux kernel root=/dev/ram0 androidboot.hardware=remix_x86_64 androidboot.selinux=permissive quiet DATA=/data
initrd /android/initrd.img}
(hdx,y) makes reference to the partition where you are installing RemixOS, Generally it is (hd0,y) where 'y' is the number of the partition
This setup works if RemixOS files are on root folder of partition
Edit: I need to warn you that my PC hang on a black screen after Setup Wizard on first boot if you have this problem ask me for the workaround
I have it booting but no WiFi, rats. It worked in the last LP build.
lukss12 said:
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
Click to expand...
Click to collapse
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
HypoTurtle said:
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
Click to expand...
Click to collapse
I actual just copied the grub.cfg for resident mode from the iso proper and used grub customizer to add it to my triple booted laptop. To bad Boardcom wifi is shot though otherwise it is perfect.
And how to add it to GRUB menu?
gb_14 said:
And how to add it to GRUB menu?
Click to expand...
Click to collapse
You can copy grub.cfg from original ISO into your /boot directory like Orion16 did. Or just edit /etc/grub.d/custom file as I told him in a previous post and run "sudo update-grub"
HypoTurtle said:
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
Click to expand...
Click to collapse
Yes androidx86 first test for system.sfs, then system.img and last for system folder. On androidx86 builds I was able to boot with system folder and it was so in first RemixOS builds but now it is not working anymore (RemixOS loops at boot). I think that having installed an OS means also having RW permission over system files but it's just an opinion.
About modified initrd.img you don't need to unpack system.sfs for this method. But currently there is no modified initrd.img for last RemixOS and I don't have the time to do it.
I NEED TO WARN EVERYONE: if you modify system files mounting system.img as RW future OTAs will refuse to install and you will need to replace your custom system with the original one if you want OTA update.
lukss12 said:
Yes androidx86 first test for system.sfs, then system.img and last for system folder. On androidx86 builds I was able to boot with system folder and it was so in first RemixOS builds but now it is not working anymore (RemixOS loops at boot). I think that having installed an OS means also having RW permission over system files but it's just an opinion.
About modified initrd.img you don't need to unpack system.sfs for this method. But currently there is no modified initrd.img for last RemixOS and I don't have the time to do it.
I NEED TO WARN EVERYONE: if you modify system files mounting system.img as RW future OTAs will refuse to install and you will need to replace your custom system with the original one if you want OTA update.
Click to expand...
Click to collapse
I have one posted here
But yea if you go the full way [if you're on ext4] and dump the system.img into a system folder; then you don't need to modify the initrd.img for rw.
I used #1 on Bash for Windows; [just wanted to check the uncompressed system file] so kudos for that
HypoTurtle said:
I have one posted here
But yea if you go the full way [if you're on ext4] and dump the system.img into a system folder; then you don't need to modify the initrd.img for rw.
I used #1 on Bash for Windows; [just wanted to check the uncompressed system file] so kudos for that
Click to expand...
Click to collapse
Good to have an initrd.img but is it RemixOS 3.x based?
About system dump on system folder, it was not working anymore with recent 2.x builds (I haven't tested it on 3.x).
Now RemixOS 3.x build comes with built in SU so I can remount RW system from Terminal or using ESFileExplorer (or similar one) and only need to have system.img for editing files within RemixOS. (I forgot I was using modified initrd.img to achieve this with system.img as you said you need to make system folder dump to edit files within RemixOS and without modified initrd.img)
But as I mentioned it will break OTA... So having an intrd.img is important.
Btw if you see anyone having trouble with new Jide Setup Wizard in 3.x, the fix is to delete /priv-app/JideSetupWizard from system.img or RemixOS will not pass welcome screen
(So no OTA for me until Jide fix this up for my PC)
lukss12 said:
Good to have an initrd.img but is it RemixOS 3.x based?
About system dump on system folder, it was not working anymore with recent 2.x builds (I haven't tested it on 3.x).
Now RemixOS 3.x build comes with built in SU so I can remount RW system from Terminal or using ESFileExplorer (or similar one) and only need to have system.img for editing files within RemixOS. But as I mentioned it will break OTA... So having an intrd.img is important.
Btw if you see anyone having trouble with new Jide Setup Wizard in 3.x, the fix is to delete /priv-app/JideSetupWizard from system.img or RemixOS will not pass welcome screen
(So no OTA for me until Jide fix this up for my PC)
Click to expand...
Click to collapse
Yea, that one is 3.x based. I have a simple script somewhere so that you could make your own [its a simple unpack; search for ro; replace with rw and repack].
And JSW - I just disabled the app [with pm disable com.jide.setupwizard] instead of removing it.
Still not sure how you are getting rw without a rw initrd.img; with RemixOS just because you have su doesn't mean you can remount rw afaik.
Code from stock initrd.img:
Code:
check_root()
{
local r
if [ "`dirname $1`" = "/dev" ]; then
[ -e $1 ] || return 1
blk=`basename $1`
[ ! -e /dev/block/$blk ] && ln $1 /dev/block
dev=/dev/block/$blk
r=$(ls /sys/block/$blk/removable /sys/block/*/$blk/../removable 2>/dev/null)
[ -n "$r" ] && r=$(cat $r) || r=0
else
dev=$1
fi
try_mount ro $dev /mnt || return 1
if [ -n "$iso" -a -e /mnt/$iso ]; then
mount --move /mnt /iso
mkdir /mnt/iso
mount -o loop /iso/$iso /mnt/iso
SRC=iso
elif [ ! -e /mnt/$SRC/ramdisk.img ]; then
return 1
fi
removable=$r
zcat /mnt/$SRC/ramdisk.img | cpio -id > /dev/null
[ -n "$SYSTEM" ] && blk=`basename $SYSTEM` || blk=
if [ -b "/dev/$blk" ]; then
[ ! -e /dev/block/$blk ] && ln /dev/$blk /dev/block
mount -o ro /dev/block/$blk system
elif [ -e /mnt/$SRC/system.sfs ]; then
mount -o loop /mnt/$SRC/system.sfs /sfs
mount -o loop,ro /sfs/system.img system
mount_system_dev_img_if_necessary
elif [ -e /mnt/$SRC/system.img ]; then
mount -o loop,ro /mnt/$SRC/system.img system
elif [ -d /mnt/$SRC/system ]; then
mount --bind /mnt/$SRC/system system
else
rm -rf *
return 1
fi
mkdir mnt
if [ -n "$DEBUG" ]; then
echo " found at $1"
fi
rm /sbin/mke2fs
hash -r
}
HypoTurtle said:
Yea, that one is 3.x based. I have a simple script somewhere so that you could make your own [its a simple unpack; search for ro; replace with rw and repack].
And JSW - I just disabled the app [with pm disable com.jide.setupwizard] instead of removing it.
Still not sure how you are getting rw without a rw initrd.img; with RemixOS just because you have su doesn't mean you can remount rw afaik.
Code from stock initrd.img:
Click to expand...
Click to collapse
You are right!!! I was using a modified initrd for having rw on 2.x and I didn't remember . Will try pm disable thanks :good:
lukss12 said:
You can copy grub.cfg from original ISO into your /boot directory like Orion16 did. Or just edit /etc/grub.d/custom file as I told him in a previous post and run "sudo update-grub"
Click to expand...
Click to collapse
Thanks
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
Three .sin files from stock are needed: vendor, kernel, system.
Unsin while in .sin folder:
-d to extract all files in working directory
./unsin.exe -d
You will end up with one .img file and two .ext4 files.
kernel_X-FLASH-ALL-C93B.img
system_X-FLASH-ALL-C93B.ext4
vendor_X-FLASH-ALL-C93B.ext4
While on the linux side of things, mount the .ext4 files using: mount -o loop
make sure folder 'ExtractFirm'(name it whatever you want) exists before hand. Folder closing then opening may be needed
sudo mount -o loop system_X-FLASH-ALL-C93B.ext4 ~/ExtractFirm/
Don't forget to chown the files as yours:
sudo chown -R username:group ExtractFirm/
copy the necessary files(into Firmware_Dump folder), then issue the command below when done with the mount:
sudo umount ~/ExtractFirm
--------------------
Find AIK-Linux in the dev sections on xda
Copy kernel_X*.img to AIK extracted folder then issue:
./unpackimg.sh kernel_X-FLASH-ALL-C93B.img
Own your files:
sudo chown -R username:group ramdisk/
Then copy(into Firmware_Dump folder) the contents of ram disk, if they're some errors(usually because of sym. links) with copying them, hit skip, otherwise merge all, replace all.
Lastly, mount vendor:
sudo mount -o loop vendor_X-FLASH-ALL-C93B.ext4 ~/ExtractFirm/
The kernel copy you did previously gave you an empty vendor folder. Copy all contents of the vendor mount into this empty vendor folder(within Firmware_Dump folder).
Dont forget:
sudo umount ~/ExtractFirm
Now that you have extracted firmware contents, you can run extract-files.sh for lineage/custom build:
~/lineageos/device/sony/poplar_dsds$ ./extract-files.sh ~/location of extracted contents/
These are just reference notes for everyone, I'm sure I'll need them again.
thanks @derf elot
great, thanks for the write up we can redirect people here if the question of how to extract files comes up again - which I'm sure it will
Sent from my Sony Xperia XZ1 Compact using XDA Labs
derf elot said:
great, thanks for the write up we can redirect people here if the question of how to extract files comes up again - which I'm sure it will
Sent from my Sony Xperia XZ1 Compact using XDA Labs
Click to expand...
Click to collapse
Indeed it will.
Great guide! I was thinking about automating stuff, but e.g. the copy works best when not done from the shell but from the file manager. The ignore, replace and merge all works perfect there.
Before anyone tries, here my failed attempts:
- Using 7z to extract the ext4 files, works somehow but fails to keep symlinks. But it would be faster...
- `cp -a` doesn't replace symlinks by actual folders and has some errors shown and some files/folders removed. Not sure if safe... So use file manager
- When using a VM make sure the AIK and the final folder are on ext4 filesystems, not shared/mounted from Windows hosts. Avoids failures with symlinks shown as "permission denied"
Edit: Ok I had failures and got an update to the guide:
- Start with the kernel extraction
- Then extract system*.ext4 to the system folder inside the above folder
- Then extract vendor.*ext4 to the vendor folder inside the above folder