Is it possible to mount a ramdisk in Android before the Android framework starts, but after the underlying Linux kernel has started? If so, what commands should I use?
Thanks!
Based on some reference books I read, an Android system starts up in following main steps:
CPU reads a hard-coded address which usually points to some bootloader program
The bootloader initializes the RAM, puts basic hardware in a quiescent state, loads the the kernel and RAM disk, and jumps to the kernel.
start_kernel() initializes subsystems and proceeds to call the init function of built-in drivers.
The kernel mount its root system (from ramdisk.img).
init.rc is then called to set up the environment variables such as system path, mount other filesystems, start native daemons and so on.
Now, to answer your question: "Is it possible to mount a ramdisk in Android before the Android framework starts, but after the underlying Linux kernel has started?"
-- I think this is exactly what android did.
You have to write shell script which you invoke from init.rc files. Another approach could be write a C program which gets launched from init.rc as daemon.
The init is the middle place where linux has booted almost while android frameowrk is about to begin booting.
Related
I've just adb shell'd into my root directory on my device and I want to install the su binary. Just to note, I'm on macOS and want to do this manually.
When I try to push the su binary to the root directory (not on SDCard), I get this error:
$ cp /sdcard/su /system/bin
cp: /system/su: Read-only file system
How do I push the su binary to /system/bin?
(My tablet is an Acer Iconia Tab 10 A3-A30)
Basically, I just want to root it but I can't find any details on unlocking the bootloader or any apps that work with this tablet.
Short version: Unfortunately, the naive approach of just pushing "su" won't work. You can verify that (unless your "su" binary is using an exploit), even "adb push su /data/local/tmp/" and then executing it from there won't work.
Detailed version:
Android 5.0 brought two fundamental changes: The first was the sealing of the root and other filesystems, so that they are not only mounted read-only, but they are also verified by DM-verity, such that if they ARE mounted read/write, changes will not be accepted.
The second was the introduction of SE-Linux (along with another change, deprecating setuid binaries), as an extra level of what is known as "Mandatory Access Control". This (as opposed to chmod/chown/etc "Discretionary Access Control") means that there is an overarching "security policy", which - once installed - cannot be overridden in any way.
There are thus two ways to root your device:
A) upload a "su" style binary which would somehow find a way around SE-Linux and grant you root privileges. This necessitates exploitation of a security vulnerability to achieve kernel memory access and "patching" of the shell credentials. These are rare enough to be discounted since these vulnerabilities are quickly patched (exceptions being MediaTek devices, for which mtk-su works well).
B) boot the device in a "boot loader unlocked" mode (which you've indeed referred to) in which a pre-patched kernel, with a modified security policy and a root filesystem (technically ,Ramdisk) with a pre-made su and an enabled daemon can be used to give you super user privileges on demand. This was started by ChainFire's 'supersu', and is now the de facto method of Magisk.
Therefore, your question is very much at a dead end. You could modify the root filesystem and install the "older" form of su if this were a development build (as would be shown by "getprop ro.debuggable" or "getprop ro.build.fingerprint" with "eng" it. But, this will not work on a release (retail) device.
Your best bet is to
A) get the OTA or factory image of your tablet in question.
B) get the boot.img from it
C) Patch the boot.img using magisk (on device,
through /sdcard/Download) or imjtool
D) Enable boot loader unlocking
(not guaranteed to be available) through Developer Options
E) put
device in fastboot mode ("adb reboot bootloader" should do)
F) Use
"fastboot flashing unlock" on host when device is thus connected.
Approve unlocking
G) use "fastboot boot " or (when you
are certain it works) "fastboot flash boot "
H) Hope for the best
I am trying to learn the kernel customization and for this I have target OnePlus 6T device. I am able to compile the kernel source code on my Ubuntu 18 with the following steps:
Download latest dtc from https://packages.ubuntu.com/cosmic/a...piler/download and install it.
Clone kernel source code: git clone https://github.com/OnePlusOSS/androi...lus_sdm845.git
Clone ToolChain: git clone -b linaro-4.9-arm-linux-androideabi https://github.com/ArchiDroid/Toolchain prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-linaro-4.8
Open terminal at prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-linaro-4.9 and run: export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
Navigate to kernel source code path in the same terminal.
export ARCH=arm64 && export SUBARCH=arm64
make clean
make mrproper
mkdir Out
make O=Out sdm845_defconfig
make O=Out DTC_EXT=dtc CONFIG_BUILD_ARM64_DT_OVERLAY=y DTC_EXT=dtc -j4
Following are the last lines of compilation:
CC drivers/media/platform/msm/broadcast/tspp.mod.o
CC drivers/media/platform/msm/dvb/adapter/mpq-adapter.mod.o
CC drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.mod.o
GZIP arch/arm64/boot/Image.gz
CC drivers/soc/qcom/llcc_perfmon.mod.o
CC drivers/video/backlight/lcd.mod.o
CC net/bridge/br_netfilter.mod.o
LD [M] drivers/char/rdbg.ko
LD [M] drivers/media/platform/msm/broadcast/tspp.ko
LD [M] drivers/media/platform/msm/dvb/adapter/mpq-adapter.ko
LD [M] drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.ko
LD [M] drivers/soc/qcom/llcc_perfmon.ko
LD [M] drivers/video/backlight/lcd.ko
LD [M] net/bridge/br_netfilter.ko
CAT arch/arm64/boot/Image.gz-dtb
make[1]: Leaving directory '/home/.../KernelCustomization/android_kernel_oneplus_sdm845/Out'
Now, the next step is to flash the image. I have rooted OnePlus 6T device and I am confused with the three image files generated after successful compilation i.e.
arch/arm64/boot/Image.gz-dtb
arch/arm64/boot/Image.gz
arch/arm64/boot/Image
I need a favour in:
What image can I use to flash on android device?
Is booting a image with TWRP is enough to flash kernel?
Found Google documentation
https://source.android.com/devices/bootloader/partitions-images
As per following lines from google documentation:
boot: The boot partition contains a kernel image and a RAM disk combined via mkbootimg. In order to flash the kernel directly without flashing a new boot partition, a virtual partition can be used:
kernel: The virtual kernel partition overwrites only the kernel (zImage, zImage-dtb, Image.gz-dtb) by writing the new image over the old one. To do this, it determines the start location of the existing kernel image in eMMC and copies to that location, keeping in mind that the new kernel image may be larger than the existing one. The bootloader can either make space by moving any data following it or abandoning the operation with an error. If the development kernel supplied is incompatible, you may need to update the dtb partition if present, or vendor or system partition with associated kernel modules.
I think I have to use arch/arm64/boot/Image.gz-dtb for flashing the kernel. My understanding is that Image.gz-dtb is a virtual image that can be used to flash only kernel on android.
Still, I am not able to figure out the correct step to flash it. I am wondering if I will do something wrong then I will break my device so I want to be sure before flashing that it will work.
Any help or guidance will be very helpful at this moment.
I found the steps that are needed to flash the custom kernel on android device i.e.
First we need to get the boot image of stock firmware we can get it by running following commands:
adb shell "ls -la /dev/block/platform/soc/1d84000.ufshc/by-name/" > MoreInfo\msm_partitions.txt
Note the boot partition name e.g. boot_a -> /dev/block/sde11 boot_b -> /dev/block/sde39
Missing steps to make boot.img with command dd command.
Download the latest Android Image Kitchen from this thread.
Run the following with the boot image: unpackimg.sh .img
Locate the zImage file and replace it with your kernel image (rename it to what came out of the boot image)
Run the following to repack: repackimg.sh
Flash the new boot image with fastboot or TWRP!
I need some more information on the missing steps. Actually the process written above is working on devices that has only one boot partition. Does any one know how can I flash my single kernel image on a device that has a/b partitioning?
Update:
I searched over the internet for A/B partitioning and I found that these are used for seamless updates i.e. One partition is active at a time and another partition which is inactive can be used to flash the update. On reboot, another partition will become active and One partition will become inactive. More Info: https://www.xda-developers.com/how-a...opment-on-xda/
If my understanding is true then I just need to follow following steps to find the correct image to be used at the first step of flashing the kernel:
fastboot getvar all | grep “current-slot”
dd if="path to boot of active slot" of=/sdcard/boot.img
Continue with boot.img and flash the kernel with above written steps for flashing a kernel.
Anyone who has this knowledge, please confirm. I will be very thankful to you.
A/B OTA update
Firstly, you need to confirm whether your phone is A/B OTA update or not by following command
fastboot getvar slot-count
If the command returns '2', then your phone supports A/B OTA update which means you have two boot
partitions 'boot_a' and 'boot_b', otherwise, there should only be one partition 'boot'
boot image
The images you built (Image.gz-dtb) are just kernel images with device tree. They
are not enough for flashing to boot partition since there should be ramdisk and boot arguments combined.
The ramdisk content contains normal boot binaries for non-A/B OTA system or recovery binaries for
A/B OTA system. You need to find official ramdisk images and combine with your kernel image. Normally
mkbootimg will be used to create boot image in AOSP android.
Flashing
fastboot flash boot boot.img
This works on both A/B and non-A/B system since image will be flashed to default active partition (boot_a
is by default if you do not have OTA or using 'fastboot set_active' to change it)
On A/B system, you can also use 'fastboot getvar current-slot' to get active slot and specific flash
partition 'fastboot flash boot_a boot.img' or 'fastboot flash boot_b boot.img'
XDA provides scripts to flash kernel images (Image.gz-dtb) with following steps:
a. Dump boot.img from your phone
b. Extract ramdisk.img from boot.img
c. Combine Image.gz-dtb with ramdisk.img to new boot.img
d. Flash new boot.img to boot partition
https://forum.xda-developers.com/oneplus-6t/development/kernel-holydragon-t3878107
provides customized kernel and flash scripts, you should check and find your suitable way to flash your kernel image.
We have an development board that has been run Yocto system. and we want it to run android system, we already has compiled android image with Yocto kernel that has android's some patch.
We don't know how to flash the android image (such as system.img boot.img and recovery.img and so on) to the development board because of the Yocto system partition different with android system.
we can use fastboot tool to flash Yocto system to EVB.and we want to know:
How to partition eMMC that we can use fastboot tool to flash android system. Do we need to modify Little Kernel code ? and how to modify it in Yocto system.
How to we boot the android system up?
It would be appreciated if you offer any useful information.
Thanks
How to partition eMMC that we can use fastboot tool to flash android system.
You'll need a tool that can partition the eMMC. Considering you are using yocto your best bet is gptfdisk package. gptfdisk recipe is at path poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.0.bb. gptfdisk provides following text-mode partitioning tools
gdisk,
cgdisk,
sgdisk,
fixparts
You can use one of these tools to recreate the partitions in the partition table.
and how to modify it in Yocto system.
Do IMAGE_INSTALL_append = " gptfdisk " in conf file to make the tools of this package part of your image.
How to we boot the android system up?
You'll need 3 partitions
system.img - goes in partition named system
boot.img - goes in system named boot
and recovery.img - goes in system named recovery
Each tool has a man page on Linux. You can read the manuals using man sgdisk, man gdisk, man cgdisk and man fixparts. Some example usages of sgdisk
sgdisk -p </dev/sda> - To print all partitions on the disk
sgdisk --delete=partnum </dev/sda> - Delete a partition. This action deletes the entry from the partition table
There is a lot of way to partition the eMMC, it depends on your system: via USB, sdcard, nfs, uboot...
I think you can have a look at the meta-variscite, especially in the scripts folder. They have flash scripts for Yocto poky images, and android image (on the same boards). They flash from the SDcard to the eMMC.
I ported these scripts for a use with uboot: I run the command ums mmc 0 to start mass storage mode via USB OTG, and on my PC I run an install script which use dd for erasing partitions, fdisk for creating partitions, mkfs to format my device connected by USB.
You can also use mmc part in uboot, but I never tested this option.
I want create and run a shell script each time i boot up the kernel along with android on my mobile
A script can't be run when you boot up the kernel because the interpreter (your shell) isn't ready at that point. At best you can run your script when the kernel is done loading, and even then it will be quite hackey to do from within the kernel.
Best use init.rc for that purpose, this is what it was designed for
This is the latest VOLD daemon from Android 4.3:
https://android.googlesource.com/platform/system/vold/+/master
It uses a new unified /fstab.<device> configuration file. Once I've modified the file in the rootfs ramdisk, I need to restart VOLD or make it reload the configuration file. I can't seem to figure out the commands or any command line parameters it takes in order to do this.
Although vold is responsible for mounting removable media, asecs and obbs it actual has little to do with the device specific fstab.<device> file.
This is instead used by the init process to mount the system and data partitions. The init process defines a command "mount_all" which takes an fstab.<device> file as a parameter. For example of the Nexus4 (mako) the the init.mako.rc script (located in device/lge/mako in the aosp source) in the "on fs" section calls
mount_all ./fstab.mako
If you are working on an existing device you will need to modify the fstab.<device> file in the ramdisk image and reflash the boot partition. This makes it difficult to do this at runtime.