☰

“file”命令正确识别我的 LUKS 设备，但内核看不到它

tag-icon • tag-icon linux luks block-device cryptsetup uuid
“file”命令正确识别我的 LUKS 设备，但内核看不到它

我最近创建了一个原生 4MiB 的 LUKS2 设备--offset。该file命令正确识别设备并列出其 UUID，但它既不会在启动时自动打开，也不可见/dev/disk/by-uuid/...（即使在之后update-initramfs）。

手动运行cryptsetup open按预期工作，但cryptdisks_start无法打开它。它UUID=与/etc/crypttab我的其他设备一样被指定。使用“父”块设备路径而不是其 UUID 是有效的。

检查xxd显示正确的幻数（偏移量 0 处的“LUKS”），并且标头以与我的其他 LUKS2 设备相同的偏移量开始（其中是正确检测到）。为什么无法检测到该设备？我该怎么做才能通过其 UUID 打开它？

答案1

从技术上讲，这里的内核没有问题。这里唯一涉及的内核是dmcrypt由配置的设备映射器设备cryptsetup。

cryptsetup能够根据存储在块设备上的元数据来配置设备映射器设备，因此也没有错误。

事实上，没有/dev/disk/by-uuid存储在那里的 LUKS 设备条目指向udev或任何负责发现 LUKS 设备的条目（另请参阅 的输出udevadm info /dev/the-block-device）。

udev使用blkid（例如，内置版本请参阅/lib/udev/rules.d/60-persistent-storage.rulesDebian 中的规则）来了解这些内容。

就您的情况而言，blkid报告TYPE="jmicron_raid_member"。如果它是 RAID 阵列成员，则不应直接访问它，因此blkid不要尝试报告内部可能存储的内容是正确的。

如果这不是一个jmicron_raid_member，那么也许它只是碰巧仍然包含某些 RAID 配置的签名，例如因为 SSD 曾经连接到 PC，并且在 BIOS 中将 ATA 模式设置为 RAID 而不是 AHCI（并且您blkdiscard在重新使用它之前忘记运行） 。或者也许最后 512 个字节恰好是J第 511 个字节M。

为了blkid 停止检测它，jmicron_raid_member如果您确定它不是故意的，并且最后一个 512 字节单元没有被任何东西使用，您需要擦除 RAID 签名，这对于 jmraid 来说显然是在块设备的最后512字节单元中找到，或者手动使用类似的东西：

size=$(blockdev --getsize -- "$dev") &&
  dd if=/dev/zero of="$dev" seek="$((size - 1))" count=1

或者使用util-linux' wipefs：

wipefs -t jmicron_raid_member -- "$dev"

列出签名。

wipefs -a -t jmicron_raid_member -n -- "$dev"

显示它将删除什么。

wipefs -a -t jmicron_raid_member -- "$dev"

擦掉。

相关内容