不能随便改UUID，因为它是文件系统创建时写入超级块的唯一标识，内核、/etc/fstab、GRUB、systemd等均依赖其精准识别设备；强行篡改会导致mount失败、系统启动卡在dracut阶段、blkid输出错乱；安全修改仅限ext2/3/4用tune2fs（需先umount），XFS不支持改UUID，只能重格式化。
不能直接“修改”已有文件系统的 UUID，只能通过重新格式化或使用特定工具重生成——且多数情况下不建议手动改 UUID，除非明确知道后果。
为什么不能随便改 UUID？
UUID 是文件系统创建时写入超级块（superblock）的唯一标识，内核、/etc/fstab、GRUB、systemd 等都依赖它做设备识别。强行篡改（比如用十六进制编辑器硬改）极易导致：
-
mount失败或挂载错分区 - 系统启动卡在
dracut阶段（找不到 root 或 /boot） -
blkid输出混乱，lsblk -f显示 UUID 与实际不一致
真正安全的“修改”方式只有两种：重新格式化（清空数据），或对 ext2/3/4 使用 tune2fs（XFS 不支持）。
ext2/3/4 分区怎么换 UUID？
仅适用于未挂载的 ext 类型分区（如 /dev/sdb1）。已挂载的必须先 umount，根分区等无法卸载的严禁操作。
- 查看当前 UUID：
blkid /dev/sdb1 - 生成新 UUID 并写入：
tune2fs -U random /dev/sdb1（推荐）或tune2fs -U 123e4567-e89b-12d3-a456-426614174000 /dev/sdb1（指定值） - 验证：
blkid /dev/sdb1，确认输出已更新
⚠️ 注意：tune2fs 对 XFS、Btrfs、swap 分区无效；-U 参数在较老的 e2fsprogs 版本中可能不支持 random，可改用 time 或 clear（后者会清空 UUID，不推荐）。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
XFS 分区能改 UUID 吗？
不能。XFS 的 UUID 是只读元数据，由内核在 mkfs.xfs 时固化，xfs_admin 只能改 label（卷标），不能动 UUID。
- 查 label：
xfs_admin -l /dev/sdb1 - 设 label（需先卸载）：
xfs_admin -L mydata /dev/sdb1 - 若真需要新 UUID，唯一办法是：
mkfs.xfs -f /dev/sdb1（彻底清空并重建）
所以如果你看到网上说 “xfs_admin -U”，那是错的——这个参数根本不存在。
改完 UUID 后必须同步哪些地方？
UUID 变了，所有引用它的配置都得手动更新，漏一项就可能起不来：
-
/etc/fstab中对应行的UUID=xxx值 -
/etc/crypttab（如果用了 LUKS 加密） -
/boot/grub2/grub.cfg或/boot/grub2/grubenv（尤其是 root=UUID=... 参数） - systemd 的 mount unit（如果用了自定义
.mount文件）
最稳妥的做法：改完 UUID 后，运行 grub2-mkconfig -o /boot/grub2/grub.cfg 并 dracut -f 重建 initramfs，再 reboot 测试。
真正容易被忽略的是：改 UUID 后，/dev/disk/by-uuid/ 下的软链接会自动刷新，但旧 UUID 的残留软链接不会自动删除——这本身不影响功能，但若有人靠 ls -l /dev/disk/by-uuid/ 手动找设备，可能误判。
