我破坏了linux luks分区，并在启动时获得initramfs，没有错误msg。

Question

我已经为这个问题搜索了类似的10+小时，但是还没有找到解决办法，所以我就在这里:/

长话短说，我破坏了我的主要linux引导驱动器(它有luks加密)，在一个活动的usb引导下缩小它的大小，以便为双引导窗口分区腾出更多的空间。

一切都很好，直到我引导到我的电脑，在那里我解密我的驱动器，但在我的磁盘解密后，我遇到了一个initramfs控制台，没有日志只是(initramfs)

我经历过多种方法，但我可以从我的调查中扣除：

*我的驱动器有一个有效的luks头(我知道密码)*驱动器上有有效的超级块*输入initramfs中的exit，只表示不能找到/dev/ (等等)没有任何暗示

我将将一些结果写入可能有助于解决此问题的命令。就像几周前，我搬到了linux，所以这对我来说是新的:/

我正在实时引导下输入这些命令。我的主linux分区位于sda3上。希望这能有所帮助。

root@pop：~# lsblk

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                                           7:0    0     2G  1 loop  /rofs
sda                                             8:0    0 223.6G  0 disk  
├─sda1                                          8:1    0   498M  0 part  
├─sda2                                          8:2    0     4G  0 part  
├─sda3                                          8:3    0 146.5G  0 part  
│ └─luks-077248fb-b2bf-4ddb-9762-3c69af031c2c 253:0    0 146.5G  0 crypt 
├─sda4                                          8:4    0     4G  0 part  [SWAP]
└─sda5                                          8:5    0    67G  0 part  /media/pop-os/c
sdb                                             8:16   0   1.8T  0 disk  
├─sdb1                                          8:17   0    16M  0 part  
└─sdb2                                          8:18   0   1.8T  0 part  
sdc                                             8:32   1  14.5G  0 disk  
├─sdc1                                          8:33   1   2.1G  0 part  /cdrom
├─sdc2                                          8:34   1     4M  0 part  
└─sdc3                                          8:35   1  12.3G  0 part  /var/crash

root@pop：~# sudo blkid _ grep LUKS

/dev/sda3: UUID="077248fb-b2bf-4ddb-9762-3c69af031c2c" TYPE="crypto_LUKS" PARTUUID="fa8127eb-222e-48ab-93ba-23fde42b29bf"

root@pop：~# sudo blkid _ grep LVM2 2

/dev/mapper/luks-077248fb-b2bf-4ddb-9762-3c69af031c2c: UUID="FMjQHW-a72R-7Z4K-37pV-dioz-vvIb-QJsKhm" TYPE="LVM2_member"

root@pop：~# sudo fdisk -l /dev/sda3 3

Disk /dev/sda3: 146.5 GiB, 157286400000 bytes, 307200000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@pop：~#密码设置luksDump /dev/sda3 3

[luks header in full]

root@pop：~# sudo mke2fs -n -n

mke2fs 1.45.5 (07-Jan-2020)
/dev/mapper/luks-077248fb-b2bf-4ddb-9762-3c69af031c2c contains a LVM2_member file system
Proceed anyway? (y,N) y
Creating filesystem with 38395904 4k blocks and 9601024 inodes
Filesystem UUID: 5eedce5b-bea9-405e-85ed-0316ea3ba13c
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

<#>root@pop：~#文件-s /dev/sda3 3

/dev/sda3: LUKS encrypted file, ver 2 [, , sha256] UUID: 077248fb-b2bf-4ddb-9762-3c69af031c2c

当试图解密并打开实时引导文件管理器上的分区时，它将返回以下内容：

错误安装/dev/dm-1在/media/pop-os/<8num>-<4num>-<4num>-<4num>-<12num>：错误fs类型、坏选项、/dev/mapper/data-root上的坏超级块、缺少代码页或辅助程序或其他错误。

我仍然有标题，所以它应该是可恢复的，但是如果我不能恢复整个事情，我想知道如何得到我的/home dir。谢谢您抽时间见我。

Answer 1

mke2fs -n运行表明加密的卷/dev/mapper/luks-077248fb-b2bf-4ddb-9762-3c69af031c2c包含一个LVM物理卷，而不仅仅是一个文件系统。因此，解锁加密卷(必要时使用cryptsetup luksOpen )之后的下一步应该是扫描LVM组件，然后在它们处于良好状态时激活它们。

由于您说您已通过缩小卷破坏了卷，它可能是可检测的，但可能不会自动激活，因为LVM和相关的udev自动化通常只会自动激活VGs，而不会出现错误。因此，在活动环境中，您需要以下命令：

vgscan
vgchange -Pay --activationmode partial

这将告诉系统查找LVM卷组(包括刚刚解锁的加密卷)并激活它们，即使它们似乎缺少部分。您可能会从这些命令中看到诊断、警告和/或错误消息。

如果VG拒绝激活，因为LVM物理卷声称大于它包含的LUKS加密卷，那么您可能需要首先将LUKS容器扩展到缩小它之前的大小。

如果这些命令成功，那么至少应该有一个LVM逻辑卷可供安装，这取决于您的系统是如何配置的。使用命令lvs和/或lsblk查看它们:您可以将LVM逻辑卷定位为/dev//或/dev/mapper/-。

根据实时引导文件管理器的错误消息，我猜您的LVM卷组的名称是data，其中的根文件系统LV名为root。

如果是这样的话，那么下一步可能是确认文件系统类型，因为它可能不是ext4，而是xfs或btrfs，这取决于您的Linux发行版和安装时可能做出的选择。所以：

file -Ls /dev/mapper/data-root

如果文件系统类型是ext4，那么响应应该类似于：

/dev/mapper/data-root: Linux rev 1.0 ext4 filesystem data, UUID=12345678-abcd-1234-abcd-123456789abcd, volume name [...]

如果文件系统类型为xfs，则响应应该类似于：

/dev/mapper/data-root: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

如果文件系统类型不是ext4、ext3或ext2，那么e2fsck和任何其他特定于D19文件系统类型家族will的文件系统工具都不适用于。尝试使用它们可能是有害的。

如果file命令无法识别文件系统类型，那么可能是因为文件系统损坏了--或者仅仅是因为您的Linux环境比实际安装更老/更有限，并且不完全支持该特定的文件系统类型。

如果可以成功地识别文件系统类型，您应该可以尝试并使用以下方法挂载您的文件系统：

mount -o ro /dev/mapper/data-root /mnt    #or whatever you want to use as a mount point

如果您有多个LVM逻辑卷，那么它们现在都应该以相同的方式挂载。