Jump to content

[Q] OC kernel for GPU or CPU


Guest djfnz

Recommended Posts

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 by targetbsp
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by targetbsp
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by targetbsp
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by shiftyc
Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 3 months later...
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 by targetbsp
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.