[Q][NVFLASH]Gain root on stock system image - Android Q&A, Help & Troubleshooting

Hi all, researcher and enthusiast,
I own a complete backup of all partition of the LG P990 with stock ICS, made it with nvflash with a command like this,
Code:
nvflash -r -read <-partition number-> my_partition.img
for all the partition listed in the partition table.
I guess that in someone of that raw image file, (outputted by nvflash), is located the entry system partition, (PartitionId=23 for the LG P990 ICS partition layout).
It's easy for every linux user to mount the raw image file, simply with 'mount' utility.
Browsing them we can find as already hypothesized the entrie android system partition!
If I copying in it the 'su' executable compiled for my platform, it could work?

Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.

louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.
Click to expand...
Click to collapse
Thanks! I'll have a close look to your work now, for others that consider this stuff interesting, louiscypherbr's work is here:
http://forum.xda-developers.com/showthread.php?t=2010671
Nice job!

louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
Click to expand...
Click to collapse
Ok louis, but the partition23 image file after adding su binary or other things is bigger than the previous that we had read with nvflash, right?
If I flash back it with
--bl fastboot.bin --download 23 image.img
how can this work..?
In the part table is write that have been reserved 536.870.912 bytes for the partiton 23, but we want flash an img file bigger than that size (because we added some stuff), this not causes problem?
And what do you mean for careful?

The extracted file is a dd partition image, meaning it's extracted byte by byte. So it includes the empty space, which you can see with "df" command after mounting it.
You can add files that fit in that position and it will be ok when flashed.
Do not say "thanks"; just press it under here.

Stupid thing! You're right!
And, what you mean for careful with perm?
The su binary should be have the setuid bit set in addition to the obvious x, is this enough?

Have you compiled su by yourself...?

louiscypherbr said:
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Click to expand...
Click to collapse
Where have you found the executable of su packed in your v28g louis...???

Hey, sorry for being far from this.
What I was talking about permissions is that you should keep su permissions/owner. I did this just copying the su from a rooted Rom zip to /system/xbin and pasting inside your loop mounted /system with file manager (I'm kde fan, so I used dolphin, the kde graphical file manager, but you can use any other as well).
Sent from my LG-P990 using xda app-developers app

Related

Honeycomb on eMMC (updated download file to the correct one)

I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
If anyone knows how to shrink a partition using parted please let me know. This would eliminate steps 2 & 3
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Install EASEUS (Windows) or gParted (Linux)
(if you need help with this just PM me)
3) Shrink the second partition of the SD card to 400mb
4) Download and extract my zip to your android/platform-tools folder
5) Run Internal.bat
Make sure not to format your sdcard from your nook while using this.
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Download link:
http://www.multiupload.com/0TTH2OJS3C
Uploading fixed version now
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
And for those who like doing everything manually. Here is Sam's modified uRamdisk. Make sure its on the bootpartiton alongside the jar files included in deeper-blue's release
Ramdisk: http://www.multiupload.com/90H38OX0S9
Also, the first time it starts up may take a few min. So be patient before trying to restart it
Thanks this will be very useful for myself and others. I'll report back with any issues.
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
marcusant said:
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Sorry to hear that. I would say you could do it without one but you need the modified ramdisk inside my boot.img
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
tgallant21 said:
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
Click to expand...
Click to collapse
its not rm * its "rm * -r" as that is the recursive switch...
MattJ951 said:
I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Download and extract my zip to your android/platform-tools folder
3) Run Internal.bat
Make sure not to format your sdcard while using this.
Note: I'm not sure if you need to clear your data partition or not. I did, but it may not be required.
the steps under froyo would be : something similar to this (I dd'd HC data partition to the internal, so i'm not 100% sure of this)
Code:
adb shell
mount -o remount,rw /dev/block/mmcblk1 /
mkdir data_temp
mount /dev/block/mmcblk0p6 data_temp
cd /data_temp [B]MAKE SURE THIS COMMAND WORKS BEFORE CONTINUING[/B]
rm * -rf
exit
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Click to expand...
Click to collapse
You have verified this working with your boot.img? Mine gets hampered during the boot and locks up... I had the same issue when I was building my ramdisk for this purpose.... I am going to continue to look into this and will post anything I find.
Cheers!
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Ooglez said:
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Click to expand...
Click to collapse
I believe I may have included an incorrect boot.img in my original upload, im reuploading it now.
As for formatting the sd card, i'll clairfy that in the OP. Don't format the sd card from inside the nook. formatting it inside a computer is fine.
MattJ951 said:
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot <B>alongside the needed jar files included on honeycombs boot.img)</B>
Click to expand...
Click to collapse
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
modembug said:
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
Click to expand...
Click to collapse
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Click to expand...
Click to collapse
Thanks for updating so quickly. I've been waiting to run Honeycomb off of EMMC. I'll let you know how it goes.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
Click to expand...
Click to collapse
I am getting ready to dd that image over as we speak, i will report back shortly...
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
MattJ951 said:
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
Click to expand...
Click to collapse
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
UPDATE: okay, so its still locking up... did you dd the data partition or any of that stuff over as well? as of right now, i am running your boot.img and i DD'd the system partition from a working HC-SD, and i removed all files from the internal /data partition....
modembug said:
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
Click to expand...
Click to collapse
Let me know if it works. The "Android _" screen originally locked up for me because of the uRamdisk. I'll upload the one Sam sent me which is included in the boot.img but maybe is causing problems for you.
The modified uRamdisk is now in the OP.
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
modembug said:
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
Click to expand...
Click to collapse
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
MattJ951 said:
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
Click to expand...
Click to collapse
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
modembug said:
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
Click to expand...
Click to collapse
That actually is my current /boot inside the 7z. Also i can't think of a reason why it wouldn't work.
I'll format my NookColor and try it to see if I can figure out whats going wrong.

