yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] matmanchu5:
Maybe flash the root version even if you already have root...could there be any harm in doing that?.....wouldnt it just replace a few things?
[Captivate Android Development] IceMonkey82:
I had previously already tried that and it didn't work, still lost root.

---------- Post added at 07:03 AM ---------- Previous post was at 06:57 AM ----------

FYI ...

I just went through all the same steps as the time just before this (when I used the No Root CWM .zip) except this time I used the Odin .tar and this time I still have root. The only difference in what I did was use the Odin instead of the CWM for this kernel so I'm guessing it has something to do with the CWM .zip that is causing the loss of root.

Hope that helps.
[Captivate Android Development] mbc663:
Starting to lose hope here. I think Samurai might be the way to go until this reaches v4.
[Captivate Android Development] mtcarey:
Fixed?

YES IceMonkey. I didn't realize that it was only happening with the CWM package... looks like the CWM installer script was messing-up the permissions. Ditto the "root" package. New versions of CWM packages posted.

P.S. Such a simple thing. I must be brain-dead. I always test with the Odin version.
[Captivate Android Development] kuraijay:
what i found to work was if your using CWM is Samurai kernal > corn kernal no root > then run the magic zip. and it worked asked me to update the binary and it went through. the magic zip i guess cleans out the su's in all locations. here it is in this post

http://xdaforums.com/showpost.php?p=18436008&postcount=153
[Captivate Android Development] Taderich:
The issue with losing root is the sticky bit on the su binary.

Before kernel install:

ls -l /system/xbin/su

-rwsr-sr-x root root 22228 2011-10-19 07:48 su

After kernel install:

ls -l /system/xbin/su

-rwxr-xr-x root root 22228 2011-10-19 07:48 su

Created an update zip that ran this and the issue is resolved. Suggest putting the set_perm part in the updater-script for the kernel install

updater-script:

ui_print(" ");

ui_print(" ");

ui_print(" ");

ui_print(" ");

ui_print(" *********************************************** ");

ui_print(" * Fixing SU binary permissions * ");

ui_print(" *********************************************** ");

ui_print(" ");

show_progress(0.100000, 0);

ui_print(" ");

ui_print(" ");

ui_print(" ");

ui_print(" ");

ui_print(" ");

run_program("/system/bin/mount", "/dev/block/stl9", "/system");

ui_print(" ");

ui_print("Setting sticky bit on su binary");

ui_print(" ");

set_perm(0, 0, 06755, "/system/xbin/su");

show_progress(0.100000, 40);

ui_print(" ");

ui_print("DONE! You should now reboot.");

Update zip to fix this can be downloaded here in the mean time: http://db.tt/2nRCB5mL
[Captivate Android Development] mtcarey:
Excellent! I will do that. I still need to figure-out how / where it is getting changed, though. I didn't think I was messing with anything in /system/xbin.
[Captivate Android Development] Taderich:
I wonder if the perms get set once the kernel boots for the first time. If this is the case, then regardless of what they are set to beforehand in the updater-script, it will get overwritten on first boot. This update script works because the first boot has already taken place (if the theory is correct).

There was a mention of Voodoo scripts a few posts back. Could there be some script there that is setting the perms?

Something to test out. If you like, I'll gladly test out any unofficial versions you have before you post them to the world. Just PM me if you like.
[Captivate Android Development] mtcarey:
I did a search through all the scripts and *.rc files and found just one thing that would change permissions on su... the su installer script in the full CWM package was messing with it even if it was already there. I've removed that line, and posted updated file links which end with "-4". Give it a shot!
[Captivate Android Development] Jsmokey:
I believe the update process itself changes some permissions, could be wrong but I do remember reading somewhere that when something is pushed to /system permissions can get changed around on it sometimes. Anyways I always put a fix permissions section in my updater scripts just to be double sure it doesn't cause issues after a reboot which you can pull from most rom updater scripts just to save some time.

Edit: saw your above post, glad you found it you may still want to put the fix permissions chunk at the end of the updater script just to be sure everything's set how it should be.
[Captivate Android Development] mtcarey:
Good idea... I already have an init.d script when makes system app writable, so I can add it there. Or I can put it in init.rc, which might be even better. I'll have to experiment.
[Captivate Android Development] Taderich:
Gave -4 a shot and it works great. Still had root.

