CWM for Galaxy Player 5.0 US (YP-G70XAA) - Samsung Galaxy Player 4.0, 5.0

CWM for Galaxy Player 5.0 US (YP-G70XAA) - Samsung Galaxy Player 4.0, 5.0

Hello all,
I'm working on porting CWM to our beloved Galaxy Player 5.0 US edition. I'm loosely following the guide here. I cannot promise that I'll be able to port it successfully, but I can promise that I'll brick my device at least once.
tl;dr : This post says some guy is working on CWM. Woot!
-apapousek

Your sending it to the people are you? And good luck, I only wish I knew how to do this

Apapouseck-
Are you a dev? PM me and give me your email address please. I have a question.
Sent from my Galaxy Nexus using xda premium

azoller1 said:
Your sending it to the people are you? And good luck, I only wish I knew how to do this
Click to expand...
Click to collapse
Of course I'm distributing it. Once I get a working copy, it's being thrown on github, or my own server, and given freely, open source, blah blah blah. No proprietary crap, except maybe enough drivers to get it up and running. But sources for those, too.
cramjammer said:
Apapouseck-
Are you a dev? PM me and give me your email address please. I have a question.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Well, technically not a dev. I just like taking software, messing around with it, seeing what it can do. My email address is [email protected]

Can't wait
Sent from my YP-G70 using Xparent Blue Tapatalk

That post, as it says, doesn't cover Samsung devices. It turns out that a while back, Koush made a commit to mkvendor.sh that allows it to operate without an example boot.img.
However, the problem is that there's a remaining bug in mkvendor.sh that TMPDIR is not set in the code path that is triggered when you don't specify boot.img
Right now I'm at a state where CWM starts and runs, but somehow it is treating the tilt sensor as volup/voldn input - so the thing scrolls eternally.

Entropy512 said:
That post, as it says, doesn't cover Samsung devices. It turns out that a while back, Koush made a commit to mkvendor.sh that allows it to operate without an example boot.img.
However, the problem is that there's a remaining bug in mkvendor.sh that TMPDIR is not set in the code path that is triggered when you don't specify boot.img
Right now I'm at a state where CWM starts and runs, but somehow it is treating the tilt sensor as volup/voldn input - so the thing scrolls eternally.
Click to expand...
Click to collapse
Maybe you need the s3c-keypad file to correct this or changing somewhere in the source /dev/input/eventX to another one.

Looks like I need to figure out how to filter out /dev/input/event1, and only pay attention to event4 and event5 (or just event4)

I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)

Entropy512 said:
I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)
Click to expand...
Click to collapse
I'm glad you got a clockworkmod which seems to work. Let us know what koush says and if it'll be official support to CWM on our devices.

Yup.
Main things you need to consider when building:
1) The recovery.fstab for Samsung devices isn't appropriate for CWM. One appropriate for CWM has just three entries:
mount point, filesystem, device
The filesystem format options (fourth and fifth columns) seen in stock recovery.fstab will screw up CWM
2) /dev/input/event1 MUST be filtered on SGP5 US devices (and probably international too) - the accelerometer spams keystrokes. This is in ev_init() in minui/events.c
3) Recovery.fstab can't be in /etc - but this path is hardcoded in CWM so you must change the path in roots.c - SGSII seems to use /misc instead of /etc - this is in load_volume_table() in roots.c

Entropy512 said:
Yup.
Main things you need to consider when building:
1) The recovery.fstab for Samsung devices isn't appropriate for CWM. One appropriate for CWM has just three entries:
mount point, filesystem, device
The filesystem format options (fourth and fifth columns) seen in stock recovery.fstab will screw up CWM
2) /dev/input/event1 MUST be filtered on SGP5 US devices (and probably international too) - the accelerometer spams keystrokes. This is in ev_init() in minui/events.c
3) Recovery.fstab can't be in /etc - but this path is hardcoded in CWM so you must change the path in roots.c - SGSII seems to use /misc instead of /etc - this is in load_volume_table() in roots.c
Click to expand...
Click to collapse
Koush put this up at rootzwiki.

apapousek said:
Koush put this up at rootzwiki.
Click to expand...
Click to collapse
I've seen it - if you read it, it's just some "best practices" document that says what you should do after you've managed to compile a working CWM recovery binary - however, I have not seen a single kernel that integrated CWM the way he says, even ones coming from very talented developers (like codeworkx)

Entropy512 said:
I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)
Click to expand...
Click to collapse
Could you post how you achieved this partial state? I'm busy downloading cm, which is just fun

I'll try to when I have some time... next few days are going to be busy.
Very quick summary:
Need to fix mkvendor.sh so TMPDIR is set when you don't provide a bootimage argument, otherwise the device tree doesn't get created properly
Need to pull recovery.fstab from the device and make it CWM-compatible (Only three columns: mount point, fstype, mount device) by removing all the Samsung-specific cruft - look at the SGSII recovery.fstab for an example of what it should look like
Put in the partition sizes and such in BoardConfig.mk
Need to do the source edits to CWM I mention a few posts above - both are oneliners. I'll try to post a patch when I have the time
Once you build by "make recoveryzip" you need to manually go and copy the recovery binary and all its symlinks into the initramfs - it's in out/target/product/samsung/yourdevicenamehere/ somewhere

