[AT&T LG Optimus G] CrustyCrack:
I modified the boot.img using Android Image Kitchen, follow the instructions and you should be fine, the files you are looking for in the boot.img reside in the ramdisk folder that is created when you unpack it.

Are you able to translate some of the steps in that post Rohan? Because Google translate does a very poor job! :rolleyes: Please and thanks in advance.

I had a look at the 25MB boot.img the past few days and was comparing the ramdisk to the SD fixes that were made and the Jelly Bean E97020j boot.img. The reason it was 25MB was the compression method used I think, using an boot.img unpacker and repacking it like Android Image Kitchen will shrink it down to 10MB or so even though I made no changes, hence why I think its the compression method making it so big. I've yet to touch the zimage/kernel as I don't know enough about it yet.

From a coding perspective, I personally think that the device specific init.rc files are oddly written by the LG devs, there are given examples to work from on the Android source code site on how to mount the storage correctly if you have a emulated external (internal storage) and secondary storage (external SD card), but they have all "the steps" mixed up and spread across different init.[hardware/device/target].rc files in the hierarchy. The SD fixes unfortunately only makes this more confusing to read, but they are definitely on the right track!

According to Android Source it should go like this / How I've rewritten it so far:

on init

mkdir /mnt/shell/emulated 0700 shell shell

mkdir /storage/emulated 0555 root root

mkdir/mnt/media_rw/external_sd 0700 media_rw media_rw

mkdir/storage/external_SD 0700 root root

export EXTERNAL_STORAGE /storage/emulated/legacy

export EMULATED_STORAGE_SOURCE /mnt/shell/emulated

export EMULATED_STORAGE_TARGET /storage/emulated

export SECONDARY_STORAGE /storage/external_SD

on fs

setprop ro.crypto.fuse_sdcard true

service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated

class late_start

service fuse_external_SD /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/external_sd /storage/external_SD

class late_start

disabled

This is how the files read in a chronological order (to me) with the E975 default:

on init

service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated

class late_start

export EXTERNAL_STORAGE /storage/emulated/legacy

export EMULATED_STORAGE_SOURCE /mnt/shell/emulated

export EMULATED_STORAGE_TARGET /storage/emulated

export SECONDARY_STORAGE /storage/external_SD

mkdir /mnt/shell/emulated 0700 shell shell

mkdir /storage/emulated 0555 root root

mkdir/storage/external_SD 0700 root root

mkdir/mnt/media_rw/external_sd 0700 media_rw media_rw

[NO SETPROP CRYPTO.FUSE_SDCARD MENTIONED]

[NO EXTERNAL SD FUSE SERVICE MENTIONED]

Both methods seem to work fine, which to me means that, to an extent, most of these lines of code/commands don't need to be in any order as they are for the most part just mounting and initializing directories. The fuse service however seems like the kind of thing that needs to be initialized after the storage has been mounted (surely?) for it to work correctly. It wasn't even mentioned anywhere in the files, other than the ones labeled "altev", which don't seem to be used, but have some interesting lines of code/commands in there regarding SD cards. Just my two cents, anyway if I make any headway with my attempt at fixing this I'll let you all know here, and at some point I'll give that "working MTP fix" a try when I have the time. :)