我在某处读到，不建议将引导分区放在基于lvm的分区上。但是，无论如何我都在做。那么，我遇到的唯一问题有时是当我安装一个新的Linux发行版并将其引导分区放在lvm上时，grub无法检测到它。该grub-mkconfig命令通常在生成grub.cfg文件时出错。但是，如果这是基于lvm的启动分区上的唯一问题，我认为还可以。因为我知道如何修复它，所以只需为要启动的启动分区提供适当的地址即可启动，然后一切正常。
那么，LVM可能会导致问题吗？因为在我看来，lvm非常灵活，并且不会降低系统速度。
Answers:
这不是性能问题，而是故障排除和解决问题。/boot是引导程序的位置-其中有一些文件会启动系统中的所有其他文件。
有时您需要在那里戳一下以解决问题（例如grub config或类似的东西）。
如果必须执行此操作，则使用最低公分母的文件系统很有用，例如在必须卸下驱动器并将其放在另一个框中以编辑配置文件的情况下，使它尽可能地容易。
如果您处于这个位置，那么您就不必为了能够阅读LVM而将其“压入”生活。
对我来说，如您所说，如果grub无法检测到您的LVM /boot文件系统，并且 grub-mkconfig通常在生成时出错grub.cfg，这似乎是避免该配置并切换到grub支持更好的东西的充分理由。当您说“只为预期的引导分区提供适当的地址”时，我不知道您所说的“地址”是什么意思，或者您实际上是在做什么，但实际上，这听起来像是一个可怕而脆弱的黑客。
作为基本且实际上是必需的功能，引导加载程序可以访问简单磁盘分区上的简单文件系统，并从那里加载下一阶段。这就是它真正需要做的。引导加载程序中的更多功能（例如解析LVM之类的容器以及在预引导环境中处理多个磁盘）仅意味着需要在grub中复制更多的Linux（内核）功能（更多代码，更多错误），但永远不会完全在两种环境下（更混乱）和更复杂的整体工作方式相同。对于引导程序，越简单越好。
grub-mkconfig在提供根路径上犯了错误/dev/dm-0。因此，我将其更改为/dev/mapper/lvm-kali--bootmycase的正确路径。
root=<path>），与位置无关/boot。grub-mkconfig绝对不应该出错。它应该对应于的输出grub-probe --target=device /。
/dev/mapper/lvm-kali--root不是boot。错字
/dev/mapper/lvm-kali--root开始！
我在Fedora上使用LVM“ /”文件系统中的“ / boot”目录已有数年之久，从来没有遇到过问题。
您只需要注意制作单个物理磁盘，其中“ /”位于卷组中的单个物理磁盘上。我有一个用于该物理驱动器的“ vgmain”卷组，其余的则是一个“ vgdata”。如果您需要在故障排除情况下将驱动器运送到另一台计算机，这很重要。如果LVM由多个物理驱动器组成，则将无法工作。但是，如果它仅由一个组成，它将成为可能。
但是我从来没有经历过这种故障排除情况。
最新的Fedora安装不会让您自动执行此操作。在安装过程中，必须将“ / boot”放在常规分区中，然后正常启动，然后将内容手动移动到LVM“ /”文件系统。确保您将内容重组为看起来像“ / boot”作为LVM“ /”下的普通目录，并将“ / boot2”作为旧的引导分区，然后进行“ grub install / dev / sda”或类似的操作。重新引导，然后删除“ / boot2”文件系统，并将分区包括回到LVM，以使其可用。