Логічні томи неактивні під час завантаження

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

Будь-які ідеї, як діяти чи активувати їх під час завантаження? Або чому томи раптово неактивні під час завантаження?

З повагою,

Марек

EDIT: Подальше дослідження показало, що це не має нічого спільного з зміною логічних обсягів. Про те, що логічні томи потрібно було активувати вручну в золі попелу після невдалого завантаження і можливе рішення цієї проблеми, висвітлено у моїй відповіді нижче.

Тож мені вдалося вирішити це врешті-решт. Існує проблема (помилка) з виявленням логічних обсягів, що є якоюсь умовою перегонів (можливо, в моєму випадку щодо того, що це відбувається всередині KVM). Про це йдеться в наступній дискусії . У моєму конкретному випадку (Debian Squeeze) рішення полягає в наступному:

• резервне копіювання сценарію / usr / share / initramfs-tools / script / 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. різний /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-менеджер 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я зміг активувати свій /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 / script / 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примусових обсягах можна знайти і Маю є при завантаженні.