O volume LVM fica inativo após a reinicialização do CentOS

Eu reinstalei um servidor Linux do CentOS 6 ao 7. O servidor possui 3 unidades - uma unidade SSD do sistema (que hospeda tudo, exceto /home) e duas unidades de disco rígido de 4 TB que hospedam /home. Tudo usa LVM. As duas unidades de 4 TB são espelhadas (usando a opção raid no próprio LVM) e são completamente preenchidas com a partição / home.

O problema é que, embora os discos de 4 TB sejam reconhecidos corretamente e o LVM veja o volume sem problemas, ele não o ativa automaticamente. Todo o resto é ativado automaticamente. Eu posso ativá-lo manualmente e funciona.

Tenho uma imagem da unidade antiga do sistema em / home. Isso também contém volumes LVM. Se eu montá-lo com kpartx, e o LVM os pega e os ativa. Mas não vejo diferença entre esses volumes e os inativos.

O sistema de arquivos raiz também é LVM, e é ativado muito bem.

Eu vejo uma coisa peculiar: a execução lvchange -aayme diz que eu preciso especificar quais unidades eu quero ativar. Também não faz isso automaticamente. Se eu especificar lvchange -ay lv_home- isso funciona.

Não consigo encontrar nada que possa ser responsável por esse comportamento.

Adicionado: notei que o sistema antigo (que usava init) tinha vgchange -aay --sysinitem seus scripts de inicialização. O novo usa systemd e não vejo a vgchangechamada em seus scripts. Mas também não sei onde colocá-lo.

Adicionado 2: Começando a descobrir o systemd. Eu descobri onde os scripts estão localizados e comecei a entender como eles são chamados. Também descobri que eu podia ver os scripts executados com systemctl -al. Isso mostra que, após iniciar, lvmetadele chama pvscancada dispositivo de bloco udev conhecido. No entanto, nesse ponto, há apenas um dispositivo de bloco udev registrado e esse é um dos volumes lvm reconhecidos. Os discos rígidos também estão lá, mas sob caminhos diferentes e nomes muito mais longos. O dispositivo de bloco reconhecido é algo como 8:3, enquanto os discos rígidos são /device/something/. Como não estou mais no servidor, não posso escrevê-lo com precisão (isso será corrigido mais tarde).

Eu acho que tem algo a ver com udev e detecção / mapeamento de dispositivos. Continuarei à noite e estudarei o udev então.

Se tudo mais falhar, encontrei o script que chama pvscane verifiquei que posso modificá-lo para verificar todos os dispositivos o tempo todo. Isso resolve o problema, mas parece um hack feio, então tentarei descobrir a verdadeira causa raiz.

Adicionado 3 : OK, ainda não sei por que isso acontece, mas pelo menos fiz uma solução razoavelmente aceitável. Eu fiz outro serviço systemd que chama pvscanuma vez, logo após iniciar lvmetad. A outra chamada para o dispositivo específico ainda está lá, e eu acho que é assim udevque chama (esse é o único lugar em que encontrei referência a ele). Por que não chama isso para os outros discos rígidos - não faço ideia.

Eu fiz isso! Eu fiz isso! Eu consertei corretamente (eu acho).

Aqui está a história:

Depois de algum tempo, o servidor mostrou-se defeituoso e teve que ser descartado. Eu mantive discos e recebi tudo o mais. Em seguida, reinstalei o CentOS novamente no SSD e conectei os HDDs. O LVM funcionou bem, os discos foram reconhecidos, a configuração mantida. Mas o mesmo problema surgiu novamente - após uma reinicialização, o volume estava inativo.

No entanto, desta vez, percebi outra coisa - o carregador de inicialização passa os seguintes parâmetros para o kernel:

crashkernel = auto rd.lvm.lv = centos / root rd.lvm.lv = centos / swap rhgb quiet

Hmm, espere um minuto, aqueles parecem familiares !

Consulta rápida do Google, e aqui estamos :

rd.lvm.lv =

somente ative os volumes lógicos com o nome fornecido. rd.lvm.lv pode ser especificado várias vezes na linha de comando do kernel.

Bem agora. Isso explica tudo!

Portanto, a resolução foi (coletada de várias outras consultas do Google):

1. Modifique /etc/defaults/grubpara incluir o volume adicional nos parâmetros:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
2. Reconfigure o grub com grub2-mkconfig -o /boot/grub2/grub.cfg
3. Reconfigure o initramfs com mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Nota: seus valores podem variar. Use uname -rpara obter essa versão do kernel. Ou apenas leia mkinitrd. (Francamente, não sei por que essa etapa é necessária, mas aparentemente é - tentei sem ela e não funcionou)
4. E, finalmente, reinstale o grub: grub2-install /dev/sda
5. Reinicie, naturalmente.

TA-DA! O volume está ativo na reinicialização. Adicione fstabe divirta-se! :)

Atualização secundária (para RHEL 7 na máquina EFI (não BIOS) ):

Eu tenho sucesso usando estas etapas:

1. Modifique /etc/defaults/grubpara incluir o volume adicional nos parâmetros: rd.lvm.lv=rhel/home(além de rhel/roote rhel/swap)

2. Reconfigure o grub com

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

   ( nota: outro caminho!)

3. Reconfigure o initramfs com

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

4. Ignorar reinstalar grub: grub2-install /dev/sda(porque eu tenho um dir vazio /usr/lib/grub/)
5. Reinicie, naturalmente.

Eu tive esse problema também. No meu caso, foi uma combinação de iscsi, multipath e lvm e a ordem de criação da sessão etc. Resolvi o problema adicionando uma chamada /sbin/vgchange -a ypara /etc/rc.local.

Então, tentei a configuração rd.lvm.lv = em / etc / default / grub e isso não funcionou

Eu precisava que os dois volumes lógicos no grupo de volumes ssd_vg estivessem ativos na inicialização. Assim como o volume lógico home_lv no kubuntu-vg para estar ativo

O que funcionou foi editar /etc/lvm/lvm.conf Na seção da lista de volumes, coloque isso em volume_list = ["ssd_vg", "kubuntu-vg / home_lv"]

resultado após a reinicialização

$ sudo lvscan inativo Original '/ dev / kubuntu-vg / root' [50.00 GiB] herdar

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

Pela minha parte, comentei esta linha em /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Porque, se estiver ativo, apenas os volumes vg00 e vg01 estarão ativos na inicialização.

A documentação do 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" ]