Я занимался перемещением экстентов логических томов на массив 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

0

Обойти решение:

1) Установите минимальную систему Linux на небольшой логический том.

2) Сделайте выбор этой системы в настройках загрузки BIOS

3) Новая установка grub2 обнаружила существующую систему и предложила ее в качестве варианта загрузки, который я затем выбрал.

4) Затем я выполнил следующую команду, чтобы вернуть систему в прежнее состояние (без необходимости выполнять резервное копирование):

pvmove -n rootpartition /dev/arraydevice 

Это переехал никаких логических экстентов томов , связанные с корневого раздела в другом месте в моем Lvm бассейне. Затем я перезагрузил систему, чтобы подтвердить исправление. Я, вероятно, оставлю установку резервного копирования как отказоустойчивую в случае какого-либо другого скользкого движения.

Теперь тот факт, что это сработало (шаги 1-3), предполагает, что система может быть настроена для загрузки с raid pv, но у меня не было времени найти причину. Первоначальный вопрос стоит на тот случай, если кто-то знает, как разобраться в ловушках переноса существующего корня Debian в rav pv.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .