Related
Hey fellas!!!
This is my first real contribution to my xda friends .I happy to share with you guys the script to make ODIN flashable rom for ext4 devices.
First of all I would like to say that this script currently supports only International variants of sgs2,sgs3 and SG Note.This is because I own only Note (similar to s2) and my friend has s3 which I used to make s3 compatible.I can support any devices if you guys can give me the required data
So now into the topic
In order to work with the script,you need the following:
A PC/Laptop with linux installed either as dualboot or in vm
A rooted Phone which supported by the script.
A usb cable
And of course you need your brain
Apart from the hardware,you will also need:
A stock rom from which you need to take the following:
cache.img
modem.bin
hidden.img
and a custom kernel(zImage) of you choice.(recovery.img and boot.img in case of s3)
Now download the script and do the following:
Extract ODIN-script.tar anywhere.
Run first_time.sh (Needed Only for the first time)
Put the above collected .img's,.bin and/or zImage inside ODIN-script directory
Connect your phone to PC/Laptop with usb debugging enabled.
Run the script and follow the instructions
Your Rom will be in the same directory in few mins
Note1:The Rom obtained by the above is not a full wipe rom.If you need to make it full wipe(factory reset),you need aditional empty data.img(for note/s2) or userdata.img(s3).I will upload data.img for Note.It "may" work on s2 too.But I havent tested.so its on your own risk
S3 users,I'm sorry I can help you .Because I dont know the size of /data partition to make an empty image.
Note2:You can always flash the rom with .pit and repartition.I have always used .pit to flash my rom.But still you are at your own risk.
Disclaimer:Do this at your own risk!!!I'm not responsible if you brick your phone.(Though you cannot if you do everything correctly )
Download link and changelog on next post.
And finally if you like my project and if you think you need to support me for future updates on this,Please do donate .And do not copy/edit/alter this work without my permission!!!
Download Links and changelogs
Changelog for v1:
Code:
[LIST]
[*]Initial release
[/LIST];)
Changelog for v2:
Code:
[LIST]
[*]Cleaned the code and redone entirely
[*]Added support for preload for some devices
[*]bug fixes
[/LIST]
Thanks to:
1.As-I9000 for zlibs and first_time.sh
vijai2011 said:
Reserved
Click to expand...
Click to collapse
Reserved!!!
really awesome...going to try now and let you know the feedback...
Ok...Thats good...Just an update...Dont add cache.img for now...It takes forever in recovery to flash....Found the issue and working on a fix
vijai2011 said:
Ok...Thats good...Just an update...Dont add cache.img for now...It takes forever in recovery to flash....Found the issue and working on a fix
Click to expand...
Click to collapse
thank you and i was about to test and i will refrain from doing that till you release the fix!
grgsiocl said:
thank you and i was about to test and i will refrain from doing that till you release the fix!
Click to expand...
Click to collapse
Hey...You can try it without cache.img as long as you have csc within you /system
But still if you have added cache.img,it will boot but only with couple of reboots and a looooong time in recovery
vijai2011 said:
Hey fellas!!!
Note1:The Rom obtained by the above is not a full wipe rom.If you need to make it full wipe(factory reset),you need aditional empty data.img(for note/s2) or userdata.img(s3).I will upload data.img for Note.It "may" work on s2 too.But I havent tested.so its on your own risk
[/COLOR]
Click to expand...
Click to collapse
If you needed FULL WIPE DATA - FACTORY RESET, you need to put the image cache file with the command wipe data...
as i9000 said:
If you needed FULL WIPE DATA - FACTORY RESET, you need to put the image cache file with the command wipe data...
Click to expand...
Click to collapse
Nope...instead I have added a empty data.img It will wipe off data...But didn't make it for s3 because I have heard s3 has /data and /sdcard combined.So if I make one for s3,it will wipe sdcard too.But need a confirmation on this
And I have fixed recovery issue too in v2 and it should be fine now.
Finally had a look on your script too.It also looks good.good job.nice work .May be we two can work together to make a kitchen???
Sent from my GT-N7000 using xda app-developers app
I used your script as guiding for customizing my own odin rom.
- I untarred my firmware.tar.md5
- $ simg2img system.img.ext4 system.raw
- $ sudo mount -t ext4 -o loop system.raw /tmp
I didn't change a thing and then repacked it
- make_ext4fs -s -l 512M -a system newsystem.img.ext4 /tmp
- chown 1000:1000 newsystem.img.ext4
- packed everything with $tar -H ustar -cvf out.tar *.img.* fat.bin
- signed the package md5sum -t out.tar >> out.tar
- mv out.tar out.tar.md5
I flashed it, had no problems, but after the flashing i see "failed to mount /system (invalid argument)
And as my system partition doesn't get mounted, i cant startup my phone.
Does anyone have a clue on what i could be doing wrong?
1bymany said:
I used your script as guiding for customizing my own odin rom.
- I untarred my firmware.tar.md5
- $ simg2img system.img.ext4 system.raw
- $ sudo mount -t ext4 -o loop system.raw /tmp
I didn't change a thing and then repacked it
- make_ext4fs -s -l 512M -a system newsystem.img.ext4 /tmp
- chown 1000:1000 newsystem.img.ext4
- packed everything with $tar -H ustar -cvf out.tar *.img.* fat.bin
- signed the package md5sum -t out.tar >> out.tar
- mv out.tar out.tar.md5
I flashed it, had no problems, but after the flashing i see "failed to mount /system (invalid argument)
And as my system partition doesn't get mounted, i cant startup my phone.
Does anyone have a clue on what i could be doing wrong?
Click to expand...
Click to collapse
If you did exactly what you posted,then,
1. You should not have got system.img.ext4 but system.img and so simg2img is simg2img system.img system.img.ext
2./temp in mount command would be your temp filesystem where system files are stored.Use a relative path like TempDir in your PWD
3. Are you sure the make_ext4fs line is correct?You said you used my script as reference and I have never used that command at all.Its like:
Code:
sudo ./mkuserimg.sh -s TempDir factoryfs.img ext4 ./temp 893386752B
(in mb is also fine)
where the numbers indicate the size of system partition in Bytes.Be sure to cd to ext4_utils before executing this command and should always be run as sudo as the mount is done as sudo.And donot include .ext4 at the end.Use just img.Works better.
4.again...chown should be sudo.As the img is owned by root and so you cannot chown it with basic user permissions.Simple user hierarchy
5.You did a blunder here in tar command if you put the original system.img and the newly packed img in the same directory.As the command will include all .img's which we donot want.
vijai2011 said:
If you did exactly what you posted,then,
1. You should not have got system.img.ext4 but system.img and so simg2img is simg2img system.img system.img.ext
2./temp in mount command would be your temp filesystem where system files are stored.Use a relative path like TempDir in your PWD
3. Are you sure the make_ext4fs line is correct?You said you used my script as reference and I have never used that command at all.Its like:
Code:
sudo ./mkuserimg.sh -s TempDir factoryfs.img ext4 ./temp 893386752B
(in mb is also fine)
where the numbers indicate the size of system partition in Bytes.Be sure to cd to ext4_utils before executing this command and should always be run as sudo as the mount is done as sudo.And donot include .ext4 at the end.Use just img.Works better.
4.again...chown should be sudo.As the img is owned by root and so you cannot chown it with basic user permissions.Simple user hierarchy
5.You did a blunder here in tar command if you put the original system.img and the newly packed img in the same directory.As the command will include all .img's which we donot want.
Click to expand...
Click to collapse
First of all, thanks for the reply.
second:
1. My phone is not rooted yet, it's a GT-S6500D aka Samsung galaxy tab. So I used a firmware.tar.md5 (that i have flashed to test and works)
and in this firmware.tar.md5 i have following files: boot.img, cache.img.ext4, fat.bin, hidden.img.ext4, recovery.img and system.img.ext4
So the system.img.ext4 wasn't a typo and the system.raw is just an arbitrary name i have chosen.
2. I don't get the mountpoint. Is this the mountpoint on the phone? of on my computer?
3. I have analysed the mkuserimg.sh script, and it is just a wrapper that flips the argument order. I have no clue why they made it..
So i doubt my problem would be in this line, but I will try, as i don't know what else can go wrong
4. chown should indeed be sudo, no doubt about that I just didn't type it here
5. I skipped this step a bit in the explanation, but i made the sure the directory only concluded the necessary files, naming the original files from step 1 or modified files.
6. I don't know if this could help, but if i unpack for example system.img.ext4 and repack it again, the new file will be bigger then the original one.. I was thinking maybe Samsung adjusted some things, but maybe i need some more arguments in my make_ext4fs command..
grtz
Fixed it!
The problem was that i was using a size of 512M without knowing where it came from.
I flashed the original firmware back to the phone, did a
Code:
adb shell "df /system "
to know what size my img needed to be. In my case it was a total size of 492M. So i used following command to make my system.img.ext4
Code:
make_ext4fs -s -l 492M -a system system.img.ext4 /system
Now trying to pack my own kernel in the boot.img
thanks for the support!
1bymany said:
Fixed it!
The problem was that i was using a size of 512M without knowing where it came from.
I flashed the original firmware back to the phone, did a
Code:
adb shell "df /system "
to know what size my img needed to be. In my case it was a total size of 492M. So i used following command to make my system.img.ext4
Code:
make_ext4fs -s -l 492M -a system system.img.ext4 /system
Now trying to pack my own kernel in the boot.img
thanks for the support!
Click to expand...
Click to collapse
Sorry for the late response .got a little busy.Happy that you solved it .Just an hint,you can use -h to see the size better readable by humans(In M and G) in df command incase you find its in kb or B
Sent from my GT-N7000 using xda app-developers app
Updated to v2
vijai2011 said:
Updated to v2
Click to expand...
Click to collapse
thanks man
Hi all,
im working on making a ROM for the Asus Transformer and im struggling a bit. im totall new to Linux, using mint and just getting used to it.
Basically im just trying to take a stock ROM and add root but adding superuser.apk and SU binary but im running into problems.
Asus Roms are a bit unusual, packed into blob files, ive unpacked that no problem, the system image is called blob.APP but its just the same as system.img just the name as i understand it.
ok so what ive done:
Code:
mkdir system
sudo mount -t ext4 -o loop blob.APP system/
so this mounts the ext4 fs as a loop device and allows me to copy the contents out
Code:
sudo cp -ar system new_system
then ive copied superuser.apk to /app and SU binary to /dev with drop and drag.
then make the filesystem image
Code:
sudo ./make_ext4fs -l 512m -a system blob.APP new_system/system
then just pack it up and flash it, flashing works fine, no errors but when i go to reboot it warns that theres no OS so somethings not worked. ive tried everything i can find googeling!
i just started learning linux on weds so go easy on me
any advice or help would be really great. thanks!
mkdir system here you will mount the old system
mkdir system_new here you will mount the new system
we now create the actual image
dd if=/dev/zero of=system_new.img bs=4k count=60000
bs=4k is the block size
count=60000 the number of blocks of 4kb size
so is something like 60000*4= 240000 which is actually 240 Mb
so it depends to you how big you want the image.
now we format the system.img in ext4
mkfs.ext4 system_new.img
Proceed anyway? (y,n) y
now we override the filesystem check
tune2fs -c0 -i0 system_new.img
Now we mount the the 2 directories that we created in the first step
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Now we copy the contet of the old image to the new one with all the perimissions
cp -v -r -p system/* system_new/
We sinc the files
sync
We unmount the partitions
umount system_new/
umount system/
And voila, the system.img in ext4 is created.
Tips: you will need superuser acces.
if you will copy new files besides the ones from the old system you will have to set by hand all the permissions.
If you are using ubuntu just type
sudo su
and you will be root and no more sudo at each command.
Thank u so much for your guide this is exactly what I'm looking for so massive thanks!
So to add root I.can drop and drag superuser.apk and the binary into the new image?
Also do I need to worry about the android mountpoint?
Sent from my HTC Sensation Z710e using xda premium
yes you can do that, as long as you set the permissions right. (you can google for them)
and from what i remeber you will have to set also the ownership of the su, and superusers files
you need to do tests first, and then try
the mountpoint should be ok as it is now.
globula_neagra said:
mkdir system here you will mount the old system
mkdir system_new here you will mount the new system
we now create the actual image
dd if=/dev/zero of=system_new.img bs=4k count=60000
bs=4k is the block size
count=60000 the number of blocks of 4kb size
so is something like 60000*4= 240000 which is actually 240 Mb
so it depends to you how big you want the image.
now we format the system.img in ext4
mkfs.ext4 system_new.img
Proceed anyway? (y,n) y
now we override the filesystem check
tune2fs -c0 -i0 system_new.img
Now we mount the the 2 directories that we created in the first step
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Now we copy the contet of the old image to the new one with all the perimissions
cp -v -r -p system/* system_new/
We sinc the files
sync
We unmount the partitions
umount system_new/
umount system/
And voila, the system.img in ext4 is created.
Tips: you will need superuser acces.
if you will copy new files besides the ones from the old system you will have to set by hand all the permissions.
If you are using ubuntu just type
sudo su
and you will be root and no more sudo at each command.
Click to expand...
Click to collapse
U said, we have to set permissions by ourselves. So what are the permissions that needs to be set when I add a new folder with an APK in it?
Sudo chmod 777 filepath/filename.apk
Sudo chmod a-rwx filepatch/filename.apk.
This is what I remember from top of my head. Google it a bit if it does not work from the first try as I have not used this like in 5 years.
If you allready have root you can you a file manager and just copy the file/folder where you want and set the permissions via thw file manager or using terminal commanda or via adb.
From what remember you can t make a folder in the apk folder as you won t be able to run the apk.
Requirements :
Need to change some system files
Install one application as system app
I know that above to requirements need rooted device, but device is not of well-known company so there is no support available from CWM, TWRP or any other.
Yet I've some how managed to get some tools and files to install android 5.1 from device manufacturer as below,
Intel's Platform Flash Tool
Also all necessary files such as recovery.img(stalk-read only permission), system.img etc.
Now what I've think of solution so far is to unpack and repack system.img and replace new system.img with existing one and install with Intel's Platform Flash Tool, XDA reference-1.
Unpack :
mkdir sys
./simg2img system.img sys.raw
sudo mount -t ext4 -o loop sys.raw sys/
Repack :
sudo ./make_ext4fs -s -l 512M -a system new.img sys/
sudo umount sys
rm -fr sys
also calculated size = "Block count" * "Block size", XDA reference-2
and after creating sucessully system.img and also installation is also complete with Intel's Platform Flash Tool, bur is not able to boot and stuck at loading screen.
Solutions that I can think of,
Is there something that I'm missing in above method of unpack/repack method of system.img?
I've Intel's Platform Flash Tool, so is there any way to put my changes during installation of android OS?
I've also recovery.img, is it possible to modify this and create custom recovery.img and give read and write permission to system files?
Are there any ohter solutions which meets my requirements?
Any help will be highly appreciated.
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.
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