LVM: PV отсутствует после перезагрузки

Проверьте ваш /etc/resolv.conf файл. YUM проверит только первый сервер имен, если это локальный DNS резолвер, то он выдаст ошибку "Couldn't resolve host.... "

Поместите это в ваш resolv.conf nameservers, как показано ниже:

nameserver 8.8.8.8
nameserver 8.8.4.4

(Это публичные DNS-серверы Google.)

3
16.12.2018, 09:41
2 ответа

Можно ли монтировать LV, если выполнить sudo vgscanи sudo vgchange -ay? Если эти команды приводят к ошибкам, у вас, вероятно, другая проблема, и, вероятно, вам следует добавить эти сообщения об ошибках в исходный пост.

Но если после этих команд LV станет готов к монтированию, читайте дальше...

Путь к логическому тому LVM (, например./dev/mapper/vgNAME-lvNAME/etc/fstabсами по себе не дадут системе понять, что эта конкретная файловая система не может быть смонтирована до тех пор, пока сеть и iSCSI не будут активированы.

Без этой подсказки система будет считать, что файловая система находится на локальном диске, и попытается смонтировать ее как можно раньше, обычно до активации сети, что, очевидно, не удастся с iSCSI LUN. Так что вам нужно как-то предоставить эту подсказку.

Один из способов — добавить _netdevк параметрам монтирования для этой файловой системы в /etc/fstab. Судя по этой справочной странице Ubuntu , он поддерживается в Ubuntu. На самом деле это может также вызвать vgscanили подобное обнаружение новых PV LVM (+, возможно, другие полезные вещи )непосредственно перед попыткой монтировать любые файловые системы, отмеченные _netdev.

Другим способом может быть использование специальной опции монтирования systemd -x-systemd.requires=<iSCSI initiator unit name>. Это должно привести к тому же результату, отложив любые попытки монтирования этой файловой системы до тех пор, пока инициатор iSCSI не будет успешно активирован.

Когда инициатор iSCSI активируется, он автоматически делает доступными любые сконфигурированные LUN, и когда они становятся доступными, LVM должен автоматически -активировать на них все VG. Итак, как только вы отложили попытку монтирования, этого должно быть достаточно.

Отсутствие PARTUUID указывает на то, что на диске/LUN нет таблицы разделов GPT. Поскольку /dev/sdcуказан как TYPE="LVM2_member", на самом деле у него вообще нет таблицы разделов. Теоретически это не должно вызвать проблем для Linux, но я лично не тестировал систему Ubuntu 18.04 с хранилищем iSCSI, поэтому не могу быть абсолютно уверен.


Проблема с дисками/LUN без таблицы разделов заключается в том, что другие операционные системы не распознают заголовок Linux LVM как признак того, что диск используется, и перезапишут его с минимальными запросами.Это могло произойти, если ваш администратор хранилища iSCSI случайно предоставил LUN хранилища, соответствующий вашему /dev/sdc, другой системе.

Вы должны найти файл резервной копии конфигурации LVM в каталоге /etc/lvm/backup, который соответствует вашей отсутствующей виртуальной группе, и прочитать его, чтобы найти ожидаемый UUID отсутствующего PV. Если он соответствует тому, что сообщает blkid, попросите администратора хранилища дважды -проверить его/ее недавнюю работу на наличие ошибок, подобных описанным выше. Если выяснится, что PV был перезаписан какой-либо другой системой, любые оставшиеся данные на LUN, вероятно, будут более или менее повреждены, и будет лучше восстановить их из резервной копии... как только вы получите новую, гарантированный -неконфликтный LUN от вашего администратора iSCSI.

Если окажется, что фактический UUID /dev/sdcотличается от ожидаемого, возможно, кто-то каким-то образом случайно запустил pvcreate -f /dev/sdc. Если это единственное, что было сделано, это относительно легко исправить.(ПРИМЕЧАНИЕ:см. man vgcfgrestoreглаву ЗАМЕНА ФИЗИЧЕСКИХ ТОМОВ для получения обновленных инструкций -ваши инструменты LVM могут быть новее моих. )Сначала восстановите UUID:

pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc

Затем восстановите конфигурацию VG:

vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>

После этого можно будет активировать виртуальную группу и, если не было нанесено никаких других повреждений, после этого смонтировать файловую систему.

4
27.01.2020, 21:12

Прочитав комментарии telcoM и покопавшись в журналах и справочных страницах, я теперь могу ответить на свой вопрос.

По какой-то причине информация о VG, к которой принадлежит PV /dev/sdc, была потеряна во время перезагрузки и больше не возвращалась.

Я не совсем понимаю решение (возможно, кто-то, кто понимает, может добавить некоторые детали ),но сработало следующее. Первый

> vgscan --cache
  Found volume group "r3vg" using metadata type lvm2

возвращает мою конфигурацию VG. Теперь PV снова известен

> pvs
  /dev/sdc   r3vg    lvm2 a--   72.76t 26.39t

LV также снова известен, но неактивен

> lvscan
   inactive          '/dev/r3vg/p0' [46.37 TiB] inherit

И, наконец,

> lvchange -ay r3vg/p0

возвращает его.

Почему при перезагрузке не подхватывается конфигурация ВГ мне непонятно. Если у кого-то есть какие-либо предложения, добавьте их в комментарии, пожалуйста.

4
27.01.2020, 21:12

Теги

Похожие вопросы