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?
Related
INTRODUCTION
This document describes a procedure for installing Ubuntu 11.10 Oneiric Ocelot onto your Android device to run alongside an existing Android rom. My instructions assume you are running CyanogenMod 7. I will try to provide workarounds for other roms.
Ubuntu on a mobile device, running alongside Android, is somewhat difficult to use and is useless for most users. You should not attempt this procedure unless you have a need to run arbitrary Linux software from a mobile device. Many mobile computing needs can be met by installing remote access software on a traditional desktop computer. Conversely if you find the idea of having a general purpose Linux system in your pocket to be freaking awesome, whether you need it or not, please read on.
CAUTION
The following procedure assumes familiarity with Linux fundamentals, and basic familiarity with Android's Linux underpinnings. Data loss is possible, especially for the data on your SD card, so please make backups. Some commercial Android software is recommended, specifically Tasker and Better Terminal Emulator Pro. A large, fast SD card is also recommended. (I <3 my PNY 32 GB class 10 card)
Some optional steps are proposed that may interfere with how your Android device manages its SD card. You may be required to manually run a script before certain Android features, like mounting your device's SD card on a desktop PC via USB cable, will function properly.
Each step will have, whenever possible, a recommended procedure and one or more alternative procedures. If the recommended procedure doesn't work for you, the alternative procedure might require some research, manual-page reading, or other outside assistance to accomplish.
Shell commands should be executed on a root shell on your Android device. Use the built-in Terminal Emulator, ConnectBot in local mode, Better Terminal Emulator Pro, "adb shell" from a connected PC, or your favorite terminal emulator.
OVERVIEW
Too long; didn't read? Here's a quick summary of the steps involved:
Partition your SD card, creating a 2 GB or 4 GB Linux partition
Confirm the new partition is mounted at /sd-ext
Unpack http://cdimage.ubuntu.com/ubuntu-core/daily/current/oneiric-core-armel.tar.gz to /sd-ext
Create an empty file /sd-ext/.nomedia
Edit /system/etc/init.d/05mountsd to bind proc, dev, and sys to /sd-ext
Optionally edit /system/etc/init.d/05mountsd to bind /data, /system, and /cache to /sd-ext/mnt
Prepare a script to open a chroot shell with correct environment variables
Update /etc/apt/sources.list and /etc/resolv.conf according to your preference
Overwrite /sbin/start with /sbin/true
Copy or link important files into /etc and /lib
Initialize the package manager and begin downloading packages
(optional) Integrate Ubuntu services with Tasker profiles
STEP 1: Partition your SD Card
While a basic Ubuntu system can be installed in as little as 200 MB of disk space, many software packages require more space. Also many Linux tasks require unusual file attributes, permissions, or types, which cannot be placed on your SD card's regular FAT32 / VFAT file system.
Recommended: Use an existing Ubuntu system, or even an Ubuntu live CD, and a USB card reader to repartition your SD card without losing any data. Be sure the first primary partition remains FAT32 / VFAT, and create a second primary partition of type ext3 or ext4.
Alternative 1: Use any desktop system to back up all of the data on your SD card, either with a card reader or using your Android device. Use your phone's recovery partition to destructively repartition your SD card with a 2 or 4 GB ext3 or ext4 partition, and NO swap partition. Then copy your SD card contents back to your SD card.
Alternative 2: If you don't want to partition your SD card, you can create large empty files on your SD card and mount those. Some of the later steps will work differently and you may have to improvise.
Create large empty files on your SD card to contain your Ubuntu filesystem: dd if=/dev/zero of=/mnt/sdcard/UBUNTU.IMG bs=32768 count=65536
Identify a free loopback device number that isn't currently in use and won't likely be occupied by Android Apps2SD in the future: ls /dev/block
Create a new loop device for your file. Note the first number is the loop filename number you observed wasn't in use (at least a few dozen higher than the highest number you see), then a b and a 7, and then a number one less than the filename number. For example: mknod /dev/block/loop200 b 7 199
Associate the loop device with your new empty file: losetup /mnt/block/loop200 /mnt/sdcard/UBUNTU.IMG
Find which versions of mkfs are on your system: ls /system/xbin/mkfs*
Using whatever version you have (ext4 or ext3 preferred, but ext2 is acceptable) run: mkfs.ext# /dev/block/loop200
Save these commands in a script for later use. The dd and mkfs commands were only used this once, but the mknod and losetup commands will have to be run manually from a script each time you boot your phone.
STEP 2: Mount your Linux Partition
To avoid causing problems for your Android system, we shouldn't tamper with any of Android's critical files or directories. We will mount our Linux partition in a new directory that Android isn't using. With any luck, our rom already contains scripts that will automatically mount this for us.
Recommended: If you have partitioned your SD card and you are running CyanogenMod 7, use a root shell or file manager to confirm /sd-ext contains at least a directory called lost+found. If lost+found is present in /sd-ext then this step is done and you should continue to step 3.
Alternative 1: Use a root shell to navigate to /etc/init.d and look for a file called 05mountsd. If that file doesn't exist, you may need to create it or use another alternative method. If it does exist, run it with ./05mountsd and observe any error messages. If fsck or mount are failing because the filesystem type doesn't match what was expected, you can edit the file and change the filesystem type in the script.
Hint: you can do a quick search-and-replace using sed and a regular expression:
Code:
mv 05mountsd 05mountsd-old
cat 05mountsd-old | sed -e s/ext3/ext4/ > 05mountsd
diff 05mountsd-old 05mountsd
#changes look good to you? then proceed:
rm 05mountsd-old
ls -al
chown root.shell 05mountsd
chmod 750 05mountsd
#adapt owner (root), group (shell) and permissions (-rwxr-x---) to match the other files in that directory
Alternative 2: If your rom doesn't create, or attempt to mount, anything called /sd-ext you might have to create your own mount point.
Code:
mount -o remount,rw /system
mkdir /system/sd-ext
mount -o remount,ro /system
Then, in the following steps, replace any reference to /sd-ext with /system/sd-ext.
STEP 3: Install the Base System
Recommended: Download this file: http://cdimage.ubuntu.com/ubuntu-core/daily/current/oneiric-core-armel.tar.gz (Should be under 32 MB, and is the only potentially-insecure download required because the file is unsigned.)
Store it on your SD card somewhere, like in /mnt/sdcard/download/. (If you use your Android device's browser, it will probably land there automatically.)
If you're nervous about making a mistake, double-check your system partition is read-only:
Code:
mount | grep -v block/dm- | grep \(rw
#If anything there looks like it shouldn't be read-write, make it read-only:
mount -o remount,ro /system
Open a root shell and navigate to /sd-ext. Use pwd (present working directory) to confirm you really are in /sd-ext. Then go ahead and unpack:
Code:
tar zxvf /mnt/sdcard/download/oneiric-core-armel.tar.gz
STEP 4: Create a .nomedia file
Android may try to scan your Linux partition for images, videos, and pictures. The Linux partition contains many files and directories and this scan can take a long time. To avoid these lengthy scans, we will add a file to the Linux partition that blocks well-behaved Android services from scanning.
Recommended: Use a root shell to navigate to /sd-ext. Create the file and set its permissions:
Code:
echo > .nomedia
chown root.root .nomedia
chmod 644 .nomedia
STEP 5: Bind /proc, /dev, and /sys to the Linux partition
Recent versions of Linux provide a way to clone a partition, so when changes are made to one copy of the partition the changes take effect immediately in the other copy. We will use this to make the /proc, /dev, and /sys partitions used by Android available in our Linux partition as well.
This is necessary because when we run Ubuntu we will be using chroot (change root) to make /sd-ext the only filesystem Ubuntu can see. Ubuntu will need to be able to see /proc, /dev, and /sys, as well as some of the files in /etc, /vendor/lib, and /system/lib. We will meet some of these needs with mount --bind
Additionally we will need these bindings to be recreated every time the /sd-ext partition is mounted. So we will add some commands to the run-parts script that mounts /sd-ext, located at /etc/init.d/05mountsd.
Recommended: Open a root shell and navigate to /etc/init.d, and use a text editor to open 05mountsd.
Near the end of the file you should see some commands that operate on /sd-ext:
Code:
$BB chown 1000:1000 $SD_EXT_DIRECTORY;
$BB chmod 770 $SD_EXT_DIRECTORY;
Edit the chmod command and change the permission mask number from 770 to 775, which grants non-root users the ability to read the contents of that directory. Then add the following commands immediately after the chown and chmod commands already present:
Code:
$BB mount --rbind /dev /sd-ext/dev
$BB mount --rbind /proc /sd-ext/proc
$BB mount --rbind /sys /sd-ext/sys
STEP 6: (OPTIONAL) Bind /system, /data, and /cache to /sd-ext
This step is optional, and provides a way to operate on Android system files from within Ubuntu. If you're concerned about a stray command destroying your Ubuntu system and you want to make sure it doesn't take any Android system files with it, you should skip this step.
Recommended: Open a root shell and navigate to /sd-ext/mnt, and create some directories which will serve as mount points:
Code:
pwd
# you should be in /sd-ext/mnt
mkdir -m 700 system data cache
chown root.root system data cache
ls -al
# Each of system, data, and cache should show drwx------ and root for both owner and group
Then navigate to /etc/init.d and edit 05mountsd. Add the following under the existing mount --rbind commands you added earlier:
Code:
$BB mount --rbind /system /sd-ext/mnt/system
$BB mount --rbind /data /sd-ext/mnt/data
$BB mount --rbind /cache /sd-ext/mnt/cache
STEP 7: Prepare a script to open a chroot shell with proper environment variables
Now you will need an easy way to create a first process, a shell, in the new environment you've created. This shell will start life in a different world than regular Android shell processes live in: it will use a different root filesystem and will be able to see different files and directories, and it will have access to a vast number of full-featured programs and services.
We will be using the Bourne Again Shell, bash. We will launch bash with a program called env, which sets some environment variables and then launches a program with that new environment. Finally, we will be launching env with a program called chroot, which changes the root filesystem seen by a program before it launches it.
Option 1: Better Terminal Emulator Pro: I don't want to say "recommended" because it involves buying software that's not really necessary. I'm partial to Better Terminal Emulator Pro because it seems to have more available options (compared to the built-in Terminal Emulator) and it doesn't kill your shell unexpectedly when network connectivity changes (unlike ConnectBot). I'm not affiliated with the author of that software. Also, after I bought that I stopped looking for alternative shells, so there may exist other alternative shells that work better for this.
Use Better Terminal Emulator Pro and add the commands necessary for starting your chroot shell to BTEP's options. Once you do this, BTEP will essentially be a dedicated Ubuntu console for you, and may be difficult to use for other tasks.
My settings are:
Shell: Android Shell
Command Line: /system/bin/sh
Initial Command:
Code:
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l; exit
clear
Start as root: yes
Option 2: Terminal Emulator, and a shell script: Open a root shell and create a file:
Code:
#!/system/bin/sh
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l
exit
Save the file with whatever name you like, perhaps "ubuntu", and put it somewhere in your path. You could add it to /system/bin: mount -o remount,rw /system; mv ubuntu /system/bin/ubuntu; mount -o remount,ro /system
Option 3: ConnectBot: I don't recommend ConnectBot for this because, while it does offer "local" connection types, if your connectivity changes (even wifi to cell) it will close your "connection" immediately.
That said: create a new connection with type local, and give it the following initial command:
Code:
su -
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l; exit
clear
STEP 8: Update /etc/apt/sources.list and /etc/resolv.conf
Ubuntu uses a package manager which automatically finds, downloads, verifies, and installs software for you. The package manager requires a list of trusted repositories which contain binaries built for ARM CPUs, like the one in your Android device.
FIXME: Later I'll discuss the pros and cons of each of these selections. For now I'll just provide my sources.list file.
Open your Ubuntu shell, using the method from step 7, and issue the following commands:
Code:
echo nameserver 8.8.8.8 > /etc/resolv.conf
# you can use a nameserver of your choice if you like.
echo nameserver 8.8.4.4 >> /etc/resolv.conf
# notice the >> instead of > which means we're appending, not overwriting.
apt-get install nano
# follow the prompts - say yes if it asks if you want to proceed.
nano -w /etc/apt/sources.list
And here are the contents of my sources.list file, containing binary sources for ARM CPUs:
Code:
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-security main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-updates main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-backports main restricted universe multiverse
deb http://archive.canonical.com/ oneiric partner
deb http://archive.canonical.com/ oneiric-security partner
deb http://archive.canonical.com/ oneiric-updates partner
deb http://archive.canonical.com/ oneiric-backports partner
STEP 9: Overwrite /sbin/start with /sbin/true
Nothing too complicated here. Some Ubuntu packages install services, which the system will usually want to automatically start and end when the system boots and shuts down.
However, on an Android device Android is responsible for booting and shutting down the system, and it doesn't know much about Ubuntu services.
Later (FIXME: when?) we'll discuss how to use an Android program like Tasker to more intelligently manage Ubuntu services. But for now, we need to trick Ubuntu's package installation scripts into believing it has successfully started a service. We will use a useless program called true, which does nothing and reports that it was successful, in place of a program called start, which will be unable to start a service because it has no access to Android's init system.
Open your Ubuntu shell and do this: cp /sbin/true /sbin/start
STEP 10: Copy or link important files into /etc and /lib
FIXME: I haven't finished this section yet. Some of my software remains broken until I fix this.
STEP 11: Initialize the package manager and begin downloading packages
Now we can begin using our Ubuntu system's package manager to install any other packages we might need.
Open your Ubuntu shell and do the following:
Code:
apt-get update
# This will take a short while, and will download updated software catalogs from each of the update servers
apt-get upgrade
# This looks for updates to any currently-installed packages. There aren't many packages installed so this should be quick.
apt-get install PACKAGE NAMES GO HERE
Then keep using apt-get install to install whatever you need.
Here are some common packages and package sets:
ubuntu-dev-tools: development tools including a compiler and linker
tightvncserver: simple X server you can connect to with androidVNC
FIXME: I need to put a lot more here.
Sorry for bumping old threat, but I am kind of stuck. Everything goes fine, but when I try to create the script in BTEP (and android terminal) I am getting segmentation fault in both of them.
Checked for syntax errors 100 of times. I am using CM6 froyo 2.2 on Motorola milestone. SD card has 2 gb of ext3 partition mounted in /sd-ext.
*EDIT*
Reflashed CM 7 latest and same thing happens. Segmentation Fault.
Ok, lately we have had a rash of errors and undesired performance. In my opinion, this is unacceptable... So I am trying to fix it. Now, I can't fix every issue, but boy can I sure help most of them...lol
So let's get started. We will call this:
The File System Cleaner
Linux has a few tools for us to see if we have a "Dirty" or "Clean" filesystem.
They are tune2fs, e2fsck, and fsck_msdos.
Now, you can't use all of them for every file system or partition (we will refer to them all as partitions from here on out). Each one works on certain filesystems. For example, e2fsck works on ext type partitions where fsck_msdos works on vfat type partitions, and tune2fs only works on large partitions.
While tune2fs is a tool that gives detailed information about a partition, it can still give us an idea on where we stand on those larger partitions as well as change certain options/features on that partition such as journaling, mount point, mount as rw or ro, etc. But the biggest thing we are going to focus on is 1 line:
Code:
Filesystem state
If you run tune2fs and the filesystem state is anything other than clean, you have some sort of gremlin floating about it and it needs to be fixed. Now what about those partitions in which we get these errors:
t
Code:
tune2fs 1.41.11 (14-Mar-2010)
tune2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/block/mmcblk0p4
Couldn't find valid filesystem superblock.
1|[email protected]:/ # tune2fs -l /dev/block/mmcblk0p28
tune2fs 1.41.11 (14-Mar-2010)
tune2fs: Bad magic number in super-block while trying to open /dev/block/mmcblk0p28
Couldn't find valid filesystem superblock
It doesn't mean that they are corrupt. It means they are either not in a format that tune2fs can read or they are not a large partition.
So for those partitions that are not compatible with tune2fs, we can use fsck.
The fsck works much like scan disk and defrag in windows. It scans the partition for several different things like bad blocks, missing/corrupt information, etc. Although you can run tune2fs on any large partition whether it is mounted or not, you DO NOT want to fsck ANY partition that is mounted or it WILL result in TOTAL data LOSS! You have been warn!
Keep in mind all this information is at your own risk, but know that I have been using this for quite some time and it hasn't failed me yet. But then again, I follow my instructions to a TEE, as you should as well...
So, here's how we use all this.
First make sure you have adb installed on your computer
To be safe, boot into recovery, plug your phone into your computer and start adb shell
Now type:
Code:
mount /system
cp /system/bin/tune2fs /tmp
cp /system/bin/e2fsck /tmp
cp /system/bin/fsck_msdos /tmp
chmod -R 777 /tmp
cd tmp
Now that our tools are set, we can now begin cleaning house.
First and most important, make sure you umount ALL partitions.
I personally unmount them manually via mounts and storage in CWM.
In terminal (with adb running) type:
Code:
./tune2fs -l <partition>
./e2fsck <partition>
./fsck_msdos <partition>
**NOTE**If you have an error "/sbin/sh: <command>: not found" when executing one of these commands simply mount /system and copy to tmp, and chmod 777 again.**
For more information on the commands, run <command> -h. here you will see additional options for that command.
Now, I didn't break down which partitions work with tune2fs, but /system, /data, and /cache can be scanned with tune2fs.
However, I did break as to what partitions need which fsck command to be cleaned.
Code:
e2fsck
|mount point| |Filesystem type|
/dev/block/mmcblk0p21 /efs
/dev/block/mmcblk0p24 /system
/dev/block/mmcblk0p25 /data
/dev/block/mmcblk0p26 /cache
/dev/block/mmcblk0p27 /tombstones
/dev/block/mmcblk1p2 unknown
Code:
fsck_msdos
|mount point| |Filesystem type|
/dev/block/mmcblk0p4 fsinfo
/dev/block/mmcblk0p13 /system/etc/firmware/misc
/dev/block/mmcblk0p17 /system/etc/firmware/misc_mdm
/dev/block/mmcblk0p28 emmc
/dev/block/mmcblk1p1 /sdcard
Example:
Code:
/tmp # e2fsck /dev/block/mmcblk0p24
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p24: clean, 4220/38320 files, 93625/153088 blocks
This should resolve many of your laggy performance and random reboot issues. As well as the issue of freezes after a reboot.
If you are a flash addict, tuning your partitions between flashes my be a GREAT idea...
If you do not have those binaries in your ROM, let me know and I will upload them here...
Now, there is a little more destructive way to clean a partition, and that is to reformat it. Most of us format /system /cache and dalvik in CWM before flashing, but sometimes that isn't enough. All CWM does is erase the files/folders contained in one of those partitions.
Here's how we do a complete reformat:
Reboot to recovery, plug phone in and start adb shell
Type:
Code:
mount /system
cp /system/bin/make_ext4fs /tmp
chmod 777 /tmp/make_ext4fs
mount <system, data or cache partition>
./make_ext4fs <partition>
This only works with ext4 partitions, so use it ONLY on these:
Code:
/dev/block/mmcblk0p24 /system
/dev/block/mmcblk0p25 /data
/dev/block/mmcblk0p26 /cache
I know there are other ext partitions, like tombstone and efs, but DO NOT use this command on them. You may BRICK or damage your device. I will say this again, ONLY DO THIS on data, cache, system!
**NOTE** If you format system partition, you WILL have to flash your ROM and Gapps again...
I have not had windows on this pc for over 2 years now and I think ADB is MS only right? I do flash a lot but I normally run ultimate kernel cleaning script and plus run the wipes a couple times myself and sumtimes format cache partitons before I install a new rom.... I like to make sure I do most I can to clean before I flash...and I always run the LZ kernel Cause its AWESOME!! but I guess my question is how can I look to see if my partitons need to be cleaned.. on AOKP with LZ kernel at moment and it is smooth fast and no bugs or reboots. is there a way to vew the partitions with ubuntu 12.04? or dose ubuntu even need ADB... linux seems very good at haveing the right drivers and software already available without installing to many extras.
not even sure your a linux desktop user but thought I would go ahead and ask.
Many thanks for everything
woodyjlw said:
I have not had windows on this pc for over 2 years now and I think ADB is MS only right? I do flash a lot but I normally run ultimate kernel cleaning script and plus run the wipes a couple times myself and sumtimes format cache partitons before I install a new rom.... I like to make sure I do most I can to clean before I flash...and I always run the LZ kernel Cause its AWESOME!! but I guess my question is how can I look to see if my partitons need to be cleaned.. on AOKP with LZ kernel at moment and it is smooth fast and no bugs or reboots. is there a way to vew the partitions with ubuntu 12.04? or dose ubuntu even need ADB... linux seems very good at haveing the right drivers and software already available without installing to many extras.
not even sure your a linux desktop user but thought I would go ahead and ask.
Many thanks for everything
Click to expand...
Click to collapse
Yeah, I'm completely windows free too...YAY! lol
You still need to install the adb binary/command and put it in your path. The good news is, it's very simple in Linux, unlike wincrapdows...
And then just follow the tutorial to check your partitions...
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.
Introduction
While Android allows to encrypt the /data partition this is not the case for the sdcard with many ROMs. So there are many files on the sdcard that remain accessible for wicked persons who have physical access to it. This script is an attempt to solve this problem by encrypting the content of the sdcard with the help of EncFS.
This thread is for people who have an interest to encrypt their sdcard. If you don't need it of if you want to discuss the necessity of encrypting the sdcard or encryption in general, please stay away and open a new thread if necessary.
Why EncFS?
When I was looking for a proper way to encrypt my sdcard, I wanted the following points to be fulfilled:
well-known, strong encryption method - the encrypted data should be accessible with other devices and systems (e.g. with Windows, MacOS, Linux)
conventional plain data and encrypted data on one sdcard - some file possibly should stay unencrypted (e.g. files for osmand, video files,...)
shared space for plain and encrypted data - especially with small sdcards it is more comfortable to stay with one big partition instead of splitting the sdcard
EncFS fulfills these points. Furthermore, there are working binaries and build instructions for Android thanks to Cryptionite.
Is it stable? Will it slow down my device?
I'm running my phone with encrypted sdcard for about a year now without any serious problems. I tested it with Sultanxda's CM11 KitKat ROM and ivanich's CM12 Lollipop ROM so I expect it to work at least on every CM11 and CM12 ROM. Please let me know if it works / doesn't work for you.
Using encryption will obviously slow down the read/write speed from/to sdcard. However, for me it is fast enough. As encryption and decryption is taking place in the CPU I expect the deceleration to be less on slow sdcards. But this is only an assumption.
With a SanDisk Ultra Class10 and AES 128 Bit encryption I tested the speed with the dd method on Android Lollipop:
Without encryption:
Write: 9 Mb/s
Read: 21,3 Mb/s
With EncFS encryption:
Write: 4,5 Mb/s
Read: 19,4 MB/s
Again, I hope to hear about the speed you measure.
Installation Instructions
Please backup your device before you try this! I don't know if this is working on your device and ROM. Do it at your own risk! I'm not responsible for any damage or data loss!
encrypt your /data partition. Your password for the sdcard-encryption will be stored on /data in plain text, so this is essential
install the attached zip-file via recovery
create a folder named ".encrypted" in the root of your sdcard
create an EncFS repository in the ".encrypted" folder. This is not difficult, search for howtos if you don't know what to do. You can do this on your device via adb or terminal (as root):
Code:
/system/bin/mount.encfs /sdcard/.encrypted /sdcard/decrypted
or with Linux, Windows or MacOS (via MacPorts), for example:
Code:
encfs /path-to-sdcard/.encrypted /only-temporary
save the password you entered in /data/local/passwd on your phone (adb or terminal as root)
Code:
echo "your-encfs-password-here" > /data/local/passwd
reboot
if everything works, you have the decrypted files of the ".encrypted" folder in "/storage/sdcard0" and ordinary plain files on your sdcard in "/storage/sdcard1"
now you can move the data of your apps, photos, ringtones, music,... from "/storage/sdcard1" to "/storage/sdcard0"
After flashing a new ROM, you only have to flash the zip-file again.
How does it work?
The script is executed every time you mount your sdcard (at boot and when inserting the sdcard). To achieve this, the sdcard daemon at /system/bin/sdcard is replaced with a script which performs the mounting stuff. It is looking for the ".encrypted" folder on the sdcard. If the folder exists, it decrypts it with the password stored in "/data/local/passwd". You will have the following sdcard structure dependent of the presence of the ".encrypted" folder:
".encrypted" folder is present (and "/data/local/passwd" containing the right password):
/storage/sdcard0 -> the decrypted data of .encrypted (the EncFS folder)
/storage/sdcard1 -> all the data of your sdcard
".encrypted" folder is not present:
/storage/sdcard0 -> all the data of your sdcard
So if you rename or delete the ".encrypted" folder on your sdcard, the script should react as if it doesn't exist.
There are some apps which can be configured to use another folder as "sdcard0". These can make use of "sdcard1", especially if they must access big files very fast (like Osmand or some podcast-apps).
Where is the EncFS binary from?
The EncFS binary is an ARMv7-version taken from Cryptonite. You can also build it yourself and replace the one in the zip file.
[ Reserved ]
support!!
Info
Can i encrypt/decrypt a single folder in internal sdcard?
ki1120 said:
support!!
Click to expand...
Click to collapse
Yeah.. so... I don't know what to say...
ultrasound1991 said:
Can i encrypt/decrypt a single folder in internal sdcard?
Click to expand...
Click to collapse
This is exactly what cryptonite does. You can mount single encrypted folders via a comfortable GUI.
If you want to mount the folder automatically together with the sdcard my script can also be adjusted. However, umnounting the sdcard (from settings or when connecting USB) could be prevented. This sould be tested. You can ask me if you need help.
Info
Cryptonite is no longer supported.
I have smartphone with Android L, root, and only internal sdcard.
I want to use your script to mount an encrypted folder, that contain encfs6.xml file.
Can you help me? I am not a programmer.
EncFS (FUSE) UID, GID not set, always "0" ("root")
It's old though, I was experimenting on a KitKat. All sets up fine, just the permissions part. Whatever uid and gid is set in command, folder is always mounted as uid=0 and gid=0 i.e. root when checked by 'mount' command. Mount details are as under:
Code:
[email protected]:/ # mount | grep "storage/sdcard"
encfs /storage/sdcard0 fuse.encfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
[email protected]:/ #
It's because sdcard daemon is run as root?
But apps need uid and gid 1023 (media_rw) or perhaps 1028 (sdcard_r). I'm not sure about this. As the init.qcom.rc lines say:
Code:
# create virtual SD card at /mnt/sdcard, based on the /data/media directory
# daemon will drop to user/group system/media_rw after initializing
# underlying files in /data/media wil be created with user and group media_rw (1023)
service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated
class late_start
service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 /mnt/media_rw/sdcard1 /storage/sdcard1
.
Now, if I run command as user 1023 or 1028, encfs can't read /storage or /mnt directories due to restricted permissions:
Code:
[email protected]:/ # su 1023 /system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=1023,gid=1023,umask=006,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
The directory "/storage/sdcard0" does not exist. Should it be created? (y,n) y
Unable to create directory: : Permission denied
06:06:32 (main.cpp:435) Unable to locate mount point, aborting.
How to achieve this drop part?:
Code:
#daemon will drop to user/group system/media_rw after initializing
I think I'm missing something very simple.
And encfs latest static binary for arm can be made available somehow other than compiling? That's a real tough part.
Does EncFS work with Android 6+? If no, any similar alternatives i.e. command-line solution, not apps.
mirfatif said:
I think I'm missing something very simple.
Click to expand...
Click to collapse
Do you use the script I provided? It should create the sdcard as root before running encfs:
Code:
mkdir /storage/sdcard0 0700 root root
After that it runs encfs as root – the "drop part" is actually "uid=0,gid=01028" with which encfs mounts the encrypted folder:
Code:
/system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=0,gid=01028,umask=6,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
mirfatif said:
And encfs latest static binary for arm can be made available somehow other than compiling? That's a real tough part.
Click to expand...
Click to collapse
Development of Cryptonite seems quite inactive unfortunately. But there is a fork that seems to have some fixes for building, a build script and build instructions.
mirfatif said:
Does EncFS work with Android 6+? If no, any similar alternatives i.e. command-line solution, not apps.
Click to expand...
Click to collapse
I didn't test it with Android 6 as from there on adoptable storage is available. Adoptable storage fulfils most of the things I wanted for sdcard encryption (see my first post: strong encryption; conventional plain data and encrypted data). Thus, it basically makes my encfs-solution obsolete for Android 6+.
bastei said:
Do you use the script I provided? It should create the sdcard as root before running encfs:
Code:
mkdir /storage/sdcard0 0700 root root
After that it runs encfs as root – the "drop part" is actually "uid=0,gid=01028" with which encfs mounts the encrypted folder:
Code:
/system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=0,gid=01028,umask=6,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
Click to expand...
Click to collapse
I used these scripts without any problems on:
Android 4.4:
Code:
#!/system/bin/sh
#####################################################################################################
# DISABLE INTERNAL MEMORY (/data/media/0) AND USE EXTERNAL SD CARD AS INTERNAL STORAGE #
# ENCRYPT FILES ON EXTERNAL SD CARD FOR SECURITY #
# #
# STEPS: #
# 1. DIM i.e disable internal memory (KitKat, Lollipop), not explained here #
# #
# 2. change in boot.img > ramdisk > init.qcom.rc: #
# service fuse_sdcard0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard0 #
# to #
# service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard1 #
# #
# ensure both lines exist in init.qcom.rc: #
# "mkdir /storage/sdcard1 0700 root root" and "mkdir /storage/sdcard0 0700 root root" #
# #
# 3. rename /system/bin/sdcard to sdcard_orig #
# 4. replace /system/bin/sdcard with this script (named "sdcard") #
# 5. copy encfs bianry to /system/bin #
# 6. set chmod +x permissions on all 3 files #
# #
# 7. encrypt internal storage (from settings) and save encfs password: #
# echo <your_password> | tee /data/local/pswd #
# 8. run this as root to mount encrypted directory: #
# /system/bin/encfs -o allow_other,umask=0 /mnt/media_rw/sdcard0/.encfs /data/local/SDCardTemp #
# copy all data on internal storage (/data/media/0/) to /data/local/SDCardTemp #
# reboot #
#####################################################################################################
export PATH=/system/bin:/system/xbin
# save log
mkdir -p /data/local/tmp
exec &>/data/local/tmp/encfs.log
date
echo "sdcard $*"
# mount encfs if not mounted already
if ! mountpoint /storage/sdcard0
then
cat /data/local/pswd | encfs -S /mnt/media_rw/sdcard0/.encfs /storage/sdcard0 -- -o allow_other,umask=0
# or may use uid=0,gid=1028,umask=006
fi
# pass original init command to sdcard daemon
sdcard_orig "[email protected]"
Android 5.0:
Code:
#!/system/bin/sh
# add following lines to boot.img > ramdisk > init.qcom.rc before sdcard service:
## service encfs /system/bin/encfs.sh
## oneshot
## class late_start
# save this script as /system/bin/encfs.sh
# copy encfs bianry to /system/bin
# chmod a+x /system/bin/encfs*
# echo <password> | tee /data/local/pswd
# /system/bin/encfs -o allow_other,umask=0 /data/media/encfs_crypted /data/local/SDCardTemp
# rsync -a --progress --exclude=encfs_crypted /data/media/ /data/local/SDCardTemp/
export PATH=/system/bin
# wait to avoid "PROTO_EXEC|PROTO_WRITE failed" error
sleep 5
# save log
exec &>/data/local/encfs.log
date
# mount encfs
exec cat /data/local/pswd | encfs -S /data/media_encfs_crypted /data/media -- -o uid=1023,gid=1023,umask=006,allow_other,nonempty &&
echo Mounted.
Mount options "nosuid" and "nodev" are set by default as a security measure. Mostly applications making use of FUSE (in kernel space) and optionally libfuse (in userspace) also set (or give a commandline parameters to set) "allow_other" and "default_permissions" options by default.
UMASK, UID, GID, ALLOW_OTHER
"umask" (or "dmask" and "fmask") needs to be provided explicitly to make files world accessible. Default mode set by "encfs" is 0600 (umask=177) and only mount owner (root) can access files unless every newly created file is manually chmod-ed.
Similarly, "uid" and "gid" options are needed to set desired owner/group. Default owner:group is the mount owner (0:0) unless every newly created file is manually chown-ed.
Actually mount owner and files/directories owner can be different, which was the source of my confusion. That's how FUSE is implemented to let non-privileged mounts work. Have a look at this:
user_id=N
group_id=N Specifies the numeric uid/gid of the mount owner.
This option should not be specified by the filesystem owner. It is set by libfuse (or, if libfuse is not used, must be set by the filesystem itself).
. . .
uid=N
Override the st_uid field set by the filesystem (N is numeric).
Click to expand...
Click to collapse
Since all "init" processes (including "sdcard" daemon) run as root (uid=0 and gid=0), 'mount' command always show "user_id=0" and "group_id=0". However it should be noted that provided "uid" and "gid" appear when we view files' ownership:
Code:
[B]/~#[/B] encfs -o allow_other,[COLOR="Red"]umask=7,uid=1023,gid=0[/COLOR] /.enc /enc
EncFS Password:
[B]/~#[/B] mount | grep enc
encfs on /encfs type fuse.encfs (rw,nosuid,nodev,relatime,[COLOR="red"]user_id=0,group_id=0[/COLOR],default_permissions,allow_other)
[B]/~#[/B] touch /enc/test
[B]/~#[/B] ls -l /.enc /enc
/.enc:
[COLOR="red"]-rw-rw-rw-[/COLOR] 1 [COLOR="Red"]0 0[/COLOR] 0 Mar 3 17:58 CoXOLL0fc0RaxZjq2HaSj9en
/enc:
[COLOR="YellowGreen"]-rwxrwx---[/COLOR] 1 [COLOR="YellowGreen"]1023 0[/COLOR] 0 Mar 3 17:58 test
[B]/~#[/B] chmod 0777 /enc/test
[B]/~#[/B] chown 0:1023 /enc/test
[B]/~#[/B] ls -l /.enc /enc
/.enc:
[COLOR="red"]-rwxrwxrwx[/COLOR] 1 [COLOR="red"]0 1023[/COLOR] 0 Mar 3 17:58 CoXOLL0fc0RaxZjq2HaSj9en
/enc:
[COLOR="YellowGreen"]-rwxrwx---[/COLOR] 1 [COLOR="YellowGreen"]1023 0[/COLOR] 0 Mar 3 17:58 test
[B]/~#[/B]
Setting "uid"/"gid" isn't necessarily required if universal access is granted using "umask=0" and "allow_other" mount options. Since every app is treated as a user on Android, so even the file explorer (same user who mounted filesystem by getting root privileges) can't access EncFS mounted directory without "allow_other" (if not running as root). So "allow_other" is necessarily required.
Mounting with "gid=9997,dmask=0007,fmask=0117,allow_other" at "/mnt/runtime/write/emulated/0/<mount_point>" on Android 6+ grants write access to apps with android.permission.WRITE_EXTERNAL_STORAGE granted. See this answer for details.
MOUNT OWNER
On Linux non-root users who are member of "fuse" group can mount and un-mount FUSE filesystems using "fusermount(3)" which is always run as root by set-UID-root or "setcap cap_sys_admin+ep". "fuse" group is the GID of "/dev/fuse". But non-privileged users can't set "allow_other" unless "user_allow_other" is set in FUSE configuration file /etc/fuse.conf. "/etc/fuse.conf" is used by "libfuse", and hence by all program depending on or linked to this library like "bindfs", "encfs", "sshfs", "rclone" and so on. So a non-root user can be the mount owner but other users (including root) can't access the mounted filesystem.
However on Android non-privileged user can't (u)mount FUSE filesystem because:
FUSE support is fully enabled from kernel side (on Linux it's usually a loadable module), can be checked by:
Code:
grep -E 'fuse|fuseblk' /proc/filesystems
But there are limitations in userspace.
There's no "fusermount" binary available on Android and the libfuse implementation doesn't use FUSE configuration because it's meant only for root users. But if we try to use binaries statically linked to standard Linux "libfuse" (like EncFS), they do read "/etc/fuse.conf" and may depend on "fusermount".
Apps on Android are run with all privileges dropped, so they can't make "mount" syscall even if "fusermount" is present with SUID bit set.
"/dev/fuse" is readable and writable only by root (0600, 0:0).
Non-root users on Android may face problem accessing filesystems (e.g. executing EncFS binary and reading "/dev/fuse") due to DAC or MAC permission checks. SELinux might need to be set "permissive" for the same reason, or the policy needs to be patched. SELinux also restricts Linux capabilities of processes.
So in short, EncFS and all other programs that make use of FUSE, can only be mounted by root on Android.
MOUNT NAMESPACE
Next important thing to be considered is "mount namespace" where even "allow_other" and root access won't help you. Mount namespaces enable apps to be exposed to an individual view of mounted filesystems. It means that "/proc/mounts" (which actually is "/proc/self/mounts") may look different to different processes. FUSE was implemented since KitKat to impose permissions derived from directory structure by emulating internal and/or external SD cards instead of direct mounting them. Mount namespaces are implemented since Marshmallow to serve the purpose of apps isolation in better way enforced by "zygote" at runtime. On rooted devices when an app requests a root shell, SU manager starts the shell in a new isolated namespace. While FUSE is implemented through UID's, namespaces are implemented through PID's. Super user rights with namespace separation are granted through
Code:
unshare -m sh
i.e. providing the app (process id) an independent view of mount points, not visible to the rest of apps.
Namespaces only affect (1) emulated SD card mounts handled by zygote or (2) any other filesystem mounted from a shell which was initiated by SuperSU with mount NS separation. All root processes started by Android ("init" on boot) run in global namespace. For example all mounts from adb shell will have no namespace separation because "adbd" is run in global namespace. Similarly, all shared mounts done at boot by init are propagated as a single unit from default/global/root namespace to all new zygote-forked per process namespaces. If we un-mount a filesystem from an app with root access, it will not affect the system and other apps. However if mount namespace separation is disabled, un-mounting a filesystem from any app will un-mount it globally. So isolated namespace feature provided by SU solutions is a security measure.
Say, you execute the following command from Termux (or any other terminal emulator app):
Code:
/system/bin/encfs -o allow_other /data/media/0/.encfs /data/media/0/encfs
Now, if mount namespace separation is enabled (by default), you will be able to open /data/media/0/encfs only from Termux app and from no other file explorer etc. For any other app, EncFS is not mounted at all. However Android su binaries provide a mount master option to always mount in global namespace:
Code:
[COLOR="Red"][B]su -mm[/B][/COLOR] /system/bin/encfs -o allow_other /data/media/0/.encfs /data/media/0/encfs
nsenter command can also be used to enter an existing isolated mount namespace. But note that namespaces are killed as soon as they have zero process running.
Other option is to disable "Mount Namespace Separation" in SuperSU app settings. However, do not disable this if you want to use apps like Titanium Backup or "Hide Root" feature as in Magisk etc. In addition to Isolated and Global, Magisk also provides a third option: Inherited i.e. run the root shell in same isolated namespace in which app is already running.
Related: Partition gets unmounted automatically in Android Oreo
DROP DAEMON PRIVILEGES
What I quoted earlier:
#daemon will drop to user/group system/media_rw after initializing
Click to expand...
Click to collapse
This "drop daemon privilege" thing is specific for "sdcard" daemon only as stated here and neither true for FUSE in general, nor related to filesystem "user_id" or "uid" options:
It must be run as root, but will drop to requested UID/GID as soon as it mounts a filesystem.
Click to expand...
Click to collapse
Code:
snprintf(opts, sizeof(opts),
"fd=%i,rootmode=40000,default_permissions,allow_other,user_id=%d,group_id=%d",
fd, uid, gid);
res = mount("/dev/fuse", dest_path, "fuse", MS_NOSUID | MS_NODEV, opts);
if (res < 0) {
ERROR("cannot mount fuse filesystem: %s\n", strerror(errno));
goto error;
}
/* Drop privs */
res = setgroups(sizeof(kGroups) / sizeof(kGroups[0]), kGroups);
if (res < 0) {
ERROR("cannot setgroups: %s\n", strerror(errno));
goto error;
}
res = setgid(gid);
if (res < 0) {
ERROR("cannot setgid: %s\n", strerror(errno));
goto error;
}
res = setuid(uid);
if (res < 0) {
ERROR("cannot setuid: %s\n", strerror(errno));
goto error;
}
fuse_init(&fuse, fd, source_path, write_gid, derive, split_perms);
umask(0);
res = ignite_fuse(&fuse, num_threads);
/* we do not attempt to umount the file system here because we are no longer
* running as the root user */
Process should call "setuid" itself to drop/elevate privileges which isn't the case for EncFS/FUSE by default. We can't use "su" or "setuidgid" or "chpst" commands to drop privileges later on but this isn't needed either as explained earlier. Only "uid=" and "gid=" options are enough.
Same source code file also explains somewhat how "legacy" and "derived permissions" work particularly on Android 4.4, 5 and 6 using FUSE filesystems for emulating SD card.
SUMMARY
On Android, only root can mount EncFS (FUSE) filesystem
Do mention "allow_other" option if you want to access EncFS mounted directory from a non-root app
Do mention "umask=" option if you want to read/write encrypted files from a non-root app
"uid" and "gid" need to be set if you want to give some specific non-root app write access to the filesystem. Otherwise "allow_other" and "umask" can suffice.
Disable "Mount Namespace Separation" option in SuperSU app if:
EncFS is to be mounted feom CLI (Terminal Emulator) app and not by some boot script or from adb shell, and
You want to access EncFS mounted directory from some app other than the root shell in CLI app
bastei said:
Development of Cryptonite seems quite inactive unfortunately. But there is a fork that seems to have some fixes for building, a build script and build instructions.
Click to expand...
Click to collapse
Latest EncFS binary is available here. Thanks to @DualJoe. It works with Android Oreo as well. However, overlapping with already mounted FUSE or sdcardfs (a FUSE-like filesystem implemented in Android 8+ that works in kernel space) should be avoided.
This is my understanding of EncFS and FUSE. Correct me if I'm wrong.
You could use /mnt/encfs. I think it might not be affected by namespace isolation.
DualJoe said:
You could use /mnt/encfs. I think it might not be affected by namespace isolation.
Click to expand...
Click to collapse
It didn't work for me. What I have understood is that mount namespace isolation implemented by SuperSU app is totally independent of that implemented by AOSP on emulated storage. SuperSU grants root access on the basis of app, not path. When an app requests root rights from SuperSU, a new namespace is created in which all global mounts are cloned. Now it's up to that app what it does with the mountpoints, not affecting any other process. So the path where filesystem is mounted doesn't matter. Also whatever location we choose, mount call won't be successful without root. I have added a few lines about this in my previous post.
Are you sure you're invoking 'mount' with 'su -mm'?
I can only speak for my system (LOS13, Magisk) but i can mount cifs or ecryptfs on any place (/data/media/0, /mnt/*) without problems. Magisk is still set to default namespace option (inherited). The '-mm' switch is always 'global namespace' though as it's primarily intended for public mounting (as described in 'su --help').
DualJoe said:
Are you sure you're invoking 'mount' with 'su -mm'?
I can only speak for my system (LOS13, Magisk) but i can mount cifs or ecryptfs on any place (/data/media/0, /mnt/*) without problems. Magisk is still set to default namespace option (inherited). The '-mm' switch is always 'global namespace' though as it's primarily intended for public mounting (as described in 'su --help').
Click to expand...
Click to collapse
Yes definitely 'su -mm' mounts in global namespace. I was talking about simple mount command from a su shell, without '-mm'.
After putting password in terminal after encfs command, does nothing. Means decrypted directory always remain empty. any idea how to resolve this ? Android 13
Edit1: now this working but new issue came which ia mentioned in next post.
{
"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"
}
i using below command:
su -mm -c "encfs --public -o nonempty,allow_other,rw,noatime,noexec,nodev,nosuid,gid=9997,umask=006 -S /mnt/runtime/write/3B86-9400/.encrypted /mnt/runtime/write/emulated/0/decrypted"
I can see content in the file manager only but not gallery.
After Android media store refresh only content of decrypted folder showing in gallery but content of sub folder of decrypted folder is not showing in the gallery.
Any idea how to resolve this issue.
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 ??