我曾经dd将 Arch linux 映像刻录到 U 盘，但现在我需要在同一个 U 盘上存储其他文件。之后usb棒是只读的，dd所以我决定手动格式化。该记忆棒被识别为可引导，但拱形无法加载系统，因为它正在寻找标有“ARCH_201912”的磁盘。据我所知，我可以使用-nflag 和mkfs.fat这样的命令：
mkfs.fat -F 32 -n "$label" "$partition"
我只是不想手动输入它，因为它每个月都会改变（我正在编写 bash 函数）。并且dd不知何故知道标签应该是什么并将其正确设置为 USB 设备。我以为有一个文件存储了这个值，所以我发出：
$ grep --directories=recurse ARCH_201912 .
./arch/boot/syslinux/archiso_pxe.cfg:APPEND archisobasedir=arch archisolabel=ARCH_201912 archiso_nbd_srv=${pxeserver}
./arch/boot/syslinux/archiso_sys.cfg:APPEND archisobasedir=arch archisolabel=ARCH_201912
Binary file ./EFI/archiso/efiboot.img matches
./loader/entries/archiso-x86_64.conf:options archisobasedir=arch archisolabel=ARCH_201912
有没有办法在不解析文件的情况下获得这个标签（因为它似乎archisolabel是特定于 arch linux 的）？我希望这种方法适用于 linux 和 windows。虽然我不确定 Windows 10 是否需要正确的标签集。
标签实际上并未以任何特殊方式设置在设备上。它只是文件系统元数据的一部分（它本身作为常规数据存储），并与所有其他文件系统结构一起被盲目复制。
它没有。如果发生这种情况，要么是在文件系统级别（可能映像仅包含不支持写入的文件系统，例如 ISO9660 在设计上是只读的），要么驱动器的物理寿命已结束（通常是便宜的 USB 记忆棒）做）。
是的。“纯”.iso 文件仅包含 CD 使用的 ISO9660 文件系统——维护者可以使用工具将其转换为包含 BIOS MBR 引导加载程序和 FAT32 或类似文件系统的混合映像。
（或者维护者当然可以跳过 .iso 部分，直接从头构建一个常规的“dd-able”磁盘映像。）
磁盘没有标签。分区可以有标签，也可以有文件系统。USB记忆棒唯一的一点是它们通常只有一个分区（和一个文件系统），因此它的标签通常被视为磁盘的标签。
这两种标签都存储在磁盘本身上，作为常规数据。（分区标签确实存储在 UEFI GPT 分区表中，但您通常看不到它们。）
文件系统标签——你看到的通常类型——存储在文件系统元数据中，例如在 Ext4 头文件或 FAT32 主文件表中。
但是，标签并不存储为实际文件——在 FAT32 中，它是一种特殊的 MFT 记录类型；在其他文件系统中，它是一个专用的文件系统头字段。
在 Linux 上，您需要使用具有相应 CLI 工具的libblkid
blkid。该库可以从数十种文件系统类型中提取基本信息（文件系统标签、UUID）。但是，blkid 需要 root 权限才能读取物理设备，因此您需要使用 udev 从 udev 获取缓存的数据
lsblk，而留下blkid图像文件。