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.
Related
I am trying to verify a small change I have made in the Activity Manager service (mostly logs that I have added). I am using the android-8.1.0_r42 aosp version and using its emulator.
I am using an eng build.
I have done a module makes (mm) and then, make services which generated the services.jar, services.odex, etc. However, I am unable to remount the system partition on the emulator (command used: mount -o rw, remount /system, on the ADB shell, but doing a push(adb push) of any of the generated services binary is failing due to reading the only partition).
So I regenerated the system.img by doing a - make snod. However, my changes are not consumed in the emulator instance I launched after generating the new system.img.
Is there a way I can verify my changes without doing a top-level full build, which takes quite a long?
It could be the case that DM-verity is enabled and prevents you from writing to the system partition after remounting.
Assuming you are working with a userdebug version, try the following:
adb root
adb disable-verity
adb reboot
adb root
adb remount
Now you should be able to push your files to the remounted partition without getting the read-only error.
I am trying to modify the init.rc file on Nexus 7 device which is rooted.
I want to insmod a simple hello world module before my /userdata/ partition is mounted.
Things I have tried:
Extracted the boot.img from the device, extracted the ramdisk, made changes to the init.rc (which do not work), recreated the boot.img (using mkbootimg tool) and then flashed it on the device again
I have placed my hello.ko compiled for the kernel at 2 places: one is the current directory in which init.rc is placed, so that I can do something like insmod hello.ko and it will find it. Secondly, I created /lib/modules/ directory and placed it inside that
In my init.rc I have placed the insmod /lib/modules/hello.ko right after on_boot.
I have also changed the init.flo.rc and placed the insmod before and after ./mount_all which mounts the file system.
However, I do not see my module loading at all.
The permissions set were 0644 ( I tried with 0777 too)
I created init.d inside /etc/folder and placed a loadmodule.sh which does an insmod /lib/modules/hello.ko and that module loads but once the boot process has completed.
I ideally want to do it right before mounting the /userdata/ partition.
Can someone help me with this?
My device is a Nexus 7, with flo_kernel and rooted, busybox installed, etc.
The root filesystem on an Android device is "read-only", insofar that you cannot hang any files off the root tree and expect it to stay around. This is the same reason that you needed to extract the ramdisk and re-pack its contents in order to persist an init.rc change; any files you want to also locate at / must be packed into the ramdisk as well. Android extracts root from the ramdisk on every boot.
A more conventional location for that file would be on the system partition, say in /system/lib
I've selected several of the trace tags and when I run the trace (from DDMS) I get the following output:
Unexpected error while collecting system trace. Unable to find trace start marker 'TRACE:':
error opening /sys/kernel/debug/tracing/options/overwrite:
No such file or directory (2)
error openi(cuts off the error here)
indeed there is no debug file in the kernel directory, but which mechanism will generate the necessary path?
It looks like your cellphone is running a boot(kernel) image that does not support systrace.
"error opening /sys/kernel/debug/tracing/options/overwrite: No such file or directory (2)"
This error message means adb daemon (the adb module running on device side) could not find /sys/kernel/debug/tracing/options/overwrite on your device's file system. systrace works over adb and communicates with kernel though sysfs nodes under /sys/kernel/debug/tracing. If these nodes are not exposed on you phone for whatever reason, systrace just will not work.
So you should first get a shell on your device using:
adb shell
Then browse to confirm if /sys exists at all and if /sys/kernel/debug/tracing exists.
If they are there which is extremely unlikely, you have to debug systrace.py to figure out how come systrace think the nodes were not there. Otherwise, you need to flash a different boot image which has systrace support, because sysfs is controlled by kernel(mostly by configurations at compile time) and init.rc , both of which are part of boot image.
Flashing a different boot image might involve unlocking/rooting the device. You probably have to go to fan sites like xdadeveloper for information and image. Another option is to download the source of kernel for your device, compile kernel and make the boot image yourself. Linux is under GPL thus manufacturer of your device is obligated to release the source code of the specialized kernel they use.
-NAM
http://www.willpromo.com
You may need to slightly modify the kernel image(boot.img). The following work find for me, just for your reference.
open terminal and enter: $adb shell
(1) $su (2) $mount -t debugfs none /sys/kernel/debug. Now you should be able to see many directories under /sys/kernel/debug/. (You may cd into /sys/kernel/debug to confirm this)
Enter: $dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/sdcard/boot.img to generate the boot.img kernel image from your device.
Use AndroidImageKitchen to unpack the boot.img and find the default.prop within Ramdisk folder. Then change ro.debuggable=0 to ro.debuggable=1. Repack the boot.img and flash boot it to your device.
Once the device boot, under terminal, enter: $adb root and message like: $restarting adbd as root may pop up. Disconnect the USB and connect again.
cd to the systrace folder, e.g. ~/androidSDK/platform-tools/systrace and use:
python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
Now you may able to generate your own systrace files.
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.
I want to change the init.rc file of an android pad. But after I change it and reboot the system, the original init.rc comes back.
How can I make the change to the init.rc persistently without rebuild the system (since I don't have the source code of the system)? Or is there any way to work around?
Unpack the uramdisk using following command in host PC(Linux)
mkdir /tmp/initrc cd /tmp/initrd
sudo mount /dev/sdb1 /mnt
sdb1 is partion where uramdisk/uInitrd resides.
dd bs=1 skip=64 if=/mnt/uInitrd of=initrd.gz
gunzip initrd.gz
At this point running the command file initrd should show:
mkdir fs
cd fs
cpio -id < ../initrd
Make changes to init.rc
Pack uramdisk using following commands:
find ./ | cpio -H newc -o > ../newinitrd
cd ..
gzip newinitrd
mkimage -A arm -O linux -C gzip -T ramdisk -n "My Android Ramdisk Image" -d newinitrd.gz uInitrd-new
A number of Android devices include code to prevent root modifications to the system files. The way this is done is by using the recovery partition. On reboot, they basically restore the system partition using the recovery image. If your system is doing that then you cannot make persistent changes - the best you could do would be to hook up something to run after reboot to re-apply your change. In CyanogenMod they had hooks in the init.rc to run sdcard scripts if found. Perhaps you can create an app or widget to then launch a script to make the mods required using a setuid root script from the data partition. Without building your own ROM you are quite restricted in this area.
Possibly you could fetch the recovery image and try unpacking that, making your changes and repacking and flashing it. But make sure you can recover with fastboot before you try this.
Try this site:
http://bootloader.wikidot.com/linux:boot:android
Read the section at the bottom:
•The Android boot image: boot.img
◦Unpack, re-pack boot image: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images#Background
When an android system boots, uboot unpacks a special compressed ball of files in your boot partition called 'uRamdisk' to RAM, and defines those files to comprise the root directory of the system. uRamdisk normally contains a bunch of directories (system, data, media, etc.) that serve as mountpoints for partitions that contain the files that go in them, but also has some very basic files vital to your system, including the init binary and startup scripts like init.rc.
when you edit the init.rc, you've actually just edited the unpackaged copy of init.rc that resides in your RAM. To really change it then, you have to copy your uRamdisk, extract it, edit the init.rc from there, repackage uRamdisk and then replace the new one with the old one in /boot.
Try looking up the 'xuramdisk' and 'mkuramdisk' scripts, these make the process very simple.
Your root partition (where /init.rc lives) is a ramdisk which is unpacked from an initrd file and mounted every time your device boots. Any changes you make are to the ramdisk only, and will be lost on the next reboot.
If you can get the initrd file, you can mount it on your Linux host system, modify the files there, unmount it, and write it back to your Android.
The initrd file exists in its own partition on the device. If you can figure out which partition it is, you can grab it from the device onto your host, mount it, modify it, and write it back to the device. This is what tripler was talking about above.
In general, modifying boot.img is something that only system developers do. If you're building the entire Android system, you'll have access to the necessary source code. My workflow for this looks like this:
# Modify init.rc
m -j8 bootimage_signed
adb reboot bootloader
fastboot flash boot $OUT/boot.img
fastboot reboot
I don't know if you are still trying to do this but without knowing your exact device nobody can give you an exact answer.
Try taking a dd image of all your internal partitions and use some scripts like those included with android kitchen on xda forums. Your recovery and boot partitions will both have a ram disk but odds are you want to modify the init.rc in the boot.img not recovery, unless you only want the changes present in recovery mode.
The unyaffs thing doesn't apply to all devices and most devices have different partition layouts so you have to figure out which is boot and what type of fs it is. Maybe if you give your device specs you can get a better answer.
Please note that it may be easier for you to use an app like Scripter to run a script at boot time than modify this file.
Before following #tripler's instructions above you need a file called boot.img which can be extracted by (run on rooted Android device, untested without root):
dd if=/dev/block/platform/<someplatform>/by-name/boot of=/sdcard/boot.img
Then connect your Android to your computer and copy the boot.img file from there.
Script:
http://linuxclues.blogspot.ca/2012/11/split-bootimg-python-android.html
Here is a modified, easier to see version of tripler's instructions (assuming boot.img is in tmp):
cd /tmp
mkdir fs
# Now use the linked script above to split the boot.img file into ramdisk.gz and kernel
python split_boot_img.py -i boot.img -o parts
cd fs
gunzip -c ../parts/ramdisk.gz | cpio -id
# make changes to init.rc
At that point you will have to rebuild the boot.img back together before reflashing, which will be device-specific. Can't help you with that, sorry!
You have to edit/change the init.rc before building your Android pad file system. This is the preferred way, and always works.