Should sfhub's init.d tool work on all stock kernel versions I.e. FD16? I assume yes but I figured I would ask anyway
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
Should sfhub's init.d tool work on all stock kernel versions I.e. FD16? I assume yes but I figured I would ask anyway
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
yuuuup..
seems like i'm the only one have slight issues getting it to work..
im on aosp kernel anyway though.
Could you post all the /*.rc files (including init.rc)stock kernel. fd19, modified for aosp of course.. the one that came baked in.
OK one more question, it says to have USB storage disabled but as soon as I plug phone in it goes to MTP and I can't uncheck that option. Am I OK as long as I don't open file on the pop up or am I missing a step?
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
As long as it is stock kernel that wasn't repacked, it should work.Should sfhub's init.d tool work on all stock kernel versions I.e. FD16? I assume yes but I figured I would ask anyway
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
For the purposes of the install, MTP is the same as USB mass storage being disabled.OK one more question, it says to have USB storage disabled but as soon as I plug phone in it goes to MTP and I can't uncheck that option. Am I OK as long as I don't open file on the pop up or am I missing a step?
OK one more question, it says to have USB storage disabled but as soon as I plug phone in it goes to MTP and I can't uncheck that option. Am I OK as long as I don't open file on the pop up or am I missing a step?
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
For the purposes of the install, MTP is the same as USB mass storage being disabled.
BTW you can use Option E to change the default from MTP to USB mass storage. Once in USB mass storage mode, you'll be able to enable and disable the mass storage using the drop down notification usb icon.
Man, you are such an asset to this community! I can't thank you enough for all that you do around here
Sent from my Nexus S 4G using Xparent Blue Tapatalk 2
Well, it definitely worked here! I ran Odex Me to odex a few more apps I added to system/app. The app requires init.d to do its thing and it worked just like it should!
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
Basically what kobridge said, but I'm wondering why they took the time to repack (and rewrite) the rc files and didn't include the init.d support. It is just the addition of a few lines. I am guessing they will be adding init.d support directly into the kernel soon as I've had some PM conversations.
Basically what kobridge said, but I'm wondering why they took the time to repack (and rewrite) the rc files and didn't include the init.d support. It is just the addition of a few lines. I am guessing they will be adding init.d support directly into the kernel soon as I've had some PM conversations.
They appear to have put emmc to sdcard mapping commands in the init.smdk4210.rc script based on what gershee posted earlier.EDIT:
the whole reason i even started looking into this is because i wanted to have the emmc mount at startup to external_sd so everything plays nicer on aosp roms without the help of additional apps.. one thing led to another and it looked like the reason was because there wasn't an init.d script to mount(or because init.d scripts haven't been incorporated in aosp kernels on e4gt yet??).. well, learned alot playing around with stuff i previously haven't messed with.. all the unexpected big time help was greatly appreciated..
Honestly, I don't think that zero byte file is coming from anything from the Auto Root package. The init.d support Auto Root installed is unused because of the custom init.rc in the kernel that your ROM was packaged with.that is what i was thinking..
also i tried the script run from the get go and it didn't do anything..
no zero byte files, nothing..
should i try again?
They appear to have put emmc to sdcard mapping commands in the init.smdk4210.rc script based on what gershee posted earlier.
So do some people run AOSP ROMs with really stock kernels are does everyone run them with the kernels repacked with new .rc scripts. I haven't installed any of these, so while I can look at the posted scripts to see what they do, don't have the actual experience installing them to see what they actually do.
---------- Post added at 01:40 AM ---------- Previous post was at 01:37 AM ----------
Honestly, I don't think that zero byte file is coming from anything from the Auto Root package. The init.d support Auto Root installed is unused because of the custom init.rc in the kernel that your ROM was packaged with.
You could try removing init.d support using the Auto Root option to do that and see what happens to that zero length file.
I know that I threw a script in init.d and set permissions to rwx/rwx/rwx and it worked fine. I'm not all that savvy on what 666 and 755 translate to in the terms if rwx but if set to rxw on all three it works like a charm. Sfhub or OP. I know its a little off topic but since you seem to know. How is that translated from rwx to ###
Yes
Yes
The scripts you run should have "execute" permission set. run-parts in busybox will only run scripts with execute permission set. run-parts is what the repacked kernels are using, so this is not a new requirement
I notice you set your scripts to "chmod 666" so that might be why they aren't running. Try changing to "chmod 755".
Either
1) the permissions on your scripts are not set to have "execute" permission
2) you don't have busybox installed in /system/xbin/busybox
3) you are not running a stock kernel nor stock+cwm nor stock+cwm-rogue
My guess is 1 or 2.
With some feedback with testing of custom ROMs, in the latest upload, I actually removed the requirement for busybox to be installed, so if that is your issue, just download the newer one (the link in the original post was updated but I'm providing it here for convenience)
e4gtauto-lite-sfx.exe