AlexFr

c LWN

Доброго времени суток. Дошли наконец руки до аккаунта Синолоджи. История такая: изначально регистрировался 3615, после крэшей, танцев с бубнами и перерегистрацией та же пара видится в Синолоджи как 3611. Серийник и мак самодельные, раньше виделись как 3615, в synoboot.img менял. Подскажите, где грабли.

Зря Swap трогал. Тем более, не собирая рейда. Хорошо, что он был Raid 1))

А что на диске 1? Отказ системного раздела - это то, что нужно. После Backupа восстановить системный раздел и, если после перезагрузки все будет нормально, новый диск можно удалять.

Вы содержимое рейда видите? Если да то очень желательно сделать резервную копию. Далее надо зайти в Диспетчер хранения. Там Вы скорее всего увидите надпись о повреждении раздела и предложение его восстановить. Если Backup сделан, то можно соглашаться. Эту операцию проделывал несколько раз. Всегда удачно. Но у меня не было рейда. Так что, на мой взгляд, копия обязательна. После того, как раздел восстановится и будет написано, что система функционирует нормально, можно перезагрузиться и снова войти в Диспетчер хранения. Если снова будет все хорошо (иногда слетает), можно выключить систему и удалить диск.

Я думаю, пойдет и через интернет. Можно записать на флешку загрузчик, поправить сид, пид, серийник и воткнуть новый диск. Дальше должно пойти само. Установится последняя версия. Когда все запустится, проверить обновления. Если стоит последняя версия, выключить систему и воткнуть диски. Мне кажется, в таких вещах с хотсвапом лучше не шутить. Если все запустится и увидится, отключить автообновления нафиг от греха подальше))

Поставить последний загрузчик (1.02b сейчас кажется), чистый диск, установить все с нуля, обновиться до последней версии (сейчас Update 8), после этого подключить свой рейд. Должен подцепиться, если на Рейде версия более ранняя. Если не получится - монтировать рейд под Линуксом и ФОРМАТИРОВАТЬ (не удалять) первый раздел. P.S. Если форматировать, данные на рейде останутся, приложения и их настройки слетят.

Хочу уточнить: если все таки с сохранением разделов не получится, перед форматированием раздела под Линукс надо собрать рейд, чтобы случайно его (рейд) не повредить.

Если текущая версия будет новее, чем на рейде, то можно так.

Первый раздел маленький. Порядка 2 Gb. Главное, его не удалять. Иначе Хренология потом свой рейд не увидит. Если что, вот ссылочка: http://admin-to-admin.info/blog/montiruem-disk-iz-nas-ili-kak-smontirovat-raid-razdel-v-linux/

Если надо сохранить только данные, можно сделать таким образом: Ставите еще одни винт (можно самый маленький, какой есть). Загружаете систему любым линуксом. ФОРМАТИРУЕТЕ (не удаляете) первые разделы дисков Хренологии. Отключаете диски Хренологии. Делаете Флэшку с последним загрузчиком, меняете VID, PID, MAC. Устанавливаете на свой маленький винт чистую Хренологию. Грузитесь, получаете рабочую систему. Выключаете ее, вставляете свои 5 дисков. Хренология должна подтянуть Ваш рейд. Ругнется на убитые разделы и предложит поправить. Делаете резервную копию своих важных данных. После этого можно согласиться на правку. Данные останутся, пакеты и настройки будут убиты. P.S. Структура дисков Хренологии такая: 1 Раздел - сама Хренология 2 Раздел - Своп 3 Раздел - собственно данные.

Рейд аппаратный, или сделан в хренолоджи?

ESXi 5.5 DS3615xs v1.02b 6.1.3-15152-Update 6 Обновился штатно. Uptime 1:45 - полет нормальный

Завелся сразу - уже хорошо. Осталось на предмет time bomb посмотреть.

Как впечатление от Update 5 ?

Если читается, можно попробовать дубликат сделать

ESXi 5.5 DS3615xs Обновился штатно. 1 час - полёт нормальный))

Первый пост был для тех, кто использует DSM на платформе VMware, и будет обновляться на новую версию загрузчика, в комплекте которого нет vmdk файла. Логично использовать этот файл от предыдущего загрузчика, или того, который уже есть в системе. Описана реальная ситуация, которая может возникнуть во втором случае, а так же, что надо сделать, чтобы не наткнуться на этот подводный камень. Технологию снапшотов VMware, а так же работу систем резервного, копирования, основанных на этой технологии, описывать в этой ветке смысла не вижу, так как прямого отношения к работе DSM она не имеет, а к описанной ситуации - прямое. Продолжать тему смысла не вижу. P.S. "Этого не может быть, потому что не может быть никогда" - это путь в тупик.

Теперь факты: убираем из папки виртуальной машины synoboot.img. Остается только synoboot.vmdk Открываем окно консоли виртуальной машины. Запускаем ее. Наблюдаем загрузку DSM. Занавес.

"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" - в качестве эпиграфа. На втором скриншоте - размер файла vmdk. На первом- его содержимое (естественно, не все 22Mb). Прошу обратить внимание: файла img, на который ссылается vmdk, в папке нет. так что на втором скриншоте чистое содержимое vmdk диска. Могу сделать предположение: когда ESXi пытается что-то записать в эту сладкую парочку (vmdk -> img), то, поскольку img по умолчанию только для чтения, то все пишется в файл vmdk. Из Википедии: VMDK (Virtual Machine Disk) — формат файла, разработанный VMware для использования в качестве образа диска в своих виртуальных машинах. VMDK схож по структуре и содержанию с жёстким диском... Так что это не просто текстовой файл. Это контейнер.

Убедился. У Вас частный случай. С таким vmdk все получится. В моем этот файл был размером 22 mb и содержал в себе кучу всего. Проверил это, открыв его блокнотом. Предлагаю вернутьсяк теме несколько позже. Пока, к сожалению, нет времени на развернутые ответы.

Я несколько позже опишу подробно, что произошло. В двух словах: если в комплекте с загрузчиком идет vmdk - круто и ни каких проблем. Если нет, надо брать из комплекта другого загрузчика. Если взять от рабочей машины, то надо смотреть размер и содержимое. Если размер несколько мегабайт - проблемы будут наверняка. P.S. Лучше ходить по чужим граблям. Для этого и написал.

Как, выяснилось - лезть надо. И это прибавило седых волос, так как полез не до обновления, а после. img файл версии 1.0.2b, взял vmdk от врсии 1.02a и на выходе получил кирпич. Хорошо, что бубен не далеко спрятал )) По результатам: VMDK файл должен быть размером где-то полкилобайта. Лучше взять от загрузчиков, где он шел в комплекте. НИКОГДА не использовать vmdk, на котором уже работала виртуальня машина - результат не предсказуемый.

Если оставить vid / pid по дефолту, работать будет?