13

I want to figure out all partitions on my device together with their resp. mount points or labels (i.e. to know which partition is holding system, recovery, boot, etc.). This needs to be device independent (as I have multiple devices). Goal is to dd them and know which image is what.

I have seen Command to list partition mount points? – however, there the goal was just a partition list of mounted partitions. I need them all, and e.g. /recovery is not mounted when booting into "normal work mode".

So far, my recherche has brought up a bunch of approaches – but none of them works on any of the devices I've tested:

  • cat /proc/mtd: this is empty or non-existing
  • cat /proc/emmc: this is empty or non-existing
  • cat /proc/dumchar_info: non existing (MTK/MediaTek)
  • ls -al /dev/block/platform/*/by-name: either non-existing, or not having the wanted details

Any idea of what I could have missed? Of course I could walk all the /dev/block/mmcblk0p* devices, dump them, and sort them out later – but then I had to repeat that investigation for every of my devices (and again when someone turns up with another one), so that's no solution.

EDIT: Please note the tag to this question. I'll have to access that information via ADB, and do not want to install some app on a device handed to me for investigation. Consider it "forensics background" (no changes to the device), though that's not exactly true ;)

Also apologies for my initial mis-phrasing: the "mount points" are only interesting in so far they reveal the purpose of the partition. I don't want to mount/remount them :)

Improve this question
0

4 Answers 4

Reset to default
8

As existing answers already show, there seems to be no "unique way" to achieve that. So I started combining ideas from allover, joining them into a script (or rather a "script library") to have them checked sequentially (until a good hit was made), and integrated that into my "Device Documentation Tool" named Adebar. Those interested can find it in the lib/partitions.lib file. As Adebar is open-source (GPLv2), feel free to copy and use it – or fork the project and improve it.

The full solution is a bit long to post here (as said, you can grab it at Github), but as our policy is to include at least the general part in the post, here's what it does:

Different sources provide different sets of details, so it tries the "best ones" first – and then recurses down until at least something was found.

  • /proc/dumchar_info gives the most details, so this is tried first. Happy MTK users will get this.
  • /proc/mtd is the second best source.
  • /proc/emmc should have almost as much as the previous candidates, but is a bit tricky to use
  • /dev/block/platform/*/by-name, cross-checked with …
  • /proc/partitions cross-checked with /proc/mounts gives us at least the partitions mounted

So the script I've built basically walks the sources in this order, stopping as soon as it was able to collect details (e.g. if /proc/dumchar_info was found, no need to parse all the others). All of them put into separate functions, returning data using the very same structure, one could even merge results from all of them.

If someone can come up with a better solution, I'm of course always open for the idea :)

Improve this answer
4

I stumbled upon this question. I like a challenge...

Tools that I used: BusyBox

I've come up with 3 commands (one you listed) to give some info about the partitions

