CentOS重新启动后，LVM卷处于非活动状态

我已经从CentOS 6到7重新安装了Linux服务器。该服务器具有3个驱动器-一个系统SSD驱动器（除所有内容外，它托管所有内容/home）和两个托管的4TB HDD驱动器/home。一切都使用LVM。两个4TB驱动器已镜像（使用LVM本身中的raid选项），并且它们完全被/ home分区填充。

问题是，尽管可以很好地识别4TB磁盘，并且LVM可以看到该卷没有问题，但是它不会自动激活它。其他所有内容都会自动激活。我可以手动激活它，并且它可以工作。

我在/ home中有旧系统驱动器的映像。那也包含LVM卷。如果我使用安装它kpartx，则LVM会拾取并激活它们。但是我看不到那些卷和不活跃的卷之间没有区别。

根文件系统也是LVM，并且可以正常激活。

但是，我看到了一个奇特的事情：执行lvchange -aay告诉我，我需要指定要激活的驱动器。它也不自动执行。如果我指定lvchange -ay lv_home-可以。

我找不到任何可能导致此行为的原因。

补充：我注意到旧系统（使用init）包含vgchange -aay --sysinit在其启动脚本中。新版本使用systemd，但vgchange在其脚本中看不到该调用。但是我也不知道该放在哪里。

增加了2：开始找出systemd。我找到了脚本的位置，并开始了解它们的调用方式。还发现我可以通过看到执行的脚本systemctl -al。这说明启动后lvmetad它会调用pvscan每个已知的udev块设备。但是，此时只有一个注册的udev块设备，这是公认的lvm卷之一。硬盘也在那里，但是使用不同的路径和更长的名称。公认的块设备就像8:3硬盘一样/device/something/。我不再在服务器上了，所以我无法精确地编写它（稍后将解决此问题）。

我认为这与udev和设备检测/映射有关。我将在晚上继续学习，然后学习udev。

如果其他所有方法均失败，则我找到了调用的脚本，pvscan并检查了是否可以修改它以始终扫描所有设备。这可以解决问题，但是看起来很丑陋，因此，我将尝试找出真正的根本原因。

添加3：好吧，我仍然不知道为什么会这样，但是至少我做了一个相当可行的解决方法。pvscan在启动之后，我又做了一次调用一次的systemd服务lvmetad。该特定设备的另一个调用仍然存在，我认为实际上udev是它的调用（这是我找到对其的唯一引用）。为什么其他硬盘驱动器不调用它-我不知道。

我做的！我做的！我已正确修复（我认为）。

这是故事：

一段时间后，服务器出现故障，必须报废。我保留了磁盘，然后重新安装了其他所有内容。然后，我再次在SSD上重新安装了CentOS，然后连接了HDD。LVM运行良好，可以识别磁盘，并保留配置。但是，同样的问题再次出现-重新启动后，该卷处于非活动状态。

但是这次，我偶然发现了一些其他东西-引导程序将以下参数传递给内核：

crashkernel =自动rd.lvm.lv = centos / root rd.lvm.lv = centos /交换 rhgb安静

嗯，等等，那些看起来很熟悉！

快速谷歌查询，我们有：

rd.lvm.lv =

仅激活具有给定名称的逻辑卷。可以在内核命令行上多次指定rd.lvm.lv。

现在好了。那解释了！

因此，解决方案是（从另外几个Google查询中收集的）：

1. 修改/etc/defaults/grub以在参数中包括其他卷：crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
2. 用以下命令重新配置grub grub2-mkconfig -o /boot/grub2/grub.cfg
3. 用重新配置initramfs mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64。注意：您的值可能会有所不同。使用uname -r来获取内核版本。或者只是继续阅读mkinitrd。（坦率地说，我不知道为什么需要此步骤，但显然是这样-我尝试了此步骤，但没有成功）
4. 最后，重新安装grub： grub2-install /dev/sda
5. 自然重启。

TA-DA！该卷在重新启动后处于活动状态。添加到fstab并享受！:)

较小更新（对于EFI （非BIOS）计算机上的RHEL 7 ）：

我必须使用以下步骤来成功：

1. 修改/etc/defaults/grub以包括在参数中附加的体积：rd.lvm.lv=rhel/home（除了rhel/root和rhel/swap）

2. 用以下命令重新配置grub

   grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
   

   （注意：另一条路！）

3. 用以下命令重新配置initramfs

   mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r)
   

4. 跳过重新安装grub ：（grub2-install /dev/sda因为我的目录为空/usr/lib/grub/）
5. 自然重启。

我也有这个问题。在我的情况下，它是iSCSI的多径和LVM和会话创建等我加入了呼吁解决的问题排序的组合/sbin/vgchange -a y来/etc/rc.local。

所以我尝试了/ etc / default / grub中的rd.lvm.lv =设置，但是没有用

我需要ssd_vg卷组上的两个逻辑卷在引导时均处于活动状态。以及kubuntu-vg上的逻辑卷home_lv处于活动状态

所做的工作是编辑/etc/lvm/lvm.conf在“卷列表”部分，将其放入volume_list = [“ ssd_vg”，“ kubuntu-vg / home_lv”]

重新启动后的结果

$ sudo lvscan inactive原始'/ dev / kubuntu-vg / root'[50.00 GiB]继承

inactive          '/dev/kubuntu-vg/swap_1' [7.88 GiB] inherit

ACTIVE            '/dev/kubuntu-vg/home_lv' [1000.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap11' [50.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap12' [50.00 GiB] inherit

ACTIVE            '/dev/ssd_vg/root' [224.02 GiB] inherit

ACTIVE            '/dev/ssd_vg/swap_1' [7.88 GiB] inherit

就我而言，我在/etc/lvm/lvm.conf中注释了这一行

auto_activation_volume_list = [ "vg00", "vg01" ]

因为如果它处于活动状态，则引导时只有卷vg00和vg01处于活动状态。

lvm.conf的文档：

If auto_activation_volume_list is defined, each LV that is to be
activated with the autoactivation option (--activate ay/-a ay) is
first checked against the list. There are two scenarios in which
the autoactivation option is used:

  - automatic activation of volumes based on incoming PVs. If all the
    PVs making up a VG are present in the system, the autoactivation
    is triggered. This requires lvmetad (global/use_lvmetad=1) and udev
    to be running. In this case, "pvscan --cache -aay" is called
    automatically without any user intervention while processing
    udev events. Please, make sure you define auto_activation_volume_list
    properly so only the volumes you want and expect are autoactivated.

  - direct activation on command line with the autoactivation option.
    In this case, the user calls "vgchange --activate ay/-a ay" or
    "lvchange --activate ay/-a ay" directly.

By default, the auto_activation_volume_list is not defined and all
volumes will be activated either automatically or by using --activate ay/-a ay.

N.B. The "activation/volume_list" is still honoured in all cases so even
if the VG/LV passes the auto_activation_volume_list, it still needs to
pass the volume_list for it to be activated in the end.

If auto_activation_volume_list is defined but empty, no volumes will be
activated automatically and --activate ay/-a ay will do nothing.

auto_activation_volume_list = []

If auto_activation_volume_list is defined and it's not empty, only matching
volumes will be activated either automatically or by using --activate ay/-a ay.

  "vgname" and "vgname/lvname" are matched exactly.
  "@tag" matches any tag set in the LV or VG.
  "@*" matches if any tag defined on the host is also set in the LV or VG


Only activate vg00 and vg01 automatically.
auto_activation_volume_list = [ "vg00", "vg01" ]