dammit...
Something is not working right. Nandroid restores aren't restoring properly... The restores always seem to get corrupted.
****ing RFS... I hate it.
Somehow restored directories are FUBAR:
Code:
ls: ./tts: No such file or directory
ls: ./bin: No such file or directory
ls: ./app: No such file or directory
ls: ./xbin: No such file or directory
ls: ./vendor: No such file or directory
ls: ./firmware: No such file or directory
ls: ./usr: No such file or directory
ls: ./fonts: No such file or directory
ls: ./lib: No such file or directory
ls: ./media: No such file or directory
ls: ./modules: No such file or directory
ls: ./vsc: No such file or directory
-rw-r--r-- 1 root root 2437 Sep 16 21:35 build.prop
drwxr-xr-x 1 root root 0 Jan 9 23:24 cameradata
-rw-r--r-- 1 root root 44 Sep 16 21:35 default.prop
drwxr-xr-x 1 root root 0 Jan 9 23:24 etc
drwxr-xr-x 1 root root 0 Jan 9 23:24 framework

Entropy512 said:
I'll try to when I have some time... next few days are going to be busy.
Very quick summary:
Need to fix mkvendor.sh so TMPDIR is set when you don't provide a bootimage argument, otherwise the device tree doesn't get created properly
Need to pull recovery.fstab from the device and make it CWM-compatible (Only three columns: mount point, fstype, mount device) by removing all the Samsung-specific cruft - look at the SGSII recovery.fstab for an example of what it should look like
Put in the partition sizes and such in BoardConfig.mk
Need to do the source edits to CWM I mention a few posts above - both are oneliners. I'll try to post a patch when I have the time
Once you build by "make recoveryzip" you need to manually go and copy the recovery binary and all its symlinks into the initramfs - it's in out/target/product/samsung/yourdevicenamehere/ somewhere
Click to expand...
Click to collapse
Can you post the patch with the modifications in the source? Thanks!

Attached patch and my current recovery.fstab - remove the .txt extensions
Still not exactly working... RFS formatting seems busted.

Figured out the formatting problems - a few services running from /system were preventing it from unmounting properly.
I did a successful Nandroid restore - things are close now. I may just need to tweak recovery.fstab a bit more to have RFS format/restore/backup fully working.
Voodoo Lagfix - whole other story...

Entropy512 said:
Figured out the formatting problems - a few services running from /system were preventing it from unmounting properly.
I did a successful Nandroid restore - things are close now. I may just need to tweak recovery.fstab a bit more to have RFS format/restore/backup fully working.
Voodoo Lagfix - whole other story...
Click to expand...
Click to collapse
It's a step closer and a BIG advance if we got CWM working on our devices. Really thank you.

Related

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.

di11i kernel beta .01 (unsecure boot.img- root shell, adb remount) ext4 tweaks/init.d

This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon
still working on the actual kernel, will release that next, still have lots of work to do
boot.img MD5- fca41dba8f4699b67fd461a1632b65cf
MAKE BACKUP FIRST
You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--
Code:
adb push boot.img /sdcard/
adb shell
su
dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
reboot
#Thanks Diamondback and friends for offsets
This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
NOT COMPATIBLE WITH CM-9

di11igaf said:
This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon
still working on the actual kernel, will release that next, still have lots of work to do
boot.img MD5- fca41dba8f4699b67fd461a1632b65cf
MAKE BACKUP FIRST
You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--
Code:
adb push boot.img /sdcard/
adb shell
su
dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
reboot
#Thanks Diamondback and friends for offsets
This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
Click to expand...
Click to collapse
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.

MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.
Click to expand...
Click to collapse
ICS kernel source is on the global download site.

Doktaphex said:
ICS kernel source is on the global download site.
Click to expand...
Click to collapse
Correct but thats an older source code V9.4.2.7 right?

MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?
Click to expand...
Click to collapse
True, I don't know how much they have changed since then. Surely they need to be releasing new source pretty quickly to be in compliance with the license. I don't know enough about that side of things though.

prime has a BLOBSIGN signature in the first 28 bytes of the blob files for prime.
you just need to copy those 28bytes from an existing blob file that works.
this is of course only working on a unlocked prime. then the BLOBSIGN signature is not checked, so anything can be pasted in front of it.
Rayman will update the packblob to include the signature later on.

MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.
Click to expand...
Click to collapse
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk

jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!

jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!
Click to expand...
Click to collapse
Flashing blobs does NOT always work. No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...
Asus really screwed up with this Unlocker thing....

MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!
Click to expand...
Click to collapse
No problem. I'm surprised it didn't work for you after you made changes.
Diamondback said:
Flashing blobs does NOT always work. No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...
Asus really screwed up with this Unlocker thing....
Click to expand...
Click to collapse
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?
Click to expand...
Click to collapse
The kernel versions seem to be the same with the latest .15 build as the previous one. I wonder if they just recompiled the same source and that's why the host name changed to Mercury.
EDIT: I'm going to pack this kernel into a flashable blob and attach it here.

