Логические тома неактивны во время загрузки

Я изменил размер логического тома и файловой системы, и все прошло гладко. Я установил новое ядро ​​и после перезагрузки не могу загрузить ни текущее, ни прежнее. Я получаю ошибку группы томов не найдена после выбора опции grub (2). Проверка из поля «занят» показывает, что тома не зарегистрированы в устройстве сопоставления устройств и что они неактивны. Я не смог смонтировать их после активации, я получил файл не найден (mount / dev / mapper / all-root / mnt).

Любые идеи, как действовать или сделать их активными во время загрузки? Или почему тома внезапно неактивны во время загрузки?

С Уважением,

Marek

РЕДАКТИРОВАТЬ: Дальнейшее расследование показало, что это не имеет ничего общего с изменением размера логических томов. Тот факт, что логические тома должны были активироваться вручную в оболочке ash после неудачной загрузки и возможного решения этой проблемы, описан в моем ответе ниже.

Так что мне удалось решить это в конце концов. Существует проблема (ошибка) с обнаружением логических томов, что является своего рода условием гонки (возможно, в моем случае относительно того, что это происходит внутри KVM). Это рассматривается в следующем обсуждении . В моем конкретном случае (Debian Squeeze) решение выглядит следующим образом:

• сделайте резервную копию скрипта / usr / share / initramfs-tools / scripts / local-top / lvm2
• применить патч из упомянутого сообщения об ошибке
• запустите update-initramfs -u

Это помогло мне, надеюсь, это поможет другим (как ни странно, это еще не часть мейнстрима).

Ссылка на патч: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; имя файла = lvm2_wait-lvm.patch; att = 1; ошибка = 568838

Ниже копия для потомков.

--- /usr/share/initramfs-tools/scripts/local-top/lvm2 2009-08-17 19:28:09.000000000 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2 2010-02-19 23:22:14.000000000 +0100
@@ -45,12 +45,30 @@

  eval $(dmsetup splitname --nameprefixes --noheadings --rows "$dev")

- if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
-   lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
-   rc=$?
-   if [ $rc = 5 ]; then
-     echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
-   fi
+ # Make sure that we have non-empty volume group and logical volume
+ if [ -z "$DM_VG_NAME" ] || [ -z "$DM_LV_NAME" ]; then
+   return 1
+ fi
+
+ # If the logical volume hasn't shown up yet, give it a little while
+ # to deal with LVM on removable devices (inspired from scripts/local)
+ fulldev="/dev/$DM_VG_NAME/$DM_LV_NAME"
+ if [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; then
+   # Use default root delay
+   slumber=$(( ${ROOTDELAY:-180} * 10 ))
+
+   while [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; do
+     /bin/sleep 0.1
+     slumber=$(( ${slumber} - 1 ))
+     [ ${slumber} -gt 0 ] || break
+   done
+ fi
+
+ # Activate logical volume
+ lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
+ rc=$?
+ if [ $rc = 5 ]; then
+   echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
  fi
 }

Создайте сценарий запуска, /etc/init.d/lvmсодержащий следующее:

#!/bin/sh

case "$1" in
 start)
    /sbin/vgscan
    /sbin/vgchange -ay
    ;;
  stop)
    /sbin/vgchange -an
    ;;
  restart|force-reload)
    ;;
esac

exit 0

Затем выполните команды:

chmod 0755 /etc/init.d/lvm
update-rc.d lvm start 26 S . stop 82 1 .

Должен сделать трюк для систем Debian.

У меня тоже была эта пробема. В конце концов это то, что, казалось, исправило это:

diff -u /usr/share/initramfs-tools/scripts/local-top/lvm2-backup /usr/share/initramfs-tools/scripts/local-top/lvm2
--- /usr/share/initramfs-tools/scripts/local-top/lvm2-backup    2014-06-06 19:55:19.249857946 -0400
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2   2014-06-21 01:26:01.015289945 -0400
@@ -60,6 +60,7 @@

 modprobe -q dm-mod

