I generate *.img by building AOSP.
Like ramdisk.img,boot.img etc.
I want to mount this file. I'm using Ubuntu.
You cannot mount boot.img file. However you can unpack it's ramdisk.
The boot.img file contains:
ramdisk
zImage (kernel binary)
dt.img (device tree)
There is an excellent open source project: mkbootimg_tools at GitHub. You can use it to split the boot.img file and unpack the ramdisk.
Unpack boot.img:
mkbootimg_tools/mkboot boot.img boot_unpacked
To unpack system.img you first need to understand what kind of partition is it:
run:
file system.img
If you get 'Android sparse image', then you have a sparse image, meaning you need to un-sparse it before mounting:
simg2img system.img system_raw.img
Then you can mount system_raw.img simply by running:
sudo mount system_raw.img /mnt/android_sys
simg2img
Some Android images are compressed by default for some builds. This is the case for example of the HiKey960 build with lunch hikey960-eng, but not for emulator builds e.g. with lunch aosp_x86_64-eng.
You must first usesimg2img to decompress them:
simg2img system.img out.img
sudo losetup --show -f -P out.img
sudo mount /dev/loop0 /mnt/loop0
simg2img lives under ./out/host/linux-x86/bin/simg2img, and gets added automatically to PATH by lunch.
Note however that this is not the case for all the images, e.g. boot.img.
If you skip simg2img, you get the error:
NTFS signature is missing.
Failed to mount '/dev/loop3': Invalid argument
The device '/dev/loop3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
when trying to mount.
It appears that the compressed format is something that fastboot can understand.
Also mentioned at: https://stackoverflow.com/a/9675784/895245
Tested in Ubuntu 16.04 host, at branch repo init -b android-8.1.0_r1.
Related
I want to change the kernel and ramdisk.img file to install magisk, however, the folder is "read-only"
My setup:
Android-x86_9.0-r2_(x8) running on Proxmox (using QEMU and qcow2
formatted image)
GRUB, GBT installed, and I selected install with
write permissions at the android installation
I tried to install magisk using the following guide: https://forum.xda-developers.com/android/general/guide-android-x86-rooted-magisk-t4077477
I successfully patched the boot.img and got the new kernel and ramdisk.img file. However, I wanted to replace them now, but I get the following error when I want to modify something in the folder where the old kernel and ramdisk.img is located:
Read-only file system
I connected to android using ADB (but also tried the terminal emulator on android itself). I already tried adb remount and other mounting options, but nothing works. Android runs as root.
The folder where the ramdisk.img and boot is located: /mnt/media_rw/Android-x86_9.0-r2_(x86)/
When running
mount | grep mnt
I receive the following (which means the folder Android-x86_9.0-r2_(x86) where the ramdisk.img etc. is stored is read-only:
/dev/block/vold/public:11,0 on /mnt/media_rw/Android-x86_9.0-r2_(x86) type iso9660 (ro,dirsync,nosuid,nodev,noexec,relatime,nojoliet,utf8,check=s,map=n,blocksize=2048,uid=1023,gid=1023)
When I try to mount it to rw using:
mount -o remount,rw /dev/block/vold/public:11,0 /mnt/media_rw/Andro*
I get:
'/dev/block/vold/public:11,0' is read-only
What can I do to change the ramdisk.img and kernel so I can install magisk?
Thank you very much!
I was having the same issue. All you can do install gearlock and find the img somewhere in gearlock/gearrot folder. You can modify that files as you want.
More info:
https://github.com/axonasif/gearlock
I need to do a strange task. I want to move whole android system to external SD card on Android Virtual Device. I need to do this, because android emulator, emulates SD commands, only for external card image. And I want to get SD commands trace, during Android Virtual Device usage.
To be more precise: I want to move at least /system and /data folders to external storage. In such way, that system could still work fine =)
Thank You!
To move some of system folders (/system or /data), to external emulated SD card, you need to do following:
Firstly, /data contents (for example) should be placed on sdcard. Initially they are loaded by emulator from userdata.img file.
So you need to copy userdata.img ($EMUPATH/system-images/android-19/armeabi-v7a/userdata.img) contents to sdcard.iso. $> dd if=userdata.img of=sdcard.iso
I assume, that android virtual device is created. To change boot configuration, you will need to change fstab.goldfish file on ramdisk.img. If it is Android 4.4 AVD, then ramdisk.img could also be find at $EMUPATH/system-images/android-19/armeabi-v7a/
Create a temporary folder, say ramdisk-ext $ mkdir ramdisk-ext
Change directory to ramdisk-ext $ cd ramdisk-ext
Extract the ramdisk.cpio in the ramdisk-ext folder $ gunzip -dcv ../ramdisk.img | cpio -idm
Modify fstab.goldfish $ gedit fstab.goldfish in such way:
String #6 from "/dev/block/mtdblock1 /data ..." to "/dev/block/mmcblk0 /data ..."
Create new ramdisk $ find . | cpio -H newc -o | gzip -9 >../ramdisk_new.img
Everything is done, now you need to start the emulator, with your new ramdisk and custom sdcard:$ ./emulator -avd $AVDNAME -sdcard sdcard.iso -ramdisk $EMUPATH/system-images/android-19/armeabi-v7a/ramdisk_new.img
P.S. Notice that in this example you can move only one of such folders (/system or /data). Maybe it could be changed, by creating sdcard image with several partitions.
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.
I need to patch a file into the system.img file used by the Android emulator, specifically I want to add an ARM binary to the /system/bin directory.
I have this binary pre-compiled and it works in my emulator perfectly, but I can't simply remount system.img as rw and adb push it because the change is non-persistent across reboots. I tried this on a copy of system.img and passing it to the emulator with -system but that was non-persistent to sadly.
In the ideal world I want to modify the "make sdk" process so that the sdk build process automatically includes my binary when it produces system.img. Can this be done?
If this isn't possible, is there anyway of patching it into the image manually?
Thanks a lot.
I was interested in permanently modifying the /system folder and tried unpacking the system.img file which went ok, but I failed to create a new img that the emulator was happy with (using the mkyaffs2 and unyaffs2 tools to extract and create a new system.img).
Instead I found a much easier solution:
Remove everything from the /data/ directory (except lost+found)
Copy the contents of /system into your /data folder
Make your desired changes to /data/
Kill the emulator
You now move your ~/.android/avd/MYANDROID.avd/userdata-qemu.img to ~/system.img (or wherever)
and startup your emulator with your new system image:
emulator -debug all -show-kernel -verbose -avd MYANDROID -no-boot-anim \
-gpu on -partition-size 800 -system [path to your new system.img]
The /data folder is where the userdata-qemu.img file gets mounted.
It gets created the first time the emulator is run and will get recreated if you delete it.
(though your installed apps will disappear).
BY populating it with the contents of the /system folder and then making your desired modifications you have created a replacement for the system.img file.
system.img replace with original one so you need give patches whenever your emulator boots check logcat & then using ADB push you manually push the patches.
I feel a bit blind developing on an emulator for Android and not being able to see the file system on the AVD (.img).
Is there a way to mount it in Windows or Linux, so that I could at least see the file listing and maybe contents?
Bonus if it's mounted with write permissions as well.
Thank you.
You can just mount the device in Linux:
sudo mount -o loop ~/.android/avd/<myvirt>/sdcard.img <destdir>
How about "adb shell"?
This will give you a root shell (on the emulator)..
For MacOS X users:
$ hdiutil attach ~/.android/avd/Samsung_Nexus_S.avd/sdcard.img
For Windows, I just ran across the ImDisk Virtual Disk Driver
Install this utility, and you can then mount sdcard.img. There's a nice tutorial here
Yes, they can be mounted. Under Ubuntu you can mount sdcard.img via vfat and system.img and userdata-qemu.img via yaffs2. See also: "Whats Android file system ??".
Note that the file system yaffs2 is not included in the standard Ubuntu kernel. Thus, in case of Ubuntu, you have to build your own kernel with yaffs2 support before you are able to mount the system.img and the userdata-qemu.img. Alternatively, you can also take a look at the yaffs2utils which allow you to extract files from yaffs2 images or to create new image files. The advantage is that you do not have to build your own kernel for using these tools.
Another option would be to use the File Explorer in DDMS (Eclipse SDK), you can see the whole file system there and download/upload files to the desired place. That way you don't have to mount and deal with images.
I tried mounting and it's cumbersome, for example if the emulator is running you can't do it. Plus you would need to mount each image if you want to see all contents.