Назад | Перейти на главную страницу

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

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

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

С Уважением,

Марек

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

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

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

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

Ссылка на патч: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; filename = lvm2_wait-lvm.patch; att = 1; bug = 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. различие /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. Вход с паролем root и запуск команд lvm vgchange -ay и systemctl default Я смог активировать свой /var LV и загрузите систему.

Я не выяснил, что вызывает эту проблему, но мой обходной путь состоял в том, чтобы включить 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. После перезагрузки системы я не получал ошибки активации моего /var LV больше, и система успешно завершит процесс загрузки.

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

так что тест в / USR / доля / initramfs-инструменты / сценарии / локальный верх / 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 принудительно находит тома и делает их доступными при загрузке.