[Q] OC kernel for GPU or CPU

[Guest targetbsp]

What did you get in the log file?

 

Hard to say... Don't think I have a /data anymore lol

 

I shall try that terminal command once I've restored.

Edited March 19, 2014 by targetbsp

[Guest shiftyc]

I'll try again but adding the lines to init.qcom.rc instead.

 

@KonstaT... just to advise that sadly this didn't work either.

[Guest KonstaT]

I thought that's all I'd need, but it didn't work.

 

Unfortunately, that doesn't seem to work either.  I pasted those lines into the sections you mentioned in init.rc.  It boots OK, but again doesn't seem to do anything.  I have /system/etc/init.d folder with 755 permissions and a 1 line script in there that creates a file in /data/local/temp, again that script has 755 permissions.  But the file isn't created on boot.

 

I'll try again but adding the lines to init.qcom.rc instead.

Can't think of a reason why that wouldn't work. It doesn't matter if it's in init.rc or init.qcom.rc, init.target.rc would work too. You checked from a booted device that the lines you added are actually there?

[Guest targetbsp]

 

And can you try the terminal line I suggested a couple of posts above just to be sure?

 

I got the same thing as you.  Though interestingly only after updating busybox.  Prior to that, -n was an unknown parameter for mountpoint.

I'm 99% sure I tried this with an updated busybox though - but worth another go after charging to be sure I spose!

Edited March 19, 2014 by targetbsp

[Guest shiftyc]

Can't think of a reason why that wouldn't work. It doesn't matter if it's in init.rc or init.qcom.rc, init.target.rc would work too. You checked from a booted device that the lines you added are actually there?

 

I'll check again tomorrow when I'm in front of the computer with the image, but I'm fairly confident unless I did something stupid (entirely possible!).

 

I got the same thing as you.  Though interestingly only after updating busybox.  Prior to that, -n was an unknown parameter for mountpoint.

I'm 99% sure I tried this with an updated busybox though - but worth another go after charging to be sure I spose!

 

That's potentially encouraging, busybox is used extensively throughout the script so it could well make a difference.

[Guest targetbsp]

Right. My log now has:

 

/dev/block/vold/179:13

 

The script still isn't doing anything useful, sd-ext is still empty.

 

So whilst I was sure I had tried updating busybox, it was clearly out of data at the time I did that extra line for the log and it is clearly needed even if it isn't the entire solution.

Edited March 19, 2014 by targetbsp

[Guest shiftyc]

So you reverted the script back to using $INT_DATA instead of your hard-coded mount point and it still doesn't work?

 

Sorry, I have no clue.

[Guest targetbsp]

No problem. I greatly appreciate your help so far! :)

 

Now what I'm hoping, is that it's going wrong due to where it's being run (from the post boot script) and it'll all magically work with your init.d supporting kernel.  No pressure! :p

[Guest shiftyc]

I think there's about as much chance of me getting the kernel working as there is of you getting the script working, but I'll give it another shot. :)

 

[edit]

Actually I can see what's going wrong with the kernel, so I guess that's progress.  Now "all" I have to do is work out how to fix it...

Edited March 20, 2014 by shiftyc

[Guest shiftyc]

Eureka.  That is all.

[Guest targetbsp]

Nice. :D

[Guest shiftyc]

Now what I'm hoping, is that it's going wrong due to where it's being run (from the post boot script) and it'll all magically work with your init.d supporting kernel.  No pressure! :P

 

Pressure's now back on you ;)

[Guest targetbsp]

Ha ha, yep. :D  I shall give it a try later this evening. Watching The Hobbit atm!

[Guest targetbsp]

Well it definitely behaves differently called from the kernel rather than post boot.  The script that used to do nothing now prevents the phone from booting!  I'll try the other scripts and see if they work differently - in a way that works preferably

[Guest shiftyc]

I believe the init.d scripts are now being executed before /data is even mounted.  In which case, that INT_DATA= line isn't going to get evaluated correctly.  Maybe go back to hard-coding it?

[Guest targetbsp]

But that script is meant to be universal and called from init.d?  Is our data doing something weird then?

[Guest shiftyc]

This seems to be the line mounting /data at boot:

mount ext4 /dev/block/mmcblk0p13 /data nosuid nodev barrier=1 noauto_da_alloc

and that doesn't occur until after my hook to init.d.  All I'm suggesting is that because the generic script doesn't seem to be working, why not replace the variables with hard-coded values that we know to be correct for the Blade V?  Other than that, I'm out of ideas.

 

You could try hard-coding:

/dev/block/platform/msm_sdcc.3/by-num/p13

as the value for INT_DATA.

[Guest targetbsp]

I shall give it a go! Thanks.

[Guest KonstaT]

This seems to be the line mounting /data at boot:

mount ext4 /dev/block/mmcblk0p13 /data nosuid nodev barrier=1 noauto_da_alloc

and that doesn't occur until after my hook to init.d.  All I'm suggesting is that because the generic script doesn't seem to be working, why not replace the variables with hard-coded values that we know to be correct for the Blade V?  Other than that, I'm out of ideas.

Did you put the start service under post-fs-data? Just because something is before or after in the .rc file, it doesn't mean that it would necessarily happen in that order. All init files are parsed together when device is booted and segments of each included files go in this order:

early-init
init
early-fs
emmc-fs
fs
post-fs
post-fs-data
early-boot
boot

 

Init.d hook most definitely needs to be somewhere after /data is mounted (and it likely already is).

[Guest targetbsp]

Come to think of it, the init.d test program outputs to /data so it must already be mounted?

 

So I'm officially at a loss with those scripts now then.

[Guest shiftyc]

 

Did you put the start service under post-fs-data? Just because something is before or after in the .rc file, it doesn't mean that it would necessarily happen in that order. All init files are parsed together when device is booted and segments of each included files go in this order:

early-init
init
early-fs
emmc-fs
fs
post-fs
post-fs-data
early-boot
boot

 

Init.d hook most definitely needs to be somewhere after /data is mounted (and it likely already is).

 

 

OK, thanks.  Yes, service start under post-fs-data and execution of scripts under boot.  I assumed init.target.rc would be executed after init.rc but now I understand.

 

 

Come to think of it, the init.d test program outputs to /data so it must already be mounted?

 

So I'm officially at a loss with those scripts now then.

 

D'oh, of course, good point.  Did you try hard-coding the mount point anyway?

[Guest targetbsp]

No luck.  It still just hangs after the boot animation.

[Guest shiftyc]

Anything useful in the log?  Does /sd-ext/$VER.log exist?  Anything in logcat?

[Guest targetbsp]

I've given up at this point. :D

 

If I ever try again I'll use ADB to grab the logs I spose.

[Guest targetbsp]

There's a new (premium) version of Link2SD that can move app data to ext partitions.  This works with the Blade V.  Storage problems solved. :)

 

https://play.google.com/store/apps/details?id=com.buak.link2sdplus

requires you to also have: https://play.google.com/store/apps/details?id=com.buak.Link2SD

as it's just an unlocker for it.

 

 

Move all your programs using the built in apps2sd functionality as that moves the libs which Link2SD can't handle properly (they move back on a reboot)

Then have Link2SD create links to ext partition for any large dex and data files (which apps2sd won't move)

Edited July 5, 2014 by targetbsp