Flash image gui?

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.

[SCRIPT/TOOL] Convert2Dualboot-SD Tool v1.4[Linux/OSX/Android/DOS][6/8]

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

Rooted XXALJL boot.img

This boot.img, attached, provides a root shell directly over adb. It is a simple modification of the stock XXALJL boot.img and could be useful for ROM developers who need to adb remount frequently, while still using the stock boot/kernel. I do not recommend this method for users in general since it is very insecure (SuperUser gives you more fine-grained permission control).
Flash it with Odin or under Linux:
Code:
heimdall flash --18 XXALJL-rooted.boot.img
WARNING: contrary to the system.img root method, this WILL increase your download count!
EDIT: in fact it would be better to simply dd the img file into mmcblk0p20, should not increase the download count.
Be careful, this also disables auto updates (now it says the device has been modified, and won't allow OTA updating).
xd.bx said:
Be careful, this also disables auto updates (now it says the device has been modified, and won't allow OTA updating).
Click to expand...
Click to collapse
are you tested if work with custom recovery ?
xd.bx said:
This boot.img, attached, provides a root shell directly over adb. It is a simple modification of the stock XXALJL boot.img and could be useful for ROM developers who need to adb remount frequently, while still using the stock boot/kernel. I do not recommend this method for users in general since it is very insecure (SuperUser gives you more fine-grained permission control).
Flash it with Odin or under Linux:
Code:
heimdall flash --18 XXALJL-rooted.boot.img
WARNING: contrary to the system.img root method, this WILL increase your download count!
Click to expand...
Click to collapse
I just dumped your image and....
Forgive for being i bit confused but in order to have a rooted Insecure image don't you need to set ro.secure=0?
This your Default.prop dumped from your image
Code:
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=1
Also why is there no root binarys in the image?
So, as far as i can see the only thing this image will do is increase you binary count, nothing else.
If im wrong i apologize in advance.
faria said:
So, as far as i can see the only thing this image will do is increase you binary count, nothing else.
If im wrong i apologize in advance.
Click to expand...
Click to collapse
I did try setting ro.secure to 0 but it didn't work. So I simply patched the setuid/setgid arm instructions inside adbd so that it never drops its privileges, no matter what. (it's very straightforward to do with objdump+a hex editor).
spawk said:
are you tested if work with custom recovery ?
Click to expand...
Click to collapse
I haven't, no.
xd.bx said:
I did try setting ro.secure to 0 but it didn't work. So I simply patched the setuid/setgid arm instructions inside adbd so that it never drops its privileges, no matter what. (it's very straightforward to do with objdump+a hex editor).
Click to expand...
Click to collapse
I see,
I believe that the best way to achieve what you want is to split the boot image ,then dump the the ram disk, edit its contents then rebuild the image.
I have wrote a linux script that does all of that if you are interested .
faria said:
I see,
I believe that the best way to achieve what you want is to split the boot image ,then dump the the ram disk, edit its contents then rebuild the image.
I have wrote a linux script that does all of that if you are interested .
Click to expand...
Click to collapse
Thanks, indeed I am. BTW I just realized it would be much better to root through system.img and then flash by using dd into mmcblk0p20. This way the download count should stay the same.
xd.bx said:
Thanks, indeed I am. BTW I just realized it would be much better to root through system.img and then flash by using dd into mmcblk0p20. This way the download count should stay the same.
Click to expand...
Click to collapse
Our current method of rooting, using the System image does not increase the binary count.
Here is the script
You will need the abootimg tools installed in linux.
unzip the package ,delete everything inside the folder except the unpack file.
Copy the boot.img to the folder.
double click on the unpack file and launch as terminal
Follow the instructions in terminal window.

