Faltan dispositivos lvm en / dev / mapper

Estoy usando Debian squeeze, y ejecutando LVM sobre el software RAID 1. Acabo de descubrir que falta la mayoría de los enlaces en /dev/mapper , aunque parece que mi sistema sigue funcionando correctamente.

No estoy seguro de lo que pasó Lo único que me puedo imaginar que causó fue mi bash fallido de hacer funcionar un contenedor de fedora LXC. Terminé borrando un directory /cgroup/laughlin , que corresponde al contenedor, pero no puedo imaginar por qué eso debería haber causado el problema. /dev/mapper miró (hice algunos cambios, ver a continuación) aproximadamente como

 orwell:/dev/mapper# ls -la total 0 drwxr-xr-x 2 root root 540 Apr 12 05:08 . drwxr-xr-x 22 root root 4500 Apr 12 05:08 .. crw------- 1 root root 10, 59 Apr 8 10:32 control lrwxrwxrwx 1 root root 7 Mar 29 08:28 debian-root -> ../dm-0 lrwxrwxrwx 1 root root 8 Apr 12 03:32 debian-video -> ../dm-23 

debian-video corresponde a un LV que acababa de crear.

Sin embargo, tengo un buen número de VG en mi sistema, que corresponden a 4 VG distribuidos en 4 discos. vgs da

 orwell:/dev/mapper# vgs VG #PV #LV #SN Attr VSize VFree backup 1 2 0 wz--n- 186.26g 96.26g debian 1 7 0 wz--n- 465.76g 151.41g olddebian 1 12 0 wz--n- 186.26g 21.26g testdebian 1 3 0 wz--n- 111.75g 34.22g 

Intenté correr

  /dev/mapper# vgscan --mknodes 

y se crearon algunos dispositivos (consulte el resultado a continuación), pero no son enlaces simbólicos a los dispositivos dm como deberían ser, por lo que no estoy seguro de si esto es inútil o algo peor. ¿Se interpondrían en la recreación de los enlaces correctos? ¿Debo eliminar estos dispositivos nuevamente?

Creo que udev crea estos enlaces, por lo que un reinicio podría solucionar este problema o ¿obtendré un sistema que no se puede iniciar? ¿Qué debo hacer para arreglar esto? ¿Hay alguna testing de diagnóstico / cordura que debo ejecutar para asegurarme de que no haya otros problemas que no haya notado? Gracias de antemano por cualquier ayuda.

 orwell:/dev/mapper# ls -la total 0 drwxr-xr-x 2 root root 540 Apr 12 05:08 . drwxr-xr-x 22 root root 4500 Apr 12 05:08 .. brw-rw---- 1 root disk 253, 1 Apr 12 05:08 backup-local_src brw-rw---- 1 root disk 253, 2 Apr 12 05:08 backup-video crw------- 1 root root 10, 59 Apr 8 10:32 control brw-rw---- 1 root disk 253, 15 Apr 12 05:08 debian-boot brw-rw---- 1 root disk 253, 16 Apr 12 05:08 debian-home brw-rw---- 1 root disk 253, 22 Apr 12 05:08 debian-lxc_laughlin brw-rw---- 1 root disk 253, 21 Apr 12 05:08 debian-lxc_squeeze lrwxrwxrwx 1 root root 7 Mar 29 08:28 debian-root -> ../dm-0 brw-rw---- 1 root disk 253, 17 Apr 12 05:08 debian-swap lrwxrwxrwx 1 root root 8 Apr 12 03:32 debian-video -> ../dm-23 brw-rw---- 1 root disk 253, 10 Apr 12 05:08 olddebian-etch_template brw-rw---- 1 root disk 253, 13 Apr 12 05:08 olddebian-fedora brw-rw---- 1 root disk 253, 8 Apr 12 05:08 olddebian-feisty brw-rw---- 1 root disk 253, 9 Apr 12 05:08 olddebian-gutsy brw-rw---- 1 root disk 253, 4 Apr 12 05:08 olddebian-home brw-rw---- 1 root disk 253, 11 Apr 12 05:08 olddebian-lenny brw-rw---- 1 root disk 253, 7 Apr 12 05:08 olddebian-msi brw-rw---- 1 root disk 253, 5 Apr 12 05:08 olddebian-oldchrest brw-rw---- 1 root disk 253, 3 Apr 12 05:08 olddebian-root brw-rw---- 1 root disk 253, 14 Apr 12 05:08 olddebian-suse brw-rw---- 1 root disk 253, 6 Apr 12 05:08 olddebian-vgentoo brw-rw---- 1 root disk 253, 12 Apr 12 05:08 olddebian-wsgi brw-rw---- 1 root disk 253, 20 Apr 12 05:08 testdebian-boot brw-rw---- 1 root disk 253, 18 Apr 12 05:08 testdebian-home brw-rw---- 1 root disk 253, 19 Apr 12 05:08 testdebian-root 

