我的 luks 加密镜像解锁但无法挂载

我的 luks 加密镜像解锁但无法挂载

我有一个 LUKS 映像,我将重要文档解密、安装并保存到其中。直到最近,它在一台 Ubuntu 19 机器上运行良好。我在安装映像时关闭了这台机器,以为这样就没问题了。我已经用不同的硬件和 MX Linux 重建了一个新文件服务器。我尝试再次安装映像。我解锁了映像文件,但无法安装它。

图像文件创建如下:

dd if=/dev/zero of=s9_vault.img bs=1M count=4096
sudo cryptsetup -y luksFormat s9_vault.img 
sudo cryptsetup luksOpen s9_vault.img s9_vault
sudo mkfs.ext4 /dev/mapper/s9_vault

现在我有了新的文件服务器,我使用以下命令开始:

sudo cryptsetup luksOpen s9_vault.img s9_vault

Key slot 0 unlocked.
Command successful.

没有报告任何错误,因此看起来图像已正确解密。我继续安装:

sudo mount /dev/mapper/s9vault temp

此操作失败并显示以下错误消息:

mount: /home/XXX/temp: wrong fs type, bad option, bad superblock on /dev/mapper/s9vault, missing codepage or helper program, or other error.

我尝试使用 fsck 修复超级块:

sudo fsck /dev/mapper/s9vault
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/s9vault

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

因此我用 mke2fs 看了一下:

sudo mke2fs -n /dev/mapper/s9vault
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 1044480 4k blocks and 261120 inodes
Filesystem UUID: 6be51418-5a91-40b9-84aa-1459bb6f5a40
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736

我已经尝试了此列表中建议的每个超级块,但此错误消息仍然出现。

sudo e2fsck -b 32768 /dev/mapper/s9vault 
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/s9vault

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

我已经尝试过这些程序解剖刀照相记录看看他们是否能找到什么。两人都没有报告任何文件,这很奇怪。

未加密的图像是否可能被破坏,以至于 luks 仍然可以解密,但本质上是将一团糟解密为另一团糟?我在十六进制编辑器中查看了解密后的图像,它似乎大部分是随机的。

干杯

附加信息。我有一个备份,它使用 rsync 将文件从一个磁盘复制到另一个磁盘,其中包含此映像。我尝试使用备份副本,但出现了相同的错误。我想知道这是否是我使用的计算机的特殊之处。最初制作和安装此映像的机器已被处理掉,新的机器取而代之,其中包含旧机器的磁盘和数据。

答案1

首先让我们找到超级块备份的保存位置。

# mke2fs -n /dev/mapper/s9vault

在这个输出的底部,应该是备份的列表。

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

最后,从备份中恢复超级块,并block_number用第一个超级块备份替换。

# e2fsck -b区块编号/dev/mapper/s9vault

现在尝试挂载文件系统,您的超级块应该已修复。如果没有,请重复上述步骤,但恢复不同的超级块备份。

答案2

我猜想在 LUKS 设备上创建 ext4 文件系统和尝试重新使用它之间发生了“一些不好的事情”。例如,如果在设备上写入未加密的内容,而 LUKS 标头保持完整,则可能出现这种情况。

相关内容