Database Info

busybox for HTC Hero

Obviously there are some missing tools from the linux OS on the droid, so I'm looking to install busybox. I went directly to the source and tried to compile and install it on the phone, but it doesn't seem to work quite well.
I see a lot of people are including a version of busybox on their custom mods, but I'm not really looking to install a custom mod on my phone quite yet, but I would like the tools.
Does anyone know where I can download a good version of busybox that works on the Sprint HTC Hero without installing a rom?
I searched around the forums, but I'm not able to find anything quite yet.

I compiled one just today for some other stuff, not fully tested, but here you are.
Let me know how it works.
[email protected]:~/android/src/busybox-1.15.2$ file busybox
busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped

packetlss said:
I compiled one just today for some other stuff, not fully tested, but here you are.
Let me know how it works.
[email protected]:~/android/src/busybox-1.15.2$ file busybox
busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
Click to expand...
Click to collapse
Nice. Cheers. I'll let you know how it goes.

Care to provide how do you install this into the Hero? I'm also interested as I don't want to use a custom ROM

Nazgulled said:
Care to provide how do you install this into the Hero? I'm also interested as I don't want to use a custom ROM
Click to expand...
Click to collapse
I'm assuming you push it, via adb....correct, packetlss?

NOTE: backup before you try, writing this from the top of my head at 4 am.
To install:
run "adb remount" (to enable rw on /system)
run "adb push busybox /data/local" (so you got busybox somewhere on the phone)
run "adb shell" (to enter shell on phone)
in phone shell:
run "/data/local/busybox mkdir /system/xbin" (wanna make sure the directory exist)
run "/data/local/busybox cp /data/local/busybox /system/xbin/busybox" (copy busybox to xbin)
run "cd /system/xbin"
run "./busybox --install -s /system/xbin" (this should create symlinks for all the busybox applets)
run "ls -al" (you should see alot of symlinks)
run "rm /data/local/busybox" (remove the temporary busybox)

Thanks a lot for that...
Now I just need to learn how to do that directly into a custom ROM. Do you happen to know?

packetlss said:
NOTE: backup before you try, writing this from the top of my head at 4 am.
To install:
run "adb remount" (to enable rw on /system)
run "adb push busybox /data/local" (so you got busybox somewhere on the phone)
run "adb shell" (to enter shell on phone)
in phone shell:
run "/data/local/busybox mkdir /system/xbin" (wanna make sure the directory exist)
run "/data/local/busybox cp /data/local/busybox /system/xbin/busybox" (copy busybox to xbin)
run "cd /system/xbin"
run "./busybox --install -s /system/xbin" (this should create symlinks for all the busybox applets)
run "ls -al" (you should see alot of symlinks)
run "rm /data/local/busybox" (remove the temporary busybox)
Click to expand...
Click to collapse
So I followed that and accomplished it, I'm wondering what next? I have an app called SU File Manager & Terminal installed and it requires busybox. I don't see any new features or benefits? Am I not looking in the right place?

I'm having a permission issue getting this to install on my Hero.
Firstly I can't run 'adb remount'. I get:
remount failed: Operation not permitted
I'm not sure why.
So instead of remounting from there, I went into the adb shell and ran:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
This remounts rw /system just fine. I then I proceed with my install. I copy busybox to the /system/xbin folder and I run:
./busybox --install -s /system/xbin
However, I again get:
./busybox: permission denied
I have root access and I'm in su. I was able to mount system rw and make the xbin directly, along with copy the file to the folder, so I'm curious why i'm not able to install this.
Would anyone have a clue? It's 2:30am here, so I might be missing something or doing something incredibly stupid and just not realizing it.
Thanks!

VoXHTC said:
So I followed that and accomplished it, I'm wondering what next? I have an app called SU File Manager & Terminal installed and it requires busybox. I don't see any new features or benefits? Am I not looking in the right place?
Click to expand...
Click to collapse
posted by mistake ignore...

