Is there a xposed framework version compatible with RemixOS on 64-bit pc??
koskr2( said:
Is there a xposed framework version compatible with RemixOS on 64-bit pc??
Click to expand...
Click to collapse
Why?
koskr2( said:
Is there a xposed framework version compatible with RemixOS on 64-bit pc??
Click to expand...
Click to collapse
Note: not tested
You may download the x86 xposed and read the updater-script (or maybe updater-binary) then follow the steps mentioned there, sometimes it works. :highfive:
>>I'm assuming that there is no recovery, as my situation (and probably as the normal situation because there is no recovery for Remix OS PC yet)
It should work. x86 binaries work on x64. Not the reverse.
---------- Post added at 15:38 ---------- Previous post was at 15:37 ----------
On remix 1 ON TECLast x98, there is no problem [at least for xprivacy]
Maybe It's to complicated instaling xposed modul binary without custom recovery...
w1nst0n sm1th said:
It should work. x86 binaries work on x64. Not the reverse.
---------- Post added at 15:38 ---------- Previous post was at 15:37 ----------
On remix 1 ON TECLast x98, there is no problem [at least for xprivacy]
Click to expand...
Click to collapse
so did anybody get xposed framework working on remix os? If so how did they do it?
mystery6006 said:
so did anybody get xposed framework working on remix os? If so how did they do it?
Click to expand...
Click to collapse
Get root permission ==> busybox ==> xposed ==> xprivacy.
Got it rooted
I have it rooted have not used busy box before what do I do to install xposed?
w1nst0n sm1th said:
Get root permission ==> busybox ==> xposed ==> xprivacy.
Click to expand...
Click to collapse
What are you talking about? This reply to what you quoted doesn't make sense:what:
It means go toward Superuser.apk, after that, turn to reach busybox, then after go straight to xposed and finally stop to xprivacy. It doesn't take a map to figure it out.
More seriously :
1. Install superuser.apk
2. Install busybox
3. Install xposed.
4. Install xprivacy.
T
Busybox can been found on the busybox website or on the play store; xposed the same, website or play store, xprivacy in xposed installer.
Supersu.apk can be installed in the unpacked system + drop of the busybox binary in the xbin folder. +remove of the JideAppPolicy.apk or AppPolicy.apk [something like that] to unlock google apks.
Repack with the help of make_ext4fs or more simply by creating an empty ext4.img in a loop mount on linux and copying the modified system fs in it before unmouting the fresh ext4 image.
At runtime, installation of busybox symlinks with the command 'busybox --install -s /system/xbin'
After that xposed and xprivacy.
Easy game.
---------- Post added at 10:16 PM ---------- Previous post was at 10:04 PM ----------
Create ext 4 partition
Since most of the high-end devices are using now EXT4 partitions i decided to make a guide.
I am doing this because this is the easiest way to create an EXT4 image.
This is not my guide I am just adapting and make it clear to everybody; someone showed me
how to do this (I will mention him at the end of the guide).
Let`s assume that you dumped the system.img from your own device and you want to add something to it.
We will create a new system.img and we will name it system_new.img, the size will be 240 Mb.
Step 1
Linux Machine (I used Ubuntu)
We prepare the the directories and copy the system.img in the folder in which we will work.
mkdir system (here we will mount the old system.img
mkdir system_new (here we will mount the system_new.img)
Step 2 – Creation of the actual EXT4.img
dd if=/dev/zero of=system_new.img bs=4k count=60000
Translation of the terms,
bs =blocksize, 4k= the size of the block`s which in this case are 4kb
count=60000, the number of block`s, in our case will result an image of 240 Mb.
The blocksize can be 1k/2k/4k/16k
To get the exact size of the image that you create use simple maths.
60000 * 4 = 240000
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y)
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Step 5 We copy the content from the old system.img in the system_new.img
cp -v -r -p system/* system_new/
We sync the files
sync
Step 6 Unmounting the partitons.
umount system_new/
umount system/
You can add new files in the new created system.img but you need to set the permissions and
ownership properply, otherwise it will not work.
#only for tablet and fastboot install ?
Step 7 Making the file system android/fastboot compatible ?
ext2simg fs2convert.img fsconverted.img
Click to expand...
Click to collapse
Supersu installation procedure document can be found somewher in the apk.
Like that you can make yourself a reliable rooted version of remix and don't have to trust blindly an unknown source from megaspyware or zippy****ware.
Lucky bastards. Someone made all the research for you. Thanks who ?
w1nst0n sm1th said:
It means go toward Superuser.apk, after that, turn to reach busybox, then after go straight to xposed and finally stop to xprivacy. It doesn't take a map to figure it out.
More seriously :
1. Install superuser.apk
2. Install busybox
3. Install xposed.
4. Install xprivacy.
T
Busybox can been found on the busybox website or on the play store; xposed the same, website or play store, xprivacy in xposed installer.
Supersu.apk can be installed in the unpacked system + drop of the busybox binary in the xbin folder. +remove of the JideAppPolicy.apk or AppPolicy.apk [something like that] to unlock google apks.
Repack with the help of make_ext4fs or more simply by creating an empty ext4.img in a loop mount on linux and copying the modified system fs in it before unmouting the fresh ext4 image.
At runtime, installation of busybox symlinks with the command 'busybox --install -s /system/xbin'
After that xposed and xprivacy.
Easy game.
---------- Post added at 10:16 PM ---------- Previous post was at 10:04 PM ----------
Create ext 4 partition
Since most of the high-end devices are using now EXT4 partitions i decided to make a guide.
I am doing this because this is the easiest way to create an EXT4 image.
This is not my guide I am just adapting and make it clear to everybody; someone showed me
how to do this (I will mention him at the end of the guide).
Let`s assume that you dumped the system.img from your own device and you want to add something to it.
We will create a new system.img and we will name it system_new.img, the size will be 240 Mb.
Step 1
Linux Machine (I used Ubuntu)
We prepare the the directories and copy the system.img in the folder in which we will work.
mkdir system (here we will mount the old system.img
mkdir system_new (here we will mount the system_new.img)
Step 2 â?? Creation of the actual EXT4.img
dd if=/dev/zero of=system_new.img bs=4k count=60000
Translation of the terms,
bs =blocksize, 4k= the size of the block`s which in this case are 4kb
count=60000, the number of block`s, in our case will result an image of 240 Mb.
The blocksize can be 1k/2k/4k/16k
To get the exact size of the image that you create use simple maths.
60000 * 4 = 240000
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y)
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Step 5 We copy the content from the old system.img in the system_new.img
cp -v -r -p system/* system_new/
We sync the files
sync
Step 6 Unmounting the partitons.
umount system_new/
umount system/
You can add new files in the new created system.img but you need to set the permissions and
ownership properply, otherwise it will not work.
#only for tablet and fastboot install ?
Step 7 Making the file system android/fastboot compatible ?
ext2simg fs2convert.img fsconverted.img
Supersu installation procedure document can be found somewher in the apk.
Like that you can make yourself a reliable rooted version of remix and don't have to trust blindly an unknown source from megaspyware or zippy****ware.
Lucky bastards. Someone made all the research for you. Thanks who ?
Click to expand...
Click to collapse
How do you set the permissions?
Orion116 said:
How do you set the permissions?
Click to expand...
Click to collapse
chmod and chown files according to the instructions in the file 'update-binary' placed in Supersu.apk. It explain which files need which permissions. It should be the case in the 1.46 version you can download on chainfire website
There is also the selinux file context which should be applied to each superuser files, but having rooted the first remix os to install it on i7 cube, the selinux file contect gave me bootloop. So if it doesn't work with selinux context applied to su files, try without.
Busybox should have system file context, but it should be the case by default being placed in xbin folder...
I didn't have rooted the remix 2 version, but it shouldn't be very different from the way to do it in the first version.
Hope this help
---------- Post added at 03:11 AM ---------- Previous post was at 03:03 AM ----------
Have a look at this, in the remix os subreddit :
https://www.reddit.com/r/RemixOS/comments/40wzes/root_remix_os/
It provide a script which can be analysed and run safelly without installing suspect stuffs. The binaries needed, if you don't trust the one provided [i'm kind of parano with unofficial/unsourced stuffs] can be found on respecting websites [busybox/chainfire].
w1nst0n sm1th said:
chmod and chown files according to the instructions in the file 'update-binary' placed in Supersu.apk. It explain which files need which permissions. It should be the case in the 1.46 version you can download on chainfire website
There is also the selinux file context which should be applied to each superuser files, but having rooted the first remix os to install it on i7 cube, the selinux file contect gave me bootloop. So if it doesn't work with selinux context applied to su files, try without.
Busybox should have system file context, but it should be the case by default being placed in xbin folder...
I didn't have rooted the remix 2 version, but it shouldn't be very different from the way to do it in the first version.
Hope this help
---------- Post added at 03:11 AM ---------- Previous post was at 03:03 AM ----------
Have a look at this, in the remix os subreddit :
https://www.reddit.com/r/RemixOS/comments/40wzes/root_remix_os/
It provide a script which can be analysed and run safelly without installing suspect stuffs. The binaries needed, if you don't trust the one provided [i'm kind of parano with unofficial/unsourced stuffs] can be found on respecting websites [busybox/chainfire].
Click to expand...
Click to collapse
Ah. I used the script to root. And replace the apk with chain fires updated one.
Orion116 said:
Ah. I used the script to root. And replace the apk with chain fires updated one.
Click to expand...
Click to collapse
:good:
Using 64-bit Remix Os. I extracted flash-script.sh and system folder from the zip. Modified the script: ABI property to abilist, ABI2 property to abilist32, ABILONG property to abilist64. Files were installed correctly but hangs on boot. Might be somewhat similar too issue similar to touch-wiz roms and xposed. Didn't deodex so gonna try again.
So I have rooted version of remix is 2.0 for pc running in virtual box I really need xposed framework I have found a way to mount the virtual disk drive in Ubuntu and modify system files which is how I rooted it. So how can I manually add exposed from terminal using a script? Does anyone know if there is one out there? My opinion is I really wish that there was an installer apk with support.
mystery6006 said:
So I have rooted version of remix is 2.0 for pc running in virtual box I really need xposed framework I have found a way to mount the virtual disk drive in Ubuntu and modify system files which is how I rooted it. So how can I manually add exposed from terminal using a script? Does anyone know if there is one out there? My opinion is I really wish that there was an installer apk with support.
Click to expand...
Click to collapse
you still have to deodex too
Maromi said:
you still have to deodex too
Click to expand...
Click to collapse
So have you successfully put xposed on remix os?
Xposed news.
http://forum.xda-developers.com/xposed/xposed-x86-64-architecture-t3416149/page1
Related
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)
Alright, finally we have CIFS support on MJO.
Cross compiled on ArchLinux from the sources posted by Rich, config pulled from /proc/config.gz and just compiled the CIFS+md4 module.
Works great here:
Code:
//10.0.0.11/vault 3.6T 2.9T 709.1G 81% /mnt/shell/emulated/0/vault
Make sure you have root, insmod md4.ko, insmod cifs.ko and enjoy! I'm using this to access my MP3s for aMPD so that my Mojo can act as my stereo too.
*edit* also make sure you have busybox installed in order to mount, and pass a username option. ie:
Code:
busybox mount -ousername=guest //1.1.1.1/share /sdcard/share
vostok4 said:
Alright, finally we have CIFS support on MJO.
Cross compiled on ArchLinux from the sources posted by Rich, config pulled from /proc/config.gz and just compiled the CIFS+md4 module.
Works great here:
Code:
//10.0.0.11/vault 3.6T 2.9T 709.1G 81% /mnt/shell/emulated/0/vault
Make sure you have root, insmod md4.ko, insmod cifs.ko and enjoy! I'm using this to access my MP3s for aMPD so that my Mojo can act as my stereo too.
*edit* also make sure you have busybox installed in order to mount, and pass a username option. ie:
Code:
busybox mount -ousername=guest //1.1.1.1/share /sdcard/share
Click to expand...
Click to collapse
That's a good idea.. just updating the modules rather then the actual kernel.
By any chance, would you know how to approach updating the kernel on the mojo?
Thank you! These modules worked for me. However I was getting an "invalid parameter" error message. Finally I had to work around it as:
Code:
busybox mount -o unc=\\\\192.168.0.2\\share name,username=myself,password=password1 -t cifs none /mnt/point
It may depend on the version of busybox..
@gwaldo if you wanted to flash a custom kernel this is what I would do:
Code:
[email protected]:/ # ls -al /dev/block/platform/sdhci-tegra.3/by-name
ls -al /dev/block/platform/sdhci-tegra.3/by-name
lrwxrwxrwx root root 2014-04-13 18:31 APP -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2014-04-13 18:31 CAC -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2014-04-13 18:31 DTB -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2014-04-13 18:31 LNX -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2014-04-13 18:31 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2014-04-13 18:31 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2014-04-13 18:31 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2014-04-13 18:31 TMP -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2014-04-13 18:31 UDA -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2014-04-13 18:31 USP -> /dev/block/mmcblk0p7
[email protected]:/ #
key line:
Code:
lrwxrwxrwx root root 2014-04-13 18:31 LNX -> /dev/block/mmcblk0p3
grab the boot image:
Code:
cat /dev/block/mmcblk0p3 > /sdcard/boot.img
load it in archikitchen: http://forum.xda-developers.com/showthread.php?t=2597220
create a barebones project, put the boot.img in the project folder, unpack. gives us:
Code:
./kernel
./kernel/boot.img-cmdline
./kernel/boot.img-kerneloff
./kernel/boot.img-zImage
./kernel/ramdisk
./kernel/ramdisk/ueventd.goldfish.rc
./kernel/ramdisk/init.nv_dev_board.usb.rc
./kernel/ramdisk/proc
./kernel/ramdisk/data
./kernel/ramdisk/init.rc
./kernel/ramdisk/init.mojo.rc
./kernel/ramdisk/ueventd.mojo.rc
./kernel/ramdisk/system
./kernel/ramdisk/sys
./kernel/ramdisk/init.usb.rc
./kernel/ramdisk/init
./kernel/ramdisk/default.prop
./kernel/ramdisk/sbin
./kernel/ramdisk/sbin/watchdogd
./kernel/ramdisk/sbin/ueventd
./kernel/ramdisk/sbin/adbd
./kernel/ramdisk/init.trace.rc
./kernel/ramdisk/fstab.mojo
./kernel/ramdisk/dev
./kernel/ramdisk/init.qvs.rc
./kernel/ramdisk/init.tf.rc
./kernel/ramdisk/init.goldfish.rc
./kernel/ramdisk/ueventd.rc
./kernel/boot.img-tagsoff
./kernel/boot.img-ramdiskoff
./kernel/boot.img-ramdisk.gz
./kernel/boot.img-base
./kernel/boot.img-pagesize
./META-INF
./META-INF/com
./META-INF/com/google
./META-INF/com/google/android
./META-INF/com/google/android/update-binary
./META-INF/com/google/android/updater-script-85_USER
./META-INF/com/google/android/updater-script-10_SYMLINKS
./META-INF/com/google/android/updater-script-99_TAIL
./META-INF/com/google/android/updater-script-90_KERNEL
./META-INF/com/google/android/updater-script-80_EXEC
./META-INF/com/google/android/updater-script-91_MODEM
./META-INF/com/google/android/updater-script-00_HEAD
./META-INF/com/google/android/updater-script-20_PERMISSIONS
./META-INF/com/google/android/updater-script
./system
./boot.img
Replace
Code:
./kernel/boot.img-zImage
with a new built kernel, repack the boot image, and you can try to boot it with fastboot without killing anything:
Code:
fastboot boot newboot.img
Should work. I will experiment in a few days when I get more time, perhaps.
vostok4 said:
@gwaldo if you wanted to flash a custom kernel this is what I would do:
...
Should work. I will experiment in a few days when I get more time, perhaps.
Click to expand...
Click to collapse
Hi vostok4, thanks for the reply.
I used the zip config from the mojo and use my kernel with the extracted initramfs from the boot.img in mojo-signed-ota-MO0202-WW.zip firmware update.
./fastboot-linux -i 0x0738 boot zImage.gwald initramfs.cpio.gz
Click to expand...
Click to collapse
It boots fine and can confirm it booted the kernel via google's setting.
I add more FS (NTSF/exfat write) support in the kernel but I'm not familiar with androids permissions.
Just cautious with it.
It would be nice if there was a system recovery image so if we made a mistake we can reset it to factory.
I kinda left it there for a while.. not sure what else to add
From a recovery standpoint with the kernel, you already have the boot.img from the update, so you can always boot that... And the device auto goes into fastboot for you, so I think a recovery from every brick should be possible.
Words are cheap though
vostok4 said:
From a recovery standpoint with the kernel, you already have the boot.img from the update, so you can always boot that... And the device auto goes into fastboot for you, so I think a recovery from every brick should be possible.
Words are cheap though
Click to expand...
Click to collapse
Oh I meant doing something wrong on the filesystem, there's no rom/image for it , NAND I think it's called, the Android OS partition.
Like the guy that changed his permissions and made his entire MOJO readonly.. I think the only fix is the reflashing.
I did post about a guy who found the recovery menu on the MOJO
http://www.freaktab.com/showthread.php?12075-FOUND-MAD-CATZ-M-O-J-O-RECOVERY-MENU
So, that could work, haven't tried..
gwaldo said:
Oh I meant doing something wrong on the filesystem, there's no rom/image for it , NAND I think it's called, the Android OS partition.
Like the guy that changed his permissions and made his entire MOJO readonly.. I think the only fix is the reflashing.
I did post about a guy who found the recovery menu on the MOJO
http://www.freaktab.com/showthread.php?12075-FOUND-MAD-CATZ-M-O-J-O-RECOVERY-MENU
So, that could work, haven't tried..
Click to expand...
Click to collapse
I think working with similar key combinations to enable nvidia recovery mode is more important. That way with nvflash we can make a copy of a clean install, and always be able to flash it back. My mojo always goes to this mode when I try the fastboot method, but it might be a special unit
Can I ask you which toolchain you used / which guide you followed? I'm following the guide at http odroid.us/mediawiki/index.php?title=Step-by-step_Cross-compiling_a_Kernel but I'm having some problem (the compiled modules wind up being armv5 instead of armv7) and I'm noob at cross compiling.
paulatz said:
Can I ask you which toolchain you used / which guide you followed? I'm following the guide at http odroid.us/mediawiki/index.php?title=Step-by-step_Cross-compiling_a_Kernel but I'm having some problem (the compiled modules wind up being armv5 instead of armv7) and I'm noob at cross compiling.
Click to expand...
Click to collapse
Looks like how I did it, I use mint linux
i don't have much of a cheap sheet, but I'll post it when I get on my PC.
gwaldo said:
Looks like how I did it, I use mint linux
i don't have much of a cheap sheet, but I'll post it when I get on my PC.
Click to expand...
Click to collapse
Don't worry, I have managed to do it using the official ndk from google (I'll post the details if someone ask for them when I can find the time).
I have compiled uvcvideo.ko, but it still is not working (uvcvideo: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)), but I do not want to hijack you thread. I'll open a specific one if I can find the time to work on the issue for real.
Just for more information here, I compile on ArchLinux and use the following make line:
Code:
$ CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make
With the following packages from the AUR (kernel headers package was modified to get the correct version):
Code:
arm-linux-gnueabi-binutils 2.24-1
arm-linux-gnueabi-eglibc 2.18-1
arm-linux-gnueabi-gcc 4.8.2-1
arm-linux-gnueabi-linux-api-headers 3.4.35-1
paulatz said:
Don't worry, I have managed to do it using the official ndk from google (I'll post the details if someone ask for them when I can find the time).
I have compiled uvcvideo.ko, but it still is not working (uvcvideo: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)), but I do not want to hijack you thread. I'll open a specific one if I can find the time to work on the issue for real.
Click to expand...
Click to collapse
It's not my thread, but here's what I do:
Mint Linux 14 (i know its old)
I downloaded the build chains:
https://github.com/DooMLoRD/android_prebuilt_toolchains/
Install extra utils:
sudo apt-get install -y build-essential kernel-package libncurses5-dev bzip2
Click to expand...
Click to collapse
Export env vars:
export CROSS_COMPILE=/home/-USER-/-DIR-/android_prebuilt_toolchains-master/arm-eabi-linaro-4.6.2/bin/arm-eabi-
export ARCH=arm
Click to expand...
Click to collapse
Prepare the kernel
make clean && make mrproper
Click to expand...
Click to collapse
extract the kernel from your MOJO kernel.zip and place in the kernel folder.
make your changes:
make menuconfig
Click to expand...
Click to collapse
Compile it:
make -j5
Click to expand...
Click to collapse
how to install cifs module
vostok4 said:
Alright, finally we have CIFS support on MJO.
Cross compiled on ArchLinux from the sources posted by Rich, config pulled from /proc/config.gz and just compiled the CIFS+md4 module.
Works great here:
Code:
//10.0.0.11/vault 3.6T 2.9T 709.1G 81% /mnt/shell/emulated/0/vault
Make sure you have root, insmod md4.ko, insmod cifs.ko and enjoy! I'm using this to access my MP3s for aMPD so that my Mojo can act as my stereo too.
*edit* also make sure you have busybox installed in order to mount, and pass a username option. ie:
Code:
busybox mount -ousername=guest //1.1.1.1/share /sdcard/share
Click to expand...
Click to collapse
sorry, bui I don't understand how install the cifs module -cifs-module-kernel-3.4.35.zip-
Could anyone support me, please
darkodarko said:
sorry, bui I don't understand how install the cifs module -cifs-module-kernel-3.4.35.zip-
Could anyone support me, please
Click to expand...
Click to collapse
What are you doing exactly? Which result do you expect? Which result do you get instead?
cheers
paulatz said:
What are you doing exactly? Which result do you expect? Which result do you get instead?
cheers
Click to expand...
Click to collapse
I want connect my mojo with my nas through cifs and mount a specific folder.
I rooted mojo whit MMM MoDaCo Mod.
but I dont have any idea how use the cifs-module-kernel-3.4.35.zip file
Thanks in advance
You need to put the archive somewhere on your MOJO, and run the following as root:
insmod md4.ko
insmod cifs.ko
Then you can mount using either mine or gwaldo's mount line.
I can write up how I got it to automount later, in order for the mount to be accessible to every application it has to be outside of /sdcard, I did mine in /mnt/share, and have it mounting on boot (in an ugly method).
darkodarko said:
I want connect my mojo with my nas through cifs and mount a specific folder.
I rooted mojo whit MMM MoDaCo Mod.
but I dont have any idea how use the cifs-module-kernel-3.4.35.zip file
Thanks in advance
Click to expand...
Click to collapse
You need to extract the content of the zip file onto a usb drive/MICROSD and copy the files to the MOJO.
Then follow vostok4's instructions
in busybox (with root permission)
cd to-where-you-put your .ko files (you need to know linux command line)
then run
insmod md4.ko
insmod insmod cifs.ko
Then you need to mount it as below:
vostok4 said:
Alright, finally we have CIFS support on MJO.
Make sure you have root, insmod md4.ko, insmod cifs.ko and enjoy! I'm using this to access my MP3s for aMPD so that my Mojo can act as my stereo too.
*edit* also make sure you have busybox installed in order to mount, and pass a username option. ie:
Code:
busybox mount -ousername=guest //1.1.1.1/share /sdcard/share
Click to expand...
Click to collapse
PS: you'll need to do this EVERYTIME you reboot/restart MOJO.
PS2: I haven't done this my self but that's my understanding.
OK, in order to not do it everytime manually, I have something like this (note the sleep 30 is ugly but I didn't bother writing a method to trigger on network connectivity). This requires busybox installed (I use this one: https://play.google.com/store/apps/details?id=stericson.busybox)
If you aren't comfortable with manually mucking around, then I'm not sure what to tell you to This is assuming you have root and busybox installed.
In order to create files under /system and /etc you need to mount /system as read-write:
Code:
$ su
# mount -orw,remount /system
# cp /sdcard/install-recovery.sh /etc/
# chmod 777 /etc/install-recovery.sh
# mount -oro,remount /system
That would copy install-recovery.sh from the sdcard (we need to do this because we have a secure boot and can't adb push to /etc). It also sets the file as executable (we want that). SO, these are the files you need:
/etc/install-recovery.sh (needs chmod 777)
Code:
#!/system/bin/sh
# fake init.d support
/system/bin/sysinit
/system/bin/sysinit (needs chmod 777)
Code:
#!/system/bin/sh
# fake init.d support
# the script below is what i use to mount my cifs share
/system/bin/sh '/system/etc/init.d/99vault'
# these are commented out, but run-parts would be the proper way to use the init.d folder
# however I couldn't get it to work on my mojo, so i just call the script directly
#export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
#run-parts /system/etc/init.d
/etc/init.d/99vault (or /system/etc/init.d/99vault if you expand the symlink) (needs chmod 777)
Code:
#!/system/bin/sh
/system/xbin/busybox mount -orw,remount /
# sometimes disappears on reboot, lets just create the mount folder to be safe
/system/xbin/busybox mkdir /mnt/vault
/system/xbin/busybox mount -oro,remount /
# mount our cifs module
/system/xbin/busybox insmod /system/etc/cifs/md4.ko
/system/xbin/busybox insmod /system/etc/cifs/cifs.ko
# wait for network to come online
sleep 30
# mount the actual share
/system/xbin/busybox mount -ousername=guest //10.0.0.11/vault /mnt/vault
That will get you mounted after each reboot without fail, at least in my experience.
did someone managed to make it work on cm 12.1?
I have been trying to follow instructions for rooting my Remix OS partition, but have been unable because I cannot find a system.img or system.sfs file to patch. My installation is on an ext4 partition on the internal SSD of my Acer Aspire 1810TZ; the Remix version is 2.0 201. (I haven't been able to update this to 202; that problem is in another thread.) The Remix partition has a folder entitled "android-2016-03-15" and another, "lost+found" (the latter hidden). Within the Android folder, there are initrd.img and ramdisk.img files and also a system folder, but no system.img or system.sfs files; not even within the system folder. Not sure where to go from here, other than to reinstall 2.0 202 from scratch to get a rooted installation. Is there something obvious that I'm missing? Incidentally, I have a Ubuntu partition, and the this where I downloaded and uncompressed the RemixRoot folder I got from the xda site.
trentfox said:
I have been trying to follow instructions for rooting my Remix OS partition, but have been unable because I cannot find a system.img or system.sfs file to patch. My installation is on an ext4 partition on the internal SSD of my Acer Aspire 1810TZ; the Remix version is 2.0 201. (I haven't been able to update this to 202; that problem is in another thread.) The Remix partition has a folder entitled "android-2016-03-15" and another, "lost+found" (the latter hidden). Within the Android folder, there are initrd.img and ramdisk.img files and also a system folder, but no system.img or system.sfs files; not even within the system folder. Not sure where to go from here, other than to reinstall 2.0 202 from scratch to get a rooted installation. Is there something obvious that I'm missing? Incidentally, I have a Ubuntu partition, and the this where I downloaded and uncompressed the RemixRoot folder I got from the xda site.
Click to expand...
Click to collapse
As you are using ext4, instead of a system.img or system.sfs (which are ext4 files - sfs one being compressed) you have a system folder.
This setup breaks ota (afaik) as it depends on there being a system.img.
If you want system root (I guess you are using 64bit), either add the root files to System folder or go the system-less root way (/data/su.img and altered initrd/ramdisk.img).
HypoTurtle said:
As you are using ext4, instead of a system.img or system.sfs (which are ext4 files - sfs one being compressed) you have a system folder.
This setup breaks ota (afaik) as it depends on there being a system.img.
If you want system root (I guess you are using 64bit), either add the root files to root folder or go the system-less root way (/data/su.img and altered initrd/ramdisk.img).
Click to expand...
Click to collapse
Thanks for the reply, HypoTurtle. Just to make sure I understand, what I would do is just add the rooted system.img file to the root of my installation? If I did this, would I have to change anything in my grub boot parameters for Remix OS? (I put them in by hand because grub2 from Ubuntu doesn't pick up Remix.)
With regard to the system-less root way, I don't have an su.img file in my /data folder. Also, where would the altered initrd.img and ramdisk.img files come from? Looking at the RemixRoot folder I downloaded and uncompressed, there is an su folder but no su.img file that I can see, nor an initrd.img or ramdisk.img file.
Thanks in advance for clarifying this. I am a beginner-intermediate Linux user, so I apologize if I'm missing something obvious to a more advanced user.
trentfox said:
Thanks for the reply, HypoTurtle. Just to make sure I understand, what I would do is just add the rooted system.img file to the root of my installation? If I did this, would I have to change anything in my grub boot parameters for Remix OS? (I put them in by hand because grub2 from Ubuntu doesn't pick up Remix.)
With regard to the system-less root way, I don't have an su.img file in my /data folder. Also, where would the altered initrd.img and ramdisk.img files come from? Looking at the RemixRoot folder I downloaded and uncompressed, there is an su folder but no su.img file that I can see, nor an initrd.img or ramdisk.img file.
Thanks in advance for clarifying this. I am a beginner-intermediate Linux user, so I apologize if I'm missing something obvious to a more advanced user.
Click to expand...
Click to collapse
I'll try to be as clear as possible feel free to ask for clarification.
Depends on what your grub command is. Initrd.img looks for system in the order;
1. Partition for system
2. System.sfs
3. System.img
4. System folder
So adding a pre-rooted system.img should take precidence over the folder (but you can delete it if you want).
What you could do with the system folder is add in the root files -- there's a rootx.sh script somewhere, look at it and ignore the mount/unmount of system.img
The system-less root stuff I have here near the top
It's an alternative to having to add stuff to system.img/system.
HypoTurtle said:
I'll try to be as clear as possible feel free to ask for clarification.
Depends on what your grub command is. Initrd.img looks for system in the order;
1. Partition for system
2. System.sfs
3. System.img
4. System folder
So adding a pre-rooted system.img should take precidence over the folder (but you can delete it if you want).
What you could do with the system folder is add in the root files -- there's a rootx.sh script somewhere, look at it and ignore the mount/unmount of system.img
The system-less root stuff I have here near the top
It's an alternative to having to add stuff to system.img/system.
Click to expand...
Click to collapse
Thanks again for this. Here is my grub entry for Remix:
Code:
splashimage=/grub/android-x86.xpm.gz
set root='hd0,9'
linux /android-2016-03-15/kernel quiet root=/dev/ram0 androidboot.hardware=remix_x86_64 SRC=/android-2016-03-15
initrd /android-2016-03-15/initrd.img
If I add the system.img file to the root level of the partition, would the grub entry have to be changed to boot from it. Also when you say I can delete "it" if I want, you aren't referring to the System folder are you? It has a bunch of folders in it, including /etc, /bin, /lib, /lib64.
When you state above that I can add in the root files to the system folder, are you referring to the su folder in RemixRoot? Or the contents of that folder or something else? Perhaps what you mean are system.img and root.img files. I see that these are referred to at the end of the rootx.sh file.
trentfox said:
Thanks again for this. Here is my grub entry for Remix:
Code:
splashimage=/grub/android-x86.xpm.gz
set root='hd0,9'
linux /android-2016-03-15/kernel quiet root=/dev/ram0 androidboot.hardware=remix_x86_64 SRC=/android-2016-03-15
initrd /android-2016-03-15/initrd.img
If I add the system.img file to the root level of the partition, would the grub entry have to be changed to boot from it. Also when you say I can delete "it" if I want, you aren't referring to the System folder are you? It has a bunch of folders in it, including /etc, /bin, /lib, /lib64.
When you state above that I can add in the root files to the system folder, are you referring to the su folder in RemixRoot? Or the contents of that folder or something else? Perhaps what you mean are system.img and root.img files. I see that these are referred to at the end of the rootx.sh file.
Click to expand...
Click to collapse
Grub should be fine; yes you can delete System folder it is just system.img unpacked; if you open it as an archive you'll see for yourself.
And if you look at rootx.sh and modify so it works with system folder:
Code:
#!/bin/bash
#chmod 0644 system.img
#mount -o loop,rw -t ext4 system.img tmp/
mv system tmp
mkdir tmp/app/SuperSU
chmod 0755 tmp/app/SuperSU
cp su/Superuser.apk tmp/app/SuperSU/SuperSU.apk
chmod 0644 tmp/app/SuperSU/SuperSU.apk
chcon --reference=tmp/bin/reboot tmp/app/SuperSU/SuperSU.apk
if [ ! -e tmp/etc/install-recovery_original.sh ]; then
if [ -e tmp/etc/install-recovery.sh ]; then
mv tmp/etc/install-recovery.sh tmp/etc/install-recovery_original.sh
fi
fi
if [ ! -e tmp/bin/install-recovery_original.sh ]; then
if [ -e tmp/bin/install-recovery.sh ]; then
mv tmp/bin/install-recovery.sh tmp/bin/install-recovery_original.sh
fi
fi
cp su/install-recovery.sh tmp/etc/install-recovery.sh
chmod 0755 tmp/etc/install-recovery.sh
chcon --reference=tmp/bin/toolbox tmp/etc/install-recovery.sh
ln -s /system/etc/install-recovery.sh tmp/bin/install-recovery.sh
cp su/su tmp/xbin/su
chmod 0755 tmp/xbin/su
chcon --reference=tmp/bin/reboot tmp/xbin/su
mkdir tmp/bin/.ext
chmod 0755 tmp/bin/.ext
cp su/su tmp/bin/.ext/.su
chmod 0755 tmp/bin/.ext/.su
chcon --reference=tmp/bin/reboot tmp/bin/.ext/.su
cp su/su tmp/xbin/daemonsu
chmod 0755 tmp/xbin/daemonsu
chcon --reference=tmp/bin/reboot tmp/xbin/daemonsu
cp su/su tmp/xbin/sugote
chmod 0755 tmp/xbin/sugote
chcon --reference=tmp/bin/app_process32 tmp/xbin/sugote
cp su/supolicy tmp/xbin/supolicy
chmod 0755 tmp/xbin/supolicy
chcon --reference=tmp/bin/reboot tmp/xbin/supolicy
cp su/libsupol.so tmp/lib64/libsupol.so
chmod 0644 tmp/lib64/libsupol.so
chcon --reference=tmp/bin/reboot tmp/lib64/libsupol.so
if [ ! -e tmp/bin/app_process64_original ]; then
if [ -e tmp/bin/app_process64 ]; then
mv tmp/bin/app_process64 tmp/bin/app_process64_original
fi
fi
chmod 0755 tmp/bin/app_process64_original
chcon --reference=tmp/bin/app_process32 tmp/bin/app_process64_original
if [ -e tmp/bin/app_process64_original ]; then
cp tmp/bin/app_process64_original tmp/bin/app_process_init
fi
chmod 0755 tmp/bin/app_process_init
chcon --reference=tmp/bin/reboot tmp/bin/app_process_init
rm tmp/bin/app_process
ln -s /system/xbin/daemonsu tmp/bin/app_process
ln -s /system/xbin/daemonsu tmp/bin/app_process64
if [ -e tmp/etc/init.d ]; then
cp su/99SuperSUDaemon tmp/etc/init.d/99SuperSUDaemon
chmod 0755 tmp/etc/init.d/99SuperSUDaemon
chcon --reference=tmp/bin/reboot tmp/etc/init.d/99SuperSUDaemon
fi
mv tmp system
Should run and root the system folder.
HypoTurtle said:
Grub should be fine; yes you can delete System folder it is just system.img unpacked; if you open it as an archive you'll see for yourself.
And if you look at rootx.sh and modify so it works with system folder:
Code:
#!/bin/bash
...
Should run and root the system folder.[/QUOTE]
So could this be as easy as making a new rootx.sh file using your code, putting that into my Remix partition (root level, not in system folder) and running the rootx.sh file, all from my Ubuntu partition? Or alternatively, copying over the system folder from Remix partition into the RemixRoot folder in Ubuntu, modifying rootx.sh file, running it, and then replacing the modified system folder into the Remix partition?
Click to expand...
Click to collapse
trentfox said:
So could this be as easy as making a new rootx.sh file using your code, putting that into my Remix partition (root level, not in system folder) and running the rootx.sh file, all from my Ubuntu partition? Or alternatively, copying over the system folder from Remix partition into the RemixRoot folder in Ubuntu, modifying rootx.sh file, running it, and then replacing the modified system folder into the Remix partition?
Click to expand...
Click to collapse
Yea:
system folder
su folder
rootx.sh script
Then run rootx.sh; it'll rename system folder to tmp instead of mounting system.img to tmp.
Then it'll add the files in the right places, with symlinks and right permissions.
Once done it'll rename tmp folder to system.
These things never so simple when you don't know what you're doing. I made the mistake of copying over the /tmp folder as well. Ran the script; got errors. Wouldn't boot into remix from grub. Went in and deleted initrd.img, ramdisk.img and /tmp and ran the script again. Got more errors. Cannot reboot into Remix OS; it was looking for an initrd.img that wasn't recreated. Within the system folder there is a locked system folder that I don't think was there before.
Suggestions? Should I just start over again with the newest version of Remix OS?
I did end up starting over; this time with the hacked version 202. I would have preferred to have done the rooting myself, but now I have a rooted version and I can access the other partitions on my drive. Thanks anyway, HypoTurtle; I appreciated the help.
OTA update and Rooting are possible for ext4 installations of Remix OS
In thread Remix OS on Hard Drive or Virtual Machine - Installation and OTA Update you'll find a solution of your problems:
- Performing an OTA update for an ext4 installation with /sytem folder
- Rooting of an ext4 installation with /system folder
The bad news is: The OTA update seems to work for USB flash drive installations only
But there are good news: The OTA updated USB flash drive can be used for updating installations in ext4 file systems.
remixtester said:
In thread Remix OS on Hard Drive or Virtual Machine - Installation and OTA Update you'll find a solution of your problems:
- Performing an OTA update for an ext4 installation with /sytem folder
- Rooting of an ext4 installation with /system folder
The bad news is: The OTA update seems to work for USB flash drive installations only
But there are good news: The OTA updated USB flash drive can be used for updating installations in ext4 file systems.
Click to expand...
Click to collapse
Is that a system folder, or a system partition?
I read through you guide this morning and it's very well thoughtout and detailed; any chance of adding the system-less root method to the bottom it might cut out a few steps.
HypoTurtle said:
Is that a system folder, or a system partition?
I read through you guide this morning and it's very well thoughtout and detailed; any chance of adding the system-less root method to the bottom it might cut out a few steps.
Click to expand...
Click to collapse
It is a system folder - have a look at this image:
http://postimage.org/index.php?lang=german
"Rooting" is just copying the folder su and the file remixroot.sh next to the folders /data and /system and executing remixroot.sh.
In order to do that you have to boot your system with PartedMagic - that's all. I think, it's not too complicated.
remixtester said:
It is a system folder - have a look at this image:
http://postimage.org/index.php?lang=german
"Rooting" is just copying the folder su and the file remixroot.sh next to the folders /data and /system and executing remixroot.sh.
In order to do that you have to boot your system with PartedMagic - that's all. I think, it's not too complicated.
Click to expand...
Click to collapse
Is sda5 not a system partion? (partition > .img/.sfs > folder if you have all 3)
System-less is replace initrd.img (and ramdisk.img) and place a su.img into data folder i.e. no script to run so could be done without PartedMagic (using ALTF1 to access /data).
HypoTurtle said:
Is sda5 not a system partion? (partition > .img/.sfs > folder if you have all 3)
System-less is replace initrd.img (and ramdisk.img) and place a su.img into data folder i.e. no script to run so could be done without PartedMagic (using ALTF1 to access /data).
Click to expand...
Click to collapse
sda2 is an extended partition, and sda5 is a linux-swap partition. In case Remix OS needs a swap like other linux operating systems it can be used. My image shows the ext4 partition sda1 only which contains the folders of the Remix OS installation.
I prefer the script because I do not have to deal with "black boxes" initrd.img, ramdisk.img, and su.img. Where do I get these img files from?
remixtester said:
sda2 is an extended partition, and sda5 is a linux-swap partition. In case Remix OS needs a swap like other linux operating systems it can be used. My image shows the ext4 partition sda1 only which contains the folders of the Remix OS installation.
I prefer the script because I do not have to deal with "black boxes" initrd.img, ramdisk.img, and su.img. Where do I get these img files from?
Click to expand...
Click to collapse
Ah, I think I was reading too much into your post here at the top of the page; you aren't saying direct OTA of system folder install is possible but update OTA of stock then use that to update the installed version right...
In that vain; from original install; renaming/removing system folder, copying system.img; booting into RemixOS -- OTA should apply, then boot into PartedMagic etc. and unpack system.img into system folder and done.
.imgs I made/modified myself; here at the top; based on how a SuperSU script would make it. They are based on v201 .imgs I think but the difference between them and the 202's are minimal.
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