I'll try it again from a different kernel but I think you fixed the problem.

Nice boot animation, btw. Simple, looks good and proves the point.

:-)

Oh, I just can't believe how screaming fast this kernel is!!
[Captivate Android Development] Taderich:
Tried again installing from a different kernel and no problem, retained root. :-)

Looks like it's fixed.
[Captivate Android Development] Kyuta Syuko:
Maybe that's why flashing my kernel then yours allowed people to retain root because, like I said before, I have my kernel set to remove all instances of su and put it in xbin. Glad to hear you've managed to figure out what was wrong though.
[Captivate Android Development] matmanchu5:
Having trouble with this boot animation. Is that supposed to be something other than att boot followed by black screen and then the big "s" for Samsung?
[Captivate Android Development] Kyuta Syuko:
Not by default. At least as far as I know.
[Captivate Android Development] Jsmokey:
Definitely couldn't hurt to throw it in an init.d script then no matter what someone did to their phone as long as it boots all the permissions would be corrected not sure how well it'd go hardcoding into .rc though as this could cause some issues in custom roms down the road depending on what the chef changed around/added although there should be a pretty slim chance of that happening.
[Captivate Android Development] mtcarey:
Right on! Now I can completely focus on my custom version of CWM Recovery with lagfix conversion built in. Working from source of CWM Recovery 5 and "Universal Lagfix" (ULF)... getting pretty close. If only the re-compiles didn't take so long....
[Captivate Android Development] mtcarey:
If you've got a "bootanimation.zip" and/or "sanim.zip" in either your /system/media or /data/local folders, that what it plays. Otherwise, the standard Samsung "S" animation is played.
[Captivate Android Development] Chargerdude70:
Flashed Corn on top of Fusion IX. Before the kernel flash, I could restore apps with TB. Now I can't, it just hangs? Tried updating TB,clearing TB cache,updating SU,rebooting. All no workie. Any Ideas
[Captivate Android Development] Jsmokey:
If you can try doing a tb restore while plugged into your pc with adb logcat running and look for a line that has to do with a temp file not being created, if thats the case I can give you a link to get you up and running again. It seems that it happens after a failed app install, if the install fails then the temp file doesn't get removed and android won't allow it to be recreated with the old one there when you try installing or restoring a back up.

If this is the problem none of what you tried would work cause the temp file is stored in one of the secure folders.

Also an easier way to see if this is the problem is pull your external sd card out if you use one, for some reason that will also take care of it although only til you put the card back in.
[Captivate Android Development] mtcarey:
Any luck? Did Jsmokey's suggestion work? I use Tibu all the time and haven't had any problems with this kernel, and no one else has reported a problem. The CWM package includes an init.d script which makes all apps world writable, but doesn't change the owner and hasn't given Tibu any trouble.
[Captivate Android Development] Jsmokey:
I'd like to know too cause all the sites I found said to remove a specific file that wasn't present on my phone but pulling external sd worked everytime and this happened in my own kernel and rom after a failed app install. Oh and logcat did say it fails to create the specified tmp file for me it just doesn't exist.for me to remove for some reason.
[Captivate Android Development] mtcarey:
Can you tell where it is trying to create it?
[Captivate Android Development] matmanchu5:
Kernel is working great...its about time:) still rooted and living evry minut of it baby!! yeeah!!

But I've still got this nagging lagging boot screen issue not sure what it causing it but it is really irritating my phone is running so well now but every time I restart it seems like the boot screen lasts forever then blackness for 7 or 8 seconds and about 20 seconds when wiping dalvik before any boot animation I flash or replace sanim or bootanim . I'm left wondering arr my bootloaders in need of an update I'm running cezars art kf1 bootloaders
[Captivate Android Development] Jsmokey:
In /mnt/secure/asec can't remember the name of the file offhand though but it's a bug in android that if the installation fails the file isn't removed and then when you try to install something else the installation process can't create it cause it's there already and you have to remove it yourself but mine wasnt there it was somewhere on the external sdcard from app2sd on a previous rom so I just put it in my pc and formatted it.