busybox ls -QAl --color=never /dev/block/platform/*/by-name
Output: 
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "DDR" -> "/dev/block/mmcblk0p4"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "aboot" -> "/dev/block/mmcblk0p5"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "abootf" -> "/dev/block/mmcblk0p16"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "boot" -> "/dev/block/mmcblk0p18"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "cache" -> "/dev/block/mmcblk0p41"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "dbi" -> "/dev/block/mmcblk0p3"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "dbibak" -> "/dev/block/mmcblk0p10"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "drm" -> "/dev/block/mmcblk0p36"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "eksst" -> "/dev/block/mmcblk0p29"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "encrypt" -> "/dev/block/mmcblk0p28"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "factory" -> "/dev/block/mmcblk0p39"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "fota" -> "/dev/block/mmcblk0p34"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "fsc" -> "/dev/block/mmcblk0p25"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "fsg" -> "/dev/block/mmcblk0p24"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "grow" -> "/dev/block/mmcblk0p43"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "laf" -> "/dev/block/mmcblk0p33"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "misc" -> "/dev/block/mmcblk0p32"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "modem" -> "/dev/block/mmcblk0p1"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "modemst1" -> "/dev/block/mmcblk0p21"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "modemst2" -> "/dev/block/mmcblk0p22"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "mpt" -> "/dev/block/mmcblk0p38"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "pad" -> "/dev/block/mmcblk0p8"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "pad1" -> "/dev/block/mmcblk0p23"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "pad2" -> "/dev/block/mmcblk0p27"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "persist" -> "/dev/block/mmcblk0p19"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "rct" -> "/dev/block/mmcblk0p30"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "recovery" -> "/dev/block/mmcblk0p20"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "rpm" -> "/dev/block/mmcblk0p6"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "rpmbak" -> "/dev/block/mmcblk0p11"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "rpmf" -> "/dev/block/mmcblk0p13"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "sbl1" -> "/dev/block/mmcblk0p2"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "sbl1b" -> "/dev/block/mmcblk0p9"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "sdif" -> "/dev/block/mmcblk0p15"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "sns" -> "/dev/block/mmcblk0p37"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "spare1" -> "/dev/block/mmcblk0p17"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "spare2" -> "/dev/block/mmcblk0p31"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "spare3" -> "/dev/block/mmcblk0p35"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "ssd" -> "/dev/block/mmcblk0p26"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "system" -> "/dev/block/mmcblk0p40"
lrwxrwxrwx    1 0        0               20 Jan 30  1970 "tz" -> "/dev/block/mmcblk0p7"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "tzbak" -> "/dev/block/mmcblk0p12"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "tzf" -> "/dev/block/mmcblk0p14"
lrwxrwxrwx    1 0        0               21 Jan 30  1970 "userdata" -> "/dev/block/mmcblk0p42"

busybox blkid
Output: 
/dev/block/vold/179:65: LABEL="ANDROID" UUID="87B8-10F1"
/dev/block/mmcblk1p1: LABEL="ANDROID" UUID="87B8-10F1"
/dev/block/mmcblk0p42: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p41: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p40: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p38: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p37: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p36: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p19: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b"
/dev/block/mmcblk0p1: UUID="00BC-614E"

busybox df -ma
Output: 
Filesystem           1M-blocks      Used Available Use% Mounted on
tmpfs                     1415         0      1415   0% /dev
devpts                       0         0         0   0% /dev/pts
proc                         0         0         0   0% /proc
sysfs                        0         0         0   0% /sys
selinuxfs                    0         0         0   0% /sys/fs/selinux
debugfs                      0         0         0   0% /sys/kernel/debug
none                         0         0         0   0% /acct
none                      1415         0      1415   0% /sys/fs/cgroup
tmpfs                     1415         0      1415   0% /mnt/asec
tmpfs                     1415         0      1415   0% /mnt/obb
none                         0         0         0   0% /dev/cpuctl
/dev/block/platform/msm_sdcc.1/by-name/system                              2524       715      1808  28% /system
/dev/block/platform/msm_sdcc.1/by-name/userdata                         25620      5066     20514  20% /data
/dev/block/platform/msm_sdcc.1/by-name/cache                           834        13       820   2% /cache
/dev/block/platform/msm_sdcc.1/by-name/persist                            31         4        27  13% /persist
/dev/block/platform/msm_sdcc.1/by-name/modem                            64        56         7  88% /firmware
/dev/block/platform/msm_sdcc.1/by-name/sns                             8         4         4  52% /sns
/dev/block/platform/msm_sdcc.1/by-name/drm                             8         4         3  56% /persist-lg
/dev/block/platform/msm_sdcc.1/by-name/mpt                            31        13        18  41% /mpt
/dev/fuse                25620      5066     20514  20% /mnt/shell/emulated
/dev/block/vold/179:65   60891     10820     50071  18% /mnt/media_rw/sdcard1
/dev/fuse                60891     10820     50071  18% /storage/sdcard1
Improve this answer
3
  • 1
    Thanks for your efforts, Ryan! I've also already played with busybox (which unfortunately isn't available on "some friends' devices" I get handed in). blkid doesn't reveal what partition it is (boot, recovery, etc), and the */by-name/* doesn't exist on all devices (and when it does, the names are sometimes pretty cryptic – e.g. on my LG Optimus 4X, names are all 3-chars only and not necessarily "speaking"). df only lists mounted devices, so it won't show e.g. recovery when running in "normal mode" – so here it's easier using /proc/mounts instead.
    – Izzy
    Commented Jan 3, 2015 at 14:37
  • You may want to also ask this over on Unix & Linux. They may be aware of ways to get the info. Everything I have researched says 'fdisk' or other tools that either return nothing, or don't exist on android system.
    – Ryan Conrad
    Commented Jan 3, 2015 at 18:01
  • That was my experience as well. I've asked a related question on SO with a different perspective, but got no response yet there. Afraid I'm asking the impossible. It's pretty easily achieved on devices supporting /proc/mtd – but unfortunately, that no longer seems to be populated with current devices. On some devices I've even found .fstab files, but again, a) not on all, and b) even if, they didn't seem reliable (some parts were definitely wrong in there).
    – Izzy
    Commented Jan 3, 2015 at 19:15
1

KPARTX

The kpartx command reads partition tables and maps partitions to device files. It works on devices and disk images. This means we can map HFS partitions in a disk image to a special block device file and mount those partitions by addressing that block device file as if it were part of an attached device.

http://linuxsleuthing.blogspot.com/2012/10/christmas-come-early-hfshfs-mounting.html

The examples in link are foe MacBook Pro, but different disk images should work fine as long as they presented to the GNU Linux in RAW. (xmount - see below)

usage : kpartx [-a|-d|-l] [-f] [-v] wholedisk

-a add partition devmappings
-r devmappings will be readonly
-d del partition devmappings
-u update partition devmappings
-l list partitions devmappings that would be added by -a
-p set device name-partition number delimiter
-g force GUID partition table (GPT)
-f force devmap create
-v verbose
-s sync mode. Don't return until the partitions are created`

xmount

xmount allows you to convert on-the-fly between multiple input and output harddisk image types. xmount creates a virtual file system using FUSE (Filesystem in Userspace) that contains a virtual representation of the input image. The virtual representation can be in raw DD, DMG, VHD, VirtualBox's virtual disk file format or in VmWare's VMDK file format. Input images can be raw DD, EWF (Expert Witness Compression Format) or AFF (Advanced Forensic Format) files. In addition, xmount also supports virtual write access to the output files that is redirected to a cache file. This makes it possible to boot acquired harddisk images using QEMU, KVM, VirtualBox, VmWare or alike.

https://www.pinguin.lu/xmount

I can provide additional detail and info if required or needed.

Improve this answer
7
  • I admire your enthusiasm, but: I've checked the devices I've got here, none of them has those commands available. Guessed from your links, those are tools available for Linux – but the partitions to investigate are on Android devices, as described, and cannot be accessed that directly from a Linux machine. Moreover: mapping a partition to a device doesn't reveal what's on it (system? data? boot?), so kpartx is out. xmount doesn't sound like solving that either.
    – Izzy
    Commented Dec 24, 2014 at 17:32
  • I really thought i was onto something. I tried. Thank you for replying so quickly. Will keep my nose to the grindstone.
    – HasH_BrowN
    Commented Dec 24, 2014 at 17:36
  • I'm thankful for your efforts! It's just that the results don't match, sorry. Imagine the following: I need to grab the /recovery partition from a running device. That's not mounted in normal mode. How do I figure which partition to pick? With the above, I had to pick them all, and find out later. Produces far too much data, and takes too long.
    – Izzy
    Commented Dec 24, 2014 at 17:40
  • 1
    That DiskInfo app will show you the unmounted recovery partition. I just checked, mine (HTC One V) is mmcblk0p21. Its pretty detailed for an app.
    – HasH_BrowN
    Commented Dec 24, 2014 at 17:45
  • 1
    My sentiment, but where. Probably not listed/stored the way we're looking for.
    – HasH_BrowN
    Commented Dec 24, 2014 at 17:49
0

DiskInfo will be the app you want. It will show all mount points, plus all unmounted, and all temp partitions.

This is just a graphical interface, with no other real functionality. Perfect for your need. This does require to be used on fully booted device. Root is not needed.

Screenshot
Screenshot (click for larger variant)

Improve this answer
5
  • 1
    Sorry, absolutely no. You must have missed the command-line tag :) Guess I'll better write that explicitly. I know a number of apps showing these details, but I need to access/gather them via adb shell, and without the help of an additional app (cannot always first install that on a device handed to me).
    – Izzy
    Commented Dec 24, 2014 at 10:01
  • Ooops. It wont hurt my feelings, want me to delete this ( so no misdirection )?
    – HasH_BrowN
    Commented Dec 24, 2014 at 16:01
  • Only if you feel the need. Could be useful for someone else looking for the same details by "other means". Otherwise I had marked it "NAA" (not-an-answer) ;) I won't downvote it (it might give the requested details, I didn't check – does it show which partition holds what, as described in my question?) – but won't upvote/accept it either ;)
    – Izzy
    Commented Dec 24, 2014 at 16:57
  • Yes it will show what the partition is for (containing), it just wont show the actual contents.
    – HasH_BrowN
    Commented Dec 24, 2014 at 17:39
  • 1
    That's fine, so from that point it matches! So please, do not delete this answer :)
    – Izzy
    Commented Dec 24, 2014 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .