Hi, I've rooted the new 20F rom (Spain)
http://yadi.sk/d/uKcmLC_-7dpxo
Regards
alejomj said:
Hi, I've rooted the new 20F rom (Spain)
Regards
Click to expand...
Click to collapse
Is it multilanguage firmware, Italian language is included?
How did you do it?
yeah it has italian lang.
for rootiing, after that you have downloaded the stock kdz, follow these steps:
1 - LGExtract.exe -kdz ..\*.kdz
2- extract .cab
3- DZDecrypt *.dz
4- DZExtract -x *.dz
5- mount -o loop -t ext4 system.img.ext /mnt/kdz
6- cp system/bin/su /mnt/kdz/bin/
7- cp system/app/Superuser.apk /mnt/kdz/app/
8- chmod 06755 /mnt/kdz/bin/su
9- ln -s /mnt/kdz/bin/su /mnt/kdz/xbin
10- DZCreate.exe -mE610 -v20E V20D_root.dz
11- create cab with dz + dll
12- create kdz with cab file using UpTestEX_original
I got it :good:
They are commands and tools that you need for creating a kdz ROM rooted. mmm I think there's a way to root your phone with adb shell but I prefer with this one.
Regards
alejomj said:
They are commands and tools that you need for creating a kdz ROM rooted. mmm I think there's a way to root your phone with adb shell but I prefer with this one.
Regards
Click to expand...
Click to collapse
I was looking for a faster method to root my device.
That wasn't my idea.
However thanks for explainations.
alejomj said:
yeah it has italian lang.
for rootiing, after that you have downloaded the stock kdz, follow these steps:
1 - LGExtract.exe -kdz ..\*.kdz
2- extract .cab
3- DZDecrypt *.dz
4- DZExtract -x *.dz
5- mount -o loop -t ext4 system.img.ext /mnt/kdz
6- cp system/bin/su /mnt/kdz/bin/
7- cp system/app/Superuser.apk /mnt/kdz/app/
8- chmod 06755 /mnt/kdz/bin/su
9- ln -s /mnt/kdz/bin/su /mnt/kdz/xbin
10- DZCreate.exe -mE610 -v20E V20D_root.dz
11- create cab with dz + dll
12- create kdz with cab file using UpTestEX_original
Click to expand...
Click to collapse
how did you push su in dz? (.dz)
you need to mount the ext file for writing inside the su package. You can do it in any linux/BSD or other posix system.
Regards
Hi guys,
I'm trying to make some changes to an android box firmware. Ultimately what I'm trying to do is extract some files from a tar.gz into a folder on the root.
I have got as far as creating the directory on the root, and having a shell script run that extracts the files to the root folder. Problem is, the files aren't appearing in my folder.
This is what I've done so far:
1. Extracted the boot image in the firmware to edit "init.rc". I've made the changes so I can make my "test" folder with 777 permissions.
In the "on init" section of init.rc I have this:
Code:
mkdir /test 777
2. I've created the following script (test.h) that runs from init.amlogic.board.rc
Code:
#!/system/bin/sh
MARK=/data/local/test
if [ ! -e $MARK ]; then
echo "test script"
busybox tar -zxf /system/test.tar.gz -C /test/
touch $MARK
echo "OK, installation complete."
fi
This is the code in the init.amlogic.board.rc
Code:
service test_copy /system/bin/test.sh
user root
group root
disabled
oneshot
on property:sys.boot_completed=1
start test_copy
Once the box has booted I can see the "test_copy" file but the tar.gz files are not in my root folder.
The last thing I need is the files from the tar.gz to be 777 permissions.
Obviously I'm a complete noob at this, hope that makes sense and someone can help?
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