mrbrice said:
I'm having a permission issue getting this to install on my Hero.
Firstly I can't run 'adb remount'. I get:
remount failed: Operation not permitted
I'm not sure why.
So instead of remounting from there, I went into the adb shell and ran:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
This remounts rw /system just fine. I then I proceed with my install. I copy busybox to the /system/xbin folder and I run:
./busybox --install -s /system/xbin
However, I again get:
./busybox: permission denied
I have root access and I'm in su. I was able to mount system rw and make the xbin directly, along with copy the file to the folder, so I'm curious why i'm not able to install this.
Would anyone have a clue? It's 2:30am here, so I might be missing something or doing something incredibly stupid and just not realizing it.
Thanks!
Click to expand...
Click to collapse
Make sure that busybox is executable:
chmod 755 busybox

VoXHTC said:
So I followed that and accomplished it, I'm wondering what next? I have an app called SU File Manager & Terminal installed and it requires busybox. I don't see any new features or benefits? Am I not looking in the right place?
Click to expand...
Click to collapse
Busybox gives you command line tools. I have no idea what that particular app uses it for. That is something you have to speak to them about.

packetlss said:
Make sure that busybox is executable:
chmod 755 busybox
Click to expand...
Click to collapse
Yeah, I had thought that, so I made sure it was executable before hand
Code:
# ls -la
ls -la
drwxrwxrwx system system 2009-11-29 07:48 nandroid
drwxrwxrwx system system 2009-11-29 05:00 rosie_scroll
-rwxrwxrwx system system 698452 2009-11-28 21:47 busybox
# ./busybox --install -s /system/xbin
./busybox --install -s /system/xbin
./busybox: permission denied
Any other idea why it might be giving me this?

mrbrice said:
Yeah, I had thought that, so I made sure it was executable before hand
Code:
# ls -la
ls -la
drwxrwxrwx system system 2009-11-29 07:48 nandroid
drwxrwxrwx system system 2009-11-29 05:00 rosie_scroll
-rwxrwxrwx system system 698452 2009-11-28 21:47 busybox
# ./busybox --install -s /system/xbin
./busybox --install -s /system/xbin
./busybox: permission denied
Any other idea why it might be giving me this?
Click to expand...
Click to collapse
Don't run it from /sdcard, copy it to /data/local.
/sdcard is mounted noexec.

packetlss said:
Don't run it from /sdcard, copy it to /data/local.
/sdcard is mounted noexec.
Click to expand...
Click to collapse
Ahh. My bad. I had followed your instructions initially but I must not have changed the permissions that time around (messing around at 2am, you make mistakes. )
Thanks for all the help, not only compiling this, but for the assistance getting it working.
Cheers man. Good job.

If you guys want some other applets added to it, let me know and I'll compile a new one.
I think I got all the useful stuff in there though.

packetlss said:
If you guys want some other applets added to it, let me know and I'll compile a new one.
I think I got all the useful stuff in there though.
Click to expand...
Click to collapse
I'm trying to make my own custom ROM (nothing too fancy, just something to fit my needs) and I'm including busybox. It would be nice to have a list of all the busybox utilities (after the --install thing) so I could do the appropriate changes to the update-script manually.
Thanks for taking your time with this

