☰

卸载未受影响的 HDD 时，加密的 LVM 无法启动

tag-icon • tag-icon boot lvm kubuntu whole-drive-encryption
卸载未受影响的 HDD 时，加密的 LVM 无法启动

我有一个奇怪的问题我不明白。

我安装了 Kubuntu 19.04，其中包含加密 LVM 根的引导式安装。

lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                        8:0    0 465,8G  0 disk  
└─sda1                     8:1    0 465,8G  0 part  
sdb                        8:16   0 223,6G  0 disk  
├─sdb1                     8:17   0   731M  0 part  /boot
├─sdb2                     8:18   0     1K  0 part  
└─sdb5                     8:21   0 222,9G  0 part  
  └─sdb5_crypt           253:0    0 222,9G  0 crypt 
    ├─kubuntu--vg-root   253:1    0 221,9G  0 lvm   /
    └─kubuntu--vg-swap_1 253:2    0   980M  0 lvm   [SWAP]

sdb 是 SSD，sda 是 HDD。

sda只是不重要数据的海量存储并且没有加密。

cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/kubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdb1 during installation
UUID=5502e3df-bf98-4ec3-9277-0b2d22308be2 /boot           ext4    defaults        0       2
/dev/mapper/kubuntu--vg-swap_1 none            swap    sw              0       0

和

/dev/sda1: UUID="86b8c281-dc71-4102-92b5-070843eb2784" TYPE="ext4" PARTUUID="998890db-01"
/dev/sdb1: UUID="5502e3df-bf98-4ec3-9277-0b2d22308be2" TYPE="ext4" PARTUUID="4b7c5ebc-01"
/dev/sdb5: UUID="85e69429-53aa-4348-83d9-cb2b68128ec4" TYPE="crypto_LUKS" PARTUUID="4b7c5ebc-05"
/dev/mapper/sdb5_crypt: UUID="ysVfBL-KvGw-tce2-g1ko-5cUu-ichc-31kfCO" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root: UUID="8995e215-a95b-499c-b83d-a12987e20600" TYPE="ext4"
/dev/mapper/kubuntu--vg-swap_1: UUID="72f9eb33-6d0e-4f86-9c3e-d1eb5e83aa63" TYPE="swap"

所以恕我直言，一切应该如果我卸载 sda 就可以了，即 86b8c281-dc71-4102-92b5-070843eb2784。但如果我这样做，系统将无法启动。事实上，如果我查看 BIOS/UEFI，实际上我是从 HDD 启动，而不是 SSD。

如果我将启动设备更改为 SSD 或卸下 HDD，则不会发生任何情况（除了左上角屏幕上闪烁的下划线之外，我无法读取/写入任何内容）

有人知道这里有什么问题（或者我理解）吗？

附加信息：

cat /etc/crypttab 
sdb5_crypt UUID=85e69429-53aa-4348-83d9-cb2b68128ec4 none luks,discard

答案1

PARTUUID 值的语法表明您的磁盘可能正在使用 MBR 分区和经典 BIOS 样式引导。这些症状表明您的引导加载程序实际上被写入sda而不是写入sdb，即使您的/boot分区是sdb1。这是因为在基于 BIOS 的系统中，操作系统安装程序不一定能知道 BIOS 将按哪个顺序查看磁盘，并且通常会假设第一个检测到的磁盘 ( sda) 是 BIOS 将从中引导系统的磁盘。

当您删除 时sda，您将没有基于 MBR 的功能性引导加载程序，不幸的是您的系统 BIOS 无法为此提供良好的错误消息。

假设您使用默认的 GRUB 引导加载程序，它会嵌入到实际的主引导记录以及 MBR 和第一个分区开头之间的空间中。因此它不是一个常规文件，不能作为一个文件进行移动或以其他方式进行操作。

然而，这个问题很容易解决。

首先，您应该编辑该/boot/grub/device.map文件：

(hd0) /dev/sdb

这将告诉 GRUB 安装工具（您很快就会使用）：“安装新的 GRUB 实例时，假设当前的磁盘sdb将是系统上第一个检测到的磁盘。”这很重要，因为我们正准备sda从系统中删除。

成功修改文件后，您应该运行：

sudo grub-install /dev/sdb

这不会对您现有的 GRUB 实例造成任何损害，但会向sdb.

现在您应该能够移除磁盘sda，并且系统仍然可以正常启动。

由于原始sda磁盘现在已被删除，该sdb磁盘可能会显示为，除非 Kubuntu 有一种保存磁盘设备名称的机制（在这种情况下，您可能会在 处找到将名称与磁盘sda关联的记录）。因此，您应该再次编辑以匹配新的系统状态（或者干脆删除该文件）：sdb/etc/udev/rules.d//boot/grub/device.map

(hd0) /dev/sda

如果/当安装了 GRUB 更新时，这将很重要。

相关内容