It should work just pulling your external sd if you have one though that was the fast and easy temporary fix for everyone.

I can also provide the command you can run from term emu or adb shell that'll delete it if you dont have a file explorer with root access. I personally use file expert it's free and can do just as much as root explorer plus a little more I think.

Heres a screeny of where it should be and some file expert options.
[Captivate Android Development] mtcarey:
I just posted version 3.07 which has a tweak to the boot animation function. Give it a try!
[Captivate Android Development] matmanchu5:
Sswwweeeet!
[Captivate Android Development] waldo98:
I attempted to upgrade to 3.07 from 3.05 and now I can't get past the AT&T boot screen. I was on Fusion. Any suggestions on how to fix this? If not, I'll have to start from scratch again
[Captivate Android Development] GuitsBoy:
I got stuck in a boot loop as well, moving from 3.06 to 3.07. I was lucky enough to have kept 3.06 on the phone just in case. I pulled the battery, did the three button salute, then CWM flashed back to 3.06, and Im back in business. If youre not so lucky to have 3.05 still on the phone, maybe there an old 3.06 ODIN version laying around somewhere?
[Captivate Android Development] phrix626:
I just flashed 3.07 and got a boot loop too.

Did a battery pull, held vol up vol down and power button to get into recovery, then flashed the older one back.

I wonder what caused the boot loop?

Edit: Guitsboy was a little quicker on the draw...
[Captivate Android Development] waldo98:
I'll have to check when I get home but I doubt it. Currently charging up my phone at the moment just in case I gotta re-flash the ROM and kernel.
[Captivate Android Development] prbassplayer:
Currently bootlooping on 3.07 none root. Used sgs kernel flasher. I was updating from 3.06 none root.
[Captivate Android Development] matmanchu5:
just flashed over stock and started bootlooping promptly after converting to ext4 still ble to reach recovery via 3button,flashed 3.06....still bootlooping oops maybe not bootlooped twice then all is OK! should i dare flashing 3.07 again...I wonder?
[Captivate Android Development] mtcarey:
3.07 pulled...

The links point back to 3.06 until I can get this fixed! Sorry folks. :confused:
[Captivate Android Development] prbassplayer:
No worries bro no real biggy
[Captivate Android Development] mtcarey:
3.07 beta posted

I re-assembled everything and posted links to 3.07 as a beta. Had no problems with 3.07 on my end, but maybe something went wrong in the packaging. The only thing that changed from 3.06 was the boot animation routine, which I tested with and without a custom animation.
[Captivate Android Development] Jsmokey:
Thats all part of the fun making roms and kernels...lol Things can always go drastically different than they do for you thats why my kernels still on hold, I have a few friends helping me test though and hopefully ill be pushing it soon.
[Captivate Android Development] mtcarey:
Do you want to take-over mine!? :D It's starting to make me crazy.
[Captivate Android Development] prbassplayer:
Happy to report 3.07 beta none root flashed fine no bootloop and better bootanimation. Good work.
[Captivate Android Development] Chargerdude70:
sorry guys...I bailed on 3.06 and flashed Boog's to get it running again....time permitting, I will give 3.07 a try...I did like the performance.... thumbs up to the Dev
[Captivate Android Development] ln100:
I installed 3.07 non-root with voodoo disabled and have had no problems.
[Captivate Android Development] mtcarey:
Cool... something must have gotten messed-up in packing the zImage the first time around. Glad it seems to be working now.
[Captivate Android Development] Jsmokey:
NO....lol I had enough headaches on mine I'm still working on kh3 base btw, figured with all the recent leaks I may as well work at getting it stable then move to the newer leaks. I ended up pulling my custom lagfix scripts for for now too until I'm completely satisfied with my conversion scripts.

