3

I generate *.img by building AOSP.

Like ramdisk.img,boot.img etc.

I want to mount this file. I'm using Ubuntu.

Bhagirathsinh Gohil
  • 673
  • 1
  • 9
  • 25

2 Answers2

4

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

skoperst
  • 2,259
  • 1
  • 23
  • 35
1

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.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
  • This is a bit confused as to the contents. As the existing answer points out, boot.img is not a filesystem image, but rather a combination of a kernel, a squashfs, and typically some other data. Ordinary gzip and squashfs tools work on the filesystem portion. What fastboot needs to "interpret" is not that, but things like the system.img which are in "sparse" form. – Chris Stratton Jan 26 '18 at 03:02
  • @ChrisStratton thanks for feedback. I now learned that this is not the case for all .img. I had tested it with `system.img` and others, but not with `boot.img`. – Ciro Santilli OurBigBook.com Jan 26 '18 at 10:04