[Q] OC kernel for GPU or CPU

[Guest targetbsp]

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 March 18, 2014 by targetbsp

[Guest KonstaT]

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.

[Guest shiftyc]

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.

[Guest shiftyc]

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?

[Guest targetbsp]

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 March 18, 2014 by targetbsp

[Guest shiftyc]

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?

[Guest targetbsp]

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 March 18, 2014 by targetbsp

[Guest KonstaT]

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.

[Guest shiftyc]

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.

[Guest targetbsp]

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 March 19, 2014 by targetbsp

[Guest shiftyc]

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!

[Guest targetbsp]

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 March 19, 2014 by targetbsp

[Guest shiftyc]

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;

[Guest targetbsp]

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 March 19, 2014 by targetbsp

[Guest shiftyc]

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.

[Guest targetbsp]

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

[Guest shiftyc]

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.

[Guest KonstaT]

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.

[Guest shiftyc]

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 March 19, 2014 by shiftyc

[Guest targetbsp]

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 March 19, 2014 by targetbsp

[Guest shiftyc]

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)

[Guest shiftyc]

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!!

[Guest targetbsp]

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.

[Guest targetbsp]

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

[Guest shiftyc]

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?