I didn't really see enough improvement for the time being to leave it in anyways with the sd card read tweaks I did. Literally takes like 15secs to scan media at boot and gallery loads almost instantly with over a thousand pics and icons without lagfix.
[Captivate Android Development] ln100:
I had downloaded 3.07 around 4:45 EST, before it was pulled and relabeled beta. Have had no problems with it - like I said - I never converted to EXT4.
[Captivate Android Development] matmanchu5:
all links seem to be down:(
[Captivate Android Development] kevria:
Weird, they worked a few hours ago from Beijing.
[Captivate Android Development] mtcarey:
Dropbox... maybe they were doing "maintenance" of something. Links are working now.
[Captivate Android Development] q659503934:
why i still hava sd card mounting problem in Recovery with newest version

I don't know where do wrong
[Captivate Android Development] networkdood:
ok, if I want to add some tweaks with this kernel...in the init.d folder, do I rename them to start before or after the corn kernel tweaks....or does it matter?
[Captivate Android Development] mtcarey:
External SD card mounting is disabled in recovery so that nandroid won't back it up. This is by design.
[Captivate Android Development] mtcarey:
The scripts are executed in ascii order by name. If you want to override anything in my scripts then you should name them so that they appear after those. Otherwise, the order doesn't really matter.
[Captivate Android Development] networkdood:
Yours start with an S1, S2, etc....so, right now, I have them after the scripts in the Corn Kernel - I get 2300-2700 Quadrant scores without O/C, so I suppose it is working. Maybe, I could reverse the order to start yours first. I am just amazed at the results I get. Thank you.
[Captivate Android Development] simbill:
I've noticed something with the way my phone sleeps running your kernel. Now I'm not sure if its a tegrak oc issue or your kernel, but some days ill see in Android System Information that phone was running 18 hours and only slept like 30min. A reboot will often rectify the problem, showing hours and hours of sleep, but for only that boot. Ill reboot after 18-24 hours after that and it's back to no sleeping and my battery dies much quicker ..

On a day that it sleeps ill still have 50% + or - like 5% after about 14 hours. No sleep days its at 20-30% within 9 hours
[Captivate Android Development] Jsmokey:
Might be the way he has power collapse set up in either a script or the kernel or the rom maker has it set in the build.prop.

With my project kernel and rom with my tweaks it takes forever to run my battery down, took it off the charger at 8:49 this morning it's 11:41 here now and I'm still at 100%. I've checked xda this morning twice and appy geek news but thats it. Under heavy use, browsing, lots of music, overclocked, most of the day by the time I go to bed I usually have about at least 50-60% and I can leave it off the charger til morning and still have almost the same battery life. I currently have lmk(mix between my vals and juwe's), tcp, and a few other tweaks in the kernel. My rom has a decent chunk of battery tweaks though.

If you dont already use the on demand governor in tegrak and change scheduling to noop under tweaks and that should help some.
[Captivate Android Development] mtcarey:
Other than the lagfix, I left the kernel pretty much stock... I didn't put any extra "tweaks" in init.rc (which you can't change) specifically so you could control everything through sysctl.conf and init.d scripts. If you installed the CWM ".zip" package, it does include a lot of tweaks in the provided sysctl.conf (/system/etc/sysctl.conf). If you want to disable them, either edit the file or rename it something like "sysctl.bak" and re-boot. Alternatively, you can comment-out the line "sysctl -p" (with "#") in "/system/etc/init.d/S01sysctl", which will disable sysctl.conf. See if that makes any difference. I haven't experienced what you're describing... my battery lasts "forever"!
[Captivate Android Development] mtcarey:
You're welcome! Amazing speed. You could also try removing the scripts I provided (on my phone, I created an "/init.d/backup" folder and move them there). See if that makes any difference. Also, see my previous post about "sysctl.conf".
[Captivate Android Development] mtcarey:
That's pretty amazing battery life. Even without tweaks, these Captivate kernels are so much better on that score than the I9000 kernels I've tried. Also, I'm going to have to get the tegrak app to play with!
[Captivate Android Development] Jsmokey:
Yeah I didn't thing you really cooked anything into the kernel. He may also want to try to clear battery stats, make sure wifi's off when using data network and vice versa as they both hog the battery when they scan and if you aren't using either you could always turn them both off.

I also disable system sounds, I find the clicking annoying and it waste battery might not be much but every bit counts. Change display brightness so it's not wasting battery, usually keep mine a little less than half during the day and less than a quarter brightness at night.

Could also be the battery is getting a little wore down too though.

@post about i9000

