我有一个 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 标头保持完整,则可能出现这种情况。