Article directory
This article is original by Rocky Watching the World (guyongqiangx), please indicate the source for reprinting.
Article link: https://blog.csdn.net/guyongqiangx/article/details/129785777
0. Introduction
0.1 background
Android 10(Q) began to introduce dynamic partitioning. The partition information in the super device is stored in the lpmetadata of the head. When the device is abnormal, it is often necessary to check the partition status. The dynamic partitioning tool lpdump is the most commonly used tool.
The default source code of lpdump is located at:system/extras/partition_tools/lpdumpd.cc
When compiling the Android source code, the host and android versions of lpdump will be compiled by default, running on x86 PC and Android device respectively.
For the host version (x86 PC), lpdump is located in the following two directories:
- out/soong/host/linux-x86/bin/lpdump
- out/host/linux-x86/bin/lpdump
When running, you need to specify the path directly, or export the path to the environment variable PATH.
For lpdump on the target version (Android device), the compiled file is located at:
- out/target/product/xxx/system/bin/lpdump
After burning the image, the device is located in /system/bin/the directory .
0.2 Chapter Guide
If you just want to know the detailed usage of lpdump, please go to Section 2, which introduces in detail the various operations of using lpdump to parse super files and partitions;
If you are curious about where lp_metadata information may be stored on the system, please go to Section 3;
If you encounter errors when running lpdump on your PC, please go to Section 4 to see if it is the cause of the path;
For more information about the list and content of Android OTA upgrade related articles, please refer to "Android OTA Upgrade Series Column Guide"
If you have already subscribed to the paid column, please be sure to add me on WeChat, and I will pull you into the Q&A group of the corresponding column.
This article is based on the Android code version: android-11.0.0_r21, but subsequent versions are similar
Online code: http://aospxref.com/android-11.0.0_r21/
1. Function of lpdump
The use of lpdump is relatively simple, the following is the entire help information of the lpdump tool.
console:/ # lpdump -h
lpdump - command-line tool for dumping Android Logical Partition images.
Usage:
lpdump [-s <SLOT#>|--slot=<SLOT#>] [-j|--json] [FILE|DEVICE]
Options:
-s, --slot=N Slot number or suffix.
-j, --json Print in JSON format.
-d, --dump-metadata-size
Print the space reserved for metadata to stdout
in bytes.
-a, --all Dump all slots (not available in JSON mode).
lpdump takes a FILE or DEVICE argument and can be used to:
-
View the partition information of non-sparse format files generated by lpmake, such as super_empty.img or super.img
The super.img generated by Android is in sparse format by default, it needs to be converted to raw format before it can be viewed with the lpdump tool
-
View the partition information of a file or device with lpmetadata, such as the partition information of the super device
2. Example of lpdump usage
2.1 sparse format conversion
lpdump can only parse images in non-sparse format. If you run lpdum on x86 PC for parsing, you need to use simg2img to convert super.img in sparse format generated by Android compilation into raw format.
$ simg2img out/target/product/xxx/super.img out/super_raw.img
Here, in order to make the path shown later shorter, save the super file in raw format to the out directory.
The full name of simg2img is sparse image to image
2.2 Example of file parsing
-
Parse the partition information of Slot 0 by default
$ lpdump /public/android-r/out/super_raw.img -
Parsing the partition information of Slot 1
$ lpdump -slot 1 /public/android-r/out/super_raw.img -
Parse all partition information
$ lpdump -a /public/android-r/out/super_raw.img -
Parse partition information in an empty super image
# 使用相对路径 $ lpdump -a out/target/product/xxx/super_empty.img # 使用绝对路径 $ lpdump -a /public/android-r/out/target/product/inuvik/super_empty.img -
View the size of metadata
Metadata refers to the size of the entire metadata, there is no slot concept, regardless of slot 0 and 1, so there is no need to specify a slot.
# 查看空的 super image 中 metadata 的大小 # 相对路径 $ lpdump -d out/target/product/xxx/super_empty.img 1048576 # 绝对路径 $ lpdump -d /public/android-r/out/target/product/inuvik/super_empty.img 1048576 # 查看完整的 super image 中 metadata 的大小 $ lpdump -d /public/android-r/out/super_raw.img 1048576 -
Use json format to display metadata partition information
$ lpdump -j /public/android-r/out/super_raw.img
2.2 super device resolution example
-
By default, there is no parameter to parse the partition information of the current slot of the super device
# 查看当前 slot 信息，位于 slot b 即 slot 1 console:/ # getprop | grep slot [ro.boot.slot]: [b] [ro.boot.slot_suffix]: [_b] # 显示 super 设备上 slot 1 的分区信息 console:/ # lpdump Slot 1: Metadata version: 10.2 Metadata size: 716 bytes Metadata max size: 65536 bytes Metadata slot count: 3 Header flags: virtual_ab_device Partition table: ------------------------ Name: system_b Group: bcm_ref_b Attributes: readonly,updated Extents: 0 .. 2466951 linear super 2048 ------------------------ Name: vendor_b Group: bcm_ref_b Attributes: readonly,updated Extents: 0 .. 157239 linear super 2469888 ------------------------ Name: system_b-cow Group: cow Attributes: none Extents: 0 .. 887 linear super 2469000 888 .. 232767 linear super 2627128 ------------------------ Super partition layout: ------------------------ super: 2048 .. 2469000: system_b (2466952 sectors) super: 2469000 .. 2469888: system_b-cow (888 sectors) super: 2469888 .. 2627128: vendor_b (157240 sectors) super: 2627128 .. 2859008: system_b-cow (231880 sectors) ------------------------ Block device table: ------------------------ Partition name: super First sector: 2048 Size: 1463812096 bytes Flags: none ------------------------ Group table: ------------------------ Name: default Maximum size: 0 bytes Flags: none ------------------------ Name: bcm_ref_b Maximum size: 1459617792 bytes Flags: none ------------------------ Name: cow Maximum size: 0 bytes Flags: none ------------------------ console:/ # -
Parse the partition information of super device Slot 1
# 解析 super 设备的 slot 1 的分区信息 # 不使用绝对路径，字符串 super 会最终被补充为: /dev/block/by-name/super $ lpdump -slot 1 super # 使用绝对路径 $ lpdump -slot 1 /dev/block/by-name/super -
Parse all the partition information of the super device
# 使用相对路径 $ lpdump -a super # 使用绝对路径 $ lpdump -a /dev/block/by-name/super -
View the size of super device metadata
# 查看完整的 super image 中 metadata 的大小 # 使用默认的 super 设备 $ lpdump -d 1048576 # 不使用绝对路径 $ lpdump -d super 1048576 # 使用绝对路径 $ lpdump -d /dev/block/by-name/super 1048576 -
Use json format to display the partition information of super device metadata
$ lpdump -j /dev/block/by-name/super
3. Where will metadata be stored?
Do you know where on the device will store metadata similar to the header of the super device?
If you think that there is only the head of the super device, what I want to tell you here is that it is wrong~~ At least, it is not complete.
As far as I know, there are 3 possible places to store partition metadata in the Android system:
-
The default super device head stores the partition table information metadata of the super partition
-
After the device is remounted, Android 11 and later systems will
/metadata/gsi/remount/lp_metadatastore the metadata of the scratch partition.After Virtual A/B is enabled in Android R(11) and subsequent versions, space will be allocated from data to mount the overlay file system by default to generate a /scratch partition.
For more information about remount, please refer to: "Android Dynamic Partition Detailed Explanation (7) overlayfs and adb remount operation"
-
During the Virtual A/B system upgrade, the system will
/metadata/gsi/ota/lp_metadatastore the information of the cow file allocated under the /data directory
Have you increased your knowledge? Quickly use lpdump to analyze the lp_metadata in these places.
4. Error running lpdump on PC
A friend in the VIP Q&A group asked me about a partition error when running lpdump on a PC, for example:
$ simg2img out/target/product/inuvik/super.img out/super_raw.img
$ lpdump out/super_raw.img
lpdump E 03-26 16:58:57 1662664 1662664 reader.cpp:443] [liblp]std::unique_ptr<LpMetadata> android::fs_mgr::ReadMetadata(const android::fs_mgr::IPartitionOpener &, const std::string &, uint32_t) open failed: out/super_raw.img: No such file or directory
Failed to read metadata.
I have also encountered this error many times. Sometimes I use lpdump to work, sometimes it doesn't work, and I am often confused.
In fact, I didn't pay attention to this problem at first, thinking that it was because I didn't correctly skip the 4096 bytes at the beginning of super.
Beiming Youyu suggested that a complete absolute path needs to be provided.
4.1 Solutions
The correct way is to provide the absolute path of the image to lpdump for analysis, as follows:
$ lpdump /public/android-r/out/super_raw.img
However, there is an exception. If you are parsing an empty super image, such as the super_empty.img generated by Android's default compilation, you can also use a relative path:
$ lpdump out/target/product/xxx/super_empty.img
The reason is that lpdump will judge in advance whether it is an empy super image and parse it, which is not the same path as parsing a complete super image.
4.2 The source of the problem
By using lldb debugging, it is found that the root cause of this problem is:
When actually reading the metadata of a file or partition device, the full path of the file or partition will be path = GetPartitionAbsolutePath(partition_name)returned . as follows:
/* file: system/core/fs_mgr/liblp/partition_opener.cpp */
unique_fd PartitionOpener::Open(const std::string& partition_name, int flags) const {
/*
* 调用 GetPartitionAbsolutePath 获取 partition_name 指定的完整的绝对路径
*/
std::string path = GetPartitionAbsolutePath(partition_name);
return GetControlFileOrOpen(path.c_str(), flags | O_CLOEXEC);
}
The problem is in GetPartitionAbsolutePaththe function :
/* file: system/core/fs_mgr/liblp/partition_opener.cpp */
std::string GetPartitionAbsolutePath(const std::string& path) {
/*
* 1. 如果传入以 "/" 开始的绝对路径，则直接返回
*/
if (android::base::StartsWith(path, "/")) {
return path;
}
/*
* 2. 如果传入的不是绝对路径，则在前面添加 "/dev/block/by-name/"
* 例如，如果使用 lpdump out/super_raw.img 解析，
* 则在这里会变成: /dev/block/by-name/out/super_raw.img
*/
auto by_name = "/dev/block/by-name/" + path;
if (access(by_name.c_str(), F_OK) != 0) {
// If the by-name symlink doesn't exist, as a special case we allow
// certain devices to be used as partition names. This can happen if a
// Dynamic System Update is installed to an sdcard, which won't be in
// the boot device list.
//
// We whitelist because most devices in /dev/block are not valid for
// storing fiemaps.
/*
* 3. 如果传入的不是绝对路径，并且以 mmcblk 开头，则在前面添加 "/dev/block/"
* 例如：mmcblk0, 则会查找 /dev/block/mmcblk0 设备。
*/
if (android::base::StartsWith(path, "mmcblk")) {
return "/dev/block/" + path;
}
}
return by_name;
}
In short, GetPartitionAbsolutePath handles the path path like this:
-
If the path passed in is an absolute path, return path directly;
-
If the path passed in is not an absolute path, return /dev/block/by-name/path;
-
If a device like mmcblkx is passed in, /dev/block/mmcblkx is returned
4.3 Apologies for mistakes
Therefore, you will also encounter this error when you use lpdump to analyze super_raw.img on the host because of referring to "Android Dynamic Partition Details (2) Introduction to Core Modules and Related Tools" . The content in the screenshot below should be specially processed in order to simplify the path when I was writing. But I didn't expect that there would be problems after simplifying to relative paths.
Sorry if you encountered this problem referring to my blog.
Special thanks to Xiao for raising this question, and Beiming Youyu pointed out that the root of this problem is the need to provide an absolute path.
5. Other
So far, I have written about Android OTA upgrade related topics including:
- Basic introduction: "Android A/B System" series
- Core module: "Android Update Engine Analysis" series
- Dynamic Partitions: "Android Dynamic Partitions" series
- Virtual A/B: "Android Virtual A/B Partition" series
- Upgrade tools: "Android OTA related tools" series
For more information on these articles about Android OTA upgrades, please refer to "Introduction to Android OTA Upgrade Series Column Articles" .
If you have already subscribed to the dynamic partition and virtual partition paid column, please be sure to add me on WeChat, note the subscription account, and pull you into the "Dynamic Partition & Virtual Partition Column VIP Q&A Group". I will answer your questions about A/B systems, dynamic partitions, virtual partitions, various OTA upgrades and signatures at a convenient time.
In addition, I have an Android OTA upgrade discussion group, which now has 400+ friends, mainly discussing OTA upgrade topics for various devices such as mobile phones, car machines, TVs, set-top boxes, and tablets. If you are engaged in OTA upgrade work, welcome Join the group to communicate together, please indicate "Android OTA Discussion Group" when adding me on WeChat. This group is limited to Android OTA developers~
Reply "wx" in the backstage of the official account "Rocky Watching the World" to get personal WeChat.