Объем LVM неактивен после перезагрузки CentOS


9

Я переустановил сервер Linux с CentOS 6 на 7. Сервер имеет 3 диска - системный SSD-диск (на нем размещено все, кроме /home) и два 4-ТБ жестких диска на этом хосте /home. Все использует LVM. Два накопителя емкостью 4 ТБ зеркально отражены (с помощью параметра raid в самом LVM) и полностью заполнены разделом / home.

Проблема в том, что хотя диски 4 ТБ распознаются нормально, и LVM видит объем без проблем, он не активирует его автоматически. Все остальное активируется автоматически. Я могу активировать его вручную, и он работает.

У меня есть образ старого системного диска в / home. Это также содержит тома LVM. Если я подключу его kpartx, LVM поднимет их и активирует. Но я не вижу разницы между этими томами и неактивными.

Корневая файловая система тоже LVM, и это прекрасно активируется.

Хотя я вижу странную вещь: выполнение lvchange -aayговорит мне, что мне нужно указать, какие диски я хочу активировать. Это также не делает это автоматически. Если я укажу lvchange -ay lv_home- это работает.

Я не могу найти ничего, что могло бы быть ответственным за это поведение.

Добавлено: я заметил, что старая система (которая использовала init) была vgchange -aay --sysinitв своих сценариях запуска. Новый использует systemd, и я не вижу vgchangeвызова в его скриптах. Но я также не знаю, где это поставить.

Добавлено 2: Начинаем разбираться в systemd. Я нашел, где находятся сценарии, и начал понимать, как они называются. Также обнаружил, что я мог видеть выполненные сценарии с systemctl -al. Это показывает мне, что после запуска lvmetadон вызывает pvscanкаждое известное блочное устройство udev. Однако на данный момент есть только одно зарегистрированное блочное устройство udev, и это один из распознанных томов lvm. Жесткие диски тоже есть, но под разными путями и гораздо более длинными именами. Распознанное блочное устройство что-то вроде 8:3, а жесткие диски похожи /device/something/. Я больше не на сервере, поэтому не могу написать точно (это исправлю позже).

Я думаю, что это как-то связано с udev и обнаружением / отображением устройств. Я продолжу вечером и буду учиться удеву.

Если pvscanничего не помогает, я нашел скрипт, который вызывает, и проверил, могу ли я изменить его, чтобы сканировать все устройства все время. Это решает проблему, но выглядит довольно уродливо, поэтому я попытаюсь выяснить истинную причину.

Добавлено 3 : ОК, я до сих пор не знаю, почему это происходит, но, по крайней мере, я сделал довольно сносный обходной путь. Я сделал еще один сервис systemd, который вызывает pvscanодин раз, сразу после запуска lvmetad. Другой вызов для конкретного устройства все еще там, и я думаю, что это действительно udevвызывает его (это единственное место, где я нашел ссылку на него). Почему это не называется для других жестких дисков - я понятия не имею.


Работают ли системные сервисы LVM? Это случилось со мной.
Нафтули Кей

@NaftuliTzviKay - Да, сервисы запускаются нормально (по крайней мере, другие lvmetadя не заметил).
Vilx-

Был еще один сервис, имя которого уклоняется от меня на данный момент.
Нафтули Кей

@NaftuliTzviKay - Хм ... там тоже была какая-то служба "мониторинга". Это также хорошо начинается, хотя я помню, что читал о том, что он делает, и пришел к выводу, что это не относится ко мне. У меня пока нет доступа к коробке, поэтому я проверю позже.
Vilx-

Ответы:


7

Я это сделал! Я это сделал! Я исправил это правильно (я думаю).

Вот история:

Через некоторое время сервер оказался неисправным и его пришлось утилизировать. Я сохранил диски и получил все остальное новое. Затем я снова установил CentOS на SSD, а затем подключил жесткие диски. LVM работал хорошо, диски были распознаны, конфигурация сохранена. Но снова возникла та же проблема - после перезагрузки том был неактивен.

Однако на этот раз я заметил кое-что еще - загрузчик передает ядру следующие параметры:

crashkernel = auto rd.lvm.lv = centos / root rd.lvm.lv = centos / swap rhgb quiet

Хм, подожди, те выглядят СЕМЕЙНЫМИ !

Быстрый запрос Google, и вот мы здесь :

rd.lvm.lv =

активировать только логические тома с указанным именем. rd.lvm.lv может быть указан несколько раз в командной строке ядра.

Ну теперь. Что объясняет его!

Итак, разрешение было (собрано из нескольких запросов Google):

  1. Изменить, /etc/defaults/grubчтобы включить дополнительный объем в параметры:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
  2. Переконфигурируйте grub с grub2-mkconfig -o /boot/grub2/grub.cfg
  3. Переконфигурируйте initramfs с помощью mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Примечание: ваши значения могут отличаться. Используйте, uname -rчтобы получить эту версию ядра. Или просто читайте дальше mkinitrd. (Честно говоря, я не знаю, зачем нужен этот шаг, но, видимо, это так - я пытался без него, и он не работал)
  4. И наконец, переустановите grub: grub2-install /dev/sda
  5. Перезагрузка, естественно.

