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
Related
V10K root guide (for advanced windows and linux users)
Download requiement apps:
LGExtract-0.2.1
DZDecryptor_v1.0b
UPDATE-SuperSU-v1.10
Download V10K firmware:
http://lg-phone-firmware.com/index.php?id_mod=13
I. Unpack KDZ file
1. Unpack LGExtract-0.2.1.zip to C:/LGExtract-0.2.1
2. Copy V10K_00.kdz file to extracted folder
3. Open command prompt
cd C:/LGExtract-0.2.1
LGExtract -kdz V10K_00.kdz
4. Unpack V10K_00.cab with WinRAR
5. Rename LGP700AT-00-V10k(...).dz to V10K_00.dz
II. Unpack DZ file
1. Unpack DZDecryptor_v1.0b to C:/DZDecryptor_v1.0b
2. Copy V10K_00.dz to C:/DZDecryptor_v1.0b
3. Move V10K_00.dz file on DZDecrypt.exe
4. Open command prompt
cd C:/DZDecryptor_v1.0b
dzdecrypt V10K_00.dz
5. Now you have "system.img.ext" file
III. Mount and edit system image under linux (ubuntu)
1.Copy "system.img.ext" to desktop
2. Open command prompt
sudo mkdir /mnt/system/
sudo mount -o loop /home/ubuntu/Desktop/system.img.ext /mnt/system
3. Now unpack system folder from "UPDATE-SuperSU-v1.10.zip" to desktop
sudo cp /home/ubuntu/Desktop/system/xbin/su /mnt/system/xbin
sudo cp /home/ubuntu/Desktop/system/app/Superuser.apk /mnt/system/app
sudo chown 0.0 /mnt/system/xbin/su
sudo chmod 06755 /mnt/system/xbin/su
sudo chown 0.0 /mnt/system/app/Superuser.apk
sudo chmod 644 /mnt/system/app/Superuser.apk
sudo umount /mnt/system
Now replace system.img.ext4 file under flashing nad enjoy rooted phone
Move your system.img.ext4 to C:\ProgramData\LGMOBILEAX\ and start updating V10K_00.kdz
Wait untill KDZ create Phone folder and create other system.img.ext4. When file reach 483MB move file to desktop
Then move your system.img.ext4 from C:\ProgramData\LGMOBILEAX\ to C:\ProgramData\LGMOBILEAX\Phone\
Wait to end update
Thanks, I'll try that out asap!
One thing, though - are you sure your chmod invocation is correct? "755" octal doesn't set the SUID bit on the executable; don't you need "4755" (for /mnt/system/bin/su) there?
Where do I get the KDZ file from - is it possible to copy that off/extract it out of my phone somehow? If I have to download it from some filehosting site, does it matter which version I get? (My phone is unbraded, bought without simlock or a contract, and I'd like to retain that status.)
This is method for rooting all (branded, unbranded, other country) V10K firmware (latest version)
Firmware download link added to thread
Linux terminal commands corrected
OK, I prepared the filesystem image like you said and planted the binaries with SETUID/SETGID bits set and owned by root:root. Everything went fine so far - pardon my ignorance when I ask, though - how do I get that filesystem Image into a "kdz" file in order to flash it onto the phone now?
You must flash system image like custom rom (by swap system image when kdz file is flashed)
With DZCreator_v1.0c maybe we can create dz file (next compress into cab and encrypt into kdz) but we don't have some info about original dz file (like dz split size, sub files offset etc)
That superuser.apk , the permission are 655, is that correct permission?
chmod 655 are set to rw-r-xr-x , meanwhile system app must set to rw-r--r-- (644)
Anyone have idea how to add init.d and script to install busybox and delete itself ?
I got V20A jellybean rooted
Loyal AMLOGIC fanboy here messing around with a CS918 for only the third time . . . .
I am trying to run a shell to unpack an archive, there's a smali file that downloads the archive to /sdcard/Android/data, this part works fine.
The SH should then unpack to the same directory, this part fails.
My question is, does the directory path format require changing depending on your action (even though it's all going to the same place)?
I unpacked the rom's IMG file to see how other scripts are interacting with the filesystem and am seeing the following paths used by different files - but they all go to the same place:
/data/user/0/
/mnt/sdcard/Android/data/
/data/data/
Here is what the .sh file is trying to accomplish:
tar -xf /sdcard/Android/data/settings.tar -C /sdcard/Android/data/
rm /sdcard/Android/data/settings.tar
For the record, this works flawlessly on AMLOGIC using the path:
/storage/emulated/legacy/Android/data
Just incase anyone comes across this via searching:
The correct path is /mnt/sdcard/Android/data/ - but you have to run the batch as root
Hi, I open this thread because I mounted system.img (unpack it), maque some changes and repack it. Does not work, but the concept do (the rmxroot script I found in the web use this concept)
To do that I follow these steps:
1) Copy system.img to a folder in my ubuntu partition.
2) Make a backup.
3) Mount the system.img with:
sudo chmod 0644 system.img (giving permisions)
and
sudo mount -o loop,rw -t ext4 system.img tmp/
4) Make than changes (the rmxroot copi the su binaries and do other stuff)
The changes and adds can be made it graphically with nautilus.
5) Repack the system.img again with:
umount tmp
Please, if someone do something like that coment, so all can learn about.
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