+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[SOLVED]Обновление до PVE6: dev-pve-data.device/start превысило время ожидания., Proxmox Виртуальная Среда

mollien

Guest

26.08.2019 16:39:00

В прошлую субботу мы попытались обновить нашу кластерную среду с 4 узлами с PVE5 до PVE6, воспользовавшись руководством и утилитой pve5to6. Следуя инструкции, мы обновили Corosync на 4 узлах, затем перешли к обновлению первого узла (PMX01) до buster. Все шло хорошо, пока система не перезагрузилась и не вошла в режим обслуживания. Просматривая журналы загрузки, кажется, что монтирование /dev/pve/data превысило время ожидания, что, в свою очередь, вызвало сбой множества зависимостей: Код: 25 авг 11:26:16 arwpmx01 systemd[1]: dev-pve-data.device: Задание dev-pve-data.device/start превысило время ожидания. 25 авг 11:26:16 arwpmx01 systemd[1]: Превышено время ожидания для устройства /dev/pve/data. -- Тема: Задание на запуск единицы dev-pve-data.device завершилось с ошибкой -- Определено: systemd -- Поддержка: https://www.debian.org/support -- -- Задание на запуск единицы dev-pve-data.device завершилось с ошибкой. -- -- Идентификатор задания 14, результат задания - превышение времени ожидания. Мы можем загрузить систему в функциональное состояние многопользовательского режима, выполнив следующие шаги: - Войти в режим обслуживания под root - отредактировать /etc/fstab и закомментировать монтирование /dev/pve/data - перезагрузиться - отредактировать /etc/fstab и раскомментировать монтирование /dev/pve/data - выполнить mount -a После этого сервер, кажется, работает как ожидается. Все изображения находятся на месте, их можно запускать, мигрировать и т.д. Однако при каждой последующей перезагрузке нам придется делать то же самое. Чтобы проверить, не является ли это проблемой конкретного устройства, мы также обновили второй сервер. Проблема повторилась, и тот же обходной путь помог. На данный момент у нас полудообновленный кластер: 2 узла с PVE6 и 2 узла с PVE5, что не идеально. Я нашел еще одну тему на этом форуме от кого-то, кто описывал ту же проблему, но решения не было предложено, а последний комментарий датируется началом августа. Весь вчерашний день я ломал голову над этой проблемой, пытаясь найти решение, но ничего, что хотя бы указывало в правильном направлении, я не нашел. Не считая попыток восстановить один из 'пострадавших' узлов кластера, что может привести к необходимости восстановления всей среды Proxmox, есть ли у кого-нибудь идея, где искать? Буду очень признателен за любую помощь!

linux203

Guest

05.02.2020 01:27:00

Я знаю, что тема старая, но я тоже столкнулся с этой проблемой на одном узле из шести в кластере. /etc/fstab пытался смонтировать LVM-thin как ext4. Это было настоящей головоломкой, почему один из шести отличается. Исследования привели меня к https://pve.proxmox.com/wiki/Instal....2Fvar.2Flib.2Fvz_.28Proxmox_4.2_and_later.29, где указано, что формат на диске изменился в версии 4.2. Этот узел был переустановлен после 4.2, в то время как остальные просто обновлялись. В какой-то момент /etc/fstab, вероятно, был скопирован с одного узла на другой, но гипервизор так и не перезагрузился.

hancok62

Guest

14.07.2020 01:40:00

та же проблема здесь при обновлении до 6.2-9, к тому же, если попробовать удалить из fstab и смонтировать вручную с помощью mount /dev/pve/data /directory/of/disk, все работает корректно, я могу создавать директории, отправлять данные и пытаться переносить машины на узел, тогда машины запускаются и работают правильно, но диск исчезает, это магическое ощущение. Более подробная информация: если я запускаю оболочку (но не удаляю из /etc/fstab) без диска после ошибки при загрузке и пытаюсь смонтировать вручную, тогда: Код: # mount /dev/pve/data /disk/path -v
mount: /dev/mapper/pve-data смонтирован в /disk/path. но когда я запускаю df -h, тогда /disk/path не смонтирован! :c если я запускаю: Код: mount /dev/pve/data /disk/path -v; df -h
mount: /dev/mapper/pve-data смонтирован в /disk/path.

