• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.
Sign in to follow this  
Followers 0

[Q] OC kernel for GPU or CPU

77 posts in this topic

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted

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

 

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

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted (edited)

 

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
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted

Eureka.  That is all.

1

Share this post


Link to post
Share on other sites

Posted

Nice. :D

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

I shall give it a go! Thanks.

0

Share this post


Link to post
Share on other sites

Posted

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).
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

 

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?

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

I've given up at this point. :D

 

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.