拿到一个完整的磁盘镜像文件，想在宿主机上直接读取里面的某个分区，或者从存储阵列新映射回来一个LUN，fdisk -l明明能看到分区，mount /dev/sdb1却提示没有这个设备——这种问题在Linux环境下特别常见，尤其是刚接触多路径和镜像处理的人，十有八九会卡在这里。原因很简单：内核没有自动为这些“非典型块设备”建立分区节点。而kpartx就是专门解决这个问题的工具，它能把分区表里的每个分区映射成独立的/dev/mapper/设备，让mount、pvscan这些命令直接可用。
这篇文章我从实际运维和开发的经验出发，把kpartx的原理、常用参数、完整操作步骤和典型的坑全部梳理一遍，覆盖整盘镜像挂载、多路径SAN磁盘、LVM嵌套分区等场景。无论你是刚接触Linux命令的初学者，还是正在处理嵌入式rootfs镜像的运维、测试工程师，都能直接照着操作，少走弯路。
1. kpartx到底解决了什么问题
1.1 分区表与“不可见的子设备”
先说清楚一个底层逻辑。在Linux的设备模型里，整个硬盘是一个块设备，比如/dev/sda、/dev/loop0。它上面的每个分区，正常情况下会对应一个独立的子设备节点，比如/dev/sda1、/dev/sda2。这些子设备节点不是平白无故出现的，而是内核在扫描到磁盘上的分区表之后，由内核的分区解析代码自动创建的。
那问题来了：同样是块设备，为什么挂载loop设备或某些多路径设备时，/dev/loop0p1不出现？因为内核扫描分区表这件事，在不同类型的块设备上表现并不一致。本地直连的SCSI/SATA硬盘，驱动在上线时就会触发分区扫描；但loop设备挂载一个镜像文件时，内核往往只把这个文件当作一个“完整磁盘”加载，并不会自动解读里面的分区布局。多路径设备更特殊，它本身是device mapper（DM）创建出来的虚拟块设备，分区信息到了这一层可能就断掉了。
打个比方，分区表就像一本书的目录，硬盘是整本书，分区是各个章节。kpartx相当于一个“翻译员”，它把目录内容读取出来，然后告诉内核“第1章从这里开始，长度是多少”，内核据此创建一个可直接访问章节内容的独立设备。没有它，你只能看到整本书，却无法单独打开某一章。
1.2 为什么不是partprobe或partx
很多人会问：Linux下有partprobe、partx，为什么还要用kpartx？这个问题我在实际工作中被问过很多次，它们确实都能“让内核重新读取分区表”，但侧重点和使用范围差别不小。
| 工具 | 工作机制 | 典型适用场景 | 局限 |
|---|---|---|---|
| partprobe | 通知内核重新读取指定块设备的分区表 | 本地SCSI/SATA磁盘修改分区后刷新 | 对loop设备、DM设备有时不生效 |
| partx | 直接向内核添加/删除分区，不依赖DM | 轻量操作，适合脚本里快速添加分区 | 不会为DM设备生成命名映射节点 |
| kpartx | 读取分区表并用device mapper创建映射 | loop设备、多路径、镜像文件、LVM | 需要依赖device-mapper内核模块 |
partprobe的工作原理是向内核发送重新读取分区表的请求，内核如果“搭理”你，就会重新扫描并更新分区信息。问题是，很多loop设备和由DM创建的虚拟设备根本没有实现这个ioctl接口，内核“不搭理”，分区自然出不来。partx则是直接操作内核的分区表结构，逻辑上更轻，但对于多路径设备这种“设备之上还有设备”的层级，它生成的分区节点往往不够持久，名字也不符合/dev/mapper/的约定。
而kpartx走的是另一条路：它不依赖内核自动扫描，而是自己解析分区表，然后用device mapper这个内核模块手动建立映射。映射完成后，每个分区都变成一个新块设备，出现在/dev/mapper/下面。这种方式几乎不受设备类型限制，所以它在镜像处理、多路径场景中几乎是事实标准。
1.3 常用场景总览
根据我自己的使用经验，kpartx的高频场景主要有下面几类：
- 挂载整盘镜像：比如嵌入式开发的SD卡镜像、虚拟机导出的raw格式磁盘文件，想读取内部某个分区的内容。
- 处理备份系统镜像：用Clonezilla（再生龙）这类工具备份出来的磁盘镜像，需要离线查看或恢复文件。
- 多路径SAN LUN：存储阵列映射的LUN经multipath聚合后，分区节点不会自动创建，需要kpartx补上。
- LVM嵌套场景：分区内部还有LVM物理卷，先用kpartx把分区映射出来，再跑pvscan/vgchange。
- KVM虚拟化：离线修改qcow2或raw格式的guest磁盘，得先把分区表映射出来再挂载。
这几个场景，我在后面会挑两个最有代表性的，从零开始完整走一遍流程。
2. 安装与核心参数详解
2.1 不同发行版上的安装方式
kpartx的基础依赖是device-mapper内核模块，几乎所有主流Linux发行版都内置了这个模块，所以剩下的工作就是把用户态工具装上。
# Debian / Ubuntu sudo apt install kpartx # RHEL / CentOS / Rocky sudo yum install kpartx # 某些最小化安装环境需要先安装EPEL仓库 # openSUSE / SLES sudo zypper install kpartx需要注意，在RHEL系里，kpartx通常被包含在device-mapper-multipath包里，所以你的机器上可能已经存在这个命令。验证方法很简单：
kpartx -v如果能输出版本号，就说明环境准备好了。我遇到过最小化安装的Ubuntu服务器上默认没有kpartx的情况，所以装完系统先确认一下，免得真正处理镜像的时候抓瞎。
2.2 关键参数逐个拆解
kpartx的命令行参数不算多，但每一个都挺重要。我用一个表把最常用的列出来，后面每个参数都会配上实操示例。
| 参数 | 作用 | 示例 |
|---|---|---|
| -l | 列出分区映射，只读操作，不做实际修改 | kpartx -l /dev/loop0 |
| -a | 添加分区映射 | kpartx -av /dev/loop0 |
| -d | 删除分区映射 | kpartx -dv /dev/loop0 |
| -u | 更新分区映射，分区表发生变化时使用 | kpartx -uv /dev/loop0 |
| -p | 自定义映射设备名前缀，默认是p | kpartx -ap myprefix /dev/loop0 |
| -r | 只读方式创建映射，适合不想写坏镜像的场景 | kpartx -ar /dev/loop0 |
| -v | 显示详细输出 | kpartx -av /dev/loop0 |
| -f | 强制操作，跳过一些提示检查 | kpartx -af /dev/loop0 |
| -s | 同步模式，在调用结束后确保DM表已更新 | kpartx -as /dev/loop0 |
这里最值得强调的两个参数是-p和-s。
-p控制生成的映射前缀。默认情况下，kpartx把设备名后面直接拼一个p再加分区号。例如原始设备是/dev/loop0，默认映射就是/dev/mapper/loop0p1。如果你指定-p part，映射名就变成/dev/mapper/loop0part1。这个特性能解决一个实际问题：某些设备名本身以数字结尾，比如/dev/mapper/3600xxx，如果默认加p，生成的名称是3600xxxp1，没问题；但如果你面对的设备名里包含了一些特殊字符（像/dev/mapper/mpatha这种也正常），想用更易读的名字时，-p就非常灵活。
-s则更关键。kpartx执行完不保证DM映射立刻对用户态可见，尤其在高并发或脚本快速连续调用的时候，可能会出现“命令返回成功但mount立刻运行时设备还没出现”的情况。加上-s，它会等待DM设备真正ready再返回。写自动化脚本时，我建议始终加上这个参数。
2.3 分区映射的工作原理
很多人用kpartx，但不清楚它底层到底做了什么。简单说，kpartx读取分区表（MBR或GPT都能识别），解析出每个分区的起始扇区和长度，然后调用device mapper的ioctl接口，创建一个名为loop0p1（或对应名字）的映射设备，并告诉内核：“这个设备的线性地址空间，对应到/dev/loop0的某个区间”。
用dmsetup table /dev/mapper/loop0p1可以查看这条映射关系，输出大概是这样的：
0 204800 linear 7:0 2048这串数字的含义是：从映射设备的第0个扇区开始，长度204800个扇区，线性映射到底层设备（主设备号7，次设备号0，也就是loop0）的第2048个扇区。如果有多个分区，kpartx会为每个分区分别建立一条这样的映射。这种“把子区间暴露为独立块设备”的机制，正是device mapper的核心能力之一，kpartx只是把分区解析和DM调用封装成了一个方便的命令行工具。
3. 实例一：挂载完整的磁盘镜像
3.1 准备镜像与loop设备
最常见的需求就是挂载一个整盘镜像，比如从嵌入式开发板导出的rootfs.img，或者用再生龙备份出来的磁盘镜像。先假设我们手头有个镜像文件叫rootfs.img，第一步是把它挂载成loop设备。
# 查看镜像文件类型 file rootfs.img # 查看可用的loop设备 losetup -f # 挂载为loop设备 sudo losetup /dev/loop0 rootfs.img # 确认分区表信息 sudo fdisk -l /dev/loop0在执行到fdisk -l时，你能看到类似下面的输出：
Disk /dev/loop0: 2 GiB, 2147483648 bytes, 4194304 sectors ... Device Boot Start End Sectors Size Id Type /dev/loop0p1 * 2048 2099199 2097152 1G 83 Linux /dev/loop0p2 2099200 4194303 2095104 1023M 82 Linux swap / Solaris注意，fdisk -l的输出里已经显示了分区信息，但/dev/loop0p1这个设备节点其实并不存在。这就是我开头说的那种情况——用户态工具能读到分区表，但内核没有为这个loop设备自动创建子设备。如果你这时候直接执行mount /dev/loop0p1 /mnt，系统会明确告诉你找不到这个设备。
3.2 用kpartx创建映射并挂载
接下来就是kpartx上场。执行添加映射：
sudo kpartx -av /dev/loop0输出类似：
add map loop0p1 (253:2): 0 2097152 linear 7:0 2048 add map loop0p2 (253:3): 0 2095104 linear 7:0 2099200这两行信息说明两个分区的映射都创建好了。第一行的253:2是这个新映射设备的主次设备号，7:0是底层loop设备的设备号。此时你再去ls /dev/mapper/loop0*，能看到loop0p1和loop0p2出现在里面。
然后正常挂载分区：
sudo mkdir -p /mnt/rootfs sudo mount /dev/mapper/loop0p1 /mnt/rootfs如果你平时习惯看lsblk输出，此时也能看到这套设备层级关系：loop0下面多了两个分区子设备，类型是dm，挂载点已经指向/mnt/rootfs。
这里有个细节：千万不要图省事直接mount /dev/loop0 /mnt，因为loop0对应的是整个“磁盘”，而磁盘的开头是分区表和引导扇区，不是文件系统超级块，mount会直接报错“wrong fs type”或“superblock无法读取”。分区映射设备才是真正对应文件系统区间的块设备。
3.3 卸载并清理映射
处理完镜像，正确的收尾操作很重要。顺序不能乱：
# 1. 卸载文件系统 sudo umount /mnt/rootfs # 2. 删除kpartx映射 sudo kpartx -dv /dev/loop0 # 3. 解绑loop设备 sudo losetup -d /dev/loop0执行kpartx -dv后，/dev/mapper/loop0p1这些节点应该被移除。如果发现设备还在，多半是有进程占用，或者LVM缓存还在引用。确认没有进程占用之后再尝试，实在不行可以查一下dmsetup ls，看还有没有遗留映射。
注意：删除映射前一定要先umount，这个顺序看起来理所当然，但真的有人图省事，直接losetup -d，结果文件系统数据都没落盘，轻则镜像损坏，重则重要数据丢失。别踩这个坑。
3.4 使用losetup -P的差异化说明
新版本内核的losetup提供-P参数，可以在挂载loop设备时强制扫描分区。比如：
sudo losetup -P /dev/loop0 rootfs.img执行后，内核会尝试自动创建/dev/loop0p1这样的分区节点。这看起来比kpartx直接，确实在很多发行版上有效。但我在CentOS 7上就遇到过兼容性问题，某些内核版本结合特定的镜像分区类型时，-P并没有生效。而且losetup -P创建出来的分区节点在清理时也需要更加小心的处理方式，包括losetup -d时可能提示设备忙。
我的个人习惯是：脚本操作还是用kpartx，兼容性更广，行为更可控，命名也比内核自动生成的规则更稳定。但了解losetup -P的存在很有必要，至少在检查问题来源时，能知道那些loop0p1设备可能从哪来。
4. 实例二：SAN/LUN与多路径磁盘的分区映射
4.1 多路径环境下为什么必须用kpartx
多路径环境我多说几句。存储阵列把LUN映射给主机，主机上同一个LUN可能通过两个HBA卡看到，于是系统里出现/dev/sdb和/dev/sdc两个设备，但它们是同一个后端LUN。DM-Multipath的作用是把这些重复路径合并成一个逻辑设备，比如/dev/mapper/mpatha，或者以WWID命名的/dev/mapper/3600c0ff000...。
问题在于，LUN本身划分了分区，fdisk -l /dev/mapper/mpatha能看到mpatha1、mpatha2，但/dev/mapper/mpatha1经常不存在。这是因为设备映射器创建的聚合设备，不会像物理磁盘那样自动触发上层的分区扫描。多路径设备或SAN环境，这个现象非常普遍，重装系统、扩容磁盘时到处都能碰到。
这时候kpartx的作用就体现出来了。
4.2 多路径LUN分区映射的完整操作
假设我们有一个多路径设备/dev/mapper/3600c0ff000d4a3a123456789，先看看它的分区情况：
# 查看多路径拓扑 sudo multipath -ll # 查看分区信息 sudo fdisk -l /dev/mapper/3600c0ff000d4a3a123456789输出显示里面有1和2两个分区。此时ls /dev/mapper/下面没有对应的分区映射设备。开始添加映射：
sudo kpartx -av /dev/mapper/3600c0ff000d4a3a123456789因为设备名很长，而且不以普通字母结尾，生成的映射名默认是3600c0ff000d4a3a123456789p1。如果你觉得这个名字太长不利于脚本操作，可以用-p指定一个短前缀：
sudo kpartx -ap mpath- /dev/mapper/3600c0ff000d4a3a123456789执行后，/dev/mapper/mpath-1和mpath-2就出现了。
如果分区内部还有LVM物理卷，多路径+分区+LVM三层嵌套时，还需要让LVM重新扫描新出现的分区设备：
sudo pvscan sudo vgchange -aypvscan会扫描所有块设备发现物理卷，而kpartx刚创建的映射设备正是它需要的“新块设备”。如果没有先做kpartx映射，LVM几乎不可能直接发现LUN里嵌着的卷组，这也是很多人配置SAN存储后重启主机找不到vg的直接原因。
4.3 清理与持久化配置
多路径设备上的分区映射，清理时要格外小心。如果有文件系统挂载，必须首先umount；如果上面还有激活的LVM卷组，得先vgchange -an停用卷组，然后再执行kpartx -dv。
sudo umount /mnt/san_data sudo vgchange -an vg_san sudo kpartx -dv /dev/mapper/3600c0ff000d4a3a123456789正因为多路径LUN经常需要跨重启保持分区映射状态，所以持久化配置也是实际运维里绕不开的。方法有几种：
- 将多路径服务设为开机自启，然后在multipath.conf里配置
user_friendly_names yes，让设备名稳定。 - 在
udev规则中加入对DM_MULTIPATH_DEVICE_PATH的判断，匹配特定WWID后自动执行kpartx命令。 - 写一个简单的systemd服务，启动顺序排在
multipathd之后，开机自动执行kpartx -a。
注意，不要所有LUN都一股脑做自动映射。生产环境里，有些LUN可能是有意不挂载的，比如单独留给数据库裸设备使用、跨主机共享卷、或者后续要重新分区。自动映射所有分区反而容易造成误操作，建议精确到WWID或路径前缀。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
kpartx本身不复杂，但我这几年用下来，碰到的问题集中在下面几个地方。整理成表格，遇到问题直接对号入座。
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| kpartx -av执行后无任何输出 | 镜像或磁盘上没有可识别的分区表 | 先执行fdisk -l确认分区存在，检查偏移是否异常 |
| 报错No partitions found | GPT分区头损坏或MBR保护分区表异常 | 用gdisk修复分区表，或检查是否误传了文件系统镜像而非整盘镜像 |
| add map提示设备已存在 | 之前添加过映射没删除 | 执行kpartx -d，或用dmsetup remove手动移除残留映射 |
| mount时提示wrong fs type | 尝试挂载的是loop0整盘而非分区映射 | 挂载/dev/mapper/loop0p1，而不是/dev/loop0 |
| 删除映射时提示Device or resource busy | 文件系统仍被占用或LVM仍激活 | umount后再次尝试，LVM场景先vgchange -an |
| 更新分区表后映射不生效 | kpartx映射还是旧的 | 先kpartx -d删除，再kpartx -a重新添加，或用-u更新 |
| 脚本里mount到设备还来不及出现 | 缺少同步等待 | 添加-s参数，确保DM设备ready后再mount |
5.2 排查步骤与独家经验
遇到问题别急着重试，我一般按下面这个顺序排查。
第一步，lsblk看设备层级全貌，确认分区映射设备是否已经创建。第二步，kpartx -l /dev/设备名只读预览分区表，确认kpartx能看到什么。第三步，dmsetup table /dev/mapper/xxxx看映射表内容，确认偏移和大小是否符合预期。第四步，dmesg | tail看内核日志，有时候问题出在底层的I/O错误或设备状态异常，光看用户态输出是找不到答案的。
再说两个独家经验。
第一个经验是，处理qcow2镜像时不要想着直接对qcow2文件执行kpartx。kpartx面对的是块设备或raw格式的镜像文件，它不认qcow2这种带格式头的文件。处理qcow2，要么先用qemu-img convert转成raw，要么用qemu-nbd通过NBD导出，再对/dev/nbd0执行kpartx。直接对qcow2文件跑kpartx大概率得到“无法识别分区表”的结论。
第二个经验是，在自动化脚本里，建议把kpartx的一套操作封装成函数，每次都先kpartx -l检查，再决定是否添加。别小看这一步check，它可以避免重复添加导致的“设备已存在”报错，也能提前暴露分区表损坏的问题。简单的封装可以参考下面这样：
add_partmap() { local dev="$1" if ! kpartx -l "$dev" > /dev/null 2>&1; then echo "NO_PARTITION_TABLE" return 1 fi kpartx -adv "$dev" || return 1 dmsetup sync }这个函数先把分区表验证放在前面，用-adv打开详细输出和同步模式，最后再调用一次dmsetup sync作为兜底，确保映射表已经刷到内核。实际用下来，比单纯执行一条kpartx命令稳定得多。
5.3 GPT分区与UEFI引导分区的特殊场景
现在GPT分区表已经是绝对主流，尤其是在UEFI启动环境里，大部分磁盘都是GPT格式。kpartx对GPT的支持很完善，MBR和GPT都能正常解析。不过有个细节需要留意：GPT分区表本身有主备份两份分区表，如果备份表损坏，kpartx可能会解析出异常结果。遇到GPT分区相关的错误，先用gdisk -l验证分区表完整性。
另一个容易忽略的点是：很多UEFI镜像里会有一个100MB-500MB的EFI System Partition（ESP），它通常是FAT16或FAT32文件系统。如果你挂载完镜像，发现/dev/mapper/loop0p1挂上去之后里面是/EFI目录而不是/boot或/，那说明你挂载的是ESP分区，得继续找根文件系统所在分区，别误以为镜像损坏了。整盘镜像一般包含ESP、rootfs、swap等多个分区，先lsblk -f看每个分区的文件系统类型，再决定挂哪个。
6. 结语：一点使用体会
最后说点个人感受。kpartx这个命令看起来简单，远没有iptables、LVM那些工具那么复杂，但在实际运维中它的价值一点不小，尤其是处理镜像读取、多路径磁盘这类“普通手段够不着”的场景，它几乎是唯一顺手的选择。用熟了以后，你会发现它的设计思路非常清晰：不干预分区，不自动挂载，只做一件事——把分区暴露成为块设备，剩下的交给更上层的工具。
我平时写脚本处理磁盘镜像，已经习惯性地把kpartx作为固定环节：losetup挂载整盘、kpartx建立分区映射、mount具体分区、处理完按反顺序清理。这套流程在本地虚拟机镜像、嵌入式开发板rootfs、多路径存储LUN上都反复用过，稳定可靠。如果你也有类似需求，记住几个关键点就够了：操作前先用-l预览，添加时带-v确认结果，脚本里务必加-s，收尾时先umount再-d。把这几点变成肌肉记忆，kpartx基本上不会再给你带来任何困扰。
