Manually Installing RemixOS-Marshmallow [NEW LZ4 System.sfs Extraction] - Remix OS for PC

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

Related

Xposed on RemixOS

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

Cannot root internal installation - no system.img file

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.

Help needed to unpack/repack Android boot.img & system.img

Hello
I am working with a Nanopi Fire3 board. I need to change the boot logo and boot animation.
With this Android Lollipop :
112.124.9.243/dvdfiles/S5P6818/images-for-eflasher/android-lollipop-images.tgz
Click to expand...
Click to collapse
If I unpack with the following method, the new image has a completely different size and does not boot.
Code:
apt install android-tools-fsutils
simg2img rootfs.img r.img
mount -t ext4 -o loop r.img /mnt
… To Change Something …
umount /mnt
img2simg r.img rootfs.img
I have tried to root the device, no tool found online works.
I have tried to unpack/repack, no tool found online works.
Tools like mkbootimg just copies the img file (it doesn't extract anything)
I am also trying to compile android completely, and it fails in the middle of the build process.
Would you have any advice please? I have run out of options
Thank you :good:

modifications in system.img ignored after flashing

Hi All,
I slightly modified system.img (details below), flash it, boot and none of my changes can be seen. It would be great if some expert could give me a hint on what I oversee here.
In detail: the device is a Sony XA2 and it was flashed successfully with AOSP Oreo 8.1 before. My approach worked on another mobile with 4.4 before, so I copied it.
What I've done: I unpacked the original system.img with simg2img, mounted it, modified a simple text file by adding a comment line (nothing crucial), pack it again with ext2simg and flash the new file. The commands were
> simg2img system.img system_unfold.img
> sudo mount -t ext4 -o loop system_unfold.img system
# modify...
> ext2simg -v system_unfold.img system_new.img
and then flashed it back via
> fastboot flash system system_new.img
Flashing worked in general, e.g. for AOSP Oreo 8.1. (also to slot A). Only the modified system_new.img does not lead to different files in /system
Any ideas?
Many Thanks!

Dumping stock firmware to use for lineage/custom build.

Three .sin files from stock are needed: vendor, kernel, system.
Unsin while in .sin folder:
-d to extract all files in working directory
./unsin.exe -d
You will end up with one .img file and two .ext4 files.
kernel_X-FLASH-ALL-C93B.img
system_X-FLASH-ALL-C93B.ext4
vendor_X-FLASH-ALL-C93B.ext4
While on the linux side of things, mount the .ext4 files using: mount -o loop
make sure folder 'ExtractFirm'(name it whatever you want) exists before hand. Folder closing then opening may be needed
sudo mount -o loop system_X-FLASH-ALL-C93B.ext4 ~/ExtractFirm/
Don't forget to chown the files as yours:
sudo chown -R username:group ExtractFirm/
copy the necessary files(into Firmware_Dump folder), then issue the command below when done with the mount:
sudo umount ~/ExtractFirm
--------------------
Find AIK-Linux in the dev sections on xda
Copy kernel_X*.img to AIK extracted folder then issue:
./unpackimg.sh kernel_X-FLASH-ALL-C93B.img
Own your files:
sudo chown -R username:group ramdisk/
Then copy(into Firmware_Dump folder) the contents of ram disk, if they're some errors(usually because of sym. links) with copying them, hit skip, otherwise merge all, replace all.
Lastly, mount vendor:
sudo mount -o loop vendor_X-FLASH-ALL-C93B.ext4 ~/ExtractFirm/
The kernel copy you did previously gave you an empty vendor folder. Copy all contents of the vendor mount into this empty vendor folder(within Firmware_Dump folder).
Dont forget:
sudo umount ~/ExtractFirm
Now that you have extracted firmware contents, you can run extract-files.sh for lineage/custom build:
~/lineageos/device/sony/poplar_dsds$ ./extract-files.sh ~/location of extracted contents/
These are just reference notes for everyone, I'm sure I'll need them again.
thanks @derf elot
great, thanks for the write up we can redirect people here if the question of how to extract files comes up again - which I'm sure it will
Sent from my Sony Xperia XZ1 Compact using XDA Labs
derf elot said:
great, thanks for the write up we can redirect people here if the question of how to extract files comes up again - which I'm sure it will
Sent from my Sony Xperia XZ1 Compact using XDA Labs
Click to expand...
Click to collapse
Indeed it will.
Great guide! I was thinking about automating stuff, but e.g. the copy works best when not done from the shell but from the file manager. The ignore, replace and merge all works perfect there.
Before anyone tries, here my failed attempts:
- Using 7z to extract the ext4 files, works somehow but fails to keep symlinks. But it would be faster...
- `cp -a` doesn't replace symlinks by actual folders and has some errors shown and some files/folders removed. Not sure if safe... So use file manager
- When using a VM make sure the AIK and the final folder are on ext4 filesystems, not shared/mounted from Windows hosts. Avoids failures with symlinks shown as "permission denied"
Edit: Ok I had failures and got an update to the guide:
- Start with the kernel extraction
- Then extract system*.ext4 to the system folder inside the above folder
- Then extract vendor.*ext4 to the vendor folder inside the above folder

Categories

Resources