无法在 luks 卷内挂载使用 mkudffs 创建的 UDF 文件系统

Question

我正在尝试创建加密的蓝光备份。我已经使用以下粗略的脚本创建并刻录了图像：

imgsize=23000M
imgfile=~/backup.img
imgloop=`sudo losetup -f`
truncate -s $imgsize $imgfile
sudo losetup $imgloop $imgfile
sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop
sudo cryptsetup luksOpen $imgloop mybackup
sudo mkudffs /dev/mapper/mybackup
if [ ! -d "/mnt/backup" ]; then
    sudo mkdir /mnt/backup
fi
sudo mount /dev/mapper/mybackup /mnt/backup

# Now copy all files that are part of the backup
echo "Copy files to backup to /mnt/backup. Type 'ready' when done";
while read line; do
    echo "$line";
    if [ "$line" == "ready" ]; then
        break;
    fi
done

sudo umount /mnt/backup
sudo cryptsetup luksClose /dev/mapper/mybackup
sudo losetup -d $imgloop

脚本完成后，我使用以下命令将其刻录到 M-Disc BD-R：

growisofs -dvd-compat -Z /dev/dvd=backup.img

刻录无故障完成。我可以使用以下方法打开 luks 卷：

sudo cryptsetup luksOpen /dev/dvd mybackup

哪个生产设备/dev/mapper/mybackup；但是，当我尝试使用以下方法安装它时：

sudo mount -t udf /dev/mapper/mybackup /mnt/backup

我收到以下错误：

mount: /dev/mapper/mybackup is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

syslog 包含以下错误：

[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found
[ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1)

更新 1

使用以下命令，我可以挂载脚本生成的图像：

sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

所以出了问题，因为它在光盘上。

Answer 1

失败的最可能原因是介质在为 LUKS 打开时的只读限制。

下面的实验表明 cryptsetup 的选项 -r 可以解决问题：

sudo cryptsetup luksOpen -r /dev/dvd mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

第一个错误理论：

光学媒体和数据文件或磁盘设备之间的主要区别是 2048 字节的块大小。例如，分区编辑器在检查 isohybrid DVD 的分区表时会对此感到困惑。也许 LUKS 也同样依赖于加密和解密具有相同的底层设备块大小。

如果您使用 BD-RE 媒体，那么您可以尝试直接在 /dev/dvd 上而不是在文件 ~/backup.img 中创建加密文件系统是否有帮助。（大量随机访问的性能会很差。您的 RAM 缓冲区可能会将其他虚拟内存推到一边并使其使用程序运行缓慢。同步或卸载可能会持续很长时间。

如果您使用 BD-R，那么您可以使用 BD-RE 创建映像，然后将其复制到 BD-R 介质。

如果没有任何效果，我可以提供 xorriso 的 -external_filter 功能，该功能将在将文件内容放入具有明文目录树的 ISO 9660 文件系统时对其进行加密。与 LUKS 的隐私不同，但另一方面没有那么异国情调。

（你到底为什么要使用 UDF？你有 Solaris 或 BSD 机器，它们的 UDF 驱动程序可能比它们的地下 ISO 9660 驱动程序更好吗？或者目标阅读器系统可以不使用 ext 吗？）

我应该遵循的跟踪：

网络上关于 LUKS 和 CD/DVD/BD 的一些问题报告建议使用 cryptsetup 选项 -r 作为灵丹妙药。（即只读而不是块大小将成为绊脚石。）

确保光学介质与 LUKS 配合使用：

我尝试了我的提案中的 BD-RE 部分，以在具有 2K 块（又名扇区）的设备上创建。BD-RE 位于 /dev/sr4 中。将其设置为加密磁盘：

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4
sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre

为了避免在运行 xorriso 时需要成为超级用户，我将出现的设备文件提供给我所在的组“cdrom”：

chgrp cdrom /dev/dm-0

使用 xorriso 编写 ISO。您将制作一个 UDF 并填充它：

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory /

这太慢了，可能是由于 BD-RE 缺陷管理，xorriso 无法通过加密设备层对其进行影响。我通过 tar 和（因为我拥有它）通过 xorriso 进行了检查：

sudo mount /dev/mapper/mybdre /mnt/iso
tar cf - /mnt/iso | wc

没有 i/o 错误，报告 ISO 内容的预期大小。

sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --

报告 ISO 会话的 MD5 匹配。所以这会奏效。现在必须有人投资 BD-R 并将 BD-RE 复制到其中。

磁盘文件和BD的块大小差异无关紧要：

我应该先尝试这个。但是现在我按照你的处方，只是我将加密的图像复制到了 BD-RE（对于 BD-R 来说仍然太节俭了）。

有用。我可以使用 -t udf 挂载 BD-RE 并将文件内容 tar 到 wc。

因此，关于只读媒体上的 cryptsetup 选项 -r 的传闻似乎是唯一合理的理论。

用 CD-RW 代替 BD-R 取得成功：

我尝试使用未格式化的 CD-RW，它被 Linux 视为只读。

sudo cryptsetup luksOpen /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

永远不会再这样做了。驱动器被内核丢弃。/var/log/messages 行之一说 Linux 试图写入它。唯一的好处是它在 USB 盒中。所以我可以通过电源循环来恢复它。

使用选项 -r 可以正常工作：

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc