Alright we have a CM9 for locked bootloader but we don't have CM10 and the people that want to help don't have a clue about where to begin.
I really didn't want to make a new thread but so much stuff is scattered in several places on this subject, and I don't feel like jacking peoples thread to answer "how to stuff".
artas182x already ported a 2nd-init (rom and recovery) for L9, so we just have to figure out the right settings to make CM10 boot.
Please read this thread http://forum.xda-developers.com/showthread.php?p=36706378
The only CM10 I have so far is from markolino631 http://forum.xda-developers.com/showthread.php?t=2313036
ROM
http://www.mediafire.com/download/fdka03ulxtxn1pg/cm-10-20130611-UNOFFICIAL-p760.zip
One of the first things you will need to learn is how to make a boot.tar or recovery.tar for locked bootloader.
How to make a boot.tar or recovery.tar
Things you will need Linux OS or cygwin (for windows), osm0sis's mkbootimg (Android Kitchen has it all set and ready to go), and last but not least a brain
okay you want to make a boot.tar, well we first need to get our hands on the boot.img. So I'll just use a stock boot.img for this example, but we really need CM10 boot.img.
I am using cygwin and Android Kitchen for this example.
First navigate to advance options (#0) select number #12 (in advanced options) and select option "a"(Extract kernel+ramdisk from boot.img/recovery.img in any folder).
Place the boot.img inside the new folder it specifies and hit enter. Afterwards you will have a "zImage" file and a "boot.img-ramdisk" folder.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note: the Kitchen will get rid of the boot.img (so don't place your only boot.img copy in that folder).
Click to expand...
Click to collapse
Now exit the Kitchen (just press Ctrl+c) and navigate to the new folder with cygwin (shorten the folder name if you want, like I did in my example).
Code:
Kuma [email protected] /home/Kuma/Kitchen
$ [B]cd bootimg_stock/boot.img-ramdisk/[/B]
Once in the "boot.img-ramdisk" folder we are all set to make the boot.tar
However, lets check the permission on all the files in that folder.
So type ls -ln and make a note of the permission for each file, without the proper permission it won't work for sure.
Another thing, if using cygwin make sure you move a folder properly. If you just move a folder (with Window explorer) you may loss the correct permission for those files. However, if you just change the name of a file it doesn't effect the permissions. I'll try and elaborate some more later.
Click to expand...
Click to collapse
Now type tar cvf boot.tar ./* and a new boot.tar will be created in that folder.
Code:
$ tar cvf boot.tar ./*
./charger
./data/
./default.prop
./dev/
./fota.rc
./init
./init.goldfish.rc
./init.lge.early.rc
./init.lge.rc
./init.lge.ril.rc
./init.lge.usb.rc
./init.lgep769board.rc
./init.post_boot.sh
./init.rc
./init.trace.rc
./init.u2.rc
./init.usb.rc
./lgdms.fota.rc
./lgdms.fota_update.rc
./proc/
./res/
./res/images/
./res/images/charger/
./res/images/charger/battery_0.png
./res/images/charger/battery_1.png
./res/images/charger/battery_2.png
./res/images/charger/battery_3.png
./res/images/charger/battery_4.png
./res/images/charger/battery_none.png
./res/images/charger/battery_overheat.png
./res/images/charger/battery_trickle_ani_01.png
./res/images/charger/battery_trickle_ani_02.png
./res/images/errorlogo.png
./sbin/
./sbin/adbd
./sbin/e2fsck_static
./sbin/lge_fota
./sbin/mke2fs_static
./sbin/resize2fs_static
./sbin/ueventd
./sbin/wallpaper
./sys/
./system/
./ueventd.goldfish.rc
./ueventd.lgep769board.rc
./ueventd.rc
Kuma [email protected] /home/Kuma/Kitchen/bootimg_stock/boot.img-ramdisk
$
Once you made your boot.tar (and made the changes you wanted) you can place the boot.tar in the system (/system/bootstrap/) with the correct permissions
Code:
chmod 755 /system/bootstrap/boot.tar
I already made a couple of recoveries and modified ram disk using this method.
For recovery type tar cvf recovery.tar ./*
I'll be posting some more stuff but i really have my hands full.
kuma82 said:
Alright we have a CM9 for locked bootloader but we don't have CM10 and the people that want to help don't have a clue about where to begin.
I really didn't want to make a new thread but so much stuff is scattered in several places on this subject, and I don't feel like jacking peoples thread to answer "how to stuff".
artas182x already ported a 2nd-init (rom and recovery) for L9, so we just have to figure out the right settings to make CM10 boot.
Please read this thread http://forum.xda-developers.com/showthread.php?p=36706378
The only CM10 I have so far is from markolino631 http://forum.xda-developers.com/showthread.php?t=2313036
ROM
http://www.mediafire.com/download/fdka03ulxtxn1pg/cm-10-20130611-UNOFFICIAL-p760.zip
One of the first things you will need to learn is how to make a boot.tar or recovery.tar for locked bootloader.
How to make a boot.tar or recovery.tar
Things you will need Linux OS or cygwin (for windows), osm0sis's mkbootimg (Android Kitchen has it all set and ready to go), and last but not least a brain
okay you want to make a boot.tar, well we first need to get our hands on the boot.img. So I'll just use a stock boot.img for this example, but we really need CM10 boot.img.
I am using cygwin and Android Kitchen for this example.
First navigate to advance options (#0) select number #12 (in advanced options) and select option "a"(Extract kernel+ramdisk from boot.img/recovery.img in any folder).
Place the boot.img inside the new folder it specifies and hit enter. Afterwards you will have a "zImage" file and a "boot.img-ramdisk" folder.
Now exit the Kitchen (just press Ctrl+c) and navigate to the new folder with cygwin (shorten the folder name if you want, like I did in my example).
Code:
Kuma [email protected] /home/Kuma/Kitchen
$ [B]cd bootimg_stock/boot.img-ramdisk/[/B]
Once in the "boot.img-ramdisk" folder we are all set to make the boot.tar
However, lets check the permission on all the files in that folder.
So type ls -ln and make a note of the permission for each file, without the proper permission it won't work for sure.
Now type tar cvf boot.tar ./* and a new boot.tar will be created in that folder.
Code:
$ tar cvf boot.tar ./*
./charger
./data/
./default.prop
./dev/
./fota.rc
./init
./init.goldfish.rc
./init.lge.early.rc
./init.lge.rc
./init.lge.ril.rc
./init.lge.usb.rc
./init.lgep769board.rc
./init.post_boot.sh
./init.rc
./init.trace.rc
./init.u2.rc
./init.usb.rc
./lgdms.fota.rc
./lgdms.fota_update.rc
./proc/
./res/
./res/images/
./res/images/charger/
./res/images/charger/battery_0.png
./res/images/charger/battery_1.png
./res/images/charger/battery_2.png
./res/images/charger/battery_3.png
./res/images/charger/battery_4.png
./res/images/charger/battery_none.png
./res/images/charger/battery_overheat.png
./res/images/charger/battery_trickle_ani_01.png
./res/images/charger/battery_trickle_ani_02.png
./res/images/errorlogo.png
./sbin/
./sbin/adbd
./sbin/e2fsck_static
./sbin/lge_fota
./sbin/mke2fs_static
./sbin/resize2fs_static
./sbin/ueventd
./sbin/wallpaper
./sys/
./system/
./ueventd.goldfish.rc
./ueventd.lgep769board.rc
./ueventd.rc
Kuma [email protected] /home/Kuma/Kitchen/bootimg_stock/boot.img-ramdisk
$
Once you made your boot.tar (and made the changes you wanted) you can place the boot.tar in the system (/system/bootstrap/) with the correct permissions
Code:
chmod 755 /system/bootstrap/boot.tar
I already made a couple of recoveries and modified ram disk using this method.
For recovery type tar cvf recovery.tar ./*
I'll be posting some more stuff but i really have my hands full.
Click to expand...
Click to collapse
what if the permissions of the files are not the same as the permissions thats in your screenshot?
just tried to make a rom and got a security error again. IDK what im doing wrong
This is sick. So once we have a boot.tar, do we just drop it onto a CM10 ROM for say, the P760? That seems all too easy and probably wrong.
Sent from my Nexus 7 using Tapatalk
ThEuNdYiNg1 said:
what if the permissions of the files are not the same as the permissions thats in your screenshot?
just tried to make a rom and got a security error again. IDK what im doing wrong
Click to expand...
Click to collapse
Need exact steps, or I won't be able to help.
More than like you aren't using a stock jellybean boot.img, that's why you are getting the security error.
Ilxaot said:
This is sick. So once we have a boot.tar, do we just drop it onto a CM10 ROM for say, the P760? That seems all too easy and probably wrong.
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
I wish it was that easy there are several other files that need to be replaced from stock, like libs and stuff.
I don't have the time to troubleshooting.
Building the rom from source is the best route, but my computer is crap.
If I knew how, I could try. I have a decent setup. The problem for me is that I have no history in development, only tweaks. And, I don't know how to make a ROM for an unlocked bootloader, so I get the feeling that if I look for help, I'll find results for unlocked bootloader ROMs and end up botching the ROM.
Sent from my Nexus 7 using Tapatalk
kuma82 said:
Need exact steps, or I won't be able to help.
More than like you aren't using a stock jellybean boot.img, that's why you are getting the security error.
I wish it was that easy there are several other files that need to be replaced from stock, like libs and stuff.
I don't have the time to troubleshooting.
Building the rom from source is the best route, but my computer is crap.
Click to expand...
Click to collapse
first thing is i download p760 cm10 and took the boot.img and decompiled it with cygwin i edited the names so instead of it saying init.lgep760board or whatever is it i changed it to p769 and i also changed in one of the files the name file for the .usb file to p769. then i made the boot.tar with your instructions. the recovery and everythin else is from the cm9 rom, i just took the bootstrap folder from there and put it in the cm10 rom
The stock boot.img is from your tweaked rom and i also copied all of the libs and things thats required to be modded like you did with cm9 for the p769 since my phone is a p769 and not a p760
ThEuNdYiNg1 said:
first thing is i download p760 cm10 and took the boot.img and decompiled it with cygwin i edited the names so instead of it saying init.lgep760board or whatever is it i changed it to p769 and i also changed in one of the files the name file for the .usb file to p769. then i made the boot.tar with your instructions. the recovery and everythin else is from the cm9 rom, i just took the bootstrap folder from there and put it in the cm10 rom
The stock boot.img is from your tweaked rom and i also copied all of the libs and things thats required to be modded like you did with cm9 for the p769 since my phone is a p769 and not a p760
Click to expand...
Click to collapse
I'm no expert, but that sounds about right. D:
Sent from my Nexus 7 using Tapatalk
I've been experimenting with porting different versions of CM (10.1 and 11), AOKP and PacMan (so basically Android 4.3 and 4.4). Didn't got them booting, but the recoveries did work and didn't give a Security Error.
Permissions in the files are important (the files you need to edit usally need 0755). You need to replace the boot.img of the ROM for the stock one and use the replaced boot.img to create a boot.tar. You also need to add a line to the updater-script that changes the permissions of the /system/bootstrap to 755, so the 2nd init script can access to them.
You also need to replace the e2fsck in /system/bin (and add the e2fsck.bin, which is the original binary). The kernel executes e2fsck to check the file system at boot, so it's the perfect candidate to launch the 2nd init process (since the original kernel executes this binary always at boot).
If you get the correct permissions in the files, the correct files replaced and edited, you may get past the Security Error. I'm now investigating why it hangs on the LG logo. I think I'm not building the boot.tar correctly, and that's why the 2nd init is unable to jump to it.
krashprocess said:
I've been experimenting with porting different versions of CM (10.1 and 11), AOKP and PacMan (so basically Android 4.3 and 4.4). Didn't got them booting, but the recoveries did work and didn't give a Security Error.
Permissions in the files are important (the files you need to edit usally need 0755). You need to replace the boot.img of the ROM for the stock one and use the replaced boot.img to create a boot.tar. You also need to add a line to the updater-script that changes the permissions of the /system/bootstrap to 755, so the 2nd init script can access to them.
You also need to replace the e2fsck in /system/bin (and add the e2fsck.bin, which is the original binary). The kernel executes e2fsck to check the file system at boot, so it's the perfect candidate to launch the 2nd init process (since the original kernel executes this binary always at boot).
If you get the correct permissions in the files, the correct files replaced and edited, you may get past the Security Error. I'm now investigating why it hangs on the LG logo. I think I'm not building the boot.tar correctly, and that's why the 2nd init is unable to jump to it.
Click to expand...
Click to collapse
so i basically need to replace that with stock file and it should work?
This thread may be of use.
http://forum.xda-developers.com/showthread.php?t=2725842
Sent from my LGMS769 using Tapatalk
ThEuNdYiNg1 said:
so i basically need to replace that with stock file and it should work?
Click to expand...
Click to collapse
No, you need the modified 2fsck, pull it from my tweak stock rom or somewhere else, like artas182x l9recovery apk. Another thing don't use the bootstrap files for CM9. Pull it from my rom as well.
Just so you know, I made the changes you are talking about (changing 760 to 769) and it didn't work. For some reason the data partition wouldn't mount. I'll give y'all some logcats later.
Sent from my LGMS769 using XDA Premium 4 mobile app
Hey Kuma, thanks so much for the guide. I'm getting stuck at the LG logo screen (before the boot animation). Obviously adbd is not getting started since I'm pretty sure my boot.tar is somehow wrong. Is it possible to still grab the logcats out of the device? I can still access the recovery (and replace it with different CWM for L9 versions). Thanks in advance.
And it's not just a matter of replacing a file AFAIK. It involves a few more steps until you get at least past the Security Error. I didn't get any of my ports to boot the actual OS, but at least the recovery works.
krashprocess said:
Hey Kuma, thanks so much for the guide. I'm getting stuck at the LG logo screen (before the boot animation). Obviously adbd is not getting started since I'm pretty sure my boot.tar is somehow wrong. Is it possible to still grab the logcats out of the device? I can still access the recovery (and replace it with different CWM for L9 versions). Thanks in advance.
And it's not just a matter of replacing a file AFAIK. It involves a few more steps until you get at least past the Security Error. I didn't get any of my ports to boot the actual OS, but at least the recovery works.
Click to expand...
Click to collapse
Best of luck to y'all! If we can manage at least a CM 10, that would be awesome! Of course, we may run into bugs but that is the norm on the nightlies.
Sent from my LG-P769 using XDA Premium 4 mobile app
krashprocess said:
Hey Kuma, thanks so much for the guide. I'm getting stuck at the LG logo screen (before the boot animation). Obviously adbd is not getting started since I'm pretty sure my boot.tar is somehow wrong. Is it possible to still grab the logcats out of the device? I can still access the recovery (and replace it with different CWM for L9 versions). Thanks in advance.
And it's not just a matter of replacing a file AFAIK. It involves a few more steps until you get at least past the Security Error. I didn't get any of my ports to boot the actual OS, but at least the recovery works.
Click to expand...
Click to collapse
I thought adb wasn't working but it was. I just kept trying and it started working. It's probably not working because you need to install android platform sooner. I noticed a driver was popping up but Windows didn't know what to do with it. So I manually installed it, not at a computer right now, so I'm not sure what the actually drive its called.
Sent from my LGMS769 using XDA Premium 4 mobile app
kuma82 said:
I thought adb wasn't working but it was. I just kept trying and it started working. It's probably not working because you need to install android platform sooner. I noticed a driver was popping up but Windows didn't know what to do with it. So I manually installed it, not at a computer right now, so I'm not sure what the actually drive its called.
Sent from my LGMS769 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'll have to check on Windows. I use Debian and OS X to do these things (which doesn't requires drivers), but since I needed Windows to flash the KDZs I have a computer available. I'll see if I can get past the LG screen soon!
BTW I have some builds that don't give Security Error, although they don't boot. If someone wants me to upload them to take a look, I can do it with no problem.
http://forum.xda-developers.com/showthread.php?t=2728404 this rom can work on locked bl?? this rom is based on v20o kernel stock and we make only the boot.tar for work thus rom on locked bl?
inviato dal mio l9 che diventerà g2
Thank i well try
Duckscreen said:
Thank i well try
Click to expand...
Click to collapse
I hope you mean you're going to use this information to look into porting and not flashing this using 2nd init cwm.
Sent from my LG-P769 using XDA Premium 4 mobile app
salvatore46 said:
http://forum.xda-developers.com/showthread.php?t=2728404 this rom can work on locked bl?? this rom is based on v20o kernel stock and we make only the boot.tar for work thus rom on locked bl?
inviato dal mio l9 che diventerà g2
Click to expand...
Click to collapse
This doesn't have stock kernel. It uses a cm kernel....
more help
The instructions on extracting the stock boot.img is important. The .rc files are running commands and are looking for specific files to execute. For example this command is found in the init.rc for V10F (LGMS769)
Code:
service mdnsd /system/bin/mdnsd
class main
user mdnsr
group inet net_raw
socket mdnsd stream 0660 mdnsr inet
disabled
oneshot
Maybe the rom won't boot because it's missing an important command that required by the kernel.
I have noticed that not all service commands actually have a script to run.
For example in init.goldfish.rc
Code:
service qemu-props /system/bin/qemu-props
class core
user root
group root
oneshot
service qemud /system/bin/qemud
socket qemud stream 666
oneshot
/system/bin/qemu-props
and
/system/bin/qemud
are not in the stock system.
Related
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
Hello all you Triple-Booters out there! I would like to introduce to you:
Convert2Dualboot-SD Tool
What is this you ask?
This is a little tool that I've put together that will convert any standard flashable roms for our Nook Color to be DualbootSD compatible. No more waiting on my lazy arse to update you guys!!! I used APK manager as a base for my script. I've written 3 different versions that will run on Linux, OSX and Android. All neccesary binaries are included with each version.
Click to expand...
Click to collapse
Can I use any kind of flashable zips?
Yes and no. You could use any standard flashable "rom" or "gapps" zips only.
Click to expand...
Click to collapse
How do I use it?
You drop a standard rom .zip into a "rom-to-modify" folder. Then execute a shell script that will give you an option to convert it for flashing to Primary or Alternate boot on the DualbootSD.
Click to expand...
Click to collapse
Can I use any CWM Recovery for flashing?
Absolutely not! Only use the CWM Recovery that was included with the DualbootSD.
Click to expand...
Click to collapse
Will you be updating this to add new features and stuff?
Not sure what features I can add, but you can always check the CHANGE LOG in post 3.
Click to expand...
Click to collapse
Can you give us step by step directions on how to use this?
Of course! See second post for more details.
Click to expand...
Click to collapse
***Disclaimer: Usual disclaimer applies here as well... you use this at your own risk, I am not responsible for anything that happens to any of your devices. You assume all responsibility when using this tool.***
Credits:
Daneshm90 for the APK Manager Script I used as a base
Pinako/Inportb/Jyio/Boss! - for his Android binaries
DizzyDen - for porting this over to DOS and his many ideas to get the script to where it's at
HacDan - for some bash guidance
If I forgot someone else, please notify me.
Convert2Dualboot-SD Tool-README
Convert2Dualboot-SD-Linux v1.4
DOWNLOAD
*C2DSD=Convert2Dualboot-SD*
1-Extract the zip file you just downloaded anywhere on your system
2-In the C2DSD folder, there are 2 folders called "modify-for-pri" and "modify-for-alt". Copy your rom.zip and/or gapps.zip file into its respective folder. No need to rename the file as long as it has a .zip extension.
3-Open up terminal and cd into Convert2Dualboot-SD-Linux
4-At the termninal prompt execute the C2DSD script
Code:
$ sh convert*
5-This will give you a menu where you can choose to modify the "rom" and/or "gapps" for either Primary or Alternate boot. It will also give you an option to clear out recently modded zips. Now with option to mod both ROM & GAPPS on the fly. Just place both files inside either "modify-for-pri" or "modify-for-alt" and choose the option to modify both from the menu.
6-Choose your option and wait while it does its thing.
7-Once it's finished you can exit the program by choosing "0"
8-Now browse to the C2DSD folder and you can find your DualbootSD modded rom file either in "Primary-Mod" or "Alternate-Mod" depending on your earlier selection.
9-Copy that file to the /sdcard partition of your DualbootSD
10-Boot to CWM Recovery that is included with the DualbootSD
11-Flash and enjoy!
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------
Convert2Dualboot-SD-OSX v1.4
DOWNLOAD
*C2DSD=Convert2Dualboot-SD*
1-Extract the zip file you just downloaded anywhere on your system
2-In the C2DSD folder, there are 2 folders called "modify-for-pri" and "modify-for-alt". Copy your rom.zip and/or gapps.zip file into its respective folder. No need to rename the file as long as it has a .zip extension.
3-Open up terminal and cd into Convert2Dualboot-SD-OSX
4-At the termninal prompt execute the C2DSD script
Code:
$ ./convert*
5-This will give you a menu where you can choose to modify the "rom" and/or "gapps" for either Primary or Alternate boot. It will also give you an option to clear out recently modded zips. Now with option to mod both ROM & GAPPS on the fly. Just place both files inside either "modify-for-pri" or "modify-for-alt" and choose the option to modify both from the menu.
6-Choose your option and wait while it does its thing.
7-Once it's finished you can exit the program by choosing "0"
8-Copy that file to the /sdcard partition of your DualbootSD
9-Boot to CWM Recovery that is included with the DualbootSD
10-Flash and enjoy!
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------
Convert2Dualboot-SD-Android v1.4
DOWNLOAD
*C2DSD=Convert2Dualboot-SD*
1-This will allow you to modify the zip files directly on your Nook
2-Extract the zip file you just downloaded to the root of your DualbootSD /sdcard partition.
3-The folder should be named c2dsd
4-In the c2dsd folder, there are 2 folders called "modify-for-pri" and "modify-for-alt". Copy your rom.zip or gapps.zip file into its respective folder. No need to rename the file as long as it has a .zip extension.
5-Open up any Terminal Emulator and cd into the c2dsd folder which should be "/sdcard/c2dsd"
6-At the termninal prompt execute the C2DSD script
Code:
$ su
# sh convert*
7-This will give you a menu where you can choose to modify the "rom" and/or "gapps" for either Primary or Alternate boot. It will also give you an option to clear out recently modded zips. Now with option to mod both ROM & GAPPS on the fly. Just place both files inside either "modify-for-pri" or "modify-for-alt" and choose the option to modify both from the menu.
8-Choose your option and wait while it does its thing.
9-Once it's finished you can exit the program by choosing "0"
10-Now you can choose to boot to CWM Recovery that is included with the DualbootSD
11-Choose "install zip from sdcard" and browse to either "Primary-Mod" or "Alternate-Mod" depending on your earlier selection.
12-Flash and enjoy!
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------
Convert2Dualboot-SD-DOS v1.3
DOWNLOAD
*C2DSD=Convert2Dualboot-SD*
1-Extract the zip file you just downloaded anywhere on your system
2-In the C2DSD folder, there are 2 folders called "modify-for-pri" and "modify-for-alt". Copy your rom.zip and/or gapps.zip file into its respective folder. No need to rename the file as long as it has a .zip extension.
3-Open up command window and cd into Convert2Dualboot-SD-DOS or create a shortcut on your desktop
4-At the command prompt execute the C2DSD script
Code:
convert2dualboot-sd-dos
5-This will give you a menu where you can choose to modify the "rom" and/or "gapps" for either Primary or Alternate boot. It will also give you an option to clear out recently modded zips. Now with option to mod both ROM & GAPPS on the fly. Just place both files inside either "modify-for-pri" or "modify-for-alt" and choose the option to modify both from the menu.
6-Choose your option and wait while it does its thing.
7-Once it's finished you can exit the program by choosing "0"
8-Copy that file to the /sdcard partition of your DualbootSD
9-Boot to CWM Recovery that is included with the DualbootSD
10-Flash and enjoy!
Click to expand...
Click to collapse
And that's all she wrote... well he, being me.
If I've helped in anyway. Don't hesitate to hit the thanks button.
Change log:
v1.4 (6/8/2012)
-Fixed gapps being zipped with rom when converting rom & gapps together
-Added SDCacheMount to converted roms (see the SDCacheMount thread for more info)
-Fixed mkimage binary executing error for Linux version
-No DOS update yet.... DizzyDen?????
-Thanks goes to xda user "shumash" for the SDCacheMount addition into the script
v1.3a
-Mkimage error on Android Script fixed.
-Mkimage is dependent on 'libmusl.so' which I did not include and linked in the tools folder. I overlooked this tidbit because I had "BOTBREW" installed on my system so it never complained about linking to it.
v1.3
-I effed up on the script!
-RASTAVIPER kept asking me about issues with his gapps. Apparently the mod for Gapps Alt Boot had the wrong mount points inserted into the updater script. NOW I SEE IT!
-Also in the DOS version. Prep of ROM Alt Boot had the wrong mount points as well. Sorry guys.
-It's been fixed and uploaded. Please don't use v1.2 anymore. Thanks.
v1.2
-Changed up UI layout of script: Please re-read README from post 2 above for edited instructions.
-Edited script to speed up mod process (Thanks DizzyDen!)
-Added option to mod both "ROM & GAPPS" on the fly
-Android version now has a tool.img file. This makes modding quicker and safer.
-Added DOS version ported by DizzyDen! (Thank you sir!)
-Modding for EMMC dualboot version in the works???? (That's if you guys want it)
v1.1
-Added gapps option
-Cleaned up some scripting behaviors
v1.0
-Initial release
Well.. after some thought, it really didn't make sense to release this without an option to mod gapps for the DualbootSD. I mean what good is a rom without gapps?!
Convert2Dualboot-SD v1.1 is up if anyone wants to try.
Check post 3 for all changlogs.
Thanks,
Racks
Taking advantage of the opportunity to try something new, I made a dual-boot card for my sister-in-law.
This is cool. I actually haven't tested the card yet as I have my device flashed to internal and have modded the recovery some. I haven't backed up any of the changes I made (I know, I know) and don't want to have to do it again.
I may try updating the card now that you've included gapps, though. I hadn't made a bootable card since I first rooted this thing, and to be honest it was by accident even that time. So I was wondering how to get gapps, was thinking about setting an alt-recovery just for that.
But anyway, I hadn't looked at how to do the gapps yet, maybe it was easier than that. But this seems even easier.
Cool, man! I bet the dual/triple booters will love being able to make their own updates. The experience I had last night couldn't have been easier. My wife got me and her sister the Nooks at the same time, I am excited for her to see what I have been talking about the last six months.
I will be sure to try this once my NC gets here. Thanks!
Racks,
Works great but there's an odd 0 byte file in the DB zip called ^[email protected] Is that an artifact and can I just delete it?
shumash said:
Racks,
Works great but there's an odd 0 byte file in the DB zip called ^[email protected] Is that an artifact and can I just delete it?
Click to expand...
Click to collapse
DB zip? Sorry, but what are you referring to with that?
And could you also let me know which one you used? OSX, Linux, Android?
Edit: That might just be the stupid __MACOSX hidden folder that osx likes to include Forgot to exclude that and the .gitignore file when zipping. Although they aren't detrimental to running the C2DSD Tool, you can choose to delete them if you wish.
Thanks,
Racks
Thanks a lot Racks... great work... we'll get together and sort out the windows based version... can include it in your work here... or as another feature of the IMEI generator.
DizzyDen said:
Thanks a lot Racks... great work... we'll get together and sort out the windows based version... can include it in your work here... or as another feature of the IMEI generator.
Click to expand...
Click to collapse
Awesome to hear! Was hoping you would jump in.
We'll hook up and get the Windows based version here as well as incorporate it into your IMEI generator.
Thanks!
Racks
racks11479 said:
Awesome to hear! Was hoping you would jump in.
We'll hook up and get the Windows based version here as well as incorporate it into your IMEI generator.
Thanks!
Racks
Click to expand...
Click to collapse
Sounds like a plan... I just got in from work... and am off tomorrow.
DizzyDen said:
Thanks a lot Racks... great work... we'll get together and sort out the windows based version... can include it in your work here... or as another feature of the IMEI generator.
Click to expand...
Click to collapse
racks11479 said:
Awesome to hear! Was hoping you would jump in.
We'll hook up and get the Windows based version here as well as incorporate it into your IMEI generator.
Thanks!
Racks
Click to expand...
Click to collapse
+1 from a meathead windows user here.
Sent from my NookColor racks tripple boot using Tapatalk 2
racks11479 said:
DB zip? Sorry, but what are you referring to with that?
And could you also let me know which one you used? OSX, Linux, Android?
--SNIP--
Thanks,
Racks
Click to expand...
Click to collapse
Sorry for being vague. I meant the modded dualboot sd zip build. But I tried it again and it was fine, so let's say no more about it, eh?
On a related note, since you're so motivated now, how about creating those separate cache1 and cache2 partitions so that we don't have to wait so long to boot between the two?
Anyone who tried the new modding option and that would like to share with us which CM9 rom (nightly) did he convert and is working fine after conversion?
spdsl said:
+1 from a meathead windows user here.
Sent from my NookColor racks tripple boot using Tapatalk 2
Click to expand...
Click to collapse
Was hoping to have something before I had to go to work this morning... didn't get it completed...
to keep as close as Racks' I will have a DOS batch file available sometime tonight...
True Windows GUI version will be available early in the week.
Keeping with Racks' desires... both will be open source and stored on his github... I use AutoIT for windows programming these things.
shumash said:
On a related note, since you're so motivated now, how about creating those separate cache1 and cache2 partitions so that we don't have to wait so long to boot between the two?
Click to expand...
Click to collapse
Racks, I just sent you a PM that might help with this issue.
shumash said:
Racks,
Works great but there's an odd 0 byte file in the DB zip called ^[email protected] Is that an artifact and can I just delete it?
Click to expand...
Click to collapse
UPDATE: I converted the latest Mirage build, and when I tried to flash it, Recovery complained that it wasn't a valid zip file. Checked it and the same weird file was in the converted flashable zip. When I ran the conversion a second time, all was good and it flashed as expected. I had deleted all the extraneous _MACOSX and .gitignore file stuff prior to running it the first time. BTW, the problem in the quoted post was when I converted an ICS build the first time, too. Racks, do you think that there is something that occurs the first time the script is run that is different on subsequent runs that might account for this?
Just installed nightly 28.4 without Opengl and then gapps which appeared in the folder Primary Mod after conversion.
After that I cant get inside shop.I click to open it and it gets me back to main menu.
Any ideas?Reflashing of gapps didnt work.
RASTAVIPER said:
Just installed nightly 28.4 without Opengl and then gapps which appeared in the folder Primary Mod after conversion.
After that I cant get inside shop.I click to open it and it gets me back to main menu.
Any ideas?Reflashing of gapps didnt work.
Click to expand...
Click to collapse
Primary mod is for Primary boot. Default primary boot was CM7, so I'm assuming you formatted /system1 & /data1 before flashing?
Could you also unzip the contents of the converted gapps zip. And check the updater script. All /system variables should be /system1.
-Racks
I didn't format anything before flashing. I thought this as an upgrade, so after conversion I just proceed to flashing.
Finally, I flashed your own gapps that you have at your dualboot topic and now everything is back to normal.
Unfortunately, even after this upgrade, I still continue to deal with FC issues of mail, Facebook and of other random apps.I think there is some problem with my card and CM9, since CM7 runs perfect from emmc or from same mem card.
Unleashed from my Revolutionized Desire HD
Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. Major downside to re-odexing is that you can't easily modify the APK. But honestly, it's not that difficult to simply deodex the APK in question, mod/theme it, then reodex it. I find the benefits are well worth it.
The original script was created by tommytomatoe. All credit goes to him for the actual creation of this script. I simply made a windows batch file to ease the setup and execution of said script.
Please PLEASE PLEASE make a NANDROID backup before you run this. I've never had it mess anything up, but who knows... just back up and be safe!..
ZIP is attached below. Unzip into any directory (make sure the files stay together) and run Dexo.bat - You MUST HAVE BUSYBOX, WORKING ADB (Wireless ADB support is built into the batch file), and ROOT!
I originally had a quick batch file made for just myself.. but I changed things around and made it a bit more user friendly and other things.... I've only tested it ONCE on my own device once (the modified one).. so just be warned.. and make a backup first!
The batch file will not close on its own, when it's done the device will reboot on its own. You can simply just close the window.
Hope this helps some people! Good luck.
--------------------
[What is Odex?]
During the build process, Android can be built with the flag “WITH_DEXPREOPT=true”. This means that the dex files are preoptimized in the build environment using a dalvikVM on the host, as opposed to optimized during boot on the device. The dex-preopt process results in two files per apk or jar – the jar/apk file and its accompanying .odex file.
----------------------
[What is so tricky about reodexing?]
Due to the nature of the dalvik VM (according to documentation in AOSP), the VM expects the optimization process to follow the strict BOOTCLASSPATH.
/* There are some fragile aspects around bootclasspath entries, owing
* largely to the VM's history of working on whenever it thought it needed
* instead of strictly doing what it was told. If optimizing bootclasspath
* entries, always do them in the order in which they appear in the path.
*/
So that is the dex-preopt during the build time. All the vendors ship devices with Odex, ie, stock ROMs are odex. What about ROMs that have been deodexed? Or how do you go about editing the smali code from the odex files? Thank goodness for JesusFreke, we have baksmali and smali. Using the two in sequence, one can successfully convert the optimized dalvik executable (odex) and dissemble it into a human readable (sorta) language called “smali”, created by JesusFreke and resembles the Jasmin language. Anyways, carrying on. Using the dexopt-wrapper binary, you can re-odex your ROM after it has been deodexed. This sounds pretty simple but as stated above, the VM expects the optimization to follow the BOOTCLASSPATH. You cannot silly nilly deodex android.policy.jar and then re-odex it. Your device will not boot. You must transfer the original “signature” from the original odex file to the newly created (Hint, dd if=original.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc). This can be done on a Linux machine or with the busybox binary.
OK. So what is this tool? I just wanted to give a brief (or not so brief) overview of the process. This tool doesn’t deal with partially odexed ROMs. This tool is for odexing a ROM that is completely DEODEX.
The benefits? Faster boot, smaller imprint on /data/ partition, overall faster feeling. The phone will generally just run a little bit faster, system apps will launch quicker..
The myths? I can’t theme ODEX! WRONG! You can theme odex just fine! Just use baksmali and smali.
This requires BUSYBOX.
This requires ADB.
Again HUGE THANKS to tommytomatoe for the original script and his original efforts.
THIS ZIP FILE IS NOT FLASHED IN RECOVERY! You simply extract it to a folder on your hard drive. Then run Dexo.bat, follow on screen instructions. Make sure to nandroid as well as having phone plugged in VIA USB with debugging enabled, or have wireless ADB ready to go.. batch file supports wireless. Just have to follow prompts and enter IP.
ericdjobs said:
Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. [/B][/SIZE]
Click to expand...
Click to collapse
Tried this on my ICS ROM and it works fine.
Thanks!
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
avenged_sevenfold27 said:
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
Click to expand...
Click to collapse
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
ericdjobs said:
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
Click to expand...
Click to collapse
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
masondoctorjt said:
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
Click to expand...
Click to collapse
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
ericdjobs said:
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
Click to expand...
Click to collapse
Thanks... It might be a couple of days before I have a chance to try this again, but I'll let you know if this way works.
Sent from my HTC_Amaze_4G using xda app-developers app
Just ran the manual instructions since I had the same error noted above and all goes well until after the last adb shell dexo command; I get a message saying everything is installed but I also see this: Please install these binaries to continue: sed cp unzip. What does that mean?
Edit: I went ahead and rebooted anyway and nothing happened, still deodexed.
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
kevinrubio1 said:
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
Click to expand...
Click to collapse
Use root explorer or some similar app and go into system/apps and if you see any files right next to the app files that say .odex then you are not deodexed.
Also most custom ROM's state right in the OP if the are deodexed or not.
Sent from my HTC_Amaze_4G using Tapatalk 2
I don't have access to computer so can I run commands through terminal emulator?
Sent from my gt-1900 using xda premium
Doesn't work as of yet...
Followed the instructions
BusyBox Rooted S-off on ViperAmaze 1.7.1 ran the script as Admin and phone restarted after completion of script and stuck on bootscreen.
running fix permission and wiping dalvik+cache just in case if it works will report back EDIT: doesn't work had to recover nandroid
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Dumb and Dumber (remember the movie?)
blindskater39 said:
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Click to expand...
Click to collapse
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Looks like.... IT WORKS on Super Sense 3.2 (coming very soon)! This will speed it up big time!
chevycowboyusa said:
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Click to expand...
Click to collapse
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
blindskater39 said:
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
Click to expand...
Click to collapse
You can. I'm sorry if I complicated that part..
Sent from my HTC_Amaze_4G using xda app-developers app
this may be a stupid question but will this work on cm11?
dtr145r said:
this may be a stupid question but will this work on cm11?
Click to expand...
Click to collapse
No, CM11 is already deodexed.
SuperAfnan said:
No, CM11 is already deodexed.
Click to expand...
Click to collapse
well yea,
i know that.
thats the point, to 'RE-Odex' it....
Instructions:
https://jolla.com/sailfishxinstall/
Download:
http://images.devaamo.fi/sfe/suzu/
thanks to all the guys that worked on this port.
Kernel source:
https://github.com/mer-hybris/android_kernel_sony_msm
This make_ext4fs works for flashing on macOS
For some reason with this build the system-icons vanish for me after restarting the device once :/
I had much better results using this build.
Also by default (at least with the image I linked) only two of the 6 cpu-cores are enabled. To fix that one must add this under the init-section of the /init.loire.pwr.rc file and reboot (All credit for this go to abranson from the #sailfishos-porters irc).
Thanks for this port! are you planning to continue building for Xperia X or is a test build before official release?
Enviado desde mi F5121 mediante Tapatalk
keep going till then, also ive updated the above link
how flash it?
FuLiterary said:
how flash it?
Click to expand...
Click to collapse
read the first post
FuLiterary said:
how flash it?
Click to expand...
Click to collapse
make sure when you are flashing sailfish support only F5121 and does not support sdxc
Hello, friend! I am a Chinese user, I do not understand the tutorial, there is no mor
Jozinek said:
so only Linux or MacOS too?
Click to expand...
Click to collapse
Flashing works on macOS too. You just need to use the make_ext4fs I linked instead of the one linked on top.
janeliang34 said:
Hello, friend! I am a Chinese user, I do not understand the tutorial, there is no mor
Click to expand...
Click to collapse
extract the tar, open a terminal inside the extracted folder and run ./flash.sh
One question. Zip file with AOSP should be moved intact or only vendor folder from inside it?
Seems it has to be whole .zip.
Jozinek said:
i never make something like this in MacOS (i have Macbook Air, but also with Windows), can you write step by step how to make it. This is something totally new for me (i flashed hundreds of XPERIA smartphones, i have Emma tool, but never try this...)
Click to expand...
Click to collapse
Sure thing
First of all your bootloader needs to be unlocked. I'm assuming you already did that but if not you should read about backuping your drm-keys because otherwise they can't be recovered after unlocking your bootloader unless you do that.
If you don't have fastboot installed yet follow this guide.
After that download the first file linked at the top of this thread.
Unpack the archive (if you can't open it I recommend "the unarchiver" from the app-store).
Place both this file and the zip from the third link at the top in the unpacked folder (in the path where the flash.sh is). Don't unpack the .zip file!
After that open a terminal and navigate to your unpacked folder (if you don't know how to do that google for "terminal tutorial mac").
Run
Code:
chmod +x flash.sh
chmod +x make_ext4fs
to mark the flash-script and the make_ext4fs-file as executable.
Boot your device into fastboot mode (hold volume up while it's turned off and plug in your usb-cable) and finally run
Code:
./flash.sh
to install sailfishOS on the device.
If there is a "hybris-recovery.img" file in the directory (can't quite remember if that's the case with this build) also run
Code:
fastboot flash recovery hybris-recovery.img
to install a sailfishOS specific recovery.
After that you can reboot your device and enjoy Sailfish OS
@Jozinek
You didn't unpack the .tar.bz, inside are all files needed to flash. Than You have to move make_ext4fs, AOSP.zip and flash.fs into created (by unpacking) folder and start/cd Terminal there.
Jozinek said:
Edit3 - it worked now, it was bad make_ext4fs, thanks all of you
Click to expand...
Click to collapse
So that means you are doing a review on YouTube, right?
Friend, is there a tutorial for Windows installation? To be more detailed, this is my first contact
janeliang34 said:
Friend, is there a tutorial for Windows installation? To be more detailed, this is my first contact
Click to expand...
Click to collapse
Right now there is no windows support. The final build (which will be officially sold by Jolla) will make windows-installation possible.
If you know your way around cygwin you could probably get it to flash using windows (other than the flash.sh script there's nothing *nix-exclusive).
Is the rom stable enough for daily use ? and is Alien Dalvik available in this rom to run Android apps ?
no android dalvik or any software that needs license, this version is just community version like aosp without play store.
when flashing there's error make_ext4fs: no such file or directory, when i use the second one there's error: wrong exec format
I need help editing the default.prop of my rooted boot.img for an LG LM-X210ULM K8+. I want to mark ro.debuggable off as 1 instead of 0 but which i have no problem doing but when i use any kitchen program it puts it back together as 15mb instead of 32mb and when i flash it to my device it always bootloops.
If any one could help i would appreciate it. Im including a copy of the rooted boot.img freshly pulled ftom my device
The size probably isn't the issue. Using AIK the size was even bigger than the original.
It's all just 0x00 the rest of that partition...
By using my old uImage/_recovery unpack-repack batch file
http://cxzstuff.blogspot.com/2013/03/uimagerecovery-unpack-repack-batch-file.html
the result was smaller but still a bit bigger than the Magisk had made.
But that is irrelevant really... result attached.
Yea i dont get it. The size doesnt matter as long as it diesnt exceed the max amount of space the partition can hold. But why does changing one value cause the boot.img to boot loop after flashing.
Even the boot.img you made looped after flashing
Duhjoker said:
Even the boot.img you made looped after flashing
Click to expand...
Click to collapse
Just tells that it's not the tool used. Or mine oldie is as bad/good as the newer one in this case.
What that Magisk img had was like it had some signature but it should not be needed and probably just garbage left there from the stock...
Should not matter, but how about doing it other way around? Modify the stock boot first and then give it to Magisk for rooting.
I think it was stock. Ill have to make sure though. wonder why magisk doesnt make the image debuggable to begin with. But your right it might be that im using a magisk patched image. Ive got some firmware already broke down ill give it another try here in a bit and post my results.
Duhjoker said:
I think it was stock. Ill have to make sure though. wonder why magisk doesnt make the image debuggable to begin with. But your right it might be that im using a magisk patched image. Ive got some firmware already broke down ill give it another try here in a bit and post my results.
Click to expand...
Click to collapse
So here we are. There should be some shortcut or something left to the original sub forum at least for a week or two when you boys move these threads - dammit...
Any luck? You have a customized recovery? How about these?
https://forum.xda-developers.com/an...g/mod-bootimage-adb-unsecure-patcher-t3618558
Yes luck tonight i did a fresh reflashing on my QC Lg k8+ and decided to break open the boot.bin from the kdz i used and made my changes to default.prop then i put the renamed to boot.img on my phone and let magisk patch it then flashed it via fastboot and dared it to go into system. Then i double dared it. Then for safe measure i double dog dared it to boot into system to which it had no choice but to go along with the or be labled a @!%\**__(€.
It booted.
So the lesson learned is to patch a fresh boot.img with your default.prop changes then have magisk patch it for root.
Now oddly when i patched and tweaked my recovery using carlive kitchen, i also made sure that the same changes to default.prop or rather i made sure they had been made and they had. But any terminal like emulator or termux pulls up the props using getprop with the changes unmade and i still cannot change the values of the system build.prop and when i patch it manually it reverts on reboot.
I literally have to open a vi in twrp to make changes. And forget about copying my own patched build.prop to system in twrp. Because that leads to boot loop as well
Ok so is there a reason that you dont make those changes in the boot.img any more? Because the past two days i have woke up to no root. I have had to reflash my boot.img both times
Ok i just compiled my first kernel from lg source code and now i dont know which of the split images in my folder is the zimage
Back to the drawing board quite literally. Im stuck for sure.
I need to make edits to a few files like init.rc and init.lge.power.rc to allow for changes in my newly compiled kernels. Basically im adding a couple properties and some cpu frequency stuff. Plus i want to make it back to adoptable storage and add a second sd partition for ext4 projects im working that would work best right off the root file system.
Im using the stock extracted boot.img from a kdz using salt and carliv kitchen to unpack and repack i have also mkbootimg tools that i compiled myself and some static arm version.
I extracted the ramdisk place my new kernel image in and repack with the init files changed and flash using recovery or fastboot and bootloop every time. And magisk isnt signing with the verity key.
ok i dont know whst was going on the other day but i can split boot.img again and make changes with out looping.
i used gparted on my linux machine to partition my 128gb sd card with 3/4 vfat and 1/4 ext4 i know that by using adb it will automount but thats one timr and i may need to switch out every now and then plus it put a center part in it of about 15mb. with gparted i get the two parts with no bs. any way i created a script that mounts the second part and even symlinks some stuff. it works good but im having trouble getting init.rc to run it.
on early-init
chmod 0755 /system/etc/init/init.mntsd.sh
exec system system /system/bin/sh /system/etc/init.mntsd.sh
any tips