[PROJECT][DIY]Dual Boot ~ the Yin-Yang way!

[PROJECT][DIY]Dual Boot ~ the Yin-Yang way! - HTC Pico (Explorer)

So, I read somewhere that what you've thought, might already have been thought by someone else. Dual-Booting the pico, as most people now know it, isn't something new to this device. When I had made this thread here, most of you might have noticed the init.rc tweak in the post 2. The day before I had written the post, I was experimenting with the possibilities of dual booting my phone, and was successfully able to. How? By changing the mount points, simple.
Now, the problem arises... How many boot.img's do you have to derp? And, how many times would you have to keep flashing your boot partition??? So, I figured out something, which I will be discussing in this thread, which allows you to boot any and any ROM if they both use the same kernel. Therefore, you don't have to flash separate boot.img's everytime you need to change between your primary ROM and secondary ROM.
There is a small change in terminologies:
Primary ROM: The ROM in the internal partition of your device. The name itself is pretty explanatory.
Secondary ROM: The ROM on your SD-Card, secondary, as in second or something like that.
Click to expand...
Click to collapse
So, how will this help me?
No need to repeatedly flash your boot partition (though it ain't gonna cause any damage).
Easier switching of ROMs.
Doesn't need SU (super user) permissions.
So, all talk no show?
Code:
You seem to be the typical TDLR; case :laugh:
Again, sorry to interrupt you, but there are a few things you'd need to know. First and foremost, this:
Code:
#include
/*
* Your warranty is/was void the time you chose to unlock your bootloader.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about how this works!
* YOU are choosing to make these modifications, and if you point
* the finger at me for messing up your device, I will laugh at you.
*
*/
Note: If this is to work with Sense 4.0/4.1; or with the new PLL2 OC'ing method, appropriate changes will have to be made, which I would be discussing in later posts. As of now, this method works with all AOSP and derived ROMs, excluding Sense, and those with PLL2 OC'ing.
How it works:
So, this is what most people want to know! Here's how. :angel:
When the device boots, the init.rc is run, if I remember correctly. Here lies the trick. What I planned to do was creating a place_holder in the SD-Card, use it as a, well, place_holder, and execute <insert-awesome-script-name.sh at bootup, which is bootsdcard.sh in this case.
When is bootsdcard.sh run?
After the internal /system, /data, and /cache partitions are mounted.
Click to expand...
Click to collapse
What bootsdcard.sh does?
It basically is an if/else command. If exist /sdcard/place_holder, which is /sdcard/.bootsdcard, in this case, BTW, it unmounts the /system, /data, and /cache partitions, and mounts the partitions on the sdcard in the /system, /data, and /cache folder.
Click to expand...
Click to collapse
So, how to do that?
Here's where I was confused. Checking for file existence, in init.rc? Then, I remembered that some init.d scripts run the same way. Searched the init.rc for /etc/init.d, in vain. Finally, found this thread, and opened up the ROM's zip. There was indeed a file named [Isysinit[/I] in /system/bin/sysinit, and it contained commands to run the files in /system/etc/init.d. What's more important is that the exec commands could be executed using exec /something After hours of searching, I found this: http://forum.xda-developers.com/showthread.php?t=1598803&highlight=dual+boot. Cool! The Samsung Galaxy Y has had dual boot before pico, thanks to irfanbagus. Still, it had a lot of bloat, and couldn't be used directly for our device. So, I saw how it worked, and, it was efficient. So, I decided to port it to our device.
Prerequisites:
Patience ~ Learn it, if you don't have it!
Two ROMs that boot with the same kernel
Linux or Notepad++
file-roller or WinRAR
partitioned sdcard, in the order: fat32>sd-data>sd-system>sd-cache
Procedure:
1. Preparing the ROMs
Get any two ROMs' zip files, which run with the same kernel. Decide which ROM you want as secondary, i.e. in the SD-Card. Now, open up the zip of the ROM which you want in the SD-Card and extract the updater-script from its META-INF/com/google/android/ folder and make the following changes:
Delete these lines:
Code:
format("yaffs2", "MTD", "system", "0", "/system");
mount("yaffs2", "MTD", "system", "/system");
Insert these lines:
Code:
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p3", "/system");
run_program("/sbin/busybox", "rm", "-rf", "/system/*");
If you feel you aren't doing it correct, please post the updater script of the ROM here. I will edit it.
Drag and drop the changed updater script into the same /META-INF/com/google/android folder. Hopefully, it should be updated within the zip.
Copy these two files to your SD-Card using *any* means possible.
2. Flashing the ROMs
Open recovery, and flash the zip for primary ROM.
Reboot recovery.
Go to Mounts and storage (CWM) or under a similar option, and unmount /data, /cache and /system.
Now, flash the zip you've created for secondary ROM.
If you reboot, you should go into the Primary ROM.
3. Installing modified kernel
You can do this using fastboot too!
Download appropriate pre-derped kernels, or provide the boot.img for derping.
Then, it is pretty simple.
Code:
fastboot flash boot <derped-boot>.img
or via Terminal Emulator
Code:
su
flash_image boot /sdcard/<derped-boot>.img
4. Switching ROMs
Primary ROM to Secondary ROM:
As I said, the place holder. It plays an important role. So, if you want to switch to another ROM, just create an empty file in your sdcard named ".bootsdcard" without quotes. You could also do this via terminal emulator using:
Code:
touch /sdcard/.bootsdcard
Secondary ROM to Primary ROM:
Remove the .bootsdcard from your SD-Card, and you will boot the primary ROM. This can also be done using terminal emulator using:
Code:
rm /sdcard/.bootsdcard
P.S. An application for this is being developed by @omerjerk, to make this easier.
Anything else?
Nothing for now Dual booting my phone with CM9 and MiniCM9.
XDA:DevDB Information
Dual Boot ~ the Yin-Yang way!, a Tool/Utility for the HTC Pico (Explorer)
Contributors
thewisenerd
Version Information
Status: Stable
Created 2013-11-16
Last Updated 2013-11-16

Editing the kernel
Procedure
You MUST know how to unpack/repack kernels, and their ramdisks.
If you unpack your kernel, you would find the folder named sbin where you'd unpacked the ramdisk. Place these two files View attachment busybox.7z and View attachment bootsdcard.txt in the folder. Rename them to "busybox" and "bootsdcard.sh" respectively.
Additionally, you will need to create a folder named "tmp" where you've unpacked the ramdisk.
Now, open up init.rc and find the 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
After these lines, you are most likely to find these lines (or similar lines):
Code:
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Add the following lines to the above:
Code:
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
En total, it should look like this:
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
on post-fs
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Click to expand...
Click to collapse
Now, you can repack the ramdisk, and repack the kernel. In most cases, you should be able to flash the kernel with the busybox included. If you are not able to flash the repacked boot.img, please post the boot.img along with thread from which obtained/sources.
P.S. For the curious, this is what bootsdcard.sh looks like:
Code:
#!/sbin/busybox sh
MOUNT="/sbin/busybox mount"
UMOUNT="/sbin/busybox umount"
MKDIR="/sbin/busybox mkdir"
RMDIR="/sbin/busybox rmdir"
TOUCH="/sbin/busybox touch"
$MKDIR /tmp/sdcard
$CHMOD 0770 /dev/block/mmcblk0p1
$MOUNT /dev/block/mmcblk0p1 /tmp/sdcard
if [ -f /tmp/sdcard/.bootsdcard ];
then
$TOUCH /tmp/.bootsdcard
fi
$UMOUNT /tmp/sdcard
$RMDIR /tmp/sdcard
if [ -f /tmp/.bootsdcard ];
then
$UMOUNT /data;
$CHMOD 0770 /dev/block/mmcblk0p2
$MOUNT -t ext3 -o nosuid,nodev /dev/block/mmcblk0p2 /data
$UMOUNT /system
$CHMOD 0770 /dev/block/mmcblk0p3
$MOUNT -t ext3 /dev/block/mmcblk0p3 /system
$MOUNT -t ext3 -o remount,ro /dev/block/mmcblk0p3 /system
$UMOUNT /cache
$CHMOD 0770 /dev/block/mmcblk0p4
$MOUNT -t ext3 /dev/block/mmcblk0p4 /cache
fi

Downloads
CM9 Build 9's boot.img: http://www.mediafire.com/download/bn2krcdgdehpkij/boot.img

Adding support for G-Apps
You'd also need G-Apps for your secondary ROM. Here's how-to:
Open up any G-Apps zip, and extract updater-script from META-INF/com/google/android folder.
Find the following line:
Code:
run_program("/sbin/busybox", "mount", "/system");
Replace it with:
Code:
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p3", "/system");
That's it! You can flash your modified g-apps for secondary ROM.

Reserved
In case the boot.img doesn't flash after re-packing, it is very likely that there isn't enough space in the boot partition. I will add the procedure, for that case too.
finished post, reviews welcome

another one , good work bro :good:
is it possible to dual boot Thinkingbridge and stock ??
how about memory scripts ? will it work on both primary and secondary roms !!!

legendlee said:
another one , good work bro :good:
is it possible to dual boot Thinkingbridge and stock ??
how about memory scripts ? will it work on both primary and secondary roms !!!
Click to expand...
Click to collapse
Not possible by the Yin-Yang. One prerequisite is that both the ROMs should use the same kernel.
You could try the other method by ayushrox, which involves using separate boot.img's with different mountpoints.
Memory increasing scripts? That's easy, but you'd need four ext3 partitions, and a modified int2ext. Procedure:
format sdcard in following layout:
fat32>sd-data>sd-system>sd-cache>sd-ext.
Open the memory script int2ext, or int2ext+, and change the following:
Use the search and replace function, it would be helpful.
Replace:
Code:
/dev/block/mmcblk0p2
With:
Code:
/dev/block/mmcblk0p5

Thread Closed
There is already a guide thread located HERE for dual booting multiple ROM's. No need for more guides.

Related

[HACK][ROM][BOOT.IMG][CACHE]-Stk SPL ROMs with Danger SPL size & extra 30mb! any SPL!

[HACK][ROM][BOOT.IMG][CACHE]-Stk SPL ROMs with Danger SPL size & extra 30mb! any SPL!
###########################
EDIT: 2010-06-24
This is totally out of date now
new easier and much better way of doing things can be found here
http://forum.xda-developers.com/showthread.php?t=704560
###########################
Hi All,
Just wanted to 'get out' what I have been working on the last couple of days, and give back to the community.
Introduction
This is an intro of my Cache 'Hack'
it was inspired by Speedysilwady's thread [HOW-TO] Flash *MOST* ROMs on Stock/Any SPL
What follows should be considered BETA or even ALPHA.
I don't belive there is any risk of permanent damage to your phone, worst that will happen is a bootloop.
However, any ROM or Hack carries a risk, there could be something I have missed which will destroy your phone after 2 days.
I can't think what that would be, maybe I missed it
So... If your wife is due to go into labour anytime soon, or you need your phone for work/alarm to get up for work.
Don't do it.
Not my fault if it messes up your phone or life..
OK, disclaimer over with...
The Primary goal was to give the guys with 'Stock'SPLs ROMs which normally require 'DangerSPL'
The DangerSPL basically chops /cache down a bit and shares it between /system and /data,
but this is operating on the phones firmware at a lower level, and is risky so people are reluctent to do it.
I have a solution, and as a bounus the 'DangerSPL' guys get an extra 30mb on /system.
The Idea is very simple, utilise the space available on /cache
Below I detail a way of using *all* of /cache in a ROM, without risking a 'brick' ( softbricks excluded )
So, how do we do it?
Well, intially ( in recovery ) I was just moving directories from /system into /cache and symlinking them
This didn't work all that well because of the way the init.rc mounts cache
Code:
mount yaffs2 [email protected] /cache [b]nosuid nodev[/b]
chown system cache /cache
chmod 0770 /cache
nosuid nodev, resrticts what it can be used for
so,,
Code:
mount yaffs2 [email protected] /cache
mount yaffs2 [email protected] /cache ro remount
got around that, basically I mount /cache in the same way as system
Next problem,
I found out what cache is used for
The Market uses cache to save 'incoming' apks, you could say it uses /cache as a cache, lol..
maybe other things use it, I didn't look to hard.
anyway, this is what we do to solve that
Code:
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected]ystem /system
mount yaffs2 [email protected] /system ro remount
# Firerat 2010-03-22 - Mount Cache in the same way as system
# Firerat 2010-03-24 - Market uses /cache, if its full it fails, so...
# Firerat 2010-03-24 - mount mtdblock4 on /system, and bind mount to cache in userland script
# Firerat 2010-03-24 - /system/bin/data-cache.sh
mount yaffs2 /dev/block/mtdblock4 /system/csys
chmod 0770 /system/csys/lost+found
mount yaffs2 /dev/block/mtdblock4 /system/csys ro remount
and here is the userland script ( be sure to get init.rc to execute it )
Code:
#!/system/bin/sh
# bind mount /data/cache to /cache - Firerat 2010-03-24
# check /data/cache exists, if not create
if [ ! -d /data/cache ];
then
mkdir /data/cache
fi
# check cache is not already mounted
if [ "`mount |grep -q \/cache;echo $?`" = "0" ];
then
echo "/cache is already mounted.. exiting"
exit 1;
else
busybox mount -o bind /data/cache /cache
fi
hmm, I should check permisions on that, could have sworn I had a chmod in it
I could of course do this in the init.rc, but this offers greater flexibility
for instance we could check for ext partition and use that.
ref
(cyanogen) Thanks Cy! & ccyrowski
in the a2sd script which does this with Dalvik-cache
Oh, nearly forgot, since /system/csys is now the new /cache you have to fix your symlinks
Da Dar!, it boots and you can download from the Market ( as long as you have space on data )
Above via a 'ROM flash'
OK, so it's all well and good moving stuff around in recovery,but how do we do this with a 'ROM' flash?
because I can't flash a Requires DangerSPL I can't move things in recovery Grrrr..
Within the ROM package I created a new Directory, cache with sub directory system
i.e. cache/system
and moved things into it, stuff like system/media system/bin system/xbin
upto a Max of 28mb ( ish ) see Partiton table below
I'm linux , so I use a script to quickly show me the sizes
Code:
for i in `find $1 -maxdepth 1 -type d|sed -e :a -e '$!N; s/\n/ /; ta'`
do
du -hs $i
done
then in the update-script
Code:
format CACHE:
copy_dir PACKAGE:cache CACHE:
show_progress 0.2 0
symlink csys/system/bin SYSTEM:bin
symlink csys/system/etc SYSTEM:etc
symlink csys/system/media SYSTEM:media
symlink csys/system/usr SYSTEM:usr
symlink csys/system/xbin SYSTEM:xbin
symlink csys/system/fonts SYSTEM:fonts
symlink toolbox CACHE:system/bin/start
symlink toolbox CACHE:system/bin/getevent
< snip >
symlink toolbox CACHE:system/bin/renice
symlink toolbox CACHE:system/bin/setconsole
symlink /system/csys/system/xbin/busybox CACHE:system/bin/sh
symlink busybox CACHE:system/xbin/zcip
symlink busybox CACHE:system/xbin/zcat
symlink busybox CACHE:sys< snip >
set_perm_recursive 0 0 0755 0644 SYSTEM:
set_perm_recursive 0 0 0755 0644 CACHE:system
set_perm_recursive 0 2000 0755 0755 CACHE:system/bin
set_perm 0 3003 02755 CACHE:system/bin/netcfg
set_perm 0 3004 02755 CACHE:system< snip >
symlink /system/csys/system/bin SYSTEM:bin
is probably easier to 'see'
Zip it up and sign
and well, thats it really...
flash it, find it won't boot, go to recovery , fix it, boot it , fix package, zip, sign, flash it..
Eventually it boots
Partition Tables
I have to admit , I have DangerSPL, and I'm reluctant to revert to stock
Speedysilwady of the thread which inspired me
[HOW-TO] Flash *MOST* ROMs on Stock/Any SPL
has given me some sizes
Code:
/system: 67.5M
/data: 74.7M
/cache: 67.5M
and here are the totals for mine, DangerSPL'd
Code:
/system: 90M
/data: 89.7M
/system/csys: 30M
Further movement
hmm, we have lots of space in cache on a 'none danger spl' and we probably have some room on /system on a 'dangerSPL'
we can move things on firstboot, keeping the 'ROM' compatible with both 'Danger' and 'NonDanger' SPLs
here is an extended version of the mount cache I hastily put together for King's Eris Port
DangerSPL , the 'framework' gets moved to the system partition
NoDanger the 'framework' gets moved to the 'cache' partition
Code:
###################
# What follows is specific to King Eris Port 1.x.x
# mind you the logic will work in any rom
###################
if [ -d /system/system-framework ] || [ ! -L /system/framework ];
then
exit 0;
fi
RM_CMD="busybox rm"
MV_CMD="busybox mv"
CP_CMD="busybox cp"
LS_CMD="busybox ls"
LN_CMD="busybox ln"
MKDIR_CMD="busybox mkdir"
MOUNT_CMD="busybox mount"
UMOUNT_CMD="busybox umount"
SWAPON_CMD="busybox swapon"
# nb the df sticks out, toolbox df output is easier to cut up
DF_CMD="toolbox df"
DU_CMD="busybox du"
SED_CMD="busybox sed"
GREP_CMD="busybox grep"
CUT_CMD="busybox cut"
GETPROP_CMD="getprop"
SETPROP_CMD="setprop"
E2FSCK_CMD="e2fsck"
CHMOD_CMD="busybox chmod"
CHOWN_CMD="busybox chown"
SYNC_CMD="sync"
rohardware=`$GETPROP_CMD ro.hardware`
if [ -d /data/system-framework ] && [ ! -L /data/system-framework ];
then
CsysFree_K=`$DF_CMD|$GREP_CMD \/csys\:|$CUT_CMD -d " " -f6|$SED_CMD s/K//`
SysFree_K=`$DF_CMD|$GREP_CMD \/system\:|$CUT_CMD -d " " -f6|$SED_CMD s/K//`
SysFramework_K=`$DU_CMD /data/system-framework/|$CUT_CMD -f1`
if [ $SysFramework_K -gt "1024" ] && [ $CsysFree_K -gt $SysFramework_K ];
then
$MOUNT_CMD -o rw,remount /system
$MOUNT_CMD -o rw,remount /system/csys
$CP_CMD -a /data/system-framework/ /system/csys/system-framework
# being very lazy here, I should look before I leap
$RM_CMD /system/framework
$LN_CMD -s /system/csys/system-framework /system/framework
$SYNC_CMD
$MOUNT_CMD -o ro,remount /system
$MOUNT_CMD -o ro,remount /system/csys
$RM_CMD -rf /data/system-framework
exit 0;
elif [ $SysFramework_K -gt "1024" ] && [ $SysFree_K -gt $SysFramework_K ];
then
$MOUNT_CMD -o rw,remount /system
$CP_CMD -a /data/system-framework/ /system/system-framework
# being very lazy here, I should look before I leap
$RM_CMD /system/framework
$LN_CMD -s /system/system-framework /system/framework
$SYNC_CMD
$MOUNT_CMD -o ro,remount /system
$RM_CMD -rf /data/system-framework
exit 0;
else
exit 0
fi
fi
I actally use this same free space checking logic in my modified a2sd when it comes to moving dalvik-cache
I try to keep dalvik-cache on Data, I hope to expand this to both system and user apps.
and with unionfs ( or aufs ) maybe set up something to handle priority apps on internal memory
Backups
Currently the Recovery Backups ignore /cache, so after a restore it aint going to boot.
Speedysilwady did say Bart worked for him, not tried it myself
a while back I had a look at the nandroid-mobile.sh in Amon's RA-1.5.2
I think I did see that cache was an option
anyway, I don't think it would take much to 'turn it on'
Edit : 2010-04-16
[UTIL] BART-1.2.0 Backup and Restore Tool
Now has cache backup!
not sure if its packed in a recovery.img yet
Coming soon
Example ROMs
CaNNon's Complete Eclair 1.2
King's Eris Port 1.1.2 - ( Warez removed - afaik its just the QuickOffice )
Pre Flash Patch
I have played with this before, you can see how I do it in Speedysilwady's thread
[HOW-TO] Flash *MOST* ROMs on Stock/Any SPL
so , my idea is the update script just formats /system and /cache and sets up symlinks from system to cache
making sure we have everything mounted ( mount -a ) we flash the ROM
we then flash a second Patch which re-creates the links, and flashes the boot.img along with supporting scripts.
I'm even toying with the idea of Pathcing a pre-installed system ( to get the extra 30mb )
Not tried this yet, but I think something like this will work
Code:
copy_dir SYSTEM:bin CACHE:/system/bin
delete SYSTEM:bin
symlink csys/system/bin SYSTEM:bin
copy_dir PACKAGE:cache CACHE:
symlink < all them links >
format BOOT:
write_raw_image PACKAGE:boot.img BOOT:
So, Enjoy
and I'll post the ROMs I modded a little later, I shoud check a few things first
Firerat

Cache Hack Modded ROMS ( demo )
As Promised a couple of Modded ROMs to showcase my 'Hack'
Please note the disclaimer in the OP under introduction
Full Credit for these ROMs goes to the Original DEVs , namely CaNNon202 and King
First up we have CaNNoN's Complete Eclair
original link CaNNoN202 Complete Eclair [v1.2]
as I'm sure many of you will know this was the ROM I made the 3D YouTube Patch for,
This is that ROM , Repackaged in Full
i.e. 3D Kernel, HQ Youtube/ mp4 along with the fixes for the WiFi FC and Facebook contact sync.
This should work fine as a *no wipe* update to a current CE12
if you have problems then do a wipe
Change log
system apps now on system
Gallery3D
New Camera.apk
The Camera.apk removes duplicate Gallery Icon in the Tray, and I have disabled video recording, since it didn't work anyway and most of the time cause freeze and FC )
new (rw/ro)system scripts
they know about the new cache thing
data-cache.sh
bind mount cache, runs on boot
modified a2sd
MT3G friendly, will skip apps to SD and setup swap automagically
additionally will keep Dalvik-cache on data if space available* keeping apps fast
oem-reset script
I neglected to mention, data wipe in recovery will kill the ROM (it wipes cache) , so I made a script to clear personal data
* if you get space low messages, try a cache cleaner from the Market
if you still have problems delete apps you don't need
still not enough space? either reboot phone, or run a2sd from terminal
but a Reboot / a2sd run will move cache to SD if available
Guys, I have left Launcher2 in this, but I really wouldn't recommend using it with 3D
################################
### Download ### since CE2.0 is now CacheHack AnySPL link has been removed
################################
MD5SUM = 97dfb9756bb553cf3cb42519483da3cc
################################
NOTE this is *not* CE 2.0
Second up Yet another King's Eris Port Mod
original link King's Eris2G1 v1.1.2
Change Log
2010-03-28 12:40 gmt - bug fix
fixed the issue with the framework not being moved on NoneDangerSPL
no more space warning, and Market works
system apps now on system
new (rw/ro)system scripts
they know about the new cache thing
data-cache.sh
bind mount cache, runs on boot, additonally moves system framework when 'SPL Known'
modified a2sd
MT3G friendly, will skip apps to SD and setup swap automagically
additionally will keep Dalvik-cache on data if space available* keeping apps fast
QuickOffice removed (Warez)
( FAO Mods, I hope I'm right in thinking that QO was the only Warez )
* if you get space low messages, try a cache cleaner from the Market
if you still have problems delete apps you don't need
still not enough space? either reboot phone, or run a2sd from terminal
but a Reboot / a2sd run will move cache to SD if available
tbh I haven't tested this as a no wipe,
Data is 66MB so you might get away with it if you are on DangerSPL
################################
### Download ###FR-KingErisP-112-CacheHack_S.zip
################################
MD5SUM = 735cde1f21e14b91ad20d65a7009c569
################################
Its probably going to get all confusing with two ROMs in one thread
These are intended as examples of what can be done with cache
we know that things like footprints don't work so try to keep on topic with posts
i.e. relating to the using cache for system files
if it does get too confusing I will perhaps give each its own thread.
but again, on topic would be nice
Cheers

Very Quick install instructions ( Danger Only, sorry NoneDanger, manual patching further down post )
First install Vega's Legend 0.9.0, boot that, then flash the You Tube Fixes, boot that
Then Flash
FR-VegaLegend091-CH_S.zip
You can try flashing all three at once, but for some reason you don't get a mobile data connection, no idea why.
As well as being CacheHack the above includes Loccy's KB Lights
http://forum.xda-developers.com/showthread.php?t=661343
be sure to drop by and thank them all
They are also working on a better solution, I believe the final solution will be within the system framework
But for now a while loop script will do
Edit : [UTIL] BART-1.2.0 Backup and Restore Tool
Now has cache backup!
Patching a fresh Vega Legend 0.9.1 DangerSPL
Fresh flash of Vega's Legend 0.9.0 with the 0.9.1 fixes over the top
Code:
Filesystem Size Used Available Use% Mounted o
n
/dev/block/mtdblock3 90.0M 89.5M 560.0K 99% /system
/dev/block/mtdblock5 89.8M 48.4M 41.4M 54% /data
/dev/block/mtdblock4 30.0M 1.2M 28.8M 4% /cache
Click to expand...
Click to collapse
a quick size up tool
Code:
[quote]
adb push Patch/cache/system/bin/qdu.sh /sbin/
[/quote]
Code:
chmod 755 /sbin/qdu.sh
its setup with a sha bang for an android ROM, to get it to work in recovery
Code:
sed s~system/~s~ /sbin/qdu.sh -i
now qd<tab><enter>
will show you the size of the directories of the directory your in
or
qd<tab>/syst<tab>
will show you the size of everything in /system
in an other term on your PC
Code:
[quote]adb shell watch "busybox df -h"[/quote]
will let you keep an eye on the space being used and avalilabe to you
ok, so lets begin
mount everything
Code:
mount -a
first we need to create a mount point for mtdblock4
Code:
mkdir /system/csys
and then we need to bind mount /cache to it
Code:
busybox mount -o bind /cache /system/csys
ok, lets start moving stuff
Code:
/ # qdu.sh /system/
86.3M /system/
89.5K /system/csys
1.3M /system/xbin
2.1M /system/usr
1.0K /system/sd
2.8M /system/media
[COLOR="Red"]44.4M /system/lib [/COLOR]
19.6M /system/framework
5.3M /system/fonts
2.6M /system/etc
2.8M /system/customize
5.3M /system/bin
2.0K /system/lost+found
Click to expand...
Click to collapse
lib is too big for DangerSPL
lets just move some of the other stuff and see what happens
Code:
cd /system/
mkdir csys/system
for i in usr/ xbin/ media/ fonts/ etc/ customize/ bin/;do
mv $i csys/system/
done
Code:
Filesystem Size Used Available Use% Mounted on
/dev/block/mtdblock3 90.0M 65.7M 24.3M 73% /system
/dev/block/mtdblock5 89.8M 48.4M 41.4M 54% /data
/dev/block/mtdblock4 30.0M 24.9M 5.1M 83% /system/csys
Click to expand...
Click to collapse
were still short of space on system
Code:
qdu.sh /data/
46.9M /data/
46.0M /data/app_s
954.0K /data/app
Click to expand...
Click to collapse
Code:
mv framework/ /data/
lets stick a few apps on /system/csys
after using
ls /data/app_s/ -Slh
I'm going to pick these
Code:
mv /data/app_s/Phone.apk csys/system/app/
mv /data/app_s/Mail.apk csys/system/app/
then move the system apps to system
Code:
mv /data/app_s/ app
and now, before we forget create links
Code:
ln -s csys/system/* .
cd app/
ln -s ../csys/system/app/* .
cd ../
ln -s /data/framework .[code]
now get the boot.img onto the phone and use
Code:
flash_image boot /sdcard/boot-cachehack.img
don't forget the kernel modules
Reboot, and you done.......
Patching Vega Legend 0.9.1 NoneDanger SPL
you guys have a harder and at the same time easier task in getting a sense ROM onto your phone, essentially you have more space available, but you can't flash direct.
you going to need to unzip the ROM on your PC , and have a look at the sizes
Decide what you need to put on cache, and make links
see lib and framework in the DangerSPL Walkthrough?
44.4M /system/lib
19.6M /system/framework
1.3M /system/xbin
65.3 mb right there
so in recovery
Code:
mount /system
rm -r /system/*
mkdir /system/sd
mount -a
mkdir /system/csys
mount -o bind /cache /system/csys
for i in lib framework xbin ;do
install -d /system/csys/system/$i
done
ln -s /system/csys/system/* /system/
now, on your PC zip up the ROM, don't sign it
get it onto your sdcard
Code:
unzip /sdcard/rezippedROM.zip system data -d /
that will unzip everything beginning with system and data to the / directory
when lib, framework xbin hit the links we made, they will end up on cache
links, a messy business
but I have a script for that
Code:
unzip /sdcard/rezippedROM.zip META-INF -d /data/
now, attachced is NoneDangerDIY-linksandperms.txt
( Edot 2010-04-19 Fixed the script so it works in recovery )
get that onto your sdcard and
Code:
sh /sdcard/NoneDangerDIY-linksandperms.txt
( Tip sh /sd<tab>/None<tab> )
this will translate the ROM's update-script links and permissions into unix commands, it spits them to screen and should save them in memory
do
Code:
cat /dev/install.sh
to make sure its there
then
Code:
sh /dev/install.sh
Ok, next is kernel Modules
the zip above ( FR-VegaLegend091-CH_S.zip ) contains the directories
sdcard/kernels/
and in that are 3D and RamHack kernels
choose one and
cp -a /sdcard/kernels/<kernel>/system to /system/
flash_image boot /sdcard//kernels/<kernel>/boot.img
other files, in cache/system/bin are
a2sd
rwsystem
rosystem
data-cache.sh
qdu.sh
Do not install a2sd, its modified to patch Danger, it might do strange things, I didn't think about NoneDanger when I was doing it
copy the others to /system/bin/
an then
Code:
chmod 755 /system/bin/*system
Last thing, system app_s
Code:
df
du /data/app_s
hopefully the du for app_s is less than the df of /system
if so
Code:
mv /data/app_ /system/app
if not, then use the same trick as I did for DangerSPL , and link an app from /system/csys/system/app to /system/app/
I think you will be ok though
Oh, nearly forgot , in cache/system of the zip is a file called patch
cp that to /system/
its Loccy's KB lights
yeay , woo hoo, were done
Code:
reboot
Hope that this is useful,
I know its still awkward for NoneDanger, soon I will try to make it a doddle for a dev zip up a ROM which is truly ready for AnySPL, and maybe optimise for mt3g
Coming sometime in the future..
I will do some more work on NoneDanger Sense I'm hoping to do a generic Patch to detect which SPL and install optimised for Danger, NoneDanger , and maybe I figure out something that will improve things for MT3G

So im trying to do something a little different. I am trying to transfer my Dalvik-cache from /cache to /system. Is there a way to do it after the rom is installed and functioning?

bubonik said:
So im trying to do something a little different. I am trying to transfer my Dalvik-cache from /cache to /system. Is there a way to do it after the rom is installed and functioning?
Click to expand...
Click to collapse
in a word, no
at the moment a2sd puts dalvik-cache on the SD card partition 2 ( if ext2,3,4)
via a bind mount
if no ext2,3,4 partition it remains on data
the above hack will not affect /data/dalvik-cache or the bind mount
but the partition /dev/block/mtdblock4 ( /cache now /system/csys )
will be 'full'
Anything going into /cache will go into the bind mount instead
in the original post I bind mount to /data/cache
but as I mentioned, we can bind mount any directory to /cache
I didn't look at what else uses cache, as far as I know nothing else does
putting dalvik-cache on /system is going to cause a few problems.
/system is mounted (ro) by init.rc , and tbh it should stay ro unless we really need to do something to the system files, Dalvik-cache needs to be writable
I mentioned my modified a2sd and Dalvik-cache
I commented out this
Code:
# bind mount dalvik-cache so we can still boot without the sdcard
busybox mount -o bind /system/sd/dalvik-cache /data/dalvik-cache;
busybox chmod 1000:1000 /data/dalvik-cache;
busybox chmod 771 /data/dalvik-cache;
and insterted this
Code:
DalvikCache
DalvikCache ()
{
# doubt they are going to change, but shoud set the 'paths' as variables
DataTotal_K=`$DF_CMD|$GREP_CMD \/data\:|$CUT_CMD -d " " -f2|$SED_CMD s/K//`
DataFree_K=`$DF_CMD|$GREP_CMD \/data\:|$CUT_CMD -d " " -f6|$SED_CMD s/K//`
DataDalvik_K=`$DU_CMD /data/dalvik-cache/|$CUT_CMD -f1`
# Pickup min free on data from config in future
Min_Data_Free_MB=10
Buffer_K=`expr $Min_Data_Free_MB \* 1024`
DataApp_K=`$DU_CMD /system/app/|$CUT_CMD -f1`
System_App_K=`$DU_CMD /data/app/|$CUT_CMD -f1`
if [ -d /system/sd/dalvik-cache ];
then
SD_Dalvik_K=`busybox $DU_CMD /system/sd/dalvik-cache|$CUT_CMD -f1`
else
SD_Dalvik_K="0"
fi
if [ ! -d /system/sd/dalvik-cache ] && [ "$DataDalvik_K" -lt "1024" ] && [ "`expr \( $DataApp_K + $System_App_K \) \/2`" -lt "$DataFree_K" ];
then
DalvikToIntMem
else
# if DalvikCache + a bit is too big, move to SD card
if [ "`expr $DataDalvik_K + $Buffer_K`" -gt "`expr $DataFree_K + $DataDalvik_K`" ];
then
DalvikToSdCard
else
if [ "`expr "$SD_Dalvik_K" + "$Buffer_K"`" -lt "$DataFree_K" ];
then
DalvikToIntMem
fi
fi
fi
DalvikComplete
return
}
DalvikToIntMem ()
{
if [ -d /system/sd/dalvik-cache ];
then
$MKDIR_CMD /data/dalvik-cache-temp
$CHOWN_CMD 1000:1000 /data/dalvik-cache-temp
$CHMOD_CMD 771 /data/dalvik-cache-temp
$CP_CMD -a /system/sd/dalvik-cache/* /data/dalvik-cache-temp/
$UMOUNT_CMD /data/dalvik-cache
$RM_CMD -rf /data/dalvik-cache
$MV_CMD /data/dalvik-cache-temp /data/dalvik-cache
$RM_CMD -rf /system/sd/dalvik-cache
else
if [ ! -d /data/dalvik-cache ];
then
$MKDIR_CMD /data/dalvik-cache
fi
$CHOWN_CMD 1000:1000 /data/dalvik-cache
$CHMOD_CMD 771 /data/dalvik-cache
fi
return
}
DalvikToSdCard ()
{
$MKDIR_CMD /system/sd/dalvik-cache/
$CP_CMD -a /data/dalvik-cache/* /system/sd/dalvik-cache/
$RM_CMD /data/dalvik-cache/*
return
}
DalvikComplete ()
{
if [ -d /system/sd/dalvik-cache ] && [ "`$MOUNT_CMD |$GREP_CMD -q "/data/dalvik-cache";echo $?`" != "0" ];
then
$MOUNT_CMD -o bind /system/sd/dalvik-cache /data/dalvik-cache;
fi
$CHOWN_CMD 1000:1000 /data/dalvik-cache;
$CHMOD_CMD 771 /data/dalvik-cache;
return
}
oh, in the 'header' I have things like
MKDIR_CMD="busybox mkdir"
DF_CMD="toolbox df"
you can see that while we have space I keep the dalvik-cache bytecode on the fast internal memory, unless space is limited, in which case bind mount to sd partition2 as per Cyanogen's original script
if we get space back, move dalvik-cache back

Thats my bad, I should have been more specific. I have a G1 and I dont use a2sd. Currently sd 1.10.2 uses /cache/dalvik-cache, but with 1.33.2005 that leaves only 3500 kb available for downloading apps. A huge problem.
So im trying to dump it somewhere else, the /data partition would be fine since I only have about 15 apps. I tried doing a symlink to /data/dalvik-cache after it was functioning but got boot loops. Which is why im here.

Just wondering when the ErisPort rom will be available, also could you try this with the Legend Port

M..N said:
Just wondering when the ErisPort rom will be available, also could you try this with the Legend Port
Click to expand...
Click to collapse
soon, I'm uploading now
and yes, you can use it with any rom
I had a quick look at Vega's Legend port,
Bold should be linked to system
Code:
29M ./cache
65M ./system
53M ./data
data/:
app app_s fix_permissions.sh [B]fonts[/B]
system/:
bin build.prop csys etc fonts lib sd usr xbin
cache/system/:
[B]customize framework media[/b]
all apps are going to go to sd here,
but around 30mb worth can be put back, to either /system or /system/csys
after boot, when we know how much space we have and where
so around 18mb on SD
leaving plenty of space for Dalvik-Cache
should be fast, no matter what SPL you have

Links to Modded ROMs added in second post

bubonik said:
Thats my bad, I should have been more specific. I have a G1 and I dont use a2sd. Currently sd 1.10.2 uses /cache/dalvik-cache, but with 1.33.2005 that leaves only 3500 kb available for downloading apps. A huge problem.
So im trying to dump it somewhere else, the /data partition would be fine since I only have about 15 apps. I tried doing a symlink to /data/dalvik-cache after it was functioning but got boot loops. Which is why im here.
Click to expand...
Click to collapse
ahh, sorry I nearly missed your follow up post
I wasn't aware that Dalvik-cache ever ended up on /cache, which tbh that has always confused me a little
if you look at Cyanogen's a2sd , he does mention in the comments that a bind mount is used so the system will still boot, even when no SD card ( since you don't have a dead link )
so I think the solution to your problem is to bind mount something to /cache/dalvik-cache
you should do this early in the boot process, else it will just get filled up
for instance a2sd is executed by init.rc , so it happens before the Android system kicks in, it doesn't matter if it fails to bind mount as you still have the directory available

Do i just wipe and install the droideris, also has anyone tested it.

M..N said:
Do i just wipe and install the droideris, also has anyone tested it.
Click to expand...
Click to collapse
full wipe is your best bet
as for testing.. lets just say I've flashed it more than a few times
but I am on Danger, would love some feedback from None DangerSPLs

it loads ok. although when im presented with low memory notification. i try downloading an app from the market, but it stays on the start downloading. Do you think you could make a port of the Legend Rom?

It would be nice if Htc, Tmo, google could use this to make larger updates but I doubt they'll bother.

M..N said:
it loads ok. although when im presented with low memory notification. i try downloading an app from the market, but it stays on the start downloading. Do you think you could make a port of the Legend Rom?
Click to expand...
Click to collapse
Maybe my script isn't moving the framework
That's around 30mb
( script is
/system/csys/system/bin/data-cache.sh
If anyone wants to have a look )
I'm not at home right now, but will have a proper look later
In the meantime if you reboot the dalvik cache should get moved to the sdcard
Giving you some space back.
I forgot the hero doesn't have term

so for danger spl ppl, ROMs will now be quicker (system apps), also roms which could not before be done now can?

So the 2 modded roms you posted above should work for us with Stock SPLS and if that is proven true, you have pretty much made any rom flashable on a Stock SPL'd G1. Is that correct? If so, you have just made a lot of people very happy. Great work, although that entire initial post was foreign language to me!

thank you...
I haven't tried this yet, but I am super excited to see this is being worked out. I don't have the danger spl, and I can't wait to see this work with some of the new eclair 2.1 roms. Thanks for your hard work.

hopefully this can make our roms faster with more apps on system.

FatBoyExtraordinaire said:
So the 2 modded roms you posted above should work for us with Stock SPLS and if that is proven true, you have pretty much made any rom flashable on a Stock SPL'd G1. Is that correct? If so, you have just made a lot of people very happy. Great work, although that entire initial post was foreign language to me!
Click to expand...
Click to collapse
yes theoretically any rom should fit any spl but as you can see in the first post,
it takes a lot of work to port a rom to stock using this method, but wow its very well put together and firerat def knows what he's doing with this, i was shocked to be the first to have a 2.1 Eclair Sense on a G1 with Hard/Stock/Engineering SPL thanks to Firerat who implemented the idea very well and lbcoder who suggested the general idea on my thread a while back.
Also Firerat as mentioned earlier, the script to move framework seems to have some kinda kink cuz the low spaace error exists on the eris port. Also google sync is still broken.

Journal Disabler For Pico! :D

----------------------- Journaling Disabler For Pico ----------------------
This is just a simple Zip to Disable Journaling on pico! as we use 2 or 3 extra ext4 partitions for OC!
It even clear's /sd-data,/sd-cache - for aosp
and /sd-ext,/sd-data,/sd-cache - for sense 4
Which means you need not always format your sd-card to switch between roms! .. But if you are switching from aosp rom to sense 4 you need to partition the sd-card appropriately!
Steps to USE:
******* Use this Zip Only when installing a Rom from scratch!... cause it wipes everything! ******
-- clear almost everything you can from recovery e.g factory-reset,/system,/boot,/cache etc
-- install this Zip! as like you do with any other zip (Prefered Recovery TWRP 2.4.X)
-- Flash Your Favourite Rom Now!!

I can use this even if i am not oc'ing?? Just like superwipe?
Disabling journal wont harm anything! Right?

Parth_14 said:
I can use this even if i am not oc'ing?? Just like superwipe?
Disabling journal wont harm anything! Right?
Click to expand...
Click to collapse
From the wikipedia's article:
A journaling file system is a file system that keeps track of the changes that will be made in a journal (usually a circular log in a dedicated area of the file system) before committing them to the main file system. In the event of a system crash or power failure, such file systems are quicker to bring back online and less likely to become corrupted.[1]
Click to expand...
Click to collapse
For overclocking, the SD Card is used for the /data and /cache partition. In that case, the SD Card would be read more frequently as the /data and /cache partitions are the most frequently accessed and modified partitions while running the Android system. In that case, using a Journal would slow down the memory access times if the SD Card is not fast enough. Also, as many modifications are made to the /data and /cache partition, the SD Card would be going through the read/write cycle twice the number of times, once for the journaling and once for the "commiting them to the main file system". So, it is likely that the SD Card might get corrupted faster than it normally should. That is the reason why Class 4 and below SD Cards are likely to "go dead" soon when overclocking with cute_prince's new PLL2 overclocking method. And, this is why ateeq72 has made this flashable zip to disable journaling. It would reduce the possibility/risk of losing your SD Card and at the same time allow you to OC your phone.
Using this when you are not OC'ing your phone? I wouldn't recommend that you flash this zip, but you would need a slightly modified zip. Also, journaling, I presume you want to disable in your phone's sd-ext memory. It would increase your phone's performance in case you are using any memory increasing scripts like int2ext which mount the sd-ext partition in the /data folder.

vineethraj49 said:
Using this when you are not OC'ing your phone? I wouldn't recommend that you flash this zip, but you would need a slightly modified zip. Also, journaling, I presume you want to disable in your phone's sd-ext memory. It would increase your phone's performance in case you are using any memory increasing scripts like int2ext which mount the sd-ext partition in the /data folder.
Click to expand...
Click to collapse
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?

Parth_14 said:
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?
Click to expand...
Click to collapse
No need to mod dude, u can use it if u dont OC.
Helped? Thanks maybe!

Parth_14 said:
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?
Click to expand...
Click to collapse
Edit the file named "ateeqscript" using Notepad++.
Make sure the file looks like the one below.
Code:
#!/bin/sh
echo ***************Begin Disable Journaling Partition***************
/sbin/busybox mount -t auto /dev/block/mmcblk0p2 /sd-ext
rm -rf /sd-ext/*
/sbin/busybox umount -l /sd-ext
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p2
fsck.ext4 -Dfy /dev/block/mmcblk0p2
sync
echo ***************Data Partion Done***************
echo ***************Finished No Journaling Partions***************
What I have done? Simple. Removed all code related to /sd-data and sd-cache, and kept only commands necessary for the sd-ext partition.
---------------------------------------------------
@OP, I suggest a few changes in your script. First, the mounting commands are run, so, if the sd-ext is already mounted by the recovery (just in case, accidentally it happened), then, you wouldn't (or rather shouldn't) be able to mount it in another folder, namely /sd-data. I would suggest the following change in your flashable zip. Try to make it look something like the one below.
Code:
#!/bin/sh
echo "\"Disabling Journaling\" Script"
echo "Initializing script..."
/sbin/busybox umount -l /sd-ext
/sbin/busybox mkdir /sd-data
/sbin/busybox mount /dev/block/mmcblk0p2 /sd-data
/sbin/busybox mkdir /sd-cache
/sbin/busybox mount /dev/block/mmcblk0p3 /sd-cache
/sbin/busybox mkdir /sd-ext2
/sbin/busybox mount /dev/block/mmcblk0p4 /sd-ext
rm -rf /sd-cache/*
rm -rf /sd-data/*
rm -rf /sd-ext/*
/sbin/busybox umount -l /sd-data
/sbin/busybox umount -l /sd-cache
/sbin/busybox umount -l /sd-ext
echo "Disabling Journal in sd-data"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p2
fsck.ext4 -Dfy /dev/block/mmcblk0p2
echo "Disabling Journal in sd-cache"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p3
fsck.ext4 -Dfy /dev/block/mmcblk0p3
echo "Disabling Journal in sd-ext"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p4
fsck.ext4 -Dfy /dev/block/mmcblk0p4
sync
echo "Partitions Journaling Disabled..."
echo "Finished no journaling partitions"

Do we need to flash this zip for every new rom or just once is enough?
Sent from my HTC Explorer A310e using xda app-developers app

faiPICO said:
Do we need to flash this zip for every new rom or just once is enough?
Sent from my HTC Explorer A310e using xda app-developers app
Click to expand...
Click to collapse
i guess one time is enough no need to flash again and again

@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!

Parth_14 said:
@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!
Click to expand...
Click to collapse
Its already there I guess

vineethraj49 said:
Its already there I guess
Click to expand...
Click to collapse
I've read that it formats through ext2/4 ! What i want is the parition to be remain untouched..

Parth_14 said:
@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!
Click to expand...
Click to collapse
vineethraj49 said:
Its already there I guess
Click to expand...
Click to collapse
journal disabling is required for only ext4 partition for max performace
if u dont use ext4 use any wiping script
the script keval gave format partitions to ext2 only not ext4

sakshamx said:
journal disabling is required for only ext4 partition for max performace
if u dont use ext4 use any wiping script
the script keval gave format partitions to ext2 only not ext4
Click to expand...
Click to collapse
NOTE:------------>Do remember the script of sense will format partitions as EXT2 and script for aosp roms will format partitions as EXT4 and sense 4.1 sctript will also format as EXT4
Click to expand...
Click to collapse

vineethraj49 said:
Click to expand...
Click to collapse
u can check the script it formats as ext2 i had also checked from sd card its ext2
i also had thought that as it was given in thread but its not

is it updated script which u posted in facebook

bloodhound42 said:
is it updated script which u posted in facebook
Click to expand...
Click to collapse
yup! it is!

vineethraj49 said:
@OP, I suggest a few changes in your script. First, the mounting commands are run, so, if the sd-ext is already mounted by the recovery (just in case, accidentally it happened), then, you wouldn't (or rather shouldn't) be able to mount it in another folder, namely /sd-data. I would suggest the following change in your flashable zip. Try to make it look something like the one below.
Code:
#!/bin/sh
echo "\"Disabling Journaling\" Script"
echo "Initializing script..."
/sbin/busybox umount -l /sd-ext
/sbin/busybox mkdir /sd-data
/sbin/busybox mount /dev/block/mmcblk0p2 /sd-data
/sbin/busybox mkdir /sd-cache
/sbin/busybox mount /dev/block/mmcblk0p3 /sd-cache
/sbin/busybox mkdir /sd-ext2
/sbin/busybox mount /dev/block/mmcblk0p4 /sd-ext
rm -rf /sd-cache/*
rm -rf /sd-data/*
rm -rf /sd-ext/*
Click to expand...
Click to collapse
Bro thats why i have mounted sd-ext as "sd-ext2" ! to make sure every recovery doesnt have any issue mounting it!

what is journal?
in many posts i found this about this journal what is this actually..

[GUIDE]Adding Support for Different ROMs for Dual Boot

#THIS GUIDE IS ONLY FOR ADVANCED USERS, WHO KNOW HOW TO COMPILE AND MAKE MODIFICATIONS TO KERNEL AND MODIFYING VARIOUS PARAMETERS IN RAMDISK IN THE RAMDISK LEVEL #
Hey guys this guide will tell you how to add support for Dual bootinga as primary ROM.
YOU MUST USE ATLEAST CLASS 6 OR ABOVE SDCARD WITH MINIMUM 8GB CAPACITY
First you need 3 EXT4 partitions on SD-card, using minitool partition wizard
1) around 400 MB - SD-SYSTEM (ext4)
2) around 1 GB (or can be less) - SD-DATA(ext4 format),
3)around 75MB (can be less) SD-CACHE(ext4 format) (refer to the screenshot):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is very important : You should remove any memory increasing script that you were using. Because /data partition is now on SDcard, using memory increasing script will cause conflict and makes ROM unbootable.
Now making kernel level Changes :
Step 1- open the defconfig of your kernel source and make this change in it
Enable LBDAF (for multiple partitions to work)
Code:
[COLOR="Navy"]CONFIG_LBDAF=y[/COLOR]
Now compile the kernel.
Step 2- Ramdisk level changes:
All modifications are performed on init.rc file.
Step 1- Search for this line :
Code:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
Replace it with this :
Code:
[COLOR="Navy"]# Mount SD-SYSTEM
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /system
mount ext4 /dev/block/mmcblk0p2 /system ro remount[/COLOR]
Step 2 - find this line :
Code:
mount yaffs2 [email protected] /data nosuid nodev
Now replace it with :
Code:
[COLOR="navy"]# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR]
Step 3- Find this line :
Code:
mount yaffs2 [email protected] /cache nosuid nodev
Replace it with :
Code:
[COLOR="navy"]# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext4 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR]
That's it now pack the ramdisk with the kernel you made earlier
All of this is much similar like pll2 Oc by cute_prince.
Now the Updater-script changes
This was the real pain in finding out, It took me nearly a month to figure out how to extract system on the partition, and learn the mount function.. If you are using it PLEASE give me some credits
Step 1- one the updater-script of the ROM find these lines :
Code:
format("yaffs2", "MTD", "system", "0", "/system");
mount("yaffs2", "MTD", "system", "/system");
package_extract_dir("system", "/system");
Replace them with these:
Code:
[COLOR="navy"]run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p2", "/system");
run_program("/sbin/busybox", "rm", "-rf", "/system/*");
package_extract_dir("system", "/system");[/COLOR]
That's it you've Successfully added support for the rom as primary ROM !!
Head Over here : http://forum.xda-developers.com/showthread.php?t=2409236
for flashing instructions ,dual boot app by galaxy freak and switching mechanisms
IF YOU WANT TO PLL2 OC BOTH PRIMARY AND SECONDARY ROMs GO TO THE GUIDE BY @Arslankirmani HERE : http://forum.xda-developers.com/showpost.php?p=45063954&postcount=84
Now if you are using it for adding support for ROM , please PM either me,adityalahiri13 or galaxyfreak the download link so that we can add on the dual boot thread.. IF you are a ROM developer ,i kindly request you to let us also keep the download link for the primary enable ROM.

The Yin-Yang Way!
Procedure
You MUST know how to unpack/repack kernels, and their ramdisks.
If you unpack your kernel, you would find the folder named sbin where you'd unpacked the ramdisk. Place these two files busybox.7z and bootsdcard.txt in the folder. Rename them to "busybox" and "bootsdcard.sh" respectively.
Additionally, you will need to create a folder named "tmp" where you've unpacked the ramdisk.
Now, open up init.rc and find the 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
After these lines, you are most likely to find these lines (or similar lines):
Code:
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Add the following lines to the above:
Code:
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
En total, it should look like this:
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
on post-fs
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Click to expand...
Click to collapse
Now, you can repack the ramdisk, and repack the kernel. In most cases, you should be able to flash the kernel with the busybox included. If you are not able to flash the repacked boot.img, please post the boot.img along with thread from which obtained/sources.
P.S. For the curious, this is what bootsdcard.sh looks like:
Code:
#!/sbin/busybox sh
MOUNT="/sbin/busybox mount"
UMOUNT="/sbin/busybox umount"
MKDIR="/sbin/busybox mkdir"
RMDIR="/sbin/busybox rmdir"
TOUCH="/sbin/busybox touch"
$MKDIR /tmp/sdcard
$CHMOD 0770 /dev/block/mmcblk0p1
$MOUNT /dev/block/mmcblk0p1 /tmp/sdcard
if [ -f /tmp/sdcard/.bootsdcard ];
then
$TOUCH /tmp/.bootsdcard
fi
$UMOUNT /tmp/sdcard
$RMDIR /tmp/sdcard
if [ -f /tmp/.bootsdcard ];
then
$UMOUNT /data;
$CHMOD 0770 /dev/block/mmcblk0p2
$MOUNT -t ext3 -o nosuid,nodev /dev/block/mmcblk0p2 /data
$UMOUNT /system
$CHMOD 0770 /dev/block/mmcblk0p3
$MOUNT -t ext3 /dev/block/mmcblk0p3 /system
$MOUNT -t ext3 -o remount,ro /dev/block/mmcblk0p3 /system
$UMOUNT /cache
$CHMOD 0770 /dev/block/mmcblk0p4
$MOUNT -t ext3 /dev/block/mmcblk0p4 /cache
fi
Now, to switch to the other ROM, please create a file named ".bootsdcard", and to switch to primary ROM, delete the ".bootsdcard" from your sdcard.
I know this post looks wierd, and outta place. the busybox.7z and bootsdcard.sh file can be obtained from here: http://forum.xda-developers.com/showthread.php?t=2413642
until I edit this post...
P.s. @omerjerk made an app for this purpose... he'd release it shortly.

What if?
@ayushrox
U said on facebook that the sd-data is only for primary rom and the data for the secondary rom is on the NAND Partition ....
So , can't we make changes in the boot.img of Secondary Rom so that it uses the SD-DATA Partition for its data ......?
So our apps can be used in both the roms......

ayushrox atleast can you make CM10.1 as primary rom for who dont know how to compile , etc... and please make primary rom support Pll2 OC.
good work!!!!!

thelegend10 said:
@ayushrox
U said on facebook that the sd-data is only for primary rom and the data for the secondary rom is on the NAND Partition ....
So , can't we make changes in the boot.img of Secondary Rom so that it uses the SD-DATA Partition for its data ......?
So our apps can be used in both the roms......
Click to expand...
Click to collapse
I can do this.. but it may cause errors since we can dual boot even GB with 4.3 so the app's a pi level may cause conflict .. but anyways I'll try it
Boyka123 said:
ayushrox atleast can you make CM10.1 as primary rom for who dont know how to compile , etc... and please make primary rom support Pll2 OC.
good work!!!!!
Click to expand...
Click to collapse
OK I'll add cm 10.1 as primary ROM.with pll2OC ... And BTW devs : u can add pll2OC easily by using the edited acpuclock or editing the ramdisk of pll2 OC Kernels just as I indicated
..

That f*cking awesome!!!!!!!!!!! If we use pll2 oc, does we need extra partition or just partition order on dual boot thread?
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app

Boyka123 said:
That f*cking awesome!!!!!!!!!!! If we use pll2 oc, does we need extra partition or just partition order on dual boot thread?
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app
Click to expand...
Click to collapse
if you enable pll2 .. then only primary rom can be used as pll2 Oc .. so yes only the partition order i mentioned on dual boot thread !!!!

ayushrox said:
if you enable pll2 .. then only primary rom can be used as pll2 Oc .. so yes only the partition order i mentioned on dual boot thread !!!!
Click to expand...
Click to collapse
nice guide :good::good:
is that CONFIG_LBDAF=y enabled in sense 4.1 kernel cause it uses multiple partitions?
if not can u provide kernel with it enabled
edit : solved

Just signed in, and thought I'd check up on how far you've gotten up to on this project... I think it should be easy enough to adapt the script I made for the HD2 to automate this quicker. I'll put up a file and instructions in a day or two; all being well, if anyone wants to test...
In terms of having the same data file/folder between different ROMs - this isn't something that we managed on the HD2 as there seemed to be permissions issues caused as well as the issue of differnt api levels, it's still worth a try though.

any chance for a noob guide?????

balajithegreat said:
any chance for a noob guide?????
Click to expand...
Click to collapse
Not a guide but yes.. i'll be posting edited updater-scripts and premade kernels.. for adding support
and guys LBDAF is enabled in all pll2 OC kernels(pandora,aries,etc.) you can take their boot.img ,unpack them,edit the init.rc file as i said and repack it.. and rest the updater-script thing should be easy !!
and @HypoTurtle i thought of giving our script a try..but didn't have time for it.. you can PM me the script , i'll test it

@ayushrox
can u build a kernel that can work with the boot manager app
with it we can boot up to 5 or more roms
is it possible???....

One question. What about gapps for primary rom? If we flash gapps just like that wouldnt they go to /system..! we need then in sd-system!
UPDATE: I compiled a kernel doing the ramdisk changes, enabling lbdaf and also edited updater-script. Formatted the partitions as SD-SYSTEM(EXT4) (455mb)---- SD-DATA(EXT4) (900mb)---- SD-CACHE(eXT4) (85mb)
Rom flashes. But it kinda finishes very early. I checked the sd-system partition using mini partition tool just after flashing and it doesnt seem to have changed..I double checked updater-script. It just stays at HTC logo.

7alvi said:
One question. What about gapps for primary rom? If we flash gapps just like that wouldnt they go to /system..! we need then in sd-system!
UPDATE: I compiled a kernel doing the ramdisk changes, enabling lbdaf and also edited updater-script. Formatted the partitions as SD-SYSTEM(EXT4) (455mb)---- SD-DATA(EXT4) (900mb)---- SD-CACHE(eXT4) (85mb)
Rom flashes. But it kinda finishes very early. I checked the sd-system partition using mini partition tool just after flashing and it doesnt seem to have changed..I double checked updater-script. It just stays at HTC logo.
Click to expand...
Click to collapse
On which ROM did you try ? Did you make the kernel changes correctly ?

ayushrox said:
On which ROM did you try ? Did you make the kernel changes correctly ?
Click to expand...
Click to collapse
Im trying on my aokp 4.2 build. Yep I did make the changes correctly.. But i think its something with updater-script as it flashes and finishes too soon and i checked sd-system just after flashing rom and the 'used' field is unchanged!

7alvi said:
Im trying on my aokp 4.2 build. Yep I did make the changes correctly.. But i think its something with updater-script as it flashes and finishes too soon and i checked sd-system just after flashing rom and the 'used' field is unchanged!
Click to expand...
Click to collapse
Please upload your updater-script.. i'll try to find problems..

ayushrox said:
Please upload your updater-script.. i'll try to find problems..
Click to expand...
Click to collapse
http://pastebin.com/wqfD8Xyk

7alvi said:
http://pastebin.com/wqfD8Xyk
Click to expand...
Click to collapse
thanks for the script... but i have already made it ... so i'll put in on pastebin shortly..

ayushrox said:
thanks for the script... but i have already made it ... so i'll put in on pastebin shortly..
Click to expand...
Click to collapse
Thank you. Can you tell me if I didn't do it correctly?

7alvi said:
Thank you. Can you tell me if I didn't do it correctly?
Click to expand...
Click to collapse
I found that your updater-script was fine.. the problem must be with the kernel.. here's my kernel : http://d-h.st/q91
Download it just take out the boot.img(its named "boot3.img" --rename it to1)boot.img use in rom 2) cm.img (put it in sd-card)
Now, also take the modules part.. then i think it should work fine.. if problem still persistes.. i'll also attach the updater-script !!
And guys the kernel i have uploaded will work for all android 4.2.2 roms .. just use the modules and boot.img
*wifi may not work
and the kernel source is same as mine pandora kernel's

[DISCUSSION]All about boot.img's and kernels!!!

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?

[GUIDE][DEV] How to convert NAND ROM to SD-EXT ROM for MultiBootloader

How to convert NAND ROM to SD-EXT ROM for MultiBootloader
Code:
After following this guide, your ROM can be use with [URL="http://forum.xda-developers.com/nokia-x2/development/sbl-multibootloader-v1-00-04-10-2015-t3217360"]MultiBootloader[/URL]
THIS GUIDE IS NOT FOR NOOBs
Requirements
Knowledge about Android Image Kitchen
Notepad ++
A nand ROM extracted
Instructions
Delete the RED COLOR
Add the BLUE COLOR
Step 1: Modifying boot.img (FOR STOCK KERNEL ONLY) - Check post #2 to download the modified boot image, you don't need to edit it yourself.
Use Android Image Kitchen's unpackimg command to unpack the boot.img file from the ROM your want to port.
Go to Android Image Kitchen\ramdisk folder, edit these files:
fstab.qcom
Change like this:
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
[COLOR="Red"]/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer[/COLOR]
[COLOR="Blue"]/dev/block/platform/msm_sdcc.1/by-name/userdata /nanddata ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer[/COLOR]
/devices/msm_sdcc.2/mmc_host /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard:auto
#/dev/block/mmcblk0p11 /system ext4 ro,barrier=1 wait
#/dev/block/mmcblk0p12 /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,encryptable=footer
init.rc
- Find this event:
Code:
on fs
- Change like this:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
[COLOR="Red"]mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev[/COLOR]
[COLOR="Blue"] mount ext4 /dev/block/mmcblk1p2 /system
mount ext4 /dev/block/mmcblk1p2 /system ro remount
mount ext4 /dev/block/mmcblk1p3 /data nosuid nodev[/COLOR]
mount yaffs2 [email protected] /cache nosuid nodev
[COLOR="Blue"]#mount nand data for sharing data/app
mkdir /nanddate 0771 system system
mount yaffs2 [email protected] /nanddata nosuid nodev
# mount sdcard
wait /dev/block/mmcblk1p1
wait /dev/block/mmcblk1p1
mount vfat /dev/block/mmcblk1p1 /storage/sdcard1[/COLOR]

init.target.rc
- Find this event:
Code:
on fs
- Change like this:
Code:
on fs
mount_all fstab.qcom
# Keeping following partitions outside fstab file. As user may not have
# these partition flashed on the device. Failure to mount any partition in fstab file
# results in failure to launch late-start class.
wait /dev/block/platform/msm_sdcc.1/by-name/cache
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/cache /cache nosuid nodev barrier=1
wait /dev/block/platform/msm_sdcc.1/by-name/persist
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/persist /persist nosuid nodev barrier=1
wait /dev/block/platform/msm_sdcc.1/by-name/modem
mount vfat /dev/block/platform/msm_sdcc.1/by-name/modem /firmware ro shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337
[COLOR="Red"] wait /dev/block/platform/msm_sdcc.1/by-name/custom
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/custom /custom nosuid nodev barrier=1 ro[/COLOR]
[COLOR="Blue"] wait /dev/block/mmcblk1p4
mount ext4 /dev/block/mmcblk1p4 /custom nosuid nodev barrier=1 ro[/COLOR]

Repack boot.img and copy to the ROM folder.
Step 2: Modifying updater-script
Open ROM-name\META-INF\com\google\android\updater-script
Find:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p19", "/system");
or
Code:
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system");
Add these lines above it:
Code:
[COLOR="blue"]ui_print(" Mounting Partitions ");
mount("ext4", "MMC", "/dev/block/mmcblk1p2", "/system-ext");
mount("ext4", "MMC", "/dev/block/mmcblk1p4", "/custom-ext");
mount("ext4", "EMMC", "/dev/block/mmcblk0p20", "/cache");
mount("ext4", "MMC", "/dev/block/mmcblk1p3", "/data-ext");
ui_print(" Formatting Partitions ");
delete_recursive("/system-ext");
delete_recursive("/custom-ext");
delete_recursive("/cache");
delete_recursive("/data/dalvik-cache");
delete_recursive("/data-ext");[/COLOR]
Find this line:
Code:
package_extract_file("boot.img", "/tmp/boot.img");
Change like this:
Code:
[INDENT][COLOR="Red"]package_extract_file("boot.img", "/tmp/boot.img");
run_program("/system/xbin/busybox", "dd", "if=/tmp/boot.img", "of=/dev/block/mmcblk0p10");
delete("/tmp/boot.img");[/COLOR][COLOR="Blue"]
package_extract_file("boot.img", "/emmc/kernels/[I]your_rom_name[/I].img");[/COLOR][/INDENT]
Find and change all /system/ to /system-EXT/
Find and change all /custom/ to /custom-EXT/
Save.
Step 3: Create the ZIP
Make sure you have copy the modified boot.img to the ROM folder
Select all the files and folders in the ROM folder (custom, system, META-INF, boot.img,etc..)
Compress into ZIP file.
Done.
<EDITTING>

I have modifed the boot.img to boot into sdext ROM:
For stock based ROM: stock_ext.img - thanks to @symbuzzer for adding some features and fixing the ril & sdcard bugs
modified_stock_insecure-kernel.img - (Maybe I've made some mistake in this file. I don't recommend to use this, it can cause some bugs with sdcard0. Better modify it yourself.)
For CM11 based ROM: ext_cm11.img

Great ! Im waiting for this

Bro how can intsall the rom
I m try but couldn't with me
Plz help ??

@SonnySimon this method doesnt work on Stock Kernel/Rom. I will attach stock kernel on XDA today. You can compare mine with yours and update this post. Thanks

symbuzzer said:
@SonnySimon this method doesnt work on Stock Kernel/Rom. I will attach stock kernel on XDA today. You can compare mine with yours and update this post. Thanks
Click to expand...
Click to collapse
It works. I tried and it boots successfully into ext stock ROM but have some bugs with ril and sdcard.

SonnySimon said:
It works. I tried and it boots successfully into ext stock ROM but have some bugs with ril and sdcard.
Click to expand...
Click to collapse
I meant yours have bugs Thanks anyway

[HOW TO] BOOT FROM SD CARD [SUCCESSFULLY] on QMobile Z8 with BRICKED/DEAD eMMC
SimonVN said:
How to convert NAND ROM to SD-EXT ROM for MultiBootloader
Click to expand...
Click to collapse
I have been successfully able to boot from SD card on QMobile Z8 by partitioning SD card on a Ubuntu machine using 'parted' and 'fdisk' commands, replicating eMMC partition table and then flashing factory firmware images to these newly created partitions using 'dd' command. Then I modified "fstab.qcom" & "init.tegra.rc" files in kernel (boot.img) and "recovery.fstab" and "uneventd.rc" files in twrp recovery to initiate mounting and booting from sd card instead of internal memory. It was successful after some experiments. Details can be found here:
https://forum.xda-developers.com/android/help/how-to-boot-sd-card-qmobile-z8-bricked-t3712171
But I have still a few queries to be answered. Please have a look. Any help, comments, information or suggestions will be appreciated.

Database Info

welcome