O volume da LVM está inativo após a reinicialização do CentOS

Question

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

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

Eu tenho uma imagem da unidade do sistema antigo em / home. Isso também contém volumes de LVM. Se eu montá-lo com kpartx , e o LVM os pegar e ativá-los. Mas não vejo diferença entre esses volumes e os inativos.

O sistema de arquivos raiz também é LVM, e isso é ótimo.

Eu vejo uma coisa peculiar: executar lvchange -aay me diz que preciso especificar quais unidades quero ativar. Não faz isso automaticamente também. 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 --sysinit em seus scripts de inicialização. O novo usa o systemd e não vejo a chamada vgchange em seus scripts. Mas também não sei onde colocar isso.

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

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

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

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

    

Answer 1

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

Aqui está a história:

Após algum tempo, o servidor ficou com defeito e teve que ser descartado. Eu mantive discos e tenho tudo novo. Então eu reinstalei o CentOS novamente no SSD e, em seguida, conectei os HDDs. O LVM funcionou muito bem, os discos foram reconhecidos, a configuração mantida. Mas o mesmo problema surgiu novamente - depois de uma reinicialização, o volume ficou inativo.

No entanto, desta vez eu percebi algo mais - o bootloader 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, esses parecem FAMILIAR !

Consulta rápida ao google e lá estamos nós :

rd.lvm.lv=

only activate the logical volumes with the given name. rd.lvm.lv can be specified multiple times on the kernel command line.

Bem, agora. Isso explica isso!

Então, a resolução foi (obtida de várias outras consultas ao google):

1. Modifique /etc/defaults/grub para incluir o volume adicional nos parâmetros: crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rd.lvm.lv=vg_home/lv_home rhgb 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 . Observação: seus valores podem variar. Use uname -r para obter essa versão do kernel. Ou apenas leia em mkinitrd . (Francamente, eu não sei porque esse passo é necessário, mas aparentemente é - eu tentei sem ele 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-o a fstab e divirta-se! :)

    

Answer 2

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

Tenho sucesso usando estas etapas:

1. Modifique /etc/defaults/grub para incluir o volume adicional nos parâmetros: rd.lvm.lv=rhel/home (além de rhel/root e 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. Ignore reinstale o grub: grub2-install /dev/sda (porque eu tenho uma pasta vazia /usr/lib/grub/ )
5. Reinicie, naturalmente.

Answer 3

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

    

Answer 4

Então eu 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. Bem 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  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] herda

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

    

Answer 5

De minha parte, eu tenho o comentário desta linha em /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Porque, se seu volume ativo, somente vg00 e vg01, estiver ativo 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" ]