So, I've seen many a people talk about boot.imgs, and kernels, and mostly spamming dev threads. So, why not create a new thread for it?
Here, ask your questions related to kernels and boot.imgs, and feel free to post any *improvements* that you've made to an existing boot.img/kernel, and so...
Also, feel free to join the discussion, feature requests, whether or not possible, etc, etc.
This thread might be one whole lot of junk, but still if it helps from keeping people from spamming dev threads, why not
So, start!
Lets start from the basics...
Compiling a kernel is easy, IMO :fingers-crossed:
But, the unpacking repacking stuff is a bit difficult...
Anyways, here's the basics:
Packaging kernel for flashing on target device (by sakindia123): http://forum.xda-developers.com/showpost.php?p=31656992&postcount=3
Packaging kernel for flashing on target device (by #define): http://forum.xda-developers.com/showthread.php?t=2114594 (start from step 6)
New CM11 Ramdisk changes...
Well, this was taking up a lot of space on the main thread... Read it here :fingers-crossed:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
edit: some more thoughts...
If you're going to boot this ROM from your SD Card, then, better beware of the new changes in the mounting process... A new fstab.pico is handling the mounting processes..
And, its moved from init.rc to init.pico.rc :|
So, If you're gonna do the editing stuff, you'd find that init.pico.rc has:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
# mount partitions
mount_all /fstab.pico
So, if you're gonna just edit those lines, and just change the [email protected], or the [email protected] lines, then, you'd likely be pretty much booting the ROM again from your internal nand. the main reason for this being the line below: mount_all /fstab.pico, which is the fstab.pico I was talking about...
Now, if you'd open up fstab.pico, its pretty much like the /etc/fstab that you'd find on any linux system. the typical device, mountpoint, type and all... If you'd open it, you'll find this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mtdblock3 /system yaffs2 ro,barrier=1 wait
/dev/block/mtdblock4 /cache yaffs2 nosuid,nodev,barrier=1 wait,check
/dev/block/mtdblock5 /data yaffs2 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto
Well, those were the lines from the CM11 preview, not exactly the same, the last line was derped by me in my vain attempts to get the sdcard running... Oh, and the mounting of the SD Card's completely changed too :silly:
BTW, getting back to mounting the ROM from the sdcard, you'd need to edit this fstab.pico file, to something similar to this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mmcblk0p2 /system ext4 ro,barrier=1 wait
/dev/block/mmcblk0p4 /cache ext4 nosuid,nodev,barrier=1 wait,check
/dev/block/mmcblk0p3 /data ext4 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto
Well this is the first post, asking for help... Hope you get the hint *wink *wink
In case you can't get something done, ask for help here!
I tried porting the touchscreen gestures from Siyah Kernel with reference from this commit: https://github.com/gokhanmoral/siyahkernel3/commit/9f57d9efc7458c1a9f540cd04bc5cb14e08fb342
Well, that more or less turned out to be like this: https://github.com/vineethraj49/android_kernel_htc_pico/tree/gestures (check the last few commits...)
And, turns out it works :laugh: with a small bug
1. only single finger gestures work, i think....
2. no way to get the infinite while loop started at init.d
Here's how I did it... Reference thread: http://forum.xda-developers.com/showthread.php?t=1831254
the init.d script is as belows, doesn't work...
Code:
#!/system/bin/sh
echo "
# Gesture 1 - swipe 1 finger near the top
1:1:(0|150,0|150)
1:1:(210|320,0|150)
" > /sys/devices/virtual/misc/touch_gestures/gesture_patterns
while [ 1 ]
do
GESTURE=`cat /sys/devices/virtual/misc/touch_gestures/wait_for_gesture`
if [ "$GESTURE" == "1" ]; then
screencap > /sdcard/`date +%H%M%S.png`
fi;
done
So, inputted those commands using adb, in adb shell, and it works... Got a hell lot of screenshots... but, any way to fix the bugs I mentioned?
Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:
#Superuser said:
Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:
Click to expand...
Click to collapse
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32
thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32
Click to expand...
Click to collapse
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS
thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
Click to expand...
Click to collapse
Lol thats a huge explanation! :good: :highfive:
#Superuser said:
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS
Click to expand...
Click to collapse
Yes, it is possible. Open your init.rc and find the following line:
Code:
mkdir /data/app 0771 system system
mkdir /data/app-private 0771 system system
mkdir /data/app-asec 0700 root root
mkdir /data/app-lib 0771 system system
Now change it like this:
Code:
# For installing apps directly to /sd-ext:
mkdir /sd-ext/app 0771 system system
mkdir /sd-ext/app-private 0771 system system
mkdir /sd-ext/app-asec 0700 root root
mkdir /sd-ext/app-lib 0771 system system
# Now the symlinking part:
symlink /sd-ext/app /data/app
symlink /sd-ext/app-private /data/app-private
symlink /sd-ext/app-asec /data/app-asec
symlink /sd-ext/app-lib /data/app-lib
NOTE: Before doing this make sure that you have mounted /sd-ext partition.
@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.
@cute_prince Thanks. Now, I'm gonna post all my doubt related to kernels and ramdisks! Thanks to @thewisenerd as well!
cuteitsme said:
@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.
Click to expand...
Click to collapse
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
## Only continue if mmcblk0p2 exists
if [ ! -e /dev/block/mmcblk0p2 ] //If /dev/block/mmcblk0p2 doesn't exist
then //then
exit //this script exists. this code's here for safety.
fi;
## Set SD cache size
SD_CACHE=/sys/devices/virtual/bdi/179:0/read_ahead_kb //read_ahead_kb is the amount of kb that the kernel reads, beforehand.
if [ -e $SD_CACHE ] //checking the existence of the file, just in case...
then
busybox echo "2048" > $SD_CACHE; //2048 is found to be an optimum value for sdcards, class 4 and better.
fi;
## Make /sd-ext directory if needed and unmount /sd-ext if it already mounted
##why? because the writer croniccorey, has done some thinking here
##will explain side by side... If the directory /sd-ext doesn't exist, its created here.
##note: the commands run by the init.rc have full access to the root file system created.
if [ ! -e /sd-ext ] //if doesn't exist sd-ext foler in root file system
then
busybox mount -o remount,rw /; //mount the root file system "/" as rewritable
busybox mkdir /sd-ext; //create a directory named sd-ext
busybox mount -o remount,ro /; //mount the file system as read-only again
else
busybox umount /sd-ext; //else, unmount the sd-ext partition, i.e. partition in the sd-card.
fi;
## Move /data mount point to /sd-ext
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1) //this gets the mountpoint of the data partition.
// this command "busybox mountpoint -n /data | cut -d ' ' -f1" is actually runnable, and you'd get the mount point
// of the /data partition in the internal memory (which is this: /dev/block/mtdblock5)
busybox umount /data; //unmount the /data partition too/
// the data partition is unmounted because we're going to do some stuff
busybox mount $INT_DATA /sd-ext;
// mount the internal data partition in the sd-ext folder
## Mount mmcblk0p2 to /data
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data; //well, this is self-explanatory. mount the partition in sdcard into internal memory.
busybox chown 1000:1000 /data; //chown the folder by root (get more help by running "man chown" in a shell)
busybox chmod 771 /data; //chmod the folder (get more help by running "man chmod" in a shell)
## Move existing files
if [ ! -e /data/app ] //why /data/app? simply, it can also be anything else like /data/data...
then
busybox mv /sd-ext/* /data;
// the sd-ext folder has the files of the internal /data partition
// those are moved to the sd-card's partition, which is mounted in /data now.
fi;
## Unmount /sd-ext
//unmount the internal data partition.
// we have the partition from the sd-card mounted in the /data partition currently.
busybox umount /sd-ext;
sync;
//sync changes with file system
Click to expand...
Click to collapse
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...
Simply awesome.....what an explanation sirji....
Still trying to understand some part but i will have to do more reading for that first....that i will do.....but must say U rock man.....thanks a lot for this....
thewisenerd said:
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...
Click to expand...
Click to collapse
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?
#Superuser said:
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?
Click to expand...
Click to collapse
Yeah....I guess that's the linux thing. I think the higher the no. the late the script will be called. This is basically to run the more important scripts before the other scripts.
hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.
cuteitsme said:
hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.
Click to expand...
Click to collapse
Hmm... Could you post the two boot.img's here? I'd like to have a look
thewisenerd said:
Hmm... Could you post the two boot.img's here? I'd like to have a look
Click to expand...
Click to collapse
Sure y not.....here u go
@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap
PiCo HackR said:
@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap
Click to expand...
Click to collapse
The question is: Why do you need swap?