你是否曾在配置Linux的/etc/fstab文件时,面对UUID和PARTUUID感到困惑?它们看起来都很相似,但又有什么不同?

这是一个非常重要的话题,因为它关系到系统能否正确和稳定地挂载所需的磁盘分区。
简单来说,UUID 标识的是文件系统本身,而 PARTUUID 标识的是磁盘上的分区。
特性 | UUID | PARTUUID |
|---|---|---|
标识对象 | 文件系统 (File System) | 分区 (Partition) |
生成方式 | 在创建文件系统时生成 (如 mkfs.ext4) | 在创建分区时生成 (如 fdisk, gdisk) |
更改条件 | 重新格式化分区会改变其 UUID | 重新分区会改变其 PARTUUID |
适用范围 | 几乎所有现代文件系统 (ext4, xfs, btrfs, ntfs, fat等) | 主要适用于 GPT 分区表,MBR 分区表支持有限 |
唯一性 | 全局唯一,用于区分不同的文件系统 | 全局唯一,用于区分不同的分区 |
你可以把一块硬盘想象成一栋大楼(磁盘)。
传统上,Linux 使用设备文件名来挂载分区,例如 /dev/sda1。但这种方式有一个致命的缺点:设备名是不稳定的。
例如,如果你在电脑上添加或移除了一块硬盘,系统检测硬盘的顺序可能会变,导致原本的 /dev/sda1 变成了 /dev/sdb1。如果你的 /etc/fstab 里写的是 /dev/sda1,系统在启动时就会找不到这个设备,从而无法正确挂载,导致系统无法启动或功能异常。
使用 UUID 或 PARTUUID 可以完美解决这个问题。因为它们是全局唯一的标识符,无论磁盘的设备名怎么变,系统总能通过这两个标识符找到正确的目标。
推荐使用顺序:UUID > PARTUUID > 设备名。绝大多数情况下,优先使用 UUID。
使用 blkid 命令是最简单直接的方法。这个命令需要 root 权限。
sudo blkid
输出示例:
/dev/sr0: BLOCK_SIZE="2048" UUID="2025-08-24-19-11-15-00" LABEL="Gentoo-amd64-20250824" TYPE="iso9660" PTTYPE="PMBR"
/dev/sda2: UUID="c30de363-3bdb-4cd1-9379-45748f03f74a" TYPE="swap" PARTUUID="fa2d6f7f-0042-4760-840e-504366e220da"
/dev/sda3: UUID="863c8b8c-af6f-422f-ba8b-86cc69e311da" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="a2f42279-8440-4010-8c71-a8be1203c676"
/dev/sda1: UUID="AFB7-FA56" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="38315cce-cf2f-44c2-867e-073109234dc1"
从输出中,你可以清晰地看到每个分区的 UUID 和 PARTUUID。

PARTUUID。/etc/fstab 文件的每一行定义了如何挂载一个文件系统。格式如下:
<文件系统标识> <挂载点> <文件系统类型> <挂载选项> <dump> <fsck>
使用 UUID 的语法:
UUID=a2f42279-8440-4010-8c71-a8be1203c676 / xfs defaults,noatime 0 1
使用 PARTUUID 的语法:
PARTUUID=a2f42279-8440-4010-8c71-a8be1203c676 /data xfs defaults,noatime 0 2
具体配置示例:假设我们想将 Ext4 格式的分区挂载到 /mnt/mydata。
使用 UUID:
# 查看UUID
sudo blkid | grep sdb1
# 假设输出:/dev/sdb1: UUID="a1b2c3d4-..." TYPE="ext4" ...
# 编辑fstab文件
sudo nano /etc/fstab
# 在文件末尾添加一行
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/mydata ext4 defaults 0 2
使用 PARTUUID:
# 查看PARTUUID
sudo blkid | grep sdb1
# 假设输出:/dev/sdb1: ... PARTUUID="abcdef12-34"
# 编辑fstab文件
sudo nano /etc/fstab
# 在文件末尾添加一行
PARTUUID=abcdef12-34 /mnt/mydata ext4 defaults 0 2
在修改完 /etc/fstab 后,千万不要直接重启!错误的配置可能导致系统无法启动。请务必使用以下命令测试:
# 重新加载fstab文件,尝试挂载所有未挂载的设备
sudo mount -a
# 检查是否成功挂载
df -h
ls /mnt/mydata # 查看挂载点下的内容
如果 mount -a 没有报错,并且 df -h 能看到你的新分区,说明配置成功。
通常你不必手动设置,但有时为了管理需要(如克隆系统后避免冲突),可以这样做。
Ext2/3/4 文件系统:
sudo tune2fs -U random /dev/sdXn # 生成一个随机UUID
sudo tune2fs -U a1b2c3d4-... /dev/sdXn # 设置成指定UUID
XFS 文件系统:
# XFS 的 UUID 无法在挂载状态下更改,需要先卸载
sudo umount /dev/sdXn
sudo xfs_admin -U generate /dev/sdXn # 生成随机UUID
Swap 分区:
sudo swapoff /dev/sdXn
sudo mkswap -U a1b2c3d4-... /dev/sdXn
警告: 更改一个已挂载文件系统的 UUID 可能会导致运行中的系统出现严重问题。最好在 Live CD/USB 环境下或确保分区未挂载时操作。
可以使用 gdisk 或 fdisk 工具。
使用 gdisk:
sudo gdisk /dev/sdX # 注意是磁盘,不是分区(如sda,不是sda1)
在命令行界面中,输入 x 进入专家模式,然后输入 c 来更改分区的 GUID(即 PARTUUID)。同样需要非常小心。
场景 | 推荐使用 |
|---|---|
绝大多数情况 | UUID。这是最常用、最可靠的方式,直接标识文件系统。 |
分区存在,但其文件系统经常被格式化/重做 | PARTUUID。例如,一个专门用于测试不同发行版的分区,你可能会频繁地将其格式化为 ext4, btrfs, xfs 等。使用 PARTUUID 可以避免每次格式化后都要修改 fstab。 |
MBR 分区表 | UUID。因为 PARTUUID 在 MBR 上的支持不如 GPT 广泛和统一。 |
GPT 分区表 | UUID 和 PARTUUID 均可,优先 UUID。 |
避免使用 | /dev/sdXx 这样的设备名。除非是临时挂载或者你非常确定磁盘顺序不会改变(例如在虚拟机中)。 |
最佳实践:
/etc/fstab 后,务必使用 sudo mount -a 进行测试。blkid 命令来准确获取标识符,不要手动拼写。掌握了UUID和PARTUUID的区别与使用方法,你就再也不用担心硬盘挂载问题了!这个小知识点虽然不起眼,却能在关键时刻避免系统无法启动的尴尬局面。
技术之美,往往藏在这些细节之中。