[Titanium Backup] Failed to protect backup

Tried every method...but I'm unable you protect my backups in titanium backup
To protect*
How I solved this problem on my Moto G LTE
Shantanu Baviskar said:
Tried every method...but I'm unable you protect my backups in titanium backup
Click to expand...
Click to collapse
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
_jis_ said:
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
Click to expand...
Click to collapse
Although in the case of Note 4 it didn't work right off the bat, I made it work a little different thanks to your idea. For some weird reason the script just doesn't get executed at boot (neither the *.sh file, nor as a script, through ROM Toolbox) but I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
As a mention for those interested in replicating all these: the suggested SD card fix made by rummy applies EXACTLY the same changes as the SDFix so you can use either of them. Again, thanks for your reply and the great idea! :good:
nacos said:
I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
Click to expand...
Click to collapse
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
_jis_ said:
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
Click to expand...
Click to collapse
This update addresses the issue mentioned before about init'd scripts not executing at boot. OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr. I've tested it and it's working, however it doesn't work directly with <X.sh> text files, instead the script must be packaged in a flashable zip and flashed from recovery. Once I did that, it worked like a charm! The 98mediarw file in the screenshot uses the same script as previously mentioned; The 98 before the file name assigns a higher execution priority - I used 98 for testing purposes, it clearly doesn't need that. :good:
nacos said:
OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr.
Click to expand...
Click to collapse
Oh, at first I thought that you post something what helps me with my tablet:
_jis_ said:
I solved this problem on all my phones but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk.
Click to expand...
Click to collapse
But this is just another example how to execute script at boot
none of these methods are working. Is it because I'm using a Custom ROM?
What are you trying to achieve? What exactly is your environment?
nacos said:
What are you trying to achieve? What exactly is your environment?
Click to expand...
Click to collapse
I have Motorola Moto E (CM11 Stable build by percy_g2) and I'm trying to protect my backups in TiB but I'm getting error "Sorry, the operation failed." It used to be the same in stock ROM. And one more question, is this bug fixed in Lollipop versions of Android?
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
nacos said:
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
Click to expand...
Click to collapse
(Please ignore that screenshot. I didn't properly read your msg in blue text)
I couldn't understand post #4 so can you please describe it more deeply? :crying: btw I don't have 00test but a file named 00banner. And can you tell me how to use tasker properly?
Sorry for butting in on this thread. I found it by searching because I too can no longer protect a backup in my tibu Pro. I used to be able to but not anymore and I'm not sure why.
I'm on a rooted nexus 5 running stock 4.4.4.
Reading your instructions I went looking for platform.xml and found it. When I checked its properties I got, see screenshot. Don't know what to modify to mount it as you say. I'm in ES Explorer.
Can you help?
Thanks.
And here is a screenshot in root Explorer
Update your tb to 7.0.1 and now you can protect backups ? this thread should get closed now
Closed? Why? Just because a shortcut is available doesn't mean there is nothing to learn from wondering around, my friend!
After all, this is exactly what XDA is: a huge data base available to those who are willing to learn and dare to wonder around, wouldn't you agree?

Categories

Resources