Pvmove от Debian root lv на устройство raid10 привел к невозможности загрузки системы
Я занимался перемещением экстентов логических томов на массив raid 10, собранный с помощью mdadmin. Одним из перемещенных логических томов был корневой каталог (система тестирования Debian), который ранее находился на одном физическом томе. Система теперь не загружается. Сообщение об ошибке, сообщаемое в grub rescue: lvmid/ex....lognuuid/ еще один длинный uuid не найден.
Я предполагаю, что два диска не найдены - это два в настоящее время в массиве raid 10, в котором сейчас находится корневой каталог. Я также предполагаю, что это потому, что массив не собирается до корневого локального тома.
Когда я загружаюсь с установочного носителя и перехожу в режим восстановления, я не могу загрузить корневой каталог. Однако, если я сначала выберу опцию для сборки массива, а затем сделаю chroot в корневой каталог, у меня получится. Я перепробовал все, что мог придумать за последние 24 часа. Включая различные комбинации изменения /etc/mdadm/mdadm.conf, update-initramfs -u.
Я даже попытался отменить pvmove, но не смог из-за ошибки lvmetad.socket. Что-то должно отсутствовать в среде спасения chroot, необходимой для этого маршрута.
Тот факт, что если я вручную собираю массив перед хроматированием, я могу получить работающую систему, это указывает либо на то, что массив не собирается вообще, либо не во времени (и, следовательно, вообще нет).
Кто-нибудь может предложить исправление, которое я мог бы попробовать? Я предполагаю, что есть что-то, что я могу сделать, чтобы система работала, но я не знаю, как действовать дальше.
1 ответ
Обойти решение:
1) Установите минимальную систему Linux на небольшой логический том.
2) Сделайте выбор этой системы в настройках загрузки BIOS
3) Новая установка grub2 обнаружила существующую систему и предложила ее в качестве варианта загрузки, который я затем выбрал.
4) Затем я выполнил следующую команду, чтобы вернуть систему в прежнее состояние (без необходимости выполнять резервное копирование):
pvmove -n rootpartition /dev/arraydevice
Это переместило все экстенты логического тома, связанные с корневым разделом, в другое место в моем пуле lvm. Затем я перезагрузил систему, чтобы подтвердить исправление. Я, вероятно, оставлю установку резервного копирования как отказоустойчивую в случае какого-либо другого скользкого движения.
Теперь тот факт, что это сработало (шаги 1-3), говорит о том, что систему можно настроить для загрузки с raid pv, но у меня не было времени найти причину. Первоначальный вопрос стоит на тот случай, если кто-то знает, как разобраться в ловушках переноса существующего корня Debian в rav pv.