最直接方式是运行blkid /dev/nvme0n1p3，它直接读取文件系统superblock，不依赖挂载状态，输出包含UUID和LABEL；如需纯字符串，可用blkid -s UUID -o value /dev/nvme0n1p3和blkid -s LABEL -o value /dev/nvme0n1p3。
用 blkid 查指定分区的 UUID 和 LABEL 最直接
要确认某一分区（比如 /dev/nvme0n1p3）当前的 UUID 和 LABEL，blkid /dev/nvme0n1p3 是最准、最快的方式。它读的是文件系统 superblock，不依赖挂载状态，也不需要提前 mount。
常见现象：普通用户运行时，若输出为空或 Permission denied，说明该设备节点权限受限（常见于 LVM 或加密卷），加 sudo 即可；但多数物理分区无需 root 就能查到。
- 输出形如：
/dev/nvme0n1p3: UUID="a1b2c3d4-..." TYPE="ext4" LABEL="data" - 只取 UUID 字符串（无引号、无空格）：
blkid -s UUID -o value /dev/nvme0n1p3 - 只取 LABEL：
blkid -s LABEL -o value /dev/nvme0n1p3
lsblk -f 看 UUID/LABEL 与挂载点的对应关系
当你需要同时确认「哪个挂载点对应哪个 UUID」，或者想快速核对分区是否已挂载并带标签，lsblk -f 比 blkid 更直观——它把设备树、文件系统类型、LABEL、UUID 和 MOUNTPOINT 放在同一行展示。
注意：未挂载且没设 LABEL 的分区，lsblk -f 的 UUID 列可能为空（哪怕 blkid 能查到），因为它的输出逻辑会过滤掉部分未激活字段。
- 只显示关键列：
lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINT - 机器可解析用 JSON：
lsblk -J -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINT - 如果某行
FSTYPE为空，基本说明该分区还没格式化（file -s /dev/xxx会返回data）
修改 LABEL 后如何确认生效
修改 LABEL 不等于改 UUID，操作也更安全。对 ext4 分区，用 e2label；对 xfs，用 xfs_admin -L；vfat/fat32 用 fatlabel。改完必须卸载再重挂，或用 udevadm trigger 刷新内核缓存。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
容易踩的坑：改完不刷新，lsblk -f 或 /dev/disk/by-label/ 还显示旧值；blkid 可能立刻反映新 LABEL（因它直读 superblock），但 udev 规则同步有延迟。
- ext4 示例：
sudo e2label /dev/sdb1 "backup_disk" - xfs 示例：
sudo xfs_admin -L "backup_disk" /dev/sdb1 - 验证是否写入成功：
sudo blkid /dev/sdb1（看输出中 LABEL= 是否更新） - 验证 udev 是否同步：
ls -l /dev/disk/by-label/，检查链接目标是否指向正确设备
修改 UUID 后必须同步更新 /etc/fstab
UUID 是文件系统级属性，修改后原 fstab 中的挂载项会失败（启动卡住或 fallback 到 emergency mode）。tune2fs 只支持 ext2/3/4；xfs 不允许改 UUID，只能 mkfs.xfs 重建。
关键动作不是“改完就完事”，而是「改 → 验证 → 更新 fstab → 测试挂载」四步缺一不可。漏掉最后一步，重启可能进不了系统。
- ext4 修改 UUID：
sudo tune2fs -U random /dev/sdb1（卸载状态下执行） - 获取新 UUID：
sudo blkid -s UUID -o value /dev/sdb1 - 编辑
/etc/fstab，把旧 UUID 替换为新值（别只改一行，用grep UUID= /etc/fstab全局检查） - 测试：
sudo mount -a，无报错才算真正生效
真正麻烦的不是命令本身，而是改 UUID 后忘记更新 fstab，或者更新了 fstab 却没验证 mount -a —— 这类问题在无人值守服务器上会导致重启失败，得靠救援模式修复。
