El volumen LVM está inactivo después de reiniciar CentOS

He reinstalado un servidor Linux de CentOS 6 a 7. El servidor tiene 3 unidades: una unidad SSD del sistema (aloja todo excepto /home) y dos unidades HDD de 4 TB que alojan /home. Todo usa LVM. Las dos unidades de 4TB están duplicadas (usando la opción de incursión dentro de LVM), y están completamente llenas con la partición / home.

El problema es que, aunque los discos de 4 TB se reconocen bien y LVM ve el volumen sin problemas, no lo activa automáticamente. Todo lo demás se activa automáticamente. Puedo activarlo manualmente y funciona.

Tengo una imagen de la unidad del sistema anterior en / home. Eso también contiene volúmenes LVM. Si lo monte kpartx, y LVM los recoge y los activa. Pero no veo diferencia entre esos volúmenes y los inactivos.

El sistema de archivos raíz también es LVM, y eso se activa muy bien.

Sin embargo, veo una cosa peculiar: la ejecución lvchange -aayme dice que necesito especificar qué unidades quiero activar. Tampoco lo hace automáticamente. Si lo especifico lvchange -ay lv_home, eso funciona.

No puedo encontrar nada que pueda ser responsable de este comportamiento.

Agregado: noté que el sistema anterior (que usaba init) tenía vgchange -aay --sysiniten sus scripts de inicio. El nuevo usa systemd, y no veo la vgchangellamada en sus scripts. Pero tampoco sé dónde ponerlo.

Agregado 2: Comenzando a descubrir systemd. Encontré dónde se encuentran los scripts y comencé a entender cómo se llaman. También descubrí que podía ver los scripts ejecutados con systemctl -al. Esto me muestra que, después de comenzar lvmetad, requiere pvscancada dispositivo de bloqueo udev conocido. Sin embargo, en ese momento solo hay un dispositivo de bloque udev registrado, y ese es uno de los volúmenes lvm reconocidos. Los discos duros también están allí, pero bajo diferentes caminos y nombres mucho más largos. El dispositivo de bloque reconocido es algo así 8:3como lo son los discos duros /device/something/. Ya no estoy en el servidor, así que no puedo escribirlo con precisión (lo arreglaré más adelante).

Creo que tiene algo que ver con udev y la detección / mapeo de dispositivos. Continuaré por la tarde y estudiaré udev entonces.

Si todo lo demás falla, encontré el script que llama pvscany verifiqué que puedo modificarlo para escanear todos los dispositivos todo el tiempo. Eso soluciona el problema, pero parece un truco bastante feo, así que intentaré descubrir la verdadera causa raíz.

Agregado 3 : OK, todavía no sé por qué sucede esto, pero al menos he hecho una solución bastante aceptable. Hice otro servicio systemd que llama pvscanuna vez, justo después de comenzar lvmetad. La otra llamada para el dispositivo específico todavía está allí, y creo que en realidad lo udevllama (ese es el único lugar donde encontré referencia). Por qué no lo llama para los otros discos duros, no tengo idea.

¡Lo hice! ¡Lo hice! Lo arreglé correctamente (creo).

Aquí está la historia:

Después de un tiempo, el servidor resultó ser defectuoso y tuvo que ser desechado. Mantuve discos y obtuve todo lo nuevo. Luego reinstalé CentOS nuevamente en el SSD y luego conecté los HDD. LVM funcionó bien, se reconocieron los discos, se mantuvo la configuración. Pero el mismo problema surgió nuevamente: después de reiniciar, el volumen estaba inactivo.

Sin embargo, esta vez tuve la oportunidad de notar algo más: el gestor de arranque pasa los siguientes parámetros al núcleo:

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

Hmm, espera un minuto, ¡esos se ven FAMILIARES !

Consulta rápida de google, y ahí estamos :

rd.lvm.lv =

solo active los volúmenes lógicos con el nombre dado. rd.lvm.lv se puede especificar varias veces en la línea de comando del kernel.

Bien ahora. ¡Eso lo explica!

Entonces, la resolución fue (recopilada de varias consultas de Google más):

1. Modifique /etc/defaults/grubpara incluir el volumen adicional en los parámetros:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
2. Reconfigurar grub con grub2-mkconfig -o /boot/grub2/grub.cfg
3. Reconfigure initramfs con 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: sus valores pueden variar. Use uname -rpara obtener esa versión del kernel. O simplemente sigue leyendo mkinitrd. (Francamente, no sé por qué es necesario este paso, pero aparentemente lo es, lo intenté sin él y no funcionó)
4. Y finalmente, reinstale grub: grub2-install /dev/sda
5. Reiniciar, naturalmente.

TA-DA! El volumen está activo al reiniciar. ¡Agrégalo fstaby disfruta! :)

Actualización menor (para RHEL 7 en máquina EFI (sin BIOS) ):

Llegué al éxito con estos pasos:

1. Modifique /etc/defaults/grubpara incluir el volumen adicional en los parámetros: rd.lvm.lv=rhel/home(además de rhel/rooty rhel/swap)

2. Reconfigurar grub con

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

   ( nota: ¡ otro camino!)

3. Reconfigurar initramfs con

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

4. Omitir reinstalar grub: grub2-install /dev/sda(porque tengo un directorio vacío /usr/lib/grub/)
5. Reiniciar, naturalmente.

Yo tuve este problema también. En mi caso, fue una combinación de iscsi, multipath y lvm y el orden de creación de la sesión, etc. Resolví el problema agregando una llamada /sbin/vgchange -a ya /etc/rc.local.

Así que probé la configuración de rd.lvm.lv = en / etc / default / grub y eso no funcionó

Necesitaba ambos volúmenes lógicos en el grupo de volúmenes ssd_vg para estar activo en el arranque. Así como el volumen lógico home_lv en kubuntu-vg para estar activo

Lo que funcionó fue editar /etc/lvm/lvm.conf. En la sección de la lista de volúmenes, coloque esto en volume_list = ["ssd_vg", "kubuntu-vg / home_lv"]

resultado después de reiniciar

$ sudo lvscan inactivo Original '/ dev / kubuntu-vg / root' [50.00 GiB] heredar

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

Por mi parte, he comentado esta línea en /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Porque si está activo, solo el volumen vg00 y vg01 están activos en el arranque.

La documentación de 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" ]