Estos días /dev está en tmpfs y se crea desde cero cada inicio por udev . Puede reiniciar de forma segura y estos enlaces volverán.

También debería encontrar enlaces simbólicos LVM a los nodos /dev/dm-X en los directorys /dev/<vg> , un directory para cada grupo de volúmenes. Sin embargo, esos nodos recreados por vgscan --mknodes también funcionarán bien, suponiendo que tengan los numbers mayores / menores correctos – y es una suposition segura de que fueron creados correctamente.

Probablemente también puedas conseguir que udev vuelva a crear los enlaces simbólicos usando el udevadm trigger con una coincidencia adecuada, probando con --dry-run hasta que sea correcto. Aunque parece que vale la pena el esfuerzo cuando un reinicio también lo arreglará.

Acabo de tener un problema similar al que describes, aunque para mí sucedió cuando intentaba instalar el nuevo Ubuntu 11.10 Oneiric Ozelot en un volumen LVM. Hice lo siguiente para configurar lvm en un sistema de arranque en vivo (los volúmenes lógicos que necesitaba ya estaban presentes):

 apt-get install lvm2 vgscan --mknodes -v 

Ahora lvscan -v mostró mis volúmenes pero no estaban en /dev/mapper ni en /dev/<vg>/ . Finalmente encontré que necesitaba activar el grupo de volúmenes, así:

 vgchange -ay <name of volume group> 

El command anterior creó todos los files de dispositivo perdidos para mí. Ahora podría iniciar el progtwig de installation y encontraría los volúmenes lvm y me permitiría instalarlos.

Encontrar esta información en google fue difícil, así que escribo esta respuesta con la esperanza de que a otros les resulte más fácil, de ahí el context en profundidad y la eliminación detallada.

Aunque no es parte de la pregunta, para completar, agregaré que en la situación anterior (installation de Ubuntu LVM) necesita agregar lvm2 al initrd del sistema recién instalado una vez que se haya terminado de instalar, o no se iniciará. Su nuevo sistema debe estar configurado para usted en / target, pero si no lo está, hágalo manualmente de esta manera:

 mount /dev/vg/new_root /target mount /dev/sdx1 /target/boot # important mount -o bind /proc /target/proc mount -o bind /sys /target/sys mount -o bind /dev /target/dev mount -o bind /dev/pts /target/dev/pts 

Necesitaba hacer esto para hacer que las networkinges funcionen en el chroot, que abordaré a continuación:

 cp /etc/resolv.conf /target/etc/ 

Ahora ingrese al nuevo sistema e instale lvm2:

 chroot /target apt-get install lvm2 

Tenga en count que ejecuta update-initramfs. Ahora solo escriba exit y reinicie, y su sistema debería iniciarse correctamente.

Esto también funcionó para mí.

 vgchange -ay -name of volume group- 

Después de un parche de kernel, mi sistema RHEL no pudo reiniciarse. Quejarse de un file /dev/mapper/VG-lv perdido.

Se inició en un solo usuario y se comentó en /etc/fstab . Una vez en línea, encontré que mi disco encryption se mostraba como "dispositivo desconocido" usando pvs .

Se corrigió esto, pero aún no hay files de dispositivo para el grupo Volumen. Al ejecutar el command anterior recreé los files del asignador de dispositivos y me permitieron montarlos.

Tuve un problema similar después de actualizar mi Debian. Durante el reinicio, este post me pareció:

 Unable to find LVM Volume. /dev/mapper/debian-root does not exist. 

Encontré la solución aquí :

 cryptsetup luksOpen /dev/sda5 lvmsys lvm lvm> vgscan ## scan for volume groups lvm> vgchange -ay ## activates the volume groups 

Y voilà, reinició muy bien después de esto.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689 es relevante aquí. Tiene que ver con times de espera tales que lvm root no aparece a time.