Yeah the i9000 kernels eat the battery alot more than captivate but thats because it's not coded for it, the hardware might be almost the same but the code isn't optimized for our specific hardware thats why the porting of i9000 roms and kernels is almost dead for the cappy now that we have true captivate gingerbread. Even if it is all leaks at this point it's still better than the ported code in the end.
[Captivate Android Development] networkdood:
Strange that I get far lower quadrant scored with the newest version of Corn. Also, when in CwM recovery, before it would say 'Corn Kernel' and now it does not.
[Captivate Android Development] boog:
It looks like the latest android bootable recovery (5.0.2.6) will do backup and restore when on ext4, rfs still might be iffy (so far rfs tests have failed).

I successfully restored a backup of my kj3 after flashing it back to stock and reconverting back to ext4.
[Captivate Android Development] Jsmokey:
Just curious but which way did you go as far as source for cwm? I've been working with the source packed into the cyanogen and using make recoveryimage command, but I also have the cwm 'official' source but haven't messed with it much.
[Captivate Android Development] boog:
right now I am using what came in cyanogen

make -j4 recovery is the command I use. and if you make a bunch of changes to the source, a make clean is needed. Just keep the terminal open with the environment set and you don't have to recompile all of cyanogen again.

You can even swap out recovery folders with different versions, make clean, then make -j4 recovery again.

I don't like to reboot just because I keep my terminal open with the environment set lol
[Captivate Android Development] Jsmokey:
Yeah I knew all the 'make' parts, I'm running my own version of cwm on my red nebula kernel to take care of running my custom lagfix, I was doing it with an update.zip that contained all my scripts and it was just over complicating the process. I was just wondering which one you started from cause I've been curious as to if the cyanogen one already has some changes compared to the one I pulled from the main cwm repo since I haven't really poked around the main one since is easier to build the cwm one since all the make scripts are all in place already.

What do you mean recompile all of cyanogen? I can build just recovery right from the start and skip everything else using "make recoveryimage" then just pack the recovery.img into a properly set up update.zip. Thats how koush's cwm porting guide said to pack it to flash so that's how I've been doing it.

BTW do you know where to find the older cwm source? I've searched some for it here and there and all I can turn up is the update.zips and no source.
[Captivate Android Development] boog:
So, your packing your kernel and cwm seperate? I build cyanogen because those were the directions from other kernel devs. It sets up an environment for the captivate, guess I never tried koush's porting method, I thought it was for having them separate.

And I'm not sure where to find all of the old versions, but existz github has his 3.0.0.5, I have the 4.0.1.5 that I started with, and the latest 5.0.2.6.
[Captivate Android Development] Jsmokey:
Huh I looked all over for them on google, guess I missed it after being up for almost 20hrs that day plus I completely spaced exitz had a github. lol.

Yeah I set up the environment like normal then just build the recovery.img and pack it in the update.zip with my kernel and install towards the end of my updater script, just for now though so it's faster to change pieces, compile, and then flash for testing.

Once I'm sure everything's good I may change how I do it or maybe just leave it this way since it only takes a little longer to flash but I have the ability to revise either my recovery separately and not have to recompile everything and just replace the old one in my update.zip.

To each his own though, I just find it much easier and faster this way and it gives me a little more room to play around and keeps both projects separate for testing.

Oh and the only part of the guide I really use is how to build the image and put your kernel in the captivatemtd folder and check boardconfig.mk to see if it's set up right, the rest I haven't tried it's easier to pull proprietary with extract-files.sh then compile the way his guide says.

Edit: I just remembered that the recovery.img includes kernel and recovery and since boardconfig.mk includes a line looking for the prebuilt kernel in the captivatemtd folder I guess I am compiling them together but I haven't pulled the recovery.img apart yet to confirm that.
[Captivate Android Development] mtcarey:
I'm using the Cyanogen source, and have found that the following avoids having to do a complete re-build... just rebuilds the bits that have changed - even between sessions.

". build/envsetup.sh && brunch captivatemtd"

One caveat is that if you change any of the Android.mk files, you sometimes have to run "make clobber" first and start over to get the changes to stick.
[Captivate Android Development] mtcarey:
Recovery only show the "Corn" background on a few screens... most have no background. As far as the lower scores go, are you using the sysctl.conf and init.d scripts that are packaged in the CWM flashable version?