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

There's just not enough room for it.  My backup is 6GB.  There's a reason i need ext support.  I have a lot of stuff. :D

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Thanks, I did successfully extract the ramdisk already today from stock but I stopped because it seemed unnecessary (and more risky) to modify boot.img.  I mean risky because someone here would need to test it and my knowledge is... limited!

 

I've also tried to build the kernel from source today, it's currently failing on a #include of a header file that it can't find, I'm not sure why because it's present.  But anyway I've run out of time today so I may pick it up again tomorrow.

 

Dunno why I'm bothering if target can't get his script working anyway lol  ;)

No, it's not risky at all. :P You don't even have to flash it to your device until you've tested that it works for sure and even then there's still nandroid backups. Just use 'fastboot boot boot.img'.

 

Yeah, it doesn't compile as usual. Change <header.h> to "header.h" (or vice versa, can't remember) on the line that it errors out.

1

Share this post


Link to post
Share on other sites

Posted

No, it's not risky at all. :P You don't even have to flash it to your device until you've tested that it works for sure and even then there's still nandroid backups. Just use 'fastboot boot boot.img'.

 

Yeah, it doesn't compile as usual. Change <header.h> to "header.h" (or vice versa, can't remember) on the line that it errors out.

 

Thanks for the encouragement!  And thanks for the tip, I'll look for that tomorrow when I'm back at the computer with the source.  Although my preference would be to write a script that modifies init.rc, that way it would work for any kernel version and I wouldn't have to worry about making source available for GPL for a one-line change!  But I suspect that's beyond my skills.

 

Whilst I have your attention, may I please ask what the advantage would be of using

/system/xbin/busybox run-parts /system/etc/init.d

rather than simply

