Anyone having this issue with ANY of the voodoo kernels? It enabled and converted everything to EXT4, but errors out when trying to convert back to RFS. ANy suggestions? Tried the flashable disable voodoo and attempted to disable in CWM, all Try to convert back but fails (see below)
Thanks for your help!
EDIT: Discovered issue was due to a non-existent file, fat.format, in custom builds. Flash the attached zip file, and Voodoo should be able to convert back to RFS.
Hope it helps!
Code:
2010-12-09 06:34:23 filesystem detection on system:
2010-12-09 06:34:24 Ext4 on /dev/block/stl9
2010-12-09 06:34:24 filesystem detection on dbdata:
2010-12-09 06:34:24 Ext4 on /dev/block/stl10
2010-12-09 06:34:24 filesystem detection on cache:
2010-12-09 06:34:24 Ext4 on /dev/block/stl11
2010-12-09 06:34:24 filesystem detection on data:
2010-12-09 06:34:24 Ext4 on /dev/block/mmcblk0p2
2010-12-09 06:34:24 convert cache (/dev/block/stl11) from ext4 to rfs
2010-12-09 06:34:24 ERROR: unable to call fat.format: cancel conversion
2010-12-09 06:34:24 convert dbdata (/dev/block/stl10) from ext4 to rfs
2010-12-09 06:34:24 ERROR: unable to call fat.format: cancel conversion
2010-12-09 06:34:24 convert data (/dev/block/mmcblk0p2) from ext4 to rfs
2010-12-09 06:34:26 ERROR: unable to call fat.format: cancel conversion
2010-12-09 06:34:26 convert system (/dev/block/stl9) from ext4 to rfs
2010-12-09 06:34:29 ERROR: unable to call fat.format: cancel conversion
known issue. supercurio pointed towards a modified fat.format as causing this to happen when running a non-stock rom, as i believe he used the purely stock kernel, and most of us are running modified kernels and roms. not a biggie, just can't disable it, to go back to rfs or flash another rom, you have to odin using the froyo that does not brick method.
Br1cK'd said:
known issue. supercurio pointed towards a modified fat.format as causing this to happen when running a non-stock rom, as i believe he used the purely stock kernel, and most of us are running modified kernels and roms. not a biggie, just can't disable it, to go back to rfs or flash another rom, you have to odin using the froyo that does not brick method.
Click to expand...
Click to collapse
What you mean is to odin back to T959UVJFD with repartition? Will odin wihout disable voodoo birck the phone?
Br1cK'd said:
known issue. supercurio pointed towards a modified fat.format as causing this to happen when running a non-stock rom, as i believe he used the purely stock kernel, and most of us are running modified kernels and roms. not a biggie, just can't disable it, to go back to rfs or flash another rom, you have to odin using the froyo that does not brick method.
Click to expand...
Click to collapse
Mna, was hoping for an easier method. Anyone have the stock fat.format available that can be pushed to /system/bin? Wonder if it would work. Anyone else w/ a better solution? Thanks again for your help!
Odin without disable is fine
I had this same issue. I was able to Odin to eugene's froyo that doesn't brick and then move on to other roms from there. The process was easy.
smartmind said:
What you mean is to odin back to T959UVJFD with repartition? Will odin wihout disable voodoo birck the phone?
Click to expand...
Click to collapse
Odin without disabling voodoo will not brick the phone, if you search for, follow, and use the Froyo That Does Not brick method, that fixes bricks, and will bring you back to stock with rfs.
zimphishmonger said:
Mna, was hoping for an easier method. Anyone have the stock fat.format available that can be pushed to /system/bin? Wonder if it would work. Anyone else w/ a better solution? Thanks again for your help!
Click to expand...
Click to collapse
not sure if pushing the stock fat.format would do it, or cause issues with the rom you're on. thats above my pay grade here. i don't think there is any way to truly remove the voodoo'd partitions and convert them back to rfs, besides the disable method that doesn't work on custom roms, or using odin.
i do think if the voodoo kernel were written into the rom, it may work, but thats just a theory, and i'm no chef.
supercurio did put out the source he used for the voodoo kernel, and i believe also has posted an injection method to inject voodoo into other kernels, however again, above my pay grade (and current knowledge level to actually make it happen)
What is strange is Im using Morific's i9000-based Voodoo kernel, which is made for TW's Nero and I ran into this issue. Guess im stuck on Voodoo for a bit. If anyone would be nice enough to upload a stock fat.format from a JK6\JL1 build, that would be much appreciated (and Ill be able to attempt that idea of pushing a stock fat.format, and attempting to convert back to RFS).
Thanks!
Just odin jk2 with repartion checked. No need for froyo that doesn't brick
Sent from my SGH-T959 using XDA App
zimphishmonger said:
What is strange is Im using Morific's i9000-based Voodoo kernel, which is made for TW's Nero and I ran into this issue. Guess im stuck on Voodoo for a bit. If anyone would be nice enough to upload a stock fat.format from a JK6\JL1 build, that would be much appreciated (and Ill be able to attempt that idea of pushing a stock fat.format, and attempting to convert back to RFS).
Thanks!
Click to expand...
Click to collapse
morific's kernel, was that built from the voodoo 5 beta or the newly released voodoo stable?
again the thought of writing it into a rom was mere speculation on my part. very interesting, i am curious to hear your results of pushing a stock fat.format and attempting a disable, please post your results if you're able to get and push the file.
stephenj37826 said:
Just odin jk2 with repartion checked. No need for froyo that doesn't brick
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
thanks for the heads up, one step that doesn't have to be stepped, i guess old practices die hard.
Okay, fixed it, and I wanted to share w/ everyone else so you can benefit from my PITA.
Voodoo does not like the (or cannot find) fat.format from custom ROMs (like Nero, Macnut, etc). The conversion to EXT4 is fine, but when it comes time to convert back to RFS for whatever reason, it errors out (if you enable debug and look at the log). Ive had suggestions of using ODIN, but I knew there had to be an easier way. Supercurio mentioned that a stock fat.format should fix the issue, and magically it did
pushed a stock fat.format to my /system/bin/, attempted a conversion back to RFS and magic! It worked.
Instructions
Unzip attached file (only for the NON-flashable version, attached to this post)
Push to /system/bin or copy\paste using Root Manager or SUFBS
Attempt conversion back to RFS
Grab some coffee
To ROM Devs, could you please include a PROPER, unmodified fat.format in all your builds to avoid issues like this in the future. Thanks!
Hope this helps!
I have searched the threads, but Eugene has dropped support for this forum, Could anyone kindly tell me where I can find the rom froyo that doesn't brick?
zimphishmonger said:
Okay, fixed it, and I wanted to share to everyone else can benefit from my PITA.
Voodoo does not like the fat.format from custom ROMs (like Nero, Macnut, etc). The conversion to EXT4 is fine, but when it comes time to convert back to RFS for whatever reason, it errors out (if you enable debug and look at the log). Ive had suggestions of using ODIN, but I knew there had to be an easier way. Supercurio mentioned that a stock fat.format should fix the issue, and magically it did
pushed a stock fat.format to my /system/bin/, attempted a conversion back to RFS and magic! It worked.
Instructions
Unzip attached file
Push to /system/bin or copy\paste using Root Manager or SUFBS
Attempt conversion back to RFS
Grab some coffee
To ROM Devs, could you please include a PROPER, unmodified fat.format in all your builds to avoid issues like this in the future. Thanks!
Hope this helps!
Click to expand...
Click to collapse
thanks for being the guinea pig, gonna push this over myself and test it out!
smartmind said:
I have searched the threads, but Eugene has dropped support for this forum, Could anyone kindly tell me where I can find the rom froyo that doesn't brick?
Click to expand...
Click to collapse
http://eb-productions.proboards.com/index.cgi?board=samsungsgs&action=display&thread=8
i would try pushing the fat.format that zimphishmonger posted a few posts back, will be a lot less effort that going with odin.
Hey Zimphishmonger, what version of Nero and which Voodoo kernel were you running when this happened?
Moved of: Samsung Vibrant > Vibrant Android Development
To: Samsung Vibrant > Vibrant Q&A
Please put your questions to: Vibrant Q&A
I can confirm pushing that fat.format zim posted to the /system/bin directory will let you disable voodoo.
Sent from my Black Froyo'd, Voodoo'd Vibrant with a gooey Macnut center
Mods, thanks for moving the thread.
I wanted to clarify, as there seems to be some confusion. I was using the Voodoo-modified CWM kernel from Morfic at 1.4Ghz (the one with the "voodoo" red Clockwork Recovery built-in).
I am using Nero b3, no other lagfixes or tweaks to the file system. The key was the error logs that pointed out that fat.format couldnt be executed, because "Linda" actually says "converting system, converting data, etc" but if you check in terminal or via adb, you will still see your partitions mounted as /ext4 (Voodoo Enabled).
Right after pushing the stock fat.format and attempting a conversion back to RFS, it completed the process, AND gave a time estimate (something it didnt do when it errored out). I hope this helps people.
I have attached a FLASHABLE version of fat.format to make things easier for everyone. It just puts the correct file in /system/bin/ so you dont have to work in terminal or adb
zimphishmonger said:
Okay, fixed it, and I wanted to share to everyone else can benefit from my PITA.
Voodoo does not like the fat.format from custom ROMs (like Nero, Macnut, etc). The conversion to EXT4 is fine, but when it comes time to convert back to RFS for whatever reason, it errors out (if you enable debug and look at the log). Ive had suggestions of using ODIN, but I knew there had to be an easier way. Supercurio mentioned that a stock fat.format should fix the issue, and magically it did
pushed a stock fat.format to my /system/bin/, attempted a conversion back to RFS and magic! It worked.
Instructions
Unzip attached file
Push to /system/bin or copy\paste using Root Manager or SUFBS
Attempt conversion back to RFS
Grab some coffee
To ROM Devs, could you please include a PROPER, unmodified fat.format in all your builds to avoid issues like this in the future. Thanks!
Hope this helps!
Click to expand...
Click to collapse
Thanks, Zimp! This type of solution research is of great value to the community!
BruceElliott said:
Thanks, Zimp! This type of solution research is of great value to the community!
Click to expand...
Click to collapse
NP, glad to share....
OP updated with flashable version (for laziness\ convenience)
zimphishmonger said:
Okay, fixed it, and I wanted to share w/ everyone else so you can benefit from my PITA.
Voodoo does not like the (or cannot find) fat.format from custom ROMs (like Nero, Macnut, etc). The conversion to EXT4 is fine, but when it comes time to convert back to RFS for whatever reason, it errors out (if you enable debug and look at the log). Ive had suggestions of using ODIN, but I knew there had to be an easier way. Supercurio mentioned that a stock fat.format should fix the issue, and magically it did
pushed a stock fat.format to my /system/bin/, attempted a conversion back to RFS and magic! It worked.
Instructions
Unzip attached file (only for the NON-flashable version, attached to this post)
Push to /system/bin or copy\paste using Root Manager or SUFBS
Attempt conversion back to RFS
Grab some coffee
To ROM Devs, could you please include a PROPER, unmodified fat.format in all your builds to avoid issues like this in the future. Thanks!
Hope this helps!
Click to expand...
Click to collapse
How did you try to convert back to RFS and what does RFS mean? Sorry for the noob questions. I have just never ran into this problem but you seemed to have saved my phone. I hope lol
Related
So far I have tested redbend_ua for backup purposes, and got the bml7 and bml8 partitions backed up, and tested just restoring the bml8 partition with the clockwork recovery that is being tested on the epic. The utility did write the image / partition correctly (afaik) and rebooted the phone upon completion. The phone booted correctly to android, but then upon another reboot to test recovery, it just boot loops, even a normal boot and trying to get to the downloader mode.
This utility seems to work and do what it was meant to, but i would not use this tool without knowledge of what you are doing. On that note, i will not post a link to the tool, just as a safeguard, for now at least.
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
z4ziggy said:
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
Click to expand...
Click to collapse
Both cache and dbdata can largely be ignored; I actually had to nuke my /dbdata partition earlier due to something I did. It gets rebuilt on boot, it's just a SQLite store for the applications and on most Android phones resides within /data. No idea why Samsung felt it necessary to separate this partition.
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
z4ziggy said:
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
Click to expand...
Click to collapse
I did some more testing and can confirm that cache and dbdata can both be empty on boot.
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
z4ziggy said:
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
Click to expand...
Click to collapse
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
fallingup said:
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
Click to expand...
Click to collapse
Yeah.. I could've used that yesterday too.. I ended up swapping out my device this morning.
Sounds like some progress is being made. Very good to hear confirmation on cache and dbdata
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
fallingup said:
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
Click to expand...
Click to collapse
Glad to hear it.. I was getting seg-faults trying to mount /system .
What is the advantage having a kernel that has Voodoo in it, and other kernels that come with the roms.
Voodoo convert your /data to Ext4 which is a much faster and reliable file system than RFS.
However, because it changes your file system, when you flash anything, I meant ANYTHING, you need to disable it first. Otherwise, you will soft brick.
There's a new lag fix that's rising. It's call zMod, and it convert /data /dbcache and some other path I don't remember. But it is a full phone conversion besides /system. Look it up in the dev forum. I am not sure about all its details.
I am actually reading up on it now. It should be realised later on tonight, or tomorrow. So i should wait for that and don't bother with Voodoo at this point.
PaiPiePia said:
Voodoo convert your /data to Ext4 which is a much faster and reliable file system than RFS.
However, because it changes your file system, when you flash anything, I meant ANYTHING, you need to disable it first. Otherwise, you will soft brick.
There's a new lag fix that's rising. It's call zMod, and it convert /data /dbcache and some other path I don't remember. But it is a full phone conversion besides /system. Look it up in the dev forum. I am not sure about all its details.
Click to expand...
Click to collapse
Ahh thanks for the info.
I was hesitant to root my Vibrant but the lag has gotten Extreme and I am about to give up on Samsung and Froyo. After messing with a PSP for years you get tired of having to hack things, but Samsung really has failed with this file system and I just cant keep letting it slug along.
PaiPiePia said:
Voodoo convert your /data to Ext4 which is a much faster and reliable file system than RFS.
However, because it changes your file system, when you flash anything, I meant ANYTHING, you need to disable it first. Otherwise, you will soft brick.
There's a new lag fix that's rising. It's call zMod, and it convert /data /dbcache and some other path I don't remember. But it is a full phone conversion besides /system. Look it up in the dev forum. I am not sure about all its details.
Click to expand...
Click to collapse
z4mod converts
/data to ext4
/dbdata to ext4
/cache to ext2
And if you want
/system to ext4 or ext2
So it converts all of those. You just have to add system to the update script. You can also choose which ext you want to use by editing the update script. So it could be /data to ext2 if you'd like. My current set up is the one above but /system is ext4 for me.
Sent from my SGH-T959 using XDA App
Im using zmod right now and it works really well. Just make sure you get the zip that converts the file system back to rfs when you flash a new rom.
Samsung Vibrant using Bionix Final w/ z4mod
hi guys,
i am a total noob to android and i just bought a vibrant(used)
it has the firmware version 2.1-update 1 .
i have rooted the phone and now have super user permission(downloaded update.zip and went to recovert mode).
and installed titanium backup then rom manager..
backed up too and flashed the clockworkmod recovery 2.5.1.2 .
then downloaded the custom rom "nero beta 3 with voodoo".
copied it to internal 16 gig storage then went to rom manager then "reboot into recovery"
everything was ok untill that point.
but in recovery,i always get blue screen with 4 options and no matter what i tried nothing happens..
please someone help me with this problem..
thanks
Ok, let me take a shot at it
go to your phone /sdcard/clockworkmod and copy recovery-update.zip into /sdcard as update.zip (you might have a file update.zip in there possibly to root your phone, you don't need it, just rename it and archive it for future use if you need to re-root your phone, etc.).
Now reboot into recovery, and select reinstall packages, it will read the cwr update.zip and will go to a similar screen with green text, from there you can select a zip to install, and flash away.
I would strongly suggest though you download a ROM that is not marked as beta - there are a few options available from different teams.
just hit reinstall packages a couple times
lqaddict said:
Ok, let me take a shot at it
go to your phone /sdcard/clockworkmod and copy recovery-update.zip into /sdcard as update.zip (you might have a file update.zip in there possibly to root your phone, you don't need it, just rename it and archive it for future use if you need to re-root your phone, etc.).
Now reboot into recovery, and select reinstall packages, it will read the cwr update.zip and will go to a similar screen with green text, from there you can select a zip to install, and flash away.
I would strongly suggest though you download a ROM that is not marked as beta - there are a few options available from different teams.
Click to expand...
Click to collapse
hi it worked !!
but new problem.. its in clockworkmod recovery and says
"installing: SDCARD:Nero_3TWE_voodoo.zip
Finding update package... "
its been sometime but nothins changes than that
royalkalana said:
hi it worked !!
but new problem.. its in clockworkmod recovery and says
"installing: SDCARD:Nero_3TWE_voodoo.zip
Finding update package... "
its been sometime but nothins changes than that
Click to expand...
Click to collapse
Wait for it to finish!!! It might take a little long.
P.S. You didn't happen to put your ROM zip file on your external card, did you?
lqaddict said:
Wait for it to finish!!! It might take a little long.
P.S. You didn't happen to put your ROM zip file on your external card, did you?
Click to expand...
Click to collapse
no no i read soo many threads so i know the process(theoretically lol )
i put the file to 16 gig internal.. and i got the green screen as u said then it found the rom too ..
i forced to power on and going to try again
please let me know what i should know
thanks
hi it worked it worked !!
thanks lqaddict and jmcghee1973 for ur help.specially lqaddict thanks alot for ur time mate
royalkalana said:
hi it worked it worked !!
thanks lqaddict and jmcghee1973 for ur help.specially lqaddict thanks alot for ur time mate
Click to expand...
Click to collapse
No problem I am glad to help. Enjoy your new Vibrant!
lqaddict said:
No problem I am glad to help. Enjoy your new Vibrant!
Click to expand...
Click to collapse
and can you recommend some stable and good custom roms for me please ?
royalkalana said:
and can you recommend some stable and good custom roms for me please ?
Click to expand...
Click to collapse
It's all user preference
All the current ROM's in the dev section can be considered at this point stable to a degree that the core functionality of the phone is working properly, there might be some quirks with advanced configurations.
Some of the established ROM's are Eugene's Ginger Clone, Team Whiskey Nero and Master's and his team Axura.
My own preference is TW NeroV3 running Supercurio's Voodoo on JL5 build.
Can't go wrong with the latest Voodoo based ROM's, they are smooth, fast and a pleasure to use.
And whoever says that once you flash a custom ROM you are in for a bag of tweaking for the rest of the phone's life I strongly disagree, I can easily see how I can stay with NeroV3 until a stable ROM based on the current iteration of Android OS - Gingerbread - appears here.
P.S. Just be careful when you flash from ROM to ROM, the current ROM's the incorporate Voodoo infused kernels do not require you to disable Voodoo before flashing a Voodoo based ROM, otherwise you must disable it before you flash another ROM. As a common practice, it is best to disable Voodoo before flashing another ROM anyway, and one of the preferred methods is to flash back to stock JFD via ODIN before you flash another ROM to hunt all the ghosts of the ROM past.
Read, read, read and read some more - the Bible in the dev section is a good place to start.
lqaddict said:
It's all user preference
All the current ROM's in the dev section can be considered at this point stable to a degree that the core functionality of the phone is working properly, there might be some quirks with advanced configurations.
Some of the established ROM's are Eugene's Ginger Clone, Team Whiskey Nero and Master's and his team Axura.
My own preference is TW NeroV3 running Supercurio's Voodoo on JL5 build.
Can't go wrong with the latest Voodoo based ROM's, they are smooth, fast and a pleasure to use.
And whoever says that once you flash a custom ROM you are in for a bag of tweaking for the rest of the phone's life I strongly disagree, I can easily see how I can stay with NeroV3 until a stable ROM based on the current iteration of Android OS - Gingerbread - appears here.
Click to expand...
Click to collapse
thanks alot mate..
i think you are saying about this rom
http://forum.xda-developers.com/showthread.php?t=883379
i installed the same
and it is soo cool..
but i dont know what is the difference between voodoo enable/disable.
and couldnt find that disable lag fix file
""" On your internal sdcard, you will find a voodoo folder containing a file called 'disable-lagfix'. This was pre-installed when you flashed. Find it.
Delete the 'disable-lagfix' file from the voodoo folder """
any idea about it ?
thanks again
royalkalana said:
thanks alot mate..
i think you are saying about this rom
http://forum.xda-developers.com/showthread.php?t=883379
i installed the same
and it is soo cool..
but i dont know what is the difference between voodoo enable/disable.
and couldnt find that disable lag fix file
""" On your internal sdcard, you will find a voodoo folder containing a file called 'disable-lagfix'. This was pre-installed when you flashed. Find it.
Delete the 'disable-lagfix' file from the voodoo folder """
any idea about it ?
thanks again
Click to expand...
Click to collapse
Voodoo converts your phone's filesystem to EXT4 (I am not gonna bore you with the technical details ), it is faster better filesystem than the one Samsung implemented. What it does, it virtually eliminates lag when you scroll/open apps, etc.
Now onto enabling/disabling Voodoo.
While your phone is up and running if you press and hold your power button for a few seconds a menu will appear, choose Recovery, and your phone should reboot into modified clockwork recovery, now all your green texts are now bloody red, navigate to Voodoo lagfix option (i think that what it is called, sorry cannot replicate it on my phone it is currently in use ) and you can enable/disable Voodoo from there.
Just let it do its thing, it will take a bit of time to convert the filesystems, do not touch your phone until the process is completed.
lqaddict said:
Voodoo converts your phone's filesystem to EXT4 (I am not gonna bore you with the technical details ), it is faster better filesystem than the one Samsung implemented. What it does, it virtually eliminates lag when you scroll/open apps, etc.
Now onto enabling/disabling Voodoo.
While your phone is up and running if you press and hold your power button for a few seconds a menu will appear, choose Recovery, and your phone should reboot into modified clockwork recovery, now all your green texts are now bloody red, navigate to Voodoo lagfix option (i think that what it is called, sorry cannot replicate it on my phone it is currently in use ) and you can enable/disable Voodoo from there.
Just let it do its thing, it will take a bit of time to convert the filesystems, do not touch your phone until the process is completed.
Click to expand...
Click to collapse
thanks mate.. you've been a big help for me..
btwn.. how could i know that its enable after i did that process ? is there a way for that ?
royalkalana said:
btwn.. how could i know that its enable after i did that process ? is there a way for that ?
Click to expand...
Click to collapse
The bulletproof way is to use a terminal emulator app or use adb to execute the follwing command
Code:
mount
If you see ext4 next to /data, /system, /cache and /dbdata in the output you are golden
thanks lqaddict
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.
I am running stock DNA, rooted, and with CWM touch recovery. For myself, being root is not merely a luxury, it is a need. Most importantly, I cannot stand having a crippled unix terminal without busybox, which of course, requires root.
I know not what the imminent OTA will bring, but root is too precious to risk losing. I would therefore like to engage in a DNA-specifc discussion about disabling the OTA update.
From what I can tell so far, the two methods include:
1) renaming the otacerts.zip file in /etc/security to a .bak file. This will not work in the present case, since /etc is mounted at /system/etc, and /system can only temporarily be mounted rw due to us being stuck with "S-ON" for now.
2) installing "FOTAkill.apk", or, flashing its corresponding zip (attached below) in custom recovery. Again, in the present case, this file was written for the EVO, and will most certainly not work. The updater-script in the zip can be modified to reflect the correct mount points, but there is a corresponding binary which I have no clue contains what, and would certainly need some expert opinion about.
Any ideas ye fine fellers?
You could always do load ota root keeper from the market back your root up temp un root via app update ota and then re root using the app, I have done this on other devices and I never lost root. Worked well. Might be worth a shot.
Sent from my HTC6435LVW using xda app-developers app
manzdagratiano said:
I am running stock DNA, rooted, and with CWM touch recovery. For myself, being root is not merely a luxury, it is a need. Most importantly, I cannot stand having a crippled unix terminal without busybox, which of course, requires root.
I know not what the imminent OTA will bring, but root is too precious to risk losing. I would therefore like to engage in a DNA-specifc discussion about disabling the OTA update.
From what I can tell so far, the two methods include:
1) renaming the otacerts.zip file in /etc/security to a .bak file. This will not work in the present case, since /etc is mounted at /system/etc, and /system can only temporarily be mounted rw due to us being stuck with "S-ON" for now.
2) installing "FOTAkill.apk", or, flashing its corresponding zip (attached below) in custom recovery. Again, in the present case, this file was written for the EVO, and will most certainly not work. The updater-script in the zip can be modified to reflect the correct mount points, but there is a corresponding binary which I have no clue contains what, and would certainly need some expert opinion about.
Any ideas ye fine fellers?
Click to expand...
Click to collapse
There are system writable kernels out there, and you can always rename your files in recovery. S-Off is not an issue in this scenario.
delete checkinprovider.apk, cotaclient.apk, and updater.apk from /system/app
Jaggar345 said:
You could always do load ota root keeper from the market back your root up temp un root via app update ota and then re root using the app, I have done this on other devices and I never lost root. Worked well. Might be worth a shot.
Click to expand...
Click to collapse
I have indeed heard this alternative thrown around but I am not willing to chance it; I have seen an equal amount of horror stories about people having their systems fried with this method (the Droid X for instance, which I had and where the last update broke root).
SolusCado said:
There are system writable kernels out there, and you can always rename your files in recovery. S-Off is not an issue in this scenario.
Click to expand...
Click to collapse
I will look at what's out there and if it is stable enough to be flashed. How does one rename files in recovery though? I rebooted into CWM (touch) and I see no such option - unless you can remount a partition and rename files in it somehow.
nitsuj17 said:
delete checkinprovider.apk, cotaclient.apk, and updater.apk from /system/app
Click to expand...
Click to collapse
This avenue seems promising. Has anyone tried this before? Also, how does one delete these in the S-ON situation? (I'm assuming recovery is the answer). I feel if I remounted rw, deleted and then rebooted, they will be right back where they are.
manzdagratiano said:
This avenue seems promising. Has anyone tried this before? Also, how does one delete these in the S-ON situation? (I'm assuming recovery is the answer). I feel if I remounted rw, deleted and then rebooted, they will be right back where they are.
Click to expand...
Click to collapse
If you install a kernel with /system writing enabled you can just delete them normally.
Sent from my HTC6435LVW using xda app-developers app
Bigandrewgold said:
If you install a kernel with /system writing enabled you can just delete them normally.
Click to expand...
Click to collapse
Great... thanks! I am looking into custom kernels. By the way, if custom kernels that do allow write to /system can be concocted, why is S-ON an issue at all? I was under the impression that this has to do with NAND memory being inaccessible, which seems to be a lower level issue than the kernel.
manzdagratiano said:
Great... thanks! I am looking into custom kernels. By the way, if custom kernels that do allow write to /system can be concocted, why is S-ON an issue at all? I was under the impression that this has to do with NAND memory being inaccessible, which seems to be a lower level issue than the kernel.
Click to expand...
Click to collapse
With s on we can not.
Flash radios
Flash kernels in recovery.
Change the splash screen
Go back to a locked bootloader
And a few other things I'm probably forgetting.
Sent from my HTC6435LVW using xda app-developers app