TA-DA! Громкость активна при перезагрузке. Добавьте это fstabи наслаждайтесь! :)


2

Незначительное обновление (для RHEL 7 на EFI (не BIOS) ):

Я добился успеха, используя эти шаги:

  1. Изменить, /etc/defaults/grubчтобы включить дополнительный объем в параметры: rd.lvm.lv=rhel/home(в дополнение к rhel/rootи rhel/swap)
  2. Переконфигурируйте grub с

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    

    ( примечание: другой путь!)

  3. Переконфигурируйте initramfs с помощью

    mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r)
    
  4. Пропустить переустановить grub: grub2-install /dev/sda(потому что у меня есть пустой каталог /usr/lib/grub/)
  5. Перезагрузка, естественно.

Хм, похоже, вы используете EFI. В моем случае это была коробка BIOS, так что, вероятно, в этом и заключается разница.
Vilx-

Да, это лезвие х240. Я добавил заметку на EFI.
Jno

@ Vilx - для этой ошибки существует решение, предложенное поставщиком . Но это действительно некрасиво. Они предлагают добавить _netdevфлаг fstab, включить chkconfig netfs onи даже выключить в только в надежде , что устройства будут повторно опрошены и заняли ...use_lvmetad = 0lvmetad/etc/lvm/lvm.conf
Jno

Извините, не вижу этого, так как я не клиент RedHat. Но я не понимаю, почему наши решения не верны, и нужен другой обходной путь. Я имею в виду, это не ошибка - все работает так, как должно.
Vilx-

Я думаю, это ошибка: root и swap явно перечислены в cmdline ядра, а home нет. Следовательно, мы установили два тома LVM и один завис в «неактивном» состоянии. Я процитировал их предложение именно здесь, чтобы избежать необходимости в определенных учетных данных для доступа :)
jno

1

У меня тоже была эта проблема. В моем случае это была комбинация iscsi, multipath и lvm и порядок создания сеанса и т. Д. Я решил проблему, добавив вызов /sbin/vgchange -a yк /etc/rc.local.


0

Поэтому я попытался установить rd.lvm.lv = / etc / default / grub, и это не сработало

Мне нужно, чтобы оба логических тома в группе томов ssd_vg были активны при загрузке. А также логический том home_lv на kubuntu-vg должен быть активным

Что сработало, так это отредактировало /etc/lvm/lvm.conf В разделе списка томов поместите это в volume_list = ["ssd_vg", "kubuntu-vg / home_lv"]

результат после перезагрузки

$ sudo lvscan неактивный Оригинал '/ dev / kubuntu-vg / root' [50.00 GiB] наследуется

inactive          '/dev/kubuntu-vg/swap_1' [7.88 GiB] inherit

ACTIVE            '/dev/kubuntu-vg/home_lv' [1000.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap11' [50.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap12' [50.00 GiB] inherit

ACTIVE            '/dev/ssd_vg/root' [224.02 GiB] inherit

ACTIVE            '/dev/ssd_vg/swap_1' [7.88 GiB] inherit

0

Со своей стороны, я прокомментировал эту строку в /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Потому что, если он активен, только том vg00 и vg01 активны при загрузке.

Документация lvm.conf:

If auto_activation_volume_list is defined, each LV that is to be
activated with the autoactivation option (--activate ay/-a ay) is
first checked against the list. There are two scenarios in which
the autoactivation option is used:

  - automatic activation of volumes based on incoming PVs. If all the
    PVs making up a VG are present in the system, the autoactivation
    is triggered. This requires lvmetad (global/use_lvmetad=1) and udev
    to be running. In this case, "pvscan --cache -aay" is called
    automatically without any user intervention while processing
    udev events. Please, make sure you define auto_activation_volume_list
    properly so only the volumes you want and expect are autoactivated.

  - direct activation on command line with the autoactivation option.
    In this case, the user calls "vgchange --activate ay/-a ay" or
    "lvchange --activate ay/-a ay" directly.

By default, the auto_activation_volume_list is not defined and all
volumes will be activated either automatically or by using --activate ay/-a ay.

N.B. The "activation/volume_list" is still honoured in all cases so even
if the VG/LV passes the auto_activation_volume_list, it still needs to
pass the volume_list for it to be activated in the end.

If auto_activation_volume_list is defined but empty, no volumes will be
activated automatically and --activate ay/-a ay will do nothing.

auto_activation_volume_list = []

If auto_activation_volume_list is defined and it's not empty, only matching
volumes will be activated either automatically or by using --activate ay/-a ay.

  "vgname" and "vgname/lvname" are matched exactly.
  "@tag" matches any tag set in the LV or VG.
  "@*" matches if any tag defined on the host is also set in the LV or VG


Only activate vg00 and vg01 automatically.
auto_activation_volume_list = [ "vg00", "vg01" ]
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.