jermaine151 said:
No problem. I'm surprised it didn't work for you after you made changes.
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
Click to expand...
Click to collapse
Hmm.. not sure whats going on but I did use this command
Code:
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
To recompile the boot.img then used the new blobtoolsv2 to repack the blob
Code:
blobpack -s kernelblob blob.LNX newboot.img
I know staging is unmounted because I'm using your updater-script

jermaine151 said:
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
Click to expand...
Click to collapse
if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.
so it can easily become a problem if p4 is mounted.
at least thats how i experienced the problem when seen initially.

Dexter_nlb said:
if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.
so it can easily become a problem if p4 is mounted.
at least thats how i experienced the problem when seen initially.
Click to expand...
Click to collapse
That's why I said to always add an unmount("/staging"); to the top of your script. The attached flashable zip works perfectly on the official CWM; staging is not mounted by default, but I told the script to unmount it anyway in case someone with the unofficial CWM tries to flash it. If it's already unmounted, the script just continues.
Anyone may use this as a template for consistently flashing a kernel to staging.

MasterZen88 said:
Hmm.. not sure whats going on but I did use this command
Code:
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
To recompile the boot.img then used the new blobtoolsv2 to repack the blob
Code:
blobpack -s kernelblob blob.LNX newboot.img
I know staging is unmounted because I'm using your updater-script
Click to expand...
Click to collapse
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?
EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.
Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:
http://forum.xda-developers.com/showthread.php?t=1193737

jermaine151 said:
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?
EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.
Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:
http://forum.xda-developers.com/showthread.php?t=1193737
Click to expand...
Click to collapse
Okay that makes sense. One f my changes was to default.prop for insecure boot.img
Code:
ro.secure=0
This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol

MasterZen88 said:
Okay that makes sense. One f my changes was to default.prop for insecure boot.img
Code:
ro.secure=0
This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol
Click to expand...
Click to collapse
LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.

jermaine151 said:
LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.
Click to expand...
Click to collapse
Would love to be on that side of the tracks. I'm banging my head against the wall right now trying to figure out how to implement Microsoft System Center Service Manager 2010 and on top of that one of our Citrix Broker boxes went down last night... Not a funny day at all. But I'll keep this thread about Android...for now....

No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.
Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)
So blob flashing obviously has some quirks....

Diamondback said:
No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.
Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)
So blob flashing obviously has some quirks....
Click to expand...
Click to collapse
I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.

jermaine151 said:
I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.
Click to expand...
Click to collapse
We only had it one time too, but one time is enough to scare me further
This whole blob stuff just is crap

[SCRIPT/FIX] Internal sdcard permissions (/data/media/)

This should be applicable to any ROM on devices which share internal storage for applications and the internal "sdcard" (Note II, SGS3, probably others). Symptoms may include inability to take screenshots and other failures, and will usually show a "Permission denied" in logcat for files under /data/media/. The underlying problem is that permission is denied to the filesystem, even by the root user when the ROM is booted (this is strange and I still don't understand why). Running "Fix permissions" did not fix this issue for me (that script doesn't change any permissions on the sdcard).
When booted into recovery (ClockworkMod was tested in my case), root has the ability to reset the permissions properly. To fix the problem, connect with adb while booted in recovery and run the following commands to correct the permissions:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
UPDATE (Credit to @Quinny899) If that does not work, you may also want to reset the SELinux contexts for the media partition with this command:
Code:
restorecon -FR /data/media/
Hope this helps! :victory:

I recently restored a Nandroid backup of my old Nexus 7 on a replacement Nexus 7. Most everything worked okay, but screenshots, deleting certain files and directories, and other basic operations weren't really working, and "Fix permissions" didn't help.
Running the commands here worked like a charm! I used TWRP and I have JellyBeer 4 on my Nexus 7. Thanks!

skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!

xak944 said:
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
Click to expand...
Click to collapse
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!

Yeah it's kinda funny. I had that script posted up in the ADBsync thread back in February because I noticed things could start acting funny when I restored an entire sdcard backup to one of my devices. But hey, great minds think alike! Good work all around!
Thanks @TheByteSmasher for bringing another use for the zip to my attention! I didn't know those things had a tendency to go awry on their own as well!
Edit:
Here's the edify script equivalent of the above, plus the proper original perms for /data/media itself, and the special perms that CWM likes its subfolder to have (root + all). TWRP keeps its backups under the primary user subfolder (/data/media/0) and doesn't seem to care as much.
cwm-sdcard.Fix.Permissions.zip/META-INF/com/google/android/updater-script:
Code:
ui_print("");
ui_print("sdcard Fix Permissions Script");
ui_print("by osm0sis @ xda-developers");
show_progress(1.34, 0);
ui_print("");
ui_print("Mounting...");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.2);
ui_print("");
ui_print("Setting /data/media to media_rw and fixing...");
set_perm_recursive(1023, 1023, 0775, 0664, "/data/media");
set_perm(1023, 1023, 0770, "/data/media");
set_progress(0.8);
ui_print("");
ui_print("Setting /data/media/clockworkmod perms...");
set_perm_recursive(0, 0, 0775, 0777, "/data/media/clockworkmod");
set_progress(1.0);
ui_print("");
ui_print("Unmounting...");
unmount("/data");
set_progress(1.2);
ui_print("");
ui_print("Done!");
set_progress(1.34);
Available over in my Odds and Ends thread as TheByteSmasher mentioned before.