+lvm vgchange -ay
 activate_vg "$ROOT"
 activate_vg "$resume"

Другие вещи, которые я пробовал:

1. ваш патч
2. diffing /etc/lvm/lvm.conf
3. GRUB_PRELOAD_MODULES="lvm"
4. GRUB_CMDLINE_LINUX="scsi_mod.scan=sync"
5. sudo grub-install /dev/sda && sudo grub-install /dev/sdb && sudo update-grub && sudo update-initramfs -u -k all
6. sudo apt-get install --reinstall lvm2 grub-pc grub-common

Я прошел и отменил другие изменения, это единственное, что имело значение для меня, хотя это, вероятно, наименее элегантно.

Если vgscan«найдет» тома, вы сможете активировать их с помощьюvgchange -ay /dev/volumegroupname

$ sudo vgscan
[sudo] password for username: 
  Reading all physical volumes.  This may take a while...
  Found volume group "vg02" using metadata type lvm2
  Found volume group "vg00" using metadata type lvm2

$ sudo vgchange -ay /dev/vg02
  7 logical volume(s) in volume group "vg00" now active

Я не уверен, что может привести к их неактивности после перезагрузки.

Без каких-либо подробностей конфигурации или сообщений об ошибках, которые нам понадобились бы, чтобы дать реальный ответ, grub-mkdevicemapв качестве решения я буду использовать удар .

Предполагая, что ваша система использует initramfs, там, вероятно, есть проблема конфигурации. Вам следует обновить образ initramfs, который запускается во время загрузки с помощью grub (в Debian вы делаете это с помощью update-initramfs, не зная о других дистрибутивах).

Вы также можете сделать это вручную, распаковав initramfs и изменив /etc/lvm/lvm.conf (или что-то подобное) в образе initramfs, а затем перепакуйте его снова.

У меня та же проблема в моей среде, где работает Red Hat 7.4 в качестве гостя KVM. Я использую qemu-kvm-1.5.3-141 и virt-manager 1.4.1. Сначала я без проблем запускал Red Hat 7.2 в качестве гостя, но после обновления минорного выпуска с 7.2 до 7.4 и ядра до последней версии 3.10.0-693.5.2 что-то пошло не так и не смог загрузить мой раздел / var LV Больше. Система перешла в аварийный режим с запросом пароля root. Ввод с корневым паролем и запуск команд lvm vgchange -ayи systemctl defaultя смог активировать /varLV и загрузить систему.

Я не понял, что вызывает эту проблему, но мой обходной путь должен был включить LV /varв , /etc/default/grubкак вы видите ниже:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg_local/root rd.lvm.lv=vg_local/var rd.lvm.lv=vg_local/swap rhgb quiet biosdevname=0 net.ifnames=0 ipv6.disable=1"

Тогда я должен был бежать grub2-mkconfig -o /boot/grub2/grub.cfgи проверить, rd.lvm.lv=vg_local/varбыл ли включен в линейку vmlinuz /boot/grub2/grub.cfg. После перезагрузки системы я больше не получаю ошибку для активации моего /varLV, и система успешно завершает процесс загрузки.

в моем случае выяснилось, что корень grub был root = / dev / vgname / root

поэтому тест в / usr / share / initramfs-tools / scripts / local-top / lvm2

  # Make sure that we have a d-m path
  dev="${dev#/dev/mapper/}"          
  if [ "$dev" = "$1" ]; then         
    return 1                         
  fi      

всегда был ложным и корневой том никогда не активируется.

обновлен / etc / fstab из

/dev/vgname/root        /

в

/dev/mapper/vgname-root   /

и сделал:

update-grub
grub-install /dev/sda

решил мою проблему

мы столкнулись с этой проблемой , и обнаружили , что отключение lvmetadпутем установки use_lvmetad=0в /etc/lvm/lvm.confпринудительных объемах можно найти и Маю доступно при загрузке.