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.
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?
CleverCoder's Guide to Mounting Android’s Internal Storage As A Mass Storage USB Device
I found inspiration from this guide: http://mohammadag.xceleo.org/mounting-your-android-devices-internal-storage/
His process did not work exactly, but by changing the “lun” to “lun0” and the path to the “android_usb” device, I was able to get this to work with my rooted Samsung Note 10.1. The instructions below were verified on my Note 2.
I was motivated to find this solution after I accidentally deleted my daughters world that she worked so hard to create in Survivalcraft. Ultimately, I wasn’t able to recover her world, but I learned a lot in the process. Enjoy!
Steps:
Boot into recovery mode (Usually holding volume (and home) down while powering up). I find the Wiki on CyanogenMod to be helpful to find device-specific bootloader instructions.
Invoke a root shell using ADB: “adb shell" (Note: This assumes you have the Android SDK installed and /platform-tools are in your PATH)
Find the /data partition, determine the block device that corresponds to it:
Code:
mount | grep /data
…
/dev/block/mmcblk0p16 on /data type ext4 (rw,seclabel,relatime,user_xattr,barrier=1,data=ordered)
…
Click to expand...
Click to collapse
Make a note of the block device name. In my case, it's "/dev/block/mmcblk0p16". Unmount the /data partition to allow mounting as a mass storage device:
Code:
umount /data
Locate the “mass storage” device LUN entry. (In my case, it was ..\lun0 rather than ..\lun):
Code:
find /sys -name lun*
…
/sys/devices/platform/s3c-usbgadget/gadget/lun0
/sys/devices/virtual/android_usb/android0/f_mass_storage/lun0
…
Click to expand...
Click to collapse
In this case, we want to make a note of the entry with "f_mass_storage" in it. This is the entry that corresponds to a USB Mass Storage device.
Map the block device to the mass storage logical device LUN “file”. Note, this will be a file called “file” within the LUN folder. For example:
"/sys/devices/virtual/android_usb/android0/f_mass_storage/lun/file":
~# echo BLOCK_DEVICE_HERE > LUN_FILE_PATH_HERE
For example:
Code:
echo /dev/block/mmcblk0p16 > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun0/file
Note: the ADB shell appears to wrap at around 80 characters, making it look like the line is split.
Reconfigure the USB device in “mass storage” mode. This has to be done in one command, since it will terminate the ADB connection. Also, the path varies to the “android_usb” device. It may be:
/sys/devices/virtual/android_usb/android0/
/sys/class/android_usb/android0/
You can use "find /sys -name *android0*" to help narrow the options. I believe either entry will work. YMMV
On my Note 2 the following worked:
Code:
echo "echo 0 > /sys/devices/virtual/android_usb/android0/enable && echo \"mass_storage,adb\" > /sys/devices/virtual/android_usb/android0/functions && echo 1 > /sys/devices/virtual/android_usb/android0/enable" > enable_mass.sh
sh enable_mass.sh &
This should terminate the ADB connection and cause a new USB device to appear, representing the /data volume mounted as a mass storage device.
At this time, the block device associated with the /data partition should show up as a USB mass storage device on your computer. I verified this with OSX. OSX did not support the ext3/4 filesystem, however, Unix utilities that support it will work.
Recovering Files
Once the device is mounted on your host machine, you can use PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec) to recover files. It performs a file signature based recovery, is very powerful, and works with any file you can think of. It’s also easy to add support for your own file types.
I hope this helps others.
Cheers!
- Sean
Have anyone tried it?
Failed while do the step with the lun0/file.
Permission denied
Quite interesting :good: and works as expected with lun/file
Thanks for this amazing post
great
command done for E300K over Wifi adb
while system running normally
working great thanks
Code:
echo /dev/block/mmcblk0p20 > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun0/file
echo 0 > /sys/devices/virtual/android_usb/android0/enable
echo "mass_storage,adb" > /sys/devices/virtual/android_usb/android0/functions
echo 1 > /sys/devices/virtual/android_usb/android0/enable
---------- Post added at 05:10 AM ---------- Previous post was at 05:08 AM ----------
wondering how we could mount many partition at the same time
will see
Edit : seems to be related to the module that provide mass storage gadget, it's set to 1 emulation for the moment... i think i have to recompile that stuff and/or the kernel to have this feature... any way not for now ^^
Note : an alternative to check deleted files is R-Studio work well
Some Hint Please?
CleverCoder said:
CleverCoder's Guide to Mounting Android’s Internal Storage As A Mass Storage USB Device
I found inspiration from this guide: http://mohammadag.xceleo.org/mounting-your-android-devices-internal-storage/
His process did not work exactly, but by changing the “lun” to “lun0” and the path to the “android_usb” device, I was able to get this to work with my rooted Samsung Note 10.1. The instructions below were verified on my Note 2.
I was motivated to find this solution after I accidentally deleted my daughters world that she worked so hard to create in Survivalcraft. Ultimately, I wasn’t able to recover her world, but I learned a lot in the process. Enjoy!
Steps:
Boot into recovery mode (Usually holding volume (and home) down while powering up). I find the Wiki on CyanogenMod to be helpful to find device-specific bootloader instructions.
Invoke a root shell using ADB: “adb shell" (Note: This assumes you have the Android SDK installed and /platform-tools are in your PATH)
Find the /data partition, determine the block device that corresponds to it:
Code:
mount | grep /data
Make a note of the block device name. In my case, it's "/dev/block/mmcblk0p16". Unmount the /data partition to allow mounting as a mass storage device:
Code:
umount /data
Locate the “mass storage” device LUN entry. (In my case, it was ..\lun0 rather than ..\lun):
Code:
find /sys -name lun*
In this case, we want to make a note of the entry with "f_mass_storage" in it. This is the entry that corresponds to a USB Mass Storage device.
Map the block device to the mass storage logical device LUN “file”. Note, this will be a file called “file” within the LUN folder. For example:
"/sys/devices/virtual/android_usb/android0/f_mass_storage/lun/file":
~# echo BLOCK_DEVICE_HERE > LUN_FILE_PATH_HERE
For example:
Code:
echo /dev/block/mmcblk0p16 > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun0/file
Note: the ADB shell appears to wrap at around 80 characters, making it look like the line is split.
Reconfigure the USB device in “mass storage” mode. This has to be done in one command, since it will terminate the ADB connection. Also, the path varies to the “android_usb” device. It may be:
/sys/devices/virtual/android_usb/android0/
/sys/class/android_usb/android0/
You can use "find /sys -name *android0*" to help narrow the options. I believe either entry will work. YMMV
On my Note 2 the following worked:
Code:
echo "echo 0 > /sys/devices/virtual/android_usb/android0/enable && echo \"mass_storage,adb\" > /sys/devices/virtual/android_usb/android0/functions && echo 1 > /sys/devices/virtual/android_usb/android0/enable" > enable_mass.sh
sh enable_mass.sh &
This should terminate the ADB connection and cause a new USB device to appear, representing the /data volume mounted as a mass storage device.
At this time, the block device associated with the /data partition should show up as a USB mass storage device on your computer. I verified this with OSX. OSX did not support the ext3/4 filesystem, however, Unix utilities that support it will work.
Recovering Files
Once the device is mounted on your host machine, you can use PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec) to recover files. It performs a file signature based recovery, is very powerful, and works with any file you can think of. It’s also easy to add support for your own file types.
I hope this helps others.
Cheers!
- Sean
Click to expand...
Click to collapse
Hello sir, I want to ask you.
What recovery version do you use? Philz Touch? TWRP or another? can you please help me.? I am using Galaxy Note II device (GT-N7100)
When I am using TWRP recovery I can do all steps you provide but no luck. Then I am try using Philz Touch, adb shell is error, Device Not Found.
What can I do? Can you please help me? :good:
I need to recover some photos that I accidentally deleted.
Hi Sean,
This is a great idea!!! I've been struggling for the past two weeks to recover data from my HTC One M7 ever since I accidentally hit the factory reset button!:crying:
I got a few questions...
Does this method work on my M7 which has only the internal memory and no SD card?
IIf I'm trying this directly on a terminal window on he phone, how would the last command change?
Also, once done, how do we mount /data back?
Sorry for the noob questions!
Thanks a lot!
No response from HTC One M7
Hello Experts,
I tried the above mentioned method on my HTC One M7. It was lun0 in my case. I have unmounted /data. However, I still found that mmcblkp037 that was mounted on /data was still linked to /sdcard for some reason. I proceeded to unmount /sdcard too. (There is no SD card in my device btw).
After unmounting both /data and /sdcard, I proceeded to edit the lun0/file and then the long command all in one go. Unfortunately nothing happens, the adb shell remains active and I do not see a USB device appearing on My Computer. I've added the snapshots from the terminal window.
Can someone please help?:crying:
Thanks!!!
So i am trying to run this so that i can do a photo recovery on the internal storage. At first i wasn't getting the list of mmcblk0p and what they were assigned to. I found a different command that I think returns the correct information ( mmcblk0p26) when i make it to the end, it mounts it on my pc as the cd rom drive, but i cant do anything with it and it doesnt show up in my recovery program. I ran the command again and i got ( mmcblk0p26-orig) but again at the end, i still only have the cd rom that it mounts. im not sure if im not pointing to the correct mmcblk or what im missing. Any help is appreciated.
anyone?
Issues with step 4 umount
Hi together,
I have issues by proceeding step 4. "umount /data" it all the times says: "umount: bad /etc/fstab: No such file or directory"
I tried so many things to solve it.
Could you please help me?
I am unable to switch to mass_storage on my Moto G 2013.
I tried with DriveDriod Android App and it successfully enabled mass_storage but I am unable toreplicate the same manually.
This is what I tried:
[email protected]:/sdcard # find /sys -name lun*
/sys/devices/virtual/android_usb/android0/f_mass_storage/lun
/sys/devices/platform/msm_hsusb/gadget/lun0
[email protected]:/sdcard #
[email protected]:/sdcard # mount | grep /data
/dev/block/mmcblk0p36 on /data type f2fs (rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,user_xattr,inline_xattr,acl,inline_data,nobarrier,active_logs=6)
[email protected]:/sdcard #
[email protected]:/sdcard # echo "/dev/block/mmcblk0p36" > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun/file
[email protected]:/sdcard #
[email protected]:/sdcard # setprop sys.usb.config mass_storage,adb
Click to expand...
Click to collapse
No luck in mounting the partition as UMS.
Please Help.
Thanks.
@CleverCoder im trying this on a OneplusX but it ends up showing as unallocated space in gparted. Any clue?
All worked fine with a bq aquaris a4.5.
~#: umount /data
umount: can't umount /data: Invalid argument
Click to expand...
Click to collapse
Why can't I unmount the /data partition?
Any hints please?
Useful guide. Thanks. :good:
Additionally, you may look into kernel source of your device or simply into these USB related initramfs files for further details what you need to edit on your device:
/init.qcom.usb.rc
/init.usb.rc
/init.recovery.usb.rc (on TWRP)
Click to expand...
Click to collapse
You can find in these files the USB vendor id and product id values provided by your device manufacturer or Google. These values should be fed to corresponding files so that PC may properly identify your phone as a USB mass storage device. In given example, 2717 is USB Vendor ID of Xiaomi; manufacturer of Redmi Note 4.
Sample init.qcom.usb.rc (RN4/mido):
Code:
# Following are the parameters required for usb functionality. They provide configurable options like
# product_id/vendor id and allows specifying required functions:
#
# Required parameters:
#
# /sys/class/android_usb/android0/enable: Enables/disables usb composition
# Value: 0 (disable), 1 (enable)
[...]
# /sys/class/android_usb/android0/functions: Stores name of the function drivers used in usb composition.
# Value: Passed one per function driver. e.g. diag[,adb]
[...]
on property:sys.usb.config=mass_storage,adb && property:sys.usb.configfs=0
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/iSerial ${ro.serialno}
write /sys/class/android_usb/android0/idVendor 2717
write /sys/class/android_usb/android0/idProduct FF28
write /sys/class/android_usb/android0/functions adb,mass_storage
write /sys/class/android_usb/android0/enable 1
start adbd
setprop sys.usb.state ${sys.usb.config}
#Mass-storage only composition
on property:sys.usb.config=mass_storage && property:sys.usb.configfs=0
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/iSerial ${ro.serialno}
write /sys/class/android_usb/android0/idVendor 2717
write /sys/class/android_usb/android0/idProduct FF20
write /sys/class/android_usb/android0/functions mass_storage
write /sys/class/android_usb/android0/enable 1
setprop sys.usb.state ${sys.usb.config}
A good source is https://android.googlesource.com/kernel/common/+/bcmdhd-3.10/Documentation/usb/mass-storage.txt
Code:
[B]mido:/ #[/B] (find / -maxdepth 1 -type f) | while read fyle; do grep -iE "/sys.{,}lun" "$fyle" && printf ">>> $fyle\n\n"; done
/sys/class/android_usb/android0/f_mass_storage/lun/file
/sys/class/android_usb/android0/f_mass_storage/lun/file
>>> /init.usb.rc
[...]
[B]mido:/ #[/B] find /sys -iname lun*
/sys/devices/soc/7000000.ssusb/7000000.dwc3/gadget/lun0
/sys/devices/virtual/android_usb/android0/f_mass_storage/lun
[...]
[B]mido:/ #[/B] file /sys/class/android_usb/android0/f_mass_storage/lun
/sys/class/android_usb/android0/f_mass_storage/lun: symbolic link to ../../../../soc/7000000.ssusb/7000000.dwc3/gadget/lun0
[B]mido:/ #[/B] file /sys/class/android_usb/f_mass_storage/lun
/sys/class/android_usb/f_mass_storage/lun: symbolic link to ../../../../soc/7000000.ssusb/7000000.dwc3/gadget/lun0
[B]mido:/ #[/B] file /sys/devices/virtual/android_usb/android0/f_mass_storage/lun
/sys/devices/virtual/android_usb/android0/f_mass_storage/lun: symbolic link to ../../../../soc/7000000.ssusb/7000000.dwc3/gadget/lun0
[B]mido:/ #[/B] file /sys/class/android_usb/android0
/sys/class/android_usb/android0: symbolic link to ../../devices/virtual/android_usb/android0
So, the original files to modify are:
/sys/devices/soc/7000000.ssusb/7000000.dwc3/gadget/lun0
and
/sys/devices/virtual/android_usb/android0
Click to expand...
Click to collapse
All others are symlinks. Check your devices accordingly.
Simply use these files:
Code:
echo '0' > /sys/class/android_usb/android0/enable
echo '/dev/block/mmcblk0p**' > /sys/class/android_usb/android0/f_mass_storage/lun/file; # replace ** with partition number
echo 'mass_storage,adb' > /sys/class/android_usb/android0/functions
If your /data partition is encrypted and TWRP can decrypt it, you should use:
Code:
echo '/dev/block/dm-0' > /sys/class/android_usb/android0/f_mass_storage/lun/file
Additional settings:
Code:
setprop persist.sys.usb.config mass_storage,adb
setprop sys.usb.config mass_storage,adb; # disabling mtp will probably cause adb unauthorized
If you want to mount /data read-only, being on safe side or to avoid overwrite if want to recover deleted stuff:
Code:
echo '1' > /sys/class/android_usb/android0/f_mass_storage/lun/ro
And finally:
Code:
echo '1' > /sys/class/android_usb/android0/enable
Don't try this in running ROM, it's only for recovery mode.
Don't forget to unmount /data from your computer before disconnecting. Otherwise eMMC may get corrupted.
You can mount other partitions having a filesystem (like /system or /cache) in similar way, but that's rarely needed.
Can you tell me how to disable mass_storage again? revert everything back?
osrl said:
Can you tell me how to disable mass_storage again? revert everything back?
Click to expand...
Click to collapse
"sysfs" is a volatile filesystem. Everything is reset on reboot. Or you may revert changes manually:
Code:
echo 0 >/sys/class/android_usb/android0/enable
echo "" >/sys/class/android_usb/android0/f_mass_storage/lun/file
setprop persist.sys.usb.config adb
setprop sys.usb.config adb
echo 1 >/sys/class/android_usb/android0/enable
honor 9 error lun
Hello, On my Honor 9 I'm trying to do the same but I'm stuck on
find /sys -name lun*
Click to expand...
Click to collapse
because this command gives no lines found, it seems that I don't have any directory with "lun" written in it, so I'm unable to continue the tutorial, what am I doing wrong?
eyewee said:
honor 9 error lun
Hello, On my Honor 9 I'm trying to do the same but I'm stuck on
because this command gives no lines found, it seems that I don't have any directory with "lun" written in it, so I'm unable to continue the tutorial, what am I doing wrong?
Click to expand...
Click to collapse
i met this same problem. My phone is OPPO R15x PBCM.
i have ever installed an apk named UMS interface which can be downloaded from coolapk and found its code in github . this apk can allow root user create an image in their sdcard and mount it as a usb device or mount an external sd card as a usb device. the latter is like ums enabler .
it work normally, until i reinstalled OS of my phone. then it always return Mass storage Unit is not ready. i take a glance at the code of the apk, and found this warning exist only when /sys/devices/virtual/android_usb/android0/f_mass_storage/lun doesn't exist. exactly, /sys/devices/virtual/android_usb/android0/f_mass_storage/ doesn't exist. when i ls /sys/devices/virtual/android_usb/android0, it only return f_audio_source f_midi power state subsystem uevent, not
Code:
f_mass_storage
. no matter i reinstalled OS for many times, nothing become normal.
Code:
grep f_mass_storage /init.usb.rc
will return
Code:
chown system system /sys/class/android_usb/android0/f_mass_storage/lun/file
chmod 0660 /sys/class/android_usb/android0/f_mass_storage/lun/file
, but i don't know its meaning. i don't have enough knowledge about android.
thanks anyone for help!
UPDATE: Changed the Topic as we are getting away from the original question in post 1 to the actual problem: figuring out how to fully root an Onyx Boox Poke3 e-reader running Android 10. "Fully" meaning including full r/w access to /system and /vendor - which isn't straight forward at the moment with "only" magisk-patching the stock boot.img
----------------------
Hi all,
possibly (probably) a "2^32 FAQ" but I can't g**gle it - everything search more or less leads to "how to patch boot img with magisk and flash it (in fastboot or twrp)".
So: Is there a tool (either on android or linux) to apply zips just like in twrp to a "boot.img" or "system.img" file, one after the other?
Why? I have a device for which there's no twrp (yet.... might look into that some day).
I have magisk-rooted it by patching the stock boot.img and then flashing that via fastboot. Rooted yes, Magisk yes, but still a "user-build" / "dm-verity" protected system, so tweaks modifying anything on /system or /vendor permanently aren't successful.
I guess there's a dozen solutions, but I just can't g**gle any (my g**gle foo isn't good enough...)
Anyone?
Disable dm-verity with adb.
You can modify build.prop and change ro.secure to 0 to get adb root.
Then disable dm-verity after that
I don't get to disable dm-verity, even with adb root (which I installed as a magisk module). Its a "user" build. Or - despite hours of reading and trying - I didn't find the right way to do it (or didn't understand). Or would it be as simple as using Android Image Kitchen to unpack (the patched boot.img), tweak build.prop, repack, re-flash? Now that I think of it...!?
But there's another odd thing here. Magisk App says I don't have a ramdisk. As I don't have the stock "recovery image" (and because I didn't really pay attention to this but followed in the steps of someone with a similar device) I patched the stock boot.img - where really I should have patched recovery.img. However, device behaves fine with the patched boot.img. If I then dd the /recovery partition, I do find ".magisk" stuff in the "ramdisk" folder. Also, in the initial magisk patching log when patching the boot.img, it says:
Code:
....
- Checking ramdisk status
- Stock boot image detected
- Patching ramdisk
Add entry [init] (0750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add entry [overlay.d/sbin/magisk32.xz] (0644)
Add entry [overlay.d/sbin/magisk64.xz] (0644)
Patch with flag KEEPVERITY=[true] KEEPFORCEENCRYPT=[true]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
....
SO, even though the device seems to have no ramdisk in stock boot.img (?) magisk patched it, and the device still runs from it....
Also, could I force magisk to set keepverity=false? In the app, there's no related tickbox available.
Will make all this into a proper howto in the end... a mess at the moment
If phone's bootloader is unlocked then you can disable AVB by means of Fastboot:
Code:
adb devices
adb reboot fastboot
fastboot reboot fastboot 2>nul
fastboot --disable-verification --disable-verity flash vbmeta vbmeta.img
fastboot reboot
@jwoegerbauer and @Kenora_I thanks for your responses.
Not sure if I'm on the right track here. I did a "dd" (from within the magisk rooted system via adb, dumping /dev/block/mmcblk0p46) to get the current (stock) vbmeta partition as a vbmeta.img to see what's in there "in stock state". avbtool.py says it doesn't look like vbmeta stuff, and I think it is right after looking at it with a hex editor: it's all zeroes. So, the information to protect /system and /vendor apparently does not come from vbmeta.
I had a look at the stock fimware update zip, unpacked it with superR's kitchen. In /vendor I have build.prop, but that does NOT contain "secure" at all. There is also a file default.prop, but can't see anything related to dm-verity in there, either.
Code:
#
# ADDITIONAL VENDOR DEFAULT PROPERTIES
#
ro.vndk.version=29
ro.adb.secure=1
ro.oem_unlock_supported=1
ro.zygote=zygote64_32
ro.logd.size.stats=64K
log.tag.stats_log=I
ro.logdumpd.enabled=0
ro.bionic.arch=arm64
ro.bionic.cpu_variant=generic
ro.bionic.2nd_arch=arm
ro.bionic.2nd_cpu_variant=cortex-a73
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.arm64.variant=generic
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.variant=cortex-a73
dalvik.vm.isa.arm.features=default
And then there is /vendor/etc/fstab - but it doesn't even list anything that would mount /vendor, only some sub-dirs mounted below that. It only contains "ro" for "/" - should I simply replace that with "rw", re-pack that stock vendor.img and flash it maybe!? With all that AVB/dm-verity stuff around it seems to simple - or not!?
Spoiler: /vendor/etc/fstab
Code:
# Non-A/B fstab.qcom variant
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,noatime,lazytime wait,check,forceencrypt=footer,crashcheck,quota,reservedsize=128M
/devices/soc/c084000.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /vendor/bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto* /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto
/dev/block/bootdevice/by-name/dsp /vendor/dsp ext4 ro,nosuid,nodev,barrier=1 wait
/dev/block/bootdevice/by-name/cache /cache ext4 nosuid,nodev,noatime,barrier=1 wait
/dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,barrier=1 wait
#/dev/block/bootdevice/by-name/onyxconfig /onyxconfig ext4 defaults defaults
Edit: device tree might be the keyword:
On pre-Oreo releases fstab was in ramdisk. With Treble it was moved to /vendor (or /system/vendor) while the fstab entries for system and vendor (and odm) are moved to Device Tree Blob (dtb). Kernel exports dtb fstab entries in device tree directory at /proc/device-tree/firmware/android
Click to expand...
Click to collapse
From: https://android.stackexchange.com/q...ty-on-android-with-user-build-type-rom/215907
Edit2:
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags lists "wait,verify"
/proc/device-tree/firmware/android/fstab/vendor/mnt_flags lists "ro,barrier=1,discard"
SO... seems I have to patch the dtb. Tomorrow maybe...
ro.adb.secure=1
This should be 0 if you want adb root command to function properly.
It shouldnt say adbd cannot run in production builds anymore.
PokeRekoP said:
@jwoegerbauer and @Kenora_I thanks for your responses.
Not sure if I'm on the right track here. I did a "dd" (from within the magisk rooted system via adb, dumping /dev/block/mmcblk0p46) to get the current (stock) vbmeta partition as a vbmeta.img to see what's in there "in stock state". avbtool.py says it doesn't look like vbmeta stuff, and I think it is right after looking at it with a hex editor: it's all zeroes. So, the information to protect /system and /vendor apparently does not come from vbmeta.
I had a look at the stock fimware update zip, unpacked it with superR's kitchen. In /vendor I have build.prop, but that does NOT contain "secure" at all. There is also a file default.prop, but can't see anything related to dm-verity in there, either.
Code:
#
# ADDITIONAL VENDOR DEFAULT PROPERTIES
#
ro.vndk.version=29
ro.adb.secure=1
ro.oem_unlock_supported=1
ro.zygote=zygote64_32
ro.logd.size.stats=64K
log.tag.stats_log=I
ro.logdumpd.enabled=0
ro.bionic.arch=arm64
ro.bionic.cpu_variant=generic
ro.bionic.2nd_arch=arm
ro.bionic.2nd_cpu_variant=cortex-a73
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.arm64.variant=generic
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.variant=cortex-a73
dalvik.vm.isa.arm.features=default
And then there is /vendor/etc/fstab - but it doesn't even list anything that would mount /vendor, only some sub-dirs mounted below that. It only contains "ro" for "/" - should I simply replace that with "rw", re-pack that stock vendor.img and flash it maybe!? With all that AVB/dm-verity stuff around it seems to simple - or not!?
Spoiler: /vendor/etc/fstab
Code:
# Non-A/B fstab.qcom variant
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,noatime,lazytime wait,check,forceencrypt=footer,crashcheck,quota,reservedsize=128M
/devices/soc/c084000.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /vendor/bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto* /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto
/dev/block/bootdevice/by-name/dsp /vendor/dsp ext4 ro,nosuid,nodev,barrier=1 wait
/dev/block/bootdevice/by-name/cache /cache ext4 nosuid,nodev,noatime,barrier=1 wait
/dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,barrier=1 wait
#/dev/block/bootdevice/by-name/onyxconfig /onyxconfig ext4 defaults defaults
Edit: device tree might be the keyword:
From: https://android.stackexchange.com/q...ty-on-android-with-user-build-type-rom/215907
Edit2:
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags lists "wait,verify"
/proc/device-tree/firmware/android/fstab/vendor/mnt_flags lists "ro,barrier=1,discard"
SO... seems I have to patch the dtb. Tomorrow maybe...
Click to expand...
Click to collapse
Replacing it with rw, yes would make it read-writeable
According to the changed thread's tite:
Rooting Android means nothing else then adding a matching SU-binary ( AKA root ) to it.
Since Android 6 every Android release comes with ( non-root ) Toybox. What you have to do is to replace this restricted version by a full ( root ) version like Toybox v0.8.5. You can achieve this by temporarily rooting Android, for example by means of copying rooted Busybox to /tmp.
jwoegerbauer said:
According to the changed thread's tite:
Rooting Android means nothing else then adding a matching SU-binary ( AKA root ) to it.
Since Android 6 every Android release comes with ( non-root ) Toybox. What you have to do is to replace this restricted version by a full ( root ) version like Toybox v0.8.5. You can achieve this by temporarily rooting Android, for example by means of copying rooted Busybox to /tmp.
Click to expand...
Click to collapse
Well ive been stumped trying to root my tv which is android 7.1.1 and ive tried the exploits everything.
Idk how easy it is too do that.
I can push files to /data/tmp though.
AFAIK both /tmp and /data/local/tmp are always present in any Android release. But I may err as always ...
Well i dont see an error but yeah android 7 is harder. Especially with the tv, /rootfa is ro and for some reason its mounted.
I guess i look through it but it dosent help me much.
I only kinda need a root shell and thats it
Its funny cause the chip seems to be hisilicon or smth.
Anyways what you said is right. He can just install the rooted version of busybox in tmp
For instructional purposes only: here a script ( what is part of an UPDATE.ZIP ) I wrote to upgrade Toybox to it's full - means containg SU - version with help of Busybox
Code:
#!/system/bin/sh
#
# Title: TOYBOX-UPDATER.SH
# Author: (c) 2021 [email protected]
# Version: 0.1
# License: BSD 2-Clause
#
busybox="/tmp/busybox" ;
tbpath="$($busybox getprop "toybox.location")";
if [ -z "$tbpath" ]; then
exit 1
fi;
tbdir="/$tbpath/bin";
if [ "$tbpath" == "system" ]; then
tbbin="toybox";
else
tbbin="toybox_vendor";
fi;
$busybox echo -e "Uninstalling actual TOYBOX";
for f in $($busybox find "$tbdir" -type l) ; do
$busybox rm "$f" ;
done
$busybox rm "$tbdir/$tbbin" ;
$busybox echo -e "Installing TOYBOX v0.8.5" ;
$busybox mv /tmp/toybox $tbdir/$tbbin ;
$busybox chmod +x $tbdir/$tbbin ;
$busybox chown root:shell $tbdir/$tbbin ;
$busybox echo -e "Adding symlink for each Toybox command to the $PATH" ;
tbcmds=(
acpi, arch, ascii, base64, basename, blkid, blockdev, bunzip2, bzcat, cal, cat,
catv, chattr, chgrp, chmod, chown, chroot, chrt, chvt, cksum, clear, cmp, comm,
count, cp, cpio, crc32, cut, date, devmem, df, dirname, dmesg, dnsdomainname,
dos2unix, du, echo, egrep, eject, env, expand, factor, fallocate, false, fgrep,
file, find, flock, fmt, free, freeramdisk, fsfreeze, fstype, fsync, ftpget,
ftpput, getconf, grep, groups, gunzip, halt, head, help, hexedit, hostname,
hwclock, i2cdetect, i2cdump, i2cget, i2cset, iconv, id, ifconfig, inotifyd,
insmod, install, ionice, iorenice, iotop, kill, killall, killall5, link, ln,
logger, login, logname, losetup, ls, lsattr, lsmod, lspci, lsusb, makedevs,
mcookie, md5sum, microcom, mix, mkdir, mkfifo, mknod, mkpasswd, mkswap, mktemp,
modinfo, mount, mountpoint, mv, nbd-client, nc, netcat, netstat, nice, nl, nohup,
nproc, nsenter, od, oneit, partprobe, passwd, paste, patch, pgrep, pidof, ping,
ping6, pivot_root, pkill, pmap, poweroff, printenv, printf, prlimit, ps, pwd,
pwdx, readahead, readlink, realpath, reboot, renice, reset, rev, rfkill, rm,
rmdir, rmmod, sed, seq, setfattr, setsid, sha1sum, shred, sleep, sntp, sort,
split, stat, strings, su, swapoff, swapon, switch_root, sync, sysctl, tac, tail
tar, taskset, tee, test, time, timeout, top, touch, true, truncate, tty, tunctl,
ulimit, umount, uname, uniq, unix2dos, unlink, unshare, uptime, usleep, uudecode,
uuencode, uuidgen, vconfig, vmstat, w, watch, wc, which, who, whoami, xargs,
xxd, yes, zcat
) ;
fs=$IFS ;
IFS=,
for cmd in "${tbcmds[@]}"; do
$busybox ln -s $tbdir/$tbbin $tbdir/"$cmd" ;
$busybox chmod +x $tbdir/"$cmd" ;
done
IFS=$fs ;
exit 0
So would that executable in a terminal emulator such as termux?
If script's permissions get set to 0755 then yes.
Oh thanks!
yes i can chmod 0755 the script.
cause adb in termux rocks when you work on a tv
But the thing wont it come up with access denied or smth like that in the thing.
I guess the tv would have loopholes but still
As said, the script is run by an updater-script where all the necessary partition-mounting is done: knowing this it should be clear that you run into errors when executing the script as printed above unless you add the necessary mounting stuff to it.
jwoegerbauer said:
As said, the script is run by an updater-script where all the necessary partition-mounting is done: knowing this it should be clear that you run into errors when executing the script as printed above unless you add the necessary mounting stuff to it.
Click to expand...
Click to collapse
Oh kk
small update: meanwhile managed to patch the
/proc/device-tree/firmware/android/fstab/vendor/fsmgr_flags from "wait,verify" to "wait"
using magiskboot binary. But it's a way too complicated for the "ordinary" guy. So still searching for an easier way.
I don't know.
I think that while we have Magisk it's easier/better to leave /system alone.
You retain the ability to do system updates.
Originally I took boot.img out of a decrypted update.upx
I extracted the kernel symbols then patched the kernel to be insecure.
I wrote a small executable that setuid/setguid to 0.
The kernel had been knee-capped to not check capabilities, it worked.
I then dd'ed recovery and fed it to Magisk.
Being able to su over ADB is all I really need; I don't like/need apps having root.
For me, being able to "pm disable com.onyx" is the bulk of what I need.
Later I discovered Qualcomm EDL mode which works just fine too.
Somebody asked me about p46 (vbmeta) and I see mine is 64K of zeroes.
@Renate : and here we meet again ;-) that somebody was me I guess
I tried
mount -o rw,remount /system/
But
mount: '/system/' not in /proc/mounts
system-as-root = system is mounted as /, not /system
Permissions are fine.
DavidxxxD said:
system-as-root = system is mounted as /, not /system
Permissions are fine.
Click to expand...
Click to collapse
I can't write to / still
Are you root?
What is output of
Bash:
id
Bash:
su -c mount -o remount,rw /
Also try this to find out more
Bash:
mount | grep "/ "
DavidxxxD said:
Are you root?
What is output of
Bash:
id
Bash:
su -c mount -o remount,rw /
Also try this to find out more
Bash:
mount | grep "/ "
Click to expand...
Click to collapse
Bash:
berlna:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012 context=u:r:shell:s0
Bash:
berlna:/ $ su -c mount -o remount,rw /
'/dev/block/dm-8' is read-only
Bash:
berlna:/ $ mount | grep "/ "
/dev/block/dm-8 on / type ext4 (ro,seclabel,relatime,discard)
And yes I have root
I've never seen this output from trying to remount. Could be a permanent read-only attribute somewhere. /dev/block/dm-8 looks like your system is on an encrypted partition, this could have something to do with the error. You can try using the busybox version of mount command. Also, does your device have a super partition? That could explain it.
DavidxxxD said:
I've never seen this output from trying to remount. Could be a permanent read-only attribute somewhere. /dev/block/dm-8 looks like your system is on an encrypted partition, this could have something to do with the error. You can try using the busybox version of mount command. Also, does your device have a super partition? That could explain it.
Click to expand...
Click to collapse
This is the same error i also face in oneplus os12 and yes my dev dm-x also is ro even after root
Its super.img and also i try with busybox
But useless
The only way now i can see is unpack backup super
Unpack edit repack and flash back
But its not possible for me
Rewriting the super partition every time, seems to be the only way in your case.
The lpflash tools are used to work with super partitions.
I've attatched a statically linked 64-bit ARM version that can run on the device, built from this source.
Extract the system image using
Bash:
./lpunpack -p system super.img
Note: This can also be run directly on the block device, it only reads.
From there, you can modify the system and add it to a super image (the firmware usually has sparse ones that need to be decompressed first). You could also flash the new system image directly via fastbootd mode.
Note: Ignore any "invaild sparse header" messages from fastboot.
Don't flash unsparse images on Samsung devices! They will not like it!
Hope this is helpful.
DavidxxxD said:
Rewriting the super partition every time, seems to be the only way in your case.
The lpflash tools are used to work with super partitions.
I've attatched a statically linked 64-bit ARM version that can run on the device, built from this source.
Extract the system image using
Bash:
./lpunpack -p system super.img
Note: This can also be run directly on the block device, it only reads.
From there, you can modify the system and add it to a super image (the firmware usually has sparse ones that need to be decompressed first). You could also flash the new system image directly via fastbootd mode.
Note: Ignore any "invaild sparse header" messages from fastboot.
Don't flash unsparse images on Samsung devices! They will not like it!
Hope this is helpful.
Click to expand...
Click to collapse
Its a super.img thx