Nice. Good to know this is a well known issue, I thought I was nearly alone (and it drove me up the wall for a while until I figured it out).
Does anyone know what is technically causing even the root user not to be able to write? I'm curious.

Probably because even root apps only run root commands when they need to, so for simple stuff could run into the same issue. Just a guess, but makes sense.

I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').

xak944 said:
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
Click to expand...
Click to collapse
Osm0sis actually states in the description of his zip, that when you use ADB push to put some stuff on the SD it can mess with the permissions... that's what did it for me.. but I guess a nandroid restore can cause it too depending on how it performs the action.
Sent from my Nexus 4 using Tapatalk 4 Beta

I'm ditching the idea of editing fix_permissions. The way they do all the system files is extremely intelligent and done on-the-fly based on the contents of certain system files to trace through. Adding something specifically for internal sdcards, even with the appropriate checks, would be a hack compared to all the really great work they've done to make the script device-nonspecific.

Deleted

1990mustafa said:
Deleted
Click to expand...
Click to collapse
Could somebody point me in the direction of how to do this for the Note 3 SM-9005 please?
I have an internal SD permissions issue and the flashable zip doesn't work, I presume because the directories are located slightly differently.
Many thanks

i m also stuck in same boat as none of scripts work for note 3... need some help / guidance here ..

You saved me, i was playing with ubuntu touch and i forgot that symbolic links and chown always modify the original directory and twrp could not fix the permissions!

Thank you! Works like a charm! :highfive:

Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
[email protected] said:
use for fixing access
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Worked a dream, might be useful for anyone else

Quinny899 said:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
Worked a dream, might be useful for anyone else
Click to expand...
Click to collapse
worked perfectly!

Hey, big THANKS to everyone who contributed to this thread. I restored by SD a different way than I used to do it and had this issue. I figured it was a permissions issue but couldn't get the 'Fix Permissions' function in TWRP or ROM Manager to fix it (now I know why). This saved me, much appreciated!

Quinny899 said:
Code:
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Oh man, so it was SELinux causing these issues all along!? I wonder why my original fix worked then since it didn't reset the SELinux context... Oh well, good to know.

