How to extract boot.img?
I am trying to see the content in a boot.img file from an Android image. I googled and found this article to extract system.img , but it doesn’t work for boot.img . When trying to do this for boot.img , it is showing the following:
Invalid sparse file format at header magi Failed to read sparse file - If so, Is there any other method to extract boot.img ?
- If not, what is the problem for not extracting boot.img ?
4 Answers 4
boot.img is a small(ish) file that contain two main parts.
Unpack boot.img :
It contains the following steps:
wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/android-serialport-api/android_bootimg_tools.tar.gz tar xvzf android_bootimg_tools.tar.gz We can extract the ramdisk also, using the following command
gunzip -c boot.img-ramdisk.gz | cpio -i After changing the files, we can again pack those files as boot.img using mkbootimg
Getting the same error for step 3 on Mint 17 here. Tried running them by sudo and after chmod 755 to no avail.
Fix for: «unpackbootimg command not found», you are running 32bit binary on a 64 bit machine without 32bit dependencies. Install them with «apt-get install gcc-multilib»
Install abootimg (available as a package, for example in Debian/Ubuntu and openSUSE).
To extract (boot|recovery).img :
$ abootimg -x (boot|recovery).img $ ls boot.img bootimg.cfg initrd.img zImage To repack (boot|recovery).img after modifying one of bootimg.cfg , zImage or initrd.img :
abootimg --create (boot|recovery).img -f bootimg.cfg -k zImage -r initrd.img This project is not maintained and did not work with my boot.img file, however the answer from @cfig worked.
boot.img is not a compressed filesystem image like system.img . It is read by the bootloader, and contains little more than a kernel image and a ramdisk image.
Some binary distribution ship the kernel and ramdisk images separately. In that case you don’t need to do anything with boot.img , just regenerate a new one with mkbootimg .
If you need to extract information from a boot.img , try split_bootimg (by William Enck, via the Android wiki).
You can use the following tool to extract and re-pack Android boot image
$ git clone https://github.com/cfig/Android_boot_image_editor.git copy your boot.img to the cloned git repository. Run:
First time run will need to download necessary libs from internet, be patient. You can get the contents at «build/unzip_boot/», like this:
build/unzip_boot/ ├── bootimg.json (boot image info) ├── kernel ├── second (2nd bootloader, if exists) ├── boot.img.avb.json (AVB only) └── root How to mount AOSP .img files?
I generate *.img by building AOSP. Like ramdisk.img,boot.img etc. I want to mount this file. I’m using Ubuntu.
2 Answers 2
You cannot mount boot.img file. However you can unpack it’s ramdisk.
The boot.img file contains:
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.
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
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 use simg2img 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? It appears that the compressed format is something that fastboot can understand.
Tested in Ubuntu 16.04 host, at branch repo init -b android-8.1.0_r1 .