Time to necro this thread again
New busybox out for those that cares, 1.15.3.
Code:
Code:
BusyBox v1.15.3 (2009-12-13 23:28:29 CET) multi-call binary
Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.
Usage: busybox [function] [arguments]...
or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as!
Currently defined functions:
[, [[, arping, ash, awk, basename, bbconfig, bunzip2, bzcat, bzip2,
cat, catv, chattr, chgrp, chmod, chown, chroot, chrt, cksum, clear,
cmp, cp, cpio, cut, date, dc, dd, depmod, devmem, df, diff, dirname,
dmesg, dnsd, dnsdomainname, dos2unix, du, echo, egrep, env, ether-wake,
expr, false, fbset, fbsplash, fdisk, fgrep, find, fold, free,
freeramdisk, fsck, fuser, getopt, grep, gunzip, gzip, head, hexdump,
hostname, ifconfig, insmod, install, ip, ipaddr, ipcalc, iplink,
iproute, iprule, iptunnel, kill, killall, killall5, last, length, less,
ln, losetup, ls, lsattr, lsmod, md5sum, mkdir, mkdosfs, mkfifo,
mkfs.vfat, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint,
mv, nc, netstat, nice, nmeter, nohup, nslookup, od, patch, pidof, ping,
pipe_progress, printenv, printf, ps, pscan, pwd, rdev, readlink,
realpath, renice, reset, resize, rm, rmdir, rmmod, route, sed, seq,
setconsole, setlogcons, setsid, sh, sha1sum, showkey, sleep, sort,
split, stat, strings, stty, sum, swapoff, swapon, switch_root, sync,
sysctl, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp, time,
top, touch, tr, traceroute, true, tty, tunctl, udpsvd, umount, uname,
uncompress, uniq, unix2dos, unzip, uptime, usleep, uudecode, uuencode,
vi, watch, wc, wget, which, who, whoami, xargs, yes, zcat

Changelog?
Thanks for the binary by the way
EDIT: This is weird... the binary you just posted is smaller compared to the previous one I had, 682Kb compared to 1.78Mb. Why such a big difference?

Nazgulled said:
Changelog?
Thanks for the binary by the way
EDIT: This is weird... the binary you just posted is smaller compared to the previous one I had, 682Kb compared to 1.78Mb. Why such a big difference?
Click to expand...
Click to collapse
Bug fix release. 1.15.3 has fixes for ash (compilation with signed chars, SIGHUP handling fix), awk, flash_eraseall (fix for newer kernel headers), grep, mount (mount -a won't mount everyting again on 2nd run), ping (fix unaligned access), split (accepts "-" as stdin now), build system (parallel build).

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

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.​

[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]_[mtk]_[boot_modifications]

Thought id post today on how to set your SELinux to permissive on boot within your boot.img along with some other mods aswell
DISCLAIMER
Make sure you have at least basic knowledge decompiling boot.img & basic understanding of the files contained within, I will not be held responsible if you mess this up, following my instructions to the tee you will have no problems though,
PRE REQUISTES
* MTK extractor or similar program to decompile the boot.img
* Notepad ++
* A copy of your devices boot.img or BOOTIMG.file
* SP flash tool to flash boot.img to device
"alternatively you can add to a flashable zip if you have a custom recovery available for your device using android script generator here on xda-developers"
GUIDE
1. If your boot file is named BOOTIMG.file rename it to boot.img
2. Copy the boot.img to the program folder youll be using to decompile for this guide ill be using MTK extractor as it has a simple gui interface for all the newbs
3. MTK EXTRACTOR ONLY
Open mtk extractor application select the BOOT option from the left, in the bottom left you will see an off switch toggle it to ON
Click start at the top under unpack boot, in the mtk extractor folder will be your boot.img files
4. SETTING THE KERNEL TO PERMISSIVE
( PART 1 )
NOTE
Not all mtk devices are the same some can be set to permissive without the need for all the files using only some and some require all the files it depends on the kernel the device uses the extra files wont make a difference if anything will enforce the state even more
In this tutorial you will be using all the files to set the SELinux contexts to permissive to ensure it is enforced.
PART 1 - STEP 1.
open the INITRD folder then open your default.prop using notepad++
Set the following :
ro.secure=1 >
ro.secure=0
(This renders the boot.img insecure)
ro.selinux=0 >
ro.selinux=1
(NOTE) UBIFS MTK does not have this option
ro.security.perf_harden=1 > ro.security.perf_harden=0
(If you also want insecure adb)
ro.adb.secure=1 >
ro.adb.secure=0
(only newer mtk devices use this ro. Code )
ro.storage_manager.enabled=1 >
ro.storage_manager.enabled=0
Additionally if your device also has a low ram size you should add this to the default prop also to reduce the amount of ram usage while enabling high-end gfx also
# begin ram properties
# for low ram device to return true
ro.config.low_ram=true
# force high-end graphics in low ram mode
persist.sys.force_highendgfx=true
# ram inhaler
ro.HOME_APP_ADJ=1
# end ram properties
Now save and exit the default.prop
PART 1 - STEP 2.
Open your init.rc & init.charging.rc file with notepad++ scroll to the very bottom of the init.rc ( if you have init.target.rc add to this also)
Place this code exactly as shown
# SELinux
on property:/system/bin/setenforce $permissive u:r:kernel:s0
on property:selinux.echo $permissive > /sys/fs/selinux/enforce u:r:kernel:s0
on property:selinux.reload_policy=0
restart ueventd
restart installd
on property:selinux.setsebool debugfs 0
setenforce 0
setprop selinux.reload_policy 0
seclabel u:r:kernel:s0
Now save & exit the init.rc
PART 1 - STEP 3.
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
PART 2 - STEP 1
( if you have init.target.rc already no need for this step)
open a new blank page in notepad++
On the first line add
On init
Space out 1 line so your now on line 3
Copy the #SELinux code we placed from init.rc to the new blank page, now save as init.target.rc
Do the above again but this time name it as init.kernel.rc
Now copy theese files to your INITRD folder
PART 2 - STEP 2.
open your init.rc & init.charging.rc once again
Add the following to the import section at the very top of the page,
import /init.kernel.rc
Import/init.target.rc
Save & exit now, your probably wondering why youve added so many files with the same code, on some devices it is necessary as i have found especially on NAND + UBIFS or JFFS2 devices.
PART 2 - STEP 3.
exit the INITRD Folder now open up the bootinfo.txt file
Change from the following
cmdline: >
cmdline: bootopt= androidboot.selinux=permissive
NOTE
FOR MT67**** 32 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,32N2 >
TO
cmdline: bootopt=64S3,32N2,32N2 androidboot.selinux=permissive
FOR MT67**** 64 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,64S3 >
TO
cmdline: bootopt=64S3,32N2,64S3 androidboot.selinux=permissive
Now save & exit the bootinfo.txt
PART 2 - STEP 4
open the cpiolist
Add the following at the bottom or add wherever dosent matter as long as its there
file init.kernel.rc initrd/init.kernel.rc 0750
file init.target.rc initrd/init.target.rc 0750
(Add this option only if you origninally didnt have the init.target.rc file)
Save & exit the cpiolist.
PART 2 - STEP 5
Recompile & flash if you did everything right youve now got an insecure boot.img without dm-verity encryption or data footer enceyption, with insecure adb & SElinux set as permissive,
To make sure its permissive go into settings and about device then scroll to bottom you should now see it,
If you found this useful you know where the thanks button is.

Matty1993 said:
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
Click to expand...
Click to collapse
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.

bigrammy said:
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
Click to expand...
Click to collapse
Wow i didnt even see this till now i need an assistant or something to organise and mark all my threads because im useless at it haha anyhow maybe could be a vendor related thing then as mine has all the info in dtb of kernel aswell as i was able to remove just "verify" from system and metadata completely and got it to boot.
I also found an easier way to get kernel permissive also as my first older method dosent seem to work with newer mtk models but my newer method works across most mtk platform from mt6572 up to mt6737m
What i did is decompiled my twrp i built for the same phone and copied the busybox applet from /sbin in the initrd then decompiled my boot.img added it to sbin gave it necessary permission of 04555 in the cpiolist whilst i had cpio list open i added below "file init initrd/init 0750"
"file init2 initrd/init2 0750" then went back to the initrd and changed the name of the "init" file to "init2" opened notepad++ to a new page and added the following
#!/sbin/busybox sh
cd/
/sbin/busybox mkdir /tmp
/sbin/busybox mount -t tmpfs tmpfs /tmp
/sbin/busybox mount -t proc proc /proc
/sbin/busybox sed -e 's/printk\.disable_uart\=1/printk\disable_uart\=1 androidboot\.selinux\=permissive/' /proc/cmdline > /tmp/cmdline
/sbin/busybox mount --bind -o -ro /tmp/cmdline /proc/cmdline
/sbin/busybox settings put global captive_portal_detection_enabled 0
/sbin/busybox chmod 755 /init2
/sbin/busybox mv /init2 /init
/bin/su settings put global captive_portal_detection_enabled 0
exec /init
All i did then was save it under the name .init to the bootimg directory then remove the "." from the file name so that it became init.file instead of .INIT format file
After that opened up the bootinfo.txt and added under cmd=bootopt=androidboot.selinux=permissive
Recompiled bootimg and had no dramas so thought id chuck it up here in case anyone else couldnt get there kernel to setenforce 0 through /bin/setenforce or any other way youve tried on these newer mtk models, do remember though results may vary this may or may not work for everyones device, no this will no permanently brick your device doing this if it dosent work you will simply still have an enforcing kernel. Have fun all

Help
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.

waryag said:
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
Click to expand...
Click to collapse
Hey bud sorry for late reply,
What board make type is it running 6580, 6735/6737 or 6763/6737 depending on which it should be pretty straight forward to get you unlocked and what not as your BL will be by default locked down either way on 6580 or 67xx
I dont recommend you pushing permissive selinux on 8.1 however as this will compromise your security integrity what were you looking to do anyhow regarding permissive selinux,
Rooting or custom recovery ??

Question No Permissions for /system/ but I have root

I tried
mount -o rw,remount /system/
But
mount: '/system/' not in /proc/mounts

system-as-root = system is mounted as /, not /system
Permissions are fine.

DavidxxxD said:
system-as-root = system is mounted as /, not /system
Permissions are fine.
Click to expand...
Click to collapse
I can't write to / still

Are you root?
What is output of
Bash:
id
Bash:
su -c mount -o remount,rw /
Also try this to find out more
Bash:
mount | grep "/ "

DavidxxxD said:
Are you root?
What is output of
Bash:
id
Bash:
su -c mount -o remount,rw /
Also try this to find out more
Bash:
mount | grep "/ "
Click to expand...
Click to collapse
Bash:
berlna:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012 context=u:r:shell:s0
Bash:
berlna:/ $ su -c mount -o remount,rw /
'/dev/block/dm-8' is read-only
Bash:
berlna:/ $ mount | grep "/ "
/dev/block/dm-8 on / type ext4 (ro,seclabel,relatime,discard)
And yes I have root

I've never seen this output from trying to remount. Could be a permanent read-only attribute somewhere. /dev/block/dm-8 looks like your system is on an encrypted partition, this could have something to do with the error. You can try using the busybox version of mount command. Also, does your device have a super partition? That could explain it.

DavidxxxD said:
I've never seen this output from trying to remount. Could be a permanent read-only attribute somewhere. /dev/block/dm-8 looks like your system is on an encrypted partition, this could have something to do with the error. You can try using the busybox version of mount command. Also, does your device have a super partition? That could explain it.
Click to expand...
Click to collapse
This is the same error i also face in oneplus os12 and yes my dev dm-x also is ro even after root
Its super.img and also i try with busybox
But useless
The only way now i can see is unpack backup super
Unpack edit repack and flash back
But its not possible for me

Rewriting the super partition every time, seems to be the only way in your case.
The lpflash tools are used to work with super partitions.
I've attatched a statically linked 64-bit ARM version that can run on the device, built from this source.
Extract the system image using
Bash:
./lpunpack -p system super.img
Note: This can also be run directly on the block device, it only reads.
From there, you can modify the system and add it to a super image (the firmware usually has sparse ones that need to be decompressed first). You could also flash the new system image directly via fastbootd mode.
Note: Ignore any "invaild sparse header" messages from fastboot.
Don't flash unsparse images on Samsung devices! They will not like it!
Hope this is helpful.

DavidxxxD said:
Rewriting the super partition every time, seems to be the only way in your case.
The lpflash tools are used to work with super partitions.
I've attatched a statically linked 64-bit ARM version that can run on the device, built from this source.
Extract the system image using
Bash:
./lpunpack -p system super.img
Note: This can also be run directly on the block device, it only reads.
From there, you can modify the system and add it to a super image (the firmware usually has sparse ones that need to be decompressed first). You could also flash the new system image directly via fastbootd mode.
Note: Ignore any "invaild sparse header" messages from fastboot.
Don't flash unsparse images on Samsung devices! They will not like it!
Hope this is helpful.
Click to expand...
Click to collapse
Its a super.img thx