Thanks @TheByteSmasher for leading me to the right solution
TheByteSmasher said:
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Click to expand...
Click to collapse
Thanks again
osm0sis said:
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc.
General Information
In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller scripts and zips I've created that I don't think merrit their own separate threads. This is partially for my own sanity and will hopefully make it easier for others to find some things as well. A lot of the stuff here was developed with the GN or N7 (my devices) and Windows in mind, but could generally be applicable to most devices either out-of-the-box or with some slight modification. If you see something that inspires you, go ahead and mod it, just let me know and give me some credit somewhere. If anyone would like to know the specifics of what's in a particular script that I haven't already linked to more information on, just let me know and I'll post that in here as well. Thanks!
Misc./Batch Tools
AnyKernel 2.0 (many devices) - link
AnyKernel was a simple template for an update.zip that could apply any kernel to any ROM, regardless of ramdisk to reduce the chance of any issues arising from the custom kernel pairing. The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. AnyKernel 2.0 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the install experience.
Android Image Kitchen (many devices) - link
A collection of Windows/Android ports of the necessary Linux utilities for Android image (kernel+recovery) mod work, and my own automation script to unpack, edit and repack the ramdisk. Other guides/scripts exist but none of them are universal for target device, compression and/or developed for Windows/Android. Now also Linux builds to bring my improved featureset back to where it came from. Has been extremely useful for me in my messing around with kernel ramdisks.
ADB Screenshot (all devices) - attached
Take screenshots while in recovery. Useful for development of recovery apps or error reporting. Original method had lots of different threads around with the general method for various devices but I figured out a couple tricks required for getting it working on the Galaxy Nexus and then automated the process. Tested and confirmed working with both pixel formats of CWM and TWRP. More information in this GN Q&A FFmpeg thread. New method uses fb2png and should work on all devices.
ADBsync sdcard Backup (many devices) - attached
Backs up the entire sdcard so that you can have a complete snapshot of your device when you make periodic backups, and be able to restore things exactly as they were. Automates the sync process of Renate NST's great ADBsync utility which makes only newer files get pulled, significantly decreasing backup time for the sdcard compared to "adb pull". Original version posted in the old ADBsync thread. Defaults for devices with /data/media/ internal sdcards (Nexus devices, etc.), but is easily customizable to backup other mountpoints.
Flashable Zips
Nexus BootUnlocker script (GN, N4, N5, N7 '13, N10) - attached
I don't know about everyone else but sometimes I find I've rebooted into the bootloader only to realize I've forgotten to unlock it in segv11's excellent BootUnlocker App beforehand. Well, I decided to make a BootUnlocker Script for my Galaxy Nexus so I could just boot to recovery quickly, unlock, then adb reboot-bootloader (or use my Reboot To Bootloader script below) to get back without having to fully boot the OS to make the change. Also extremely useful in the case you aren't able to boot. As with the app there is no data loss like there would be with fastboot, allowing you to relock for safety. Originally posted in the GN EDIFY Scripting thread. Modified for the newer Nexus devices and combined into a single Nexus BootUnlocker zip with tamperbit reset support added using information from the BootUnlocker App Dev thread.
N7 BootUnlocker script (N7 '12) [creation guide] - link
The Nexus 7 2012 is a special case. Per-device encryption of an entire partition makes it impossible to support the N7 '12 in a simple root app, or flashable zip as above, however using my guide and included script you can now create a working BootUnlocker Script Zip for your specific device. As with the above scripts there is no data loss like there would be with fastboot, allowing you to relock for safety.
Flashify script (many devices) - attached
This script zip makes flashing boot.img (kernel), recovery.img, and radio.img/modem.img (baseband) files via recovery simple. Inspired by cgollner's powerful and visually stunning Flashify App, it aims to save the average user the hassle of repacking their own image zip, or using the command-line or fastboot to flash it. Place an appropriately named file in the same directory as the zip and flash away! Should work on all emmc devices with normal partition naming ("boot", "recovery" and "radio" or "modem") which accept Android standards-compliant images. Extremely handy when used with amarullz' brilliant AROMA Filemanager, and/or my Android Image Kitchen: Mobile Edition (linked above).
Kernel Emergency Reset script (many devices) - link
Basically a go-to cure-all for custom kernel users experiencing issues after an upgrade due to old settings left over in a kernel control app (eg. franco.Kernel updater, Trickster, etc.), or problematic init.d/userinit.d scripts. It's also useful if you just want to make sure you're running clean defaults without conflicts.
Reboot To Bootloader script (all devices) - attached
Those who prefer using CWM may have noticed a couple of things missing that the other popular custom recovery, TWRP, has built-in. One of these is a file explorer/manager, which is answered by amarullz' brilliant AROMA Filemanager. Another thing I found myself wanting is a way to reboot back to the bootloader once I'm in recovery, so I created this very very simple flashable zip script. (No longer required on CWM >=6.0.3.5). Note: Once in the bootloader, "Start" will boot you back to recovery. Not sure why, but it's not a big deal, just reboot normally from recovery at that point.
sdcard Fix Permissions script (many devices) - attached
A little flashable zip script to fix ownership and permissions of files and directories on the sdcard to what they would be if Android OS had put them there itself, since some apps can't access pushed files that have root.root as owner/group. This is useful when restoring to your sdcard backup, as with my ADBsync sdcard Backup batch script above, since generally, pushed files get root.root from adb shell and higher permissions than usual. Also a solution for a bug where sdcard files get lower permissions somehow, resulting in similar access problems. Currently written for devices with /data/media/ internal sdcards (Nexus devices, etc.), but could easily be modified for other mountpoints.
nano Terminal Editor v2.2.6 Installer (all devices) - attached
A simple installer to push bgcngm's great Android port of the nano editor binary to /system/xbin/ along with the required files in /system/etc/terminfo/. It can then be used from Terminal while booted from that point on. Each time you flash it also temporarily enables use in recovery by pushing a script to /sbin/nano with the required environment variables, so you can then trigger it from recovery shell or the console in amarullz' brilliant AROMA Filemanager. Makes it extremely easy and worry-free to tweak and mod on the go, knowing you can edit the faulty build.prop or init.d script if something goes wrong. This script could also be added to recovery to make the functionality permanent.
odex Script Installer (all devices) - attached
Based on the great work and binaries from this thread, a simple installer to push my odex script along with the required dexopt-wrapper and zip binaries to /system/xbin and set the appropriate permissions. Automates the procedure to odex any apk or jar from the commandline to potentially improve performance. Dalvik runtime only. Also uses cut from busybox.
Kernel init.d Support Injector (many devices) - attached
Following from great ideas by Captain_Throwback in my AnyKernel2 thread and using script from my Flashify script above, this AK2 zip will inject basic init.d bootscript support into any kernel ramdisk on any emmc device with normal partition naming and using the Android bootable image standard, without having to bloat a ramdisk using a busybox binary. This zip is also signed, so could potentially be used with stock recovery on a locked bootloader, but that depends on the stock recovery supporting grep, etc. for the zip script to perform the required file changes.
Dev Team init.d Pack Installer (all devices) [see "950iosettings, etc." below] - link
A simple installer I wrote to create the /system/etc/init.d/ directory, extract the latest init.d scripts as published by the "Franco's Dev Team" tuning collective (of which I'm a member), then set correct owner, group and permissions to the entire init.d directory. Link points to my Dev-Host since these may still be subject to change from time to time. If you are a developer and would like to include these tunables/scripts in your kernel or ROM please provide credit. A lot of time and effort has gone into this project and that's all we ask.
Credits & Thanks: All authors of any included binaries and libraries for their amazing work. Anyone who's helped me with these projects along the way.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
XDA:DevDB Information
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc., Tool/Utility for the Android General
Contributors
osm0sis
Version Information
Status: Stable
Created 2013-11-13
Last Updated 2015-03-30
Click to expand...
Click to collapse

[CM7][GP3.6][LOGCAT] CM7 porting - Need some help

Hello XDA community for the GPs,
some of you may heard about my project to port CyanogenMod 7.2 to the Galaxy Player 3.6.
The thing is.. I got it successfully compiled and installed on my player but it won't boot (it is stuck at zygote).
So I thin here are some really good CM porters and experts which could may help ... so...
Please be a community and help me a bit
The poor thing is that I'm the only dev for this device.
Here are some files...
If you need more information or files.. LET ME KNOW!
Here's the init.rc which I'm using to boot (I used the stock one as a base to write a new init.rc)
http://pastebin.com/nbkubMyx
That's the init.<devicename>.rc (devicename: aalto) (I fixed some things on the kernel so it gets executed)
http://pastebin.com/g0FxQUja
That's the logcat which gets made via init.rc (service: logcat)
http://pastebin.com/bN4yfPiq
Here's the logcat which gets made via ADB
https://www.dropbox.com/s/j1zbganc8whowly/log
Device tree
https://github.com/androthan/android_device_samsung_aalto
Thanks for any help in advance

If the 3.6 is anything like 5.0, the stock gingerbread had much more in it's initramfs than CM puts in there. Alot of the paths in the stock init.rc and init.(device).rc may point to locations expected to be there in the initramfs which cm has moved to the /system dir. You might want to try looking at the init.rc and init.(device).rc for a device that has a similar partition layout( and CM7 working). Maybe use that as a base instead of stock init.rc???
I've never built CM7. I'm actually pretty new to building CM but it looks like you've got mount point problems....
Hope this helps

This commit shows how mounting was done in for the 5.0 in CM7 : https://github.com/ambrice/android_...mmit/891c1f59058d4d7e082d44ca40f9fcf3addd6188 . Not exactly sure how far @ambrice got with CM7 though...
I know that the partition table is different for 3.6 but I thought it might give you an idea of how it's should be.
EDIT: I should mention that in the 5.0, we try to mount ext4 first but we fail back to rfs if we can't mount ext4....
Another thing I noticed is that you are trying to mount mmcblk0p1. I don't know how it is on the 3.6 but on the 5.0 that partition represents the entire extended partition and I don't think it can actually be mounted....

Meticulus said:
This commit shows how mounting was done in for the 5.0 in CM7 : https://github.com/ambrice/android_...mmit/891c1f59058d4d7e082d44ca40f9fcf3addd6188 . Not exactly sure how far @ambrice got with CM7 though...
I know that the partition table is different for 3.6 but I thought it might give you an idea of how it's should be.
EDIT: I should mention that in the 5.0, we try to mount ext4 first but we fail back to rfs if we can't mount ext4....
Another thing I noticed is that you are trying to mount mmcblk0p1. I don't know how it is on the 3.6 but on the 5.0 that partition represents the entire extended partition and I don't think it can actually be mounted....
Click to expand...
Click to collapse
The mmcblk0p1 is the efs partition which is why it is needed to be mounted as reperesented here:
https://github.com/zaclimon/initramfs-ypgs1/blob/master/init.aalto.rc#L68
However he looks like he doesn't put the mounting flags to his partition so that to be done as well. Also those devices mounts as ext4 by default as well.

Meticulus said:
If the 3.6 is anything like 5.0, the stock gingerbread had much more in it's initramfs than CM puts in there. Alot of the paths in the stock init.rc and init.(device).rc may point to locations expected to be there in the initramfs which cm has moved to the /system dir. You might want to try looking at the init.rc and init.(device).rc for a device that has a similar partition layout( and CM7 working). Maybe use that as a base instead of stock init.rc???
I've never built CM7. I'm actually pretty new to building CM but it looks like you've got mount point problems....
Hope this helps
Click to expand...
Click to collapse
zaclimon said:
Yeah that's what I've seen. Though here's a beginning for what you can do @Androthan
1. Make a cleaner vold.fstab (yours look like stock samsung crap, even vold can't read it as per your logcat says ), you can base yourself here: https://github.com/dhiru1602/android_device_samsung_galaxysl/blob/gingerbread/etc/vold.fstab
Also you can remove that sdcard mounting in your init.rc as it is already supposed to be mounted with vold.
2. Looks like from the log that your device can't access dalvik cache needed for the apps. Here's a commit I've found that will replace the path location from /cache to /dbdata. Though perhaps it would be better if it could be /cache. For this I would need to check dmesg as well to see if something haven't broke during the process. Here's the commit for the path change in case you need it:
https://github.com/dhiru1602/androi...mmit/5c2a2a54541448565a8d2418cfd75a1a4882342d
My guess would be that maybe cache doesn't get mounted right but it's not only logcat that can tell me this.
Hope it helps!
EDIT: Looks like it's better to use /data for dalvik-cache instead of /cache then make a symlink to it as per the commit says...
Click to expand...
Click to collapse
Thank you both for answering my thread
I used the init.rc from <cmsource>/system/core/rootdir and added the things from the stock init.rc. I also cleaned up init.aalto.rc and modified it to work with CM.
I already tried to symlink /cache/dalvik-cache and /data/dalvik-cache
but this doesn't fixed my issue that it can't create the DEX caches.
I think I'll have to fix...
... the vold.fstab (like you said)
... Add some folders to ramdisk
... libaudio.so (libaudio doesn't get located but its needed to start the system server
... Figure why it doesn't mount cache
... Figurebwhy dbus can't find etc/dbus.conf (even when /system/etc is symlinked to /etc)
BTW, zaclimon you said you need a 'dmesg'. What is it and how can I get it?
Thanks, Androthan
Sent from my Nexus 7 using xda app-developers app

Androthan said:
Thank you both for answering my thread
I used the init.rc from <cmsource>/system/core/rootdir and added the things from the stock init.rc. I also cleaned up init.aalto.rc and modified it to work with CM.
I already tried to symlink /cache/dalvik-cache and /data/dalvik-cache
but this doesn't fixed my issue that it can't create the DEX caches.
I think I'll have to fix...
... the vold.fstab (like you said)
... Add some folders to ramdisk
... libaudio.so (libaudio doesn't get located but its needed to start the system server
... Figure why it doesn't mount cache
... Figurebwhy dbus can't find etc/dbus.conf (even when /system/etc is symlinked to /etc)
BTW, zaclimon you said you need a 'dmesg'. What is it and how can I get it?
Thanks, Androthan
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Thing is the approach for the dalvik cache is different from the one you maybe made. This one implies that you make a dalvik-cache folder inside /dbdata which is in /data, then symlink it to make it /cache/dalvik-cache as well. For the moment these are the most important. Also as for cache, I didn't say that it won't mount it, I said that maybe it won't mount it because of some issues unless the dalvik-cache isn't made here.
Also the dmesg is the kernel log (it's basically a logcat but from a kernel side instead, here you can see how the kernel make it's initialization. You can have it either with this:
adb shell dmesg > dmesg.log
A proc/last_ksmg is a dmesg too but from the previous boot.
It's better to do one at a time then fix the other things after (this way you could get other problems than the one you have already)

Androthan said:
Thank you both for answering my thread
I used the init.rc from <cmsource>/system/core/rootdir and added the things from the stock init.rc. I also cleaned up init.aalto.rc and modified it to work with CM.
I already tried to symlink /cache/dalvik-cache and /data/dalvik-cache
but this doesn't fixed my issue that it can't create the DEX caches.
I think I'll have to fix...
... the vold.fstab (like you said)
... Add some folders to ramdisk
... libaudio.so (libaudio doesn't get located but its needed to start the system server
... Figure why it doesn't mount cache
... Figurebwhy dbus can't find etc/dbus.conf (even when /system/etc is symlinked to /etc)
BTW, zaclimon you said you need a 'dmesg'. What is it and how can I get it?
Thanks, Androthan
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Here is the dmesg man:
http://unixhelp.ed.ac.uk/CGI/man-cgi?dmesg+8
Normally you could get a dmesg by being root and typing dmesg > nameoffile.log but you'd need to be in a directory that you can write to for that. You can type dmesg as root in the shell and it will output to the screen...
I normally just
adb root
adb shell
dmesg
EDIT: Sorry @zaclimon, I didn't think you were going to answer

Meticulus said:
Here is the dmesg man:
http://unixhelp.ed.ac.uk/CGI/man-cgi?dmesg+8
Normally you could get a dmesg by being root and typing dmesg > nameoffile.log but you'd need to be in a directory that you can write to for that. You can type dmesg as root in the shell and it will output to the screen...
I normally just
adb root
adb shell
dmesg
EDIT: Sorry @zaclimon, I didn't think you were going to answer
Click to expand...
Click to collapse
Haha ya well perhaps it wouldn't have worked if he didn't made adb root so I guess this is a team work after all.
Envoyé depuis mon Nexus 7 avec Tapatalk 4

zaclimon said:
Haha ya well perhaps it wouldn't have worked if he didn't made adb root so I guess this is a team work after all.
Envoyé depuis mon Nexus 7 avec Tapatalk 4
Click to expand...
Click to collapse
Meticulus said:
Here is the dmesg man:
http://unixhelp.ed.ac.uk/CGI/man-cgi?dmesg+8
Normally you could get a dmesg by being root and typing dmesg > nameoffile.log but you'd need to be in a directory that you can write to for that. You can type dmesg as root in the shell and it will output to the screen...
I normally just
adb root
adb shell
dmesg
EDIT: Sorry @zaclimon, I didn't think you were going to answer
Click to expand...
Click to collapse
Thanks for the tip and the explanation of dmsg.
I'm now testing a new build with the following changes :
- added lines to init.rc "export ANDROID_CACHE /cache and export DOWNLOD_CACHE /cache/download"
- Added mounting flags (for example: nodev,noexec,wait...)
- symlinked /dbdata/dalvik-cache /cache/dalvik-cache
Another question... Do I have to use the libaudio.so library (and libasound.so) from the device (proprietary way) or can I use the libaudio which gets compiled with CM7 (ALSA sound) ?
Greetings, Androthan
Sent from my Nexus 7 using xda app-developers app

Androthan said:
...
Another question... Do I have to use the libaudio.so library (and libasound.so) from the device (proprietary way) or can I use the libaudio which gets compiled with CM7 (ALSA sound) ?
...
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
I honestly don't know but If I were you, I'd do which ever one worked and if they both worked, then I'd do which ever one worked better...:cyclops:

Androthan said:
Thanks for the tip and the explanation of dmsg.
I'm now testing a new build with the following changes :
- added lines to init.rc "export ANDROID_CACHE /cache and export DOWNLOD_CACHE /cache/download"
- Added mounting flags (for example: nodev,noexec,wait...)
- symlinked /dbdata/dalvik-cache /cache/dalvik-cache
Another question... Do I have to use the libaudio.so library (and libasound.so) from the device (proprietary way) or can I use the libaudio which gets compiled with CM7 (ALSA sound) ?
Greetings, Androthan
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
As meticulus said, I'd probably test which one sound better but it would be better to use the open source variant. Though it would be better as I said earlier to make the thing booting first.
As for the dalvik cache, be sure to make a directory in dbdata before symlink it to /cache.
Envoyé depuis mon Nexus 7 avec Tapatalk 4

Androthan said:
Thank you both for answering my thread
I used the init.rc from <cmsource>/system/core/rootdir and added the things from the stock init.rc. I also cleaned up init.aalto.rc and modified it to work with CM.
I already tried to symlink /cache/dalvik-cache and /data/dalvik-cache
but this doesn't fixed my issue that it can't create the DEX caches.
I think I'll have to fix...
... the vold.fstab (like you said)
... Add some folders to ramdisk
... libaudio.so (libaudio doesn't get located but its needed to start the system server
... Figure why it doesn't mount cache
... Figurebwhy dbus can't find etc/dbus.conf (even when /system/etc is symlinked to /etc)
BTW, zaclimon you said you need a 'dmesg'. What is it and how can I get it?
Thanks, Androthan
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
So, I reworked some things and fixed...
... vold.fstab (rewrote it)
... dbus.conf (deleted etc in the ramdisk)
... dalvik-cache (the rootfilesystem '/' system was mounted as 'read only' so we hadn't the right permissions // symlinked /cache/dalvik-cache and /dbdata/dalvik-cache )
My/Our problem is now the libaudio.so:
It is needed to load the SystemServer.
I'm actually using the stock libaudio files (libaudiopolicy.so, libaudioflinger.so, libasound.so, libsoundpool.so,...) but theres an error in libaudio.so , something doesn't get located.
Some websites are saying that libaudio.so contains the proprietary code (HAL implementation) for the audio device (like libcamera.so for the camera).
How to fix that? Did I missed a proprietary file?
Greetings, Androthan

Androthan said:
So, I reworked some things and fixed...
... vold.fstab (rewrote it)
... dbus.conf (deleted etc in the ramdisk)
... dalvik-cache (the rootfilesystem '/' system was mounted as 'read only' so we hadn't the right permissions // symlinked /cache/dalvik-cache and /dbdata/dalvik-cache )
My/Our problem is now the libaudio.so:
It is needed to load the SystemServer.
I'm actually using the stock libaudio files (libaudiopolicy.so, libaudioflinger.so, libasound.so, libsoundpool.so,...) but theres an error in libaudio.so , something doesn't get located.
Some websites are saying that libaudio.so contains the proprietary code (HAL implementation) for the audio device (like libcamera.so for the camera).
How to fix that? Did I missed a proprietary file?
Greetings, Androthan
Click to expand...
Click to collapse
Logs?

Androthan said:
So, I reworked some things and fixed...
... vold.fstab (rewrote it)
... dbus.conf (deleted etc in the ramdisk)
... dalvik-cache (the rootfilesystem '/' system was mounted as 'read only' so we hadn't the right permissions // symlinked /cache/dalvik-cache and /dbdata/dalvik-cache )
My/Our problem is now the libaudio.so:
It is needed to load the SystemServer.
I'm actually using the stock libaudio files (libaudiopolicy.so, libaudioflinger.so, libasound.so, libsoundpool.so,...) but theres an error in libaudio.so , something doesn't get located.
Some websites are saying that libaudio.so contains the proprietary code (HAL implementation) for the audio device (like libcamera.so for the camera).
How to fix that? Did I missed a proprietary file?
Greetings, Androthan
Click to expand...
Click to collapse
Well as a temporary solution you could use the one found in the stock rom and then copy it to your vendor files so it can be copied into your lib folder. This way it'll work no problem. Also as @Meticulus said, a bunch of logs is always appreciated.
Envoyé depuis mon Nexus 7 avec Tapatalk 4

[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?

Better Mobile App

welcome