/system/etc/init.d/*

which seems to give the same result?  I ask because I can see a couple of possible disadvantages with the busybox route:

 

1) It requires a new enough version of busybox to have run-parts support, and

2) There is potentially this issue

 

Thanks for all your help.

0

Share this post


Link to post
Share on other sites

Posted

There's just not enough room for it.  My backup is 6GB.  There's a reason i need ext support.  I have a lot of stuff. :D

 

If you're going to need to restore repeatedly why not flash stock, de-bloat and back that up?  That should be enough to prove whether your changes work, you don't really need to restore 6GB every time do you?

0

Share this post


Link to post
Share on other sites

Posted (edited)

Well.. I didn't plan on breaking it. :D

 

run-parts works with the included busybox - you don't need to update it,  It was just something I tried yesterday when the real problem was the permissions.

 

[edit]

Mind you, I already have a small backup I could be playing with I spose: http://www.modaco.com/topic/368502-virgin-uk-22-update-for-cwm/

Perhaps I'll have more luck with the scripts on a clean rom?

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Perhaps I'll have more luck with the scripts on a clean rom?

 

Not sure what difference it would make but certainly worth a try.

 

I mistakenly thought you'd written your own script.  Do you mean you're trying something like one of these?  If so, how far does it get according to the log file before failing?

0

Share this post


Link to post
Share on other sites

Posted (edited)

Those are the ones.  The log files for Int2Ext (both v1 and v2) seem to think they have worked but nothing has happened.  Data was still the data partition.

I've no idea how far the older D2Ext got as the phone stopped booting. :D

 

The reason I'm wondering about a clean system is that the scripts attempt to move your existing data when they run.  It's possible D2Ext got stuck there.  I left it a good while but...

 

Int2Ext didn't even try that as the boot time was unaffected so it went pear shaped before that but continued on past there to claim it had completed successfully.

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Thanks for the encouragement!  And thanks for the tip, I'll look for that tomorrow when I'm back at the computer with the source.  Although my preference would be to write a script that modifies init.rc, that way it would work for any kernel version and I wouldn't have to worry about making source available for GPL for a one-line change!  But I suspect that's beyond my skills.

 

Whilst I have your attention, may I please ask what the advantage would be of using

/system/xbin/busybox run-parts /system/etc/init.d

rather than simply

/system/etc/init.d/*

which seems to give the same result?  I ask because I can see a couple of possible disadvantages with the busybox route:

 

1) It requires a new enough version of busybox to have run-parts support, and

2) There is potentially this issue

 

Thanks for all your help.

Well, I wouldn't worry too much about GPL if the vendor has released a kernel source that doesn't even compile and you're only fixing that. GPL states that the full source code needs to be made available but it doesn't say how. Link to ZTE site and a diff patch if/when requested should be enough to comply with GPL in this case. Iirc there's another small issue that needs to be fixed to compile as well. If you only want to add the init.d support, you can of course just use the stock kernel too. Split the boot.img and make your modifications to the ramdisk and put it back together with the stock zImage.
 
Using run-parts only executes scripts in given location, * would try to execute everything including directories and symlinks. Calling 'busybox run-parts' executes it directly from the busybox, it doesn't matter where it's been symlinked and it makes no sense why it would get called twice.
1

Share this post


Link to post
Share on other sites

Posted

Thanks a lot - all makes sense.

 

I've given up trying to compile the source, every time I fixed one error, it found another.

 

If you only want to add the init.d support, you can of course just use the stock kernel too. Split the boot.img and make your modifications to the ramdisk and put it back together with the stock zImage.

 

That's exactly what I've just done.  I booted from the new image using fastboot and I got a picture of a dead android and the stock recovery :P But I think that's because I tried to be too clever and added a few more things, so I'll try again with pure init.d support.

0

Share this post


Link to post
Share on other sites

Posted (edited)

So here's the script: 

#!/system/bin/sh
######################################
##  CronMod INT2EXTV2+ - 02/28/2013 ##
##    Written by CronicCorey @xda   ##
##             40int2ext            ##
######################################
## Thanks to vvFICKvv, DK75, and Dark Passenger @xda for help to fix compatibility issues with Android 4.2.x
## Thanks to Mortaromarcello @github for code to check if mmcblk0p2 exists

VER=INT2EXTV2+
LOG=/data/$VER.log

## Only continue if mmcblk0p2 exists
if [ ! -e /dev/block/mmcblk0p2 ]
then
busybox echo "mmcblk0p2 does not exist, $VER cannot start" > $LOG;
exit
else
busybox echo "Starting $VER" > $LOG;
fi;

## Set SD cache size
SD_CACHE=/sys/devices/virtual/bdi/179:0/read_ahead_kb
if [ -e $SD_CACHE ]
then
busybox echo "Setting SD_CACHE to 2MB" >> $LOG;
busybox echo "2048" > $SD_CACHE;
else
busybox echo "Setting SD_CACHE failed " >> $LOG;
fi;

## Make /sd-ext directory if needed and unmount /sd-ext if it already mounted
if [ ! -e /sd-ext ]
then
busybox echo "/sd-ext directory does not exist, making it now" >> $LOG;
busybox mount -o remount,rw /;
busybox mkdir /sd-ext;
busybox mount -o remount,ro /;
else
busybox echo "Unmounting /sd-ext in case it mounted already" >> $LOG;
busybox umount /sd-ext;
fi;

## Move /data mount point to /sd-ext
busybox echo "Moving /data mount point to /sd-ext" >> $LOG;
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1)
busybox umount /data;
busybox mount $INT_DATA /sd-ext;

## Mount mmcblk0p2 to /data
busybox echo "Mounting sd-ext to /data" >> /sd-ext/$VER.log;
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
busybox chown 1000:1000 /data;
busybox chmod 771 /data;

## Move log file back to /data
busybox mv /sd-ext/$VER.log /data;

## Move existing files
for i in app app-private dalvik-cache;
do
if [ ! -e /data/$i ]
then
busybox echo "Moving /sd-ext/$i to /data" >> $LOG;
busybox mv /sd-ext/$i /data;
fi;

## Setup directorys for binds
if [ -e /sd-ext/$i ]
then
busybox echo "Removing /sd-ext/$i so it wont get binded" >> $LOG;
busybox rm -rf /sd-ext/$i;
fi;
done;

for i in `ls /sd-ext`;
do
if [ ! -e /data/$i ]
then
busybox echo "Making /data/$i directory for bind" >> $LOG;
busybox mkdir /data/$i;
fi;

## Make binds
if [ -e /data/$i ]
then
busybox echo "Binding /sd-ext/$i to /data/$i" >> $LOG;
busybox mount -o bind /sd-ext/$i /data/$i;
fi;
done;

## Unmount /sd-ext, if swap2int is installed leave it mounted until it activates
if [ ! -e /system/bin/swap2int ] && [ ! -e /system/etc/init.d/45swap2int ]
then
busybox echo "Unmounting /sd-ext" >> $LOG;
busybox umount /sd-ext;
else
busybox echo "Leaving /sd-ext mounted so SWAP2INT can activate" >> $LOG;
fi;

busybox echo "Started $VER successfully" >> $LOG;

sync;

And here's the log:

Starting INT2EXTV2+
Setting SD_CACHE to 2MB
/sd-ext directory does not exist, making it now
Moving /data mount point to /sd-ext
Unmounting /sd-ext
Started INT2EXTV2+ successfully

Sd-Ext exists. That bit works.

But the data mount isn't being moved to sd-ext, it's failing there.

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Are there any files in /sd-ext?  Specifically, a file called INT2EXTV2+.log?

 

I think I'm giving up on trying to add init.d support to the kernel.  I have a boot.img that boots fine but it doesn't seem to do anything different to stock.  It's certainly not running my init.d scripts.  How 1 line of code can not work is beyond me.

 

Still, I can add it to my list of Blade V failures: failed to port CM10, failed to build CWM, failed to compile the kernel and now failed to mod the kernel ramdisk.  Go me!

0

Share this post


Link to post
Share on other sites

Posted (edited)

No, that log is from /data on internal.

sd-ext is completely empty.

 

D2Ext+ is at least doing something on a wiped phone.  Specifically it's making the phone app crash over and over. :D

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Well if you look at this snippet:

## Move /data mount point to /sd-ext
busybox echo "Moving /data mount point to /sd-ext" >> $LOG;
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1)
busybox umount /data;
busybox mount $INT_DATA /sd-ext;

## Mount mmcblk0p2 to /data
busybox echo "Mounting sd-ext to /data" >> /sd-ext/$VER.log;

The first busybox echo is working, but the second one isn't; which means the mount is failing.  Can you add the following after the "INT_DATA=..." line, then try again and post what the log contains?

busybox echo $INT_DATA >> $LOG;
1

Share this post


Link to post
Share on other sites

Posted (edited)

Will do in a bit.  One thing though, why does it skip that log entry (mounting sd-ext) but reach the two at the end?

 

[edit]

Ah, I just saw, it's trying to output that line to a different log.

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

Because it's outputting it to a different log file - $VER.log, which equates to /sd-ext/INT2EXTV2+.log.  That's why I asked if that file was there :)

 

I think what you'll get is an extra line in the log saying "/dev/block/mmcblk0p13". If that's the original mount point for /data, then I don't see why the script isn't working.  And this is the point where we sit and hope someone that knows what they're talking about (hi KonstaT!) re-joins the discussion.

0

Share this post


Link to post
Share on other sites

Posted

So, presumably what we're hoping for is that busybox mountpoint is letting the side down and we can instead hard code INT_DATA to the correct value for our phone. :D

0

Share this post


Link to post
Share on other sites

Posted

That was originally my hope, but I ran the mountpoint line in a terminal window and it came back with "/dev/block/mmcblk0p13".  I dunno if that's correct, but it certainly seems reasonable.

0

Share this post


Link to post
Share on other sites

Posted

I think I'm giving up on trying to add init.d support to the kernel.  I have a boot.img that boots fine but it doesn't seem to do anything different to stock.  It's certainly not running my init.d scripts.  How 1 line of code can not work is beyond me.

I guess it would a bit more than just one line if you're adding it to ramdisk (though 'exec /system/xbin/busybox run-parts /system/etc/init.d' might work too).
on post-fs-data
    start sysinit

on boot
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
    user root
    oneshot
    disabled

'on post-fs-data' and 'on boot' are only for reference under which segments the service belongs, they're already in the init.(qcom).rc.

1

Share this post


Link to post
Share on other sites

Posted (edited)

Thanks so much for taking the time to help.

 

 

I guess it would a bit more than just one line if you're adding it to ramdisk (though 'exec /system/xbin/busybox run-parts /system/etc/init.d' might work too).

 

 

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

 

on post-fs-data
    start sysinit

on boot
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
    user root
    oneshot
    disabled

'on post-fs-data' and 'on boot' are only for reference under which segments the service belongs, they're already in the init.(qcom).rc.

 

 

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.

Edited by shiftyc
0

Share this post


Link to post
Share on other sites

Posted (edited)

INT_DATA appears to be empty!

 

It's certainly taking its time doing something now I've hard coded that value.  And I hope what it's doing is moving my data over... :D

Edited by targetbsp
0

Share this post


Link to post
Share on other sites

Posted

So there's a blank line in the log?

 

From a terminal window on your phone, what result does this give:

echo $(busybox mountpoint -n /data | cut -d ' ' -f1)

(note that the penultimate character is the digit one, not a lowercase L)

0

Share this post


Link to post
Share on other sites

Posted

It's certainly taking its time doing something now I've hard coded that value.  And I hope what it's doing is moving my data over... :D

 

Um... in that case let's hope the mountpoint is the same for your phone as it is for mine!!

0

Share this post


Link to post
Share on other sites

Posted

The problem with this is knowing how long to remain patient for vs concluding that it's going horribly wrong. :D

It's sat on an 'android is upgrading... starting apps' screen.

 

If it's much longer, I'll try this from wiped data again.  But I'll probably have to take a break to charge the battery first.

0

Share this post


Link to post
Share on other sites

Posted

I gave up. And according to my partitioning software, nothing had moved across to the Ext partition. :(

0

Share this post


Link to post
Share on other sites

Posted

What did you get in the log file?

 

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

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.