большой вывод df, я не копирую его, потому что я через vnc

интересное здесь,

/dev/mapper/pve-data размер-диска размер-использованного размер-доступного %-использования /disk/path диск правильно смонтирован, но сразу размонтирован. Я оставил узел неработающим на 1 день, если нужно больше информации об ошибке и как правильно исправить. С уважением.

Stoiko Ivanov Guest	#4 0 14.07.2020 09:38:00 hm - пожалуйста, опубликуй вывод следующих команд: Code: pvs vgs lvs lsblk mount \|grep /dev/pve/data в любом случае, убедись, что у тебя есть резервная копия!

hancok62

Guest

14.07.2020 18:16:00

Привет, Stoiko, Код: # pvs
PV VG Фmt Атриб PSize PFree
/dev/sda3 pve lvm2 a-- <1.82t <16.38g

# vgs
VG #PV #LV #SN Атриб VSize VFree
pve 1 3 0 wz--n- <1.82t <16.38g

# lvs
LV VG Атриб LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-a-tz-- 1.71t 0.00 0.15
root pve -wi-ao---- 50.00g
swap pve -wi-ao---- 8.00g

# lsblk
ИМЯ MAJ:MIN RM РАЗМЕР RO ТИП ТОЧКА_MОНТАЖА
sda 8:0 0 1.8T 0 диск
|-sda1 8:1 0 1007K 0 раздел
|-sda2 8:2 0 512M 0 раздел
`-sda3 8:3 0 1.8T 0 раздел
|-pve-swap 253:0 0 8G 0 lvm [SWAP]
|-pve-root 253:1 0 50G 0 lvm /
|-pve-data_tmeta 253:2 0 15.8G 0 lvm
| `-pve-data 253:4 0 1.7T 0 lvm
`-pve-data_tdata 253:3 0 1.7T 0 lvm
`-pve-data 253:4 0 1.7T 0 lvm

# mount |grep /dev/pve/data С наилучшими пожеланиями,

Stoiko Ivanov

Guest

14.07.2020 18:49:00

Похоже, что /dev/pve/data — это lvm-thinpool, на котором каким-то образом также была создана файловая система EXT4. Я бы сначала сделал резервную копию диска (с помощью dd или что-то подобное), затем примонтировал бы его с ext4, скопировал все важные данные и перенес их на новый диск.

hancok62

Guest

14.07.2020 20:54:00

Привет, я отформатировал весь диск и создал его заново без LVM, без LVM — без проблем, я не могу бояться каждого обновления, по моему опыту, без LVM таких серьезных проблем не возникает, и это не первая проблема, с которой я столкнулся из-за LVM. Спасибо за отзыв, с уважением.

hancok62

Guest

20.07.2020 23:33:00

Привет, если у кого-то есть такая проблема, то удаление диска из fstab и добавление этого в crontab сработало для меня: Код: @reboot mount /dev/pve/data /directory_of_disk (чувствую себя плохо от этого). Думаю, это происходит из-за того, что Linux не может смонтировать диск (очевидно), по какой-то причине не загружается что-то из lvm во время монтирования диска из fstab при загрузке. Если ты используешь lvm из директории, то после загрузки ОС это работает корректно, но когда fstab монтирует диск при загрузке, он прекращает попытки монтирования и запускает аварийный шелл. Это все еще не загружает правильно, потому что блокирует следующие шаги загрузки после ошибки загрузки. С уважением,

Stoiko Ivanov Guest	#9 0 21.07.2020 09:31:00 пожалуйста, не делай этого. В таких случаях LV /dev/pve/data отформатирован как ext4 и настроен как lvm thin pool - это очень неустойчивая конфигурация, и я ожидаю, что это в конечном итоге приведет к проблемам, включая потерю данных, просто создавай резервные копии твоих машин - очисти LV, настрой его либо как ext4 (для директории), либо как lvm thinpool и добавь его в свою конфигурацию хранения.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры