Jump to content
XPEnology Community

AlexFr

Member
  • Posts

    204
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by AlexFr

  1. Доброго времени суток.

    Дошли наконец руки до аккаунта Синолоджи.

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

    Серийник и мак самодельные, раньше виделись как 3615, в synoboot.img  менял.

     

    Подскажите, где грабли.

  2. 10 минут назад, l3nd3r сказал:

    Диск 1 и 2 в рейде 1 )

    на одном из дисков я ещё и swap форматировал, не знал в какой из них нужно чтобы прекратило запрашиваться пароль))

    Скоро второй рейд подниму, перенесу инфу и форматну полностью.

     

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

  3. Только что, l3nd3r сказал:

    Да, инфа видится.

    Но:

    Диск 1 Не инициализирован

    Диск 2 Отказ системного раздела

     

    В разделе Raid Group - Настроить, активна только кнопка восстановить с предупреждением, что все будет удалено в этом случае.. пока оставлю.

     

    Поэтому сейчас ищу диски для бэкапа, потом сделаю полный формат и переустановку ос..

    Главное что все есть, спасибо за помощь. Т.к. трудно ориентироваться в линуксоподобных :)

    А что на диске 1?

    Отказ системного раздела - это то, что нужно.

    После Backupа восстановить системный раздел и, если после перезагрузки все будет нормально, новый диск можно удалять.

  4. 17 часов назад, l3nd3r сказал:

    Загрузился акронисом, на свой страх форматнул раздел 2 гб, как и подсказал AlexFr.

    Теперь почти все ок.

    Если Новый диск вынуть, при загрузке -  система не установлена и предлагает установить. Т.е. я могу теперь заново выполнить установку  и структура с данными рейд не пострадают?

    Вы содержимое  рейда видите?

    Если да то очень желательно сделать резервную копию.

     

    Далее надо зайти в Диспетчер хранения. Там Вы скорее всего увидите надпись о повреждении раздела и предложение его восстановить.

    Если Backup сделан, то можно соглашаться.

    Эту операцию проделывал несколько раз. Всегда удачно. Но у меня не было рейда.

    Так что, на мой взгляд, копия обязательна.

    После того, как раздел восстановится и будет написано, что система функционирует нормально, можно перезагрузиться и снова войти в  Диспетчер хранения.

    Если снова будет все хорошо (иногда слетает), можно выключить систему и удалить диск.

    • Thanks 1
  5. 4 минуты назад, l3nd3r сказал:

    Благодарю!

     

    Еще пара вопросов:

    1. Обновление до Update 8 идет с интерфейса системы, через инет. Или нужно что-то скачать и указать в каком то месте для обновы?

    2. Возможно установка последней DSM, это 6.1.3 (update 8 ) ?

    3. Подключение рейда в выключенном состоянии или возможно включить сначала хотсвап и потом вставить? или это невозможно..

     

     

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

    Мне кажется, в таких вещах с хотсвапом лучше не шутить.

    Если все запустится и увидится, отключить автообновления нафиг от греха подальше))

    • Thanks 1
  6. 1 час назад, l3nd3r сказал:

    Добрый день!

    Помогите пожалуйста, тем кто владеет информацией.

     

    Ситуация следующая:

    Имеется мини-серв, своей сборки, 2 диска в Raid 1.

    Стоял больше года Xpenoboot 5.2-5644, все было хорошо, но как известно на нем перестал работать Dropbox.

     

    Решено было обновиться по инструкции.

    На новую флешку закатан Jun’s loader, начал с последнего 1.02b (ds3615xs)

     

    Система при загрузке  виделась и предлагала выполнить миграцию. Указывал разные PAT версии файлов для данного NAS, но выскакивала ошибка 13, что возможно поврежден файл.

     

    Далее начались эксперименты, с разными загрузчиками, разными PAT файлами вплоть до последнего 6.1.3

    И скорей всего здесь кроется проблема.

    В какой то момент система съела обнову, ребутнулась, но дальше дело не пошло..

     

    Далее начал сначала.

    Вытащит Рейд массив, вставил чистый HDD, поставил уже загрузчик 1.01, систему DSM_DS3615xs_8451.pat

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

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

    (скорей всего на дисках имеется отметка что они более поздней версии чем установленная и поэтому ничего не происходит)

     

    Как мне поступить в данном случае, чтобы не потерять инфу ? Буду благодарен за любую информацию. Извиняюсь, что возможно непонятно изъясняюсь, пытаюсь восстановить хронологию действий)

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

     

    P.S. Если форматировать, данные на рейде останутся, приложения и их настройки слетят.

  7. 2 часа назад, survivor2005 сказал:

    спасибо, теперь более менее понятно, может все таки для начала рискнуть и без удаления старых разделов попробовать запуститься с нового диска...

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

  8. 7 минут назад, survivor2005 сказал:

    спасибо, теперь более менее понятно, может все таки для начала рискнуть и без удаления старых разделов попробовать запуститься с нового диска...

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

  9. Только что, survivor2005 сказал:

    Спасибо, попробую, отпишусь, просто у меня еще со знанием линукс полный кабздец( Как бы не снести инфу вместо разделов хренки...

    Первый раздел маленький. Порядка 2 Gb.

    Главное, его не удалять. Иначе Хренология потом свой рейд не увидит.

    2 минуты назад, survivor2005 сказал:

    спасибо, теперь более менее понятно, может все таки для начала рискнуть и без удаления старых разделов попробовать запуститься с нового диска...

    Если что, вот ссылочка: http://admin-to-admin.info/blog/montiruem-disk-iz-nas-ili-kak-smontirovat-raid-razdel-v-linux/

     

  10. 10 часов назад, survivor2005 сказал:

    Всем добра, ребят, помогите пожалуйста!

    Не знаю что делать. 

    Установил когда то на сервер из 5 дисков в рейде 5 хренолоджи 5.2. Затем обновился до 6.

    Затем, что бы заработал виртуал машин мэнеджер пришлось переделать раздел в бтрфс их новый.

    И все бы ничего, если б я не стал делать глупости. Однажды приходит письмо об изменении пароля админа. После чего я не мог войти в систему. И с паники попытался переустановить систему, вместо сброса пароля, но в общем не получалось никак переустановить, так как асистент говорил что система уже стоит. Теперь я делаю еще одну роковую ошибку, возвращаю систему на 5.2. И все, понимаю что он не видит раздел бтрфс и пишет мол раздел поврежден. Теперь я чуть ли не плачу ибо там очень ценная инфа. Пытался обратно поставить дсм 6. Но система пишет что мол обнаружены ошибки на дисках. Как мне вытащить инфу, ПОЖАЛУЙСТА, может есть какое то решение или это конец? 

    Если надо сохранить только данные, можно сделать таким образом:

    Ставите еще одни винт (можно самый маленький, какой есть).

    Загружаете систему любым линуксом.

    ФОРМАТИРУЕТЕ (не удаляете) первые разделы дисков Хренологии.

    Отключаете диски Хренологии.

    Делаете Флэшку с последним загрузчиком, меняете VID, PID, MAC.

    Устанавливаете на свой маленький винт чистую Хренологию.

    Грузитесь, получаете рабочую систему.

    Выключаете ее, вставляете свои 5 дисков.

    Хренология должна подтянуть Ваш рейд.

    Ругнется на убитые разделы и предложит поправить.

    Делаете резервную копию своих важных данных.

    После этого можно согласиться на правку.

     

    Данные останутся, пакеты и настройки будут убиты.

     

    P.S.

    Структура дисков Хренологии такая:

    1 Раздел - сама Хренология

    2 Раздел - Своп

    3 Раздел - собственно данные.

  11. 10 часов назад, survivor2005 сказал:

    Всем добра, ребят, помогите пожалуйста!

    Не знаю что делать. 

    Установил когда то на сервер из 5 дисков в рейде 5 хренолоджи 5.2. Затем обновился до 6.

    Затем, что бы заработал виртуал машин мэнеджер пришлось переделать раздел в бтрфс их новый.

    И все бы ничего, если б я не стал делать глупости. Однажды приходит письмо об изменении пароля админа. После чего я не мог войти в систему. И с паники попытался переустановить систему, вместо сброса пароля, но в общем не получалось никак переустановить, так как асистент говорил что система уже стоит. Теперь я делаю еще одну роковую ошибку, возвращаю систему на 5.2. И все, понимаю что он не видит раздел бтрфс и пишет мол раздел поврежден. Теперь я чуть ли не плачу ибо там очень ценная инфа. Пытался обратно поставить дсм 6. Но система пишет что мол обнаружены ошибки на дисках. Как мне вытащить инфу, ПОЖАЛУЙСТА, может есть какое то решение или это конец? 

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

  12. 1 минуту назад, df_evgen сказал:

    Все работает WOL и т.д. и т.п. Смысл был проверить работоспособность загрузчика после обновы. Глубоко не копал по обнове и исправления что сделали  не читал.

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

  13. 28 минут назад, Kizilkum сказал:

    действительно, подобной клоунады давненько не было.

    вы пожалуйста не обижайтесь, но иначе сказать не получается.

    вы разберитесь, чего вы там у себя накосячили, и тогда все встанет по местам.

    ну или если вы совершенно уверены в своей правоте, снимайте пошаговое видео и выкладывайте на ютуб.

    ссылку сюда. популярность вам гарантирована!

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

    Технологию снапшотов VMware, а так же работу систем резервного, копирования, основанных на этой технологии, описывать в этой ветке смысла не вижу, так как прямого отношения к работе DSM она не имеет, а к описанной ситуации - прямое.

    Продолжать тему смысла не вижу.

    P.S.

    "Этого не может быть, потому что не может быть никогда" - это путь в тупик.

  14. В 30.06.2017 в 20:39, Kizilkum сказал:

    я извиняюсь, но это не предположение, это ересь.

    предположения строятся на фактах.

    засим откланяюсь

    Теперь факты: убираем из папки виртуальной машины synoboot.img.

    Остается только synoboot.vmdk

    Открываем окно консоли виртуальной машины.

    Запускаем ее.

    Наблюдаем загрузку DSM.

    Занавес.

  15. 18 часов назад, Kizilkum сказал:

    загляните на прошлую страницу, я для вас скриншот добавил. с 3мя 4х терабайтными vmdk

     

    я устал переливать из пустого в порожнее.

    поэтому повторяю в последний раз: файл vmdk является простым текстовым файлом описания жесткого диска для виртуальной машины.

    умному этого будет достаточно, а дураку разъяснять бесполезно.

    "Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" - в качестве эпиграфа.

    На втором скриншоте - размер файла vmdk.

    На первом- его содержимое (естественно, не все 22Mb).

    Прошу обратить внимание: файла img, на который ссылается vmdk, в папке нет. так что на втором скриншоте чистое содержимое vmdk диска.

    Могу сделать предположение: когда ESXi пытается что-то записать в эту сладкую парочку (vmdk -> img), то, поскольку img по умолчанию только для чтения, то все пишется в файл vmdk.

    Из Википедии:

    VMDK (Virtual Machine Disk) — формат файла, разработанный VMware для использования в качестве образа диска в своих виртуальных машинах. VMDK схож по структуре и содержанию с жёстким диском...

    Так что это не просто текстовой файл.

    Это контейнер.

     

     

     

    synoboot1.gif

    synoboot2.gif

  16. 10 минут назад, Kizilkum сказал:

    чего вы привязались к размеру? размер зависит только от конфигурации виртуально машины на аппаратном уровне (по типу биоса)

    вот полное содержимое моего файла, ничего другого там нет!

     

    
    # Disk DescriptorFile
    version=1
    CID=7035772b
    parentCID=ffffffff
    isNativeSnapshot="no"
    createType="vmfs"
    
    # Extent description
    RW 102400 VMFS "synoboot.img"
    
    # The Disk Data Base 
    #DDB
    
    ddb.adapterType = "lsilogic"
    ddb.deletable = "true"
    ddb.encoding = "UTF-8"
    ddb.longContentID = "25703ef9e5148528371361257035772b"
    ddb.thinProvisioned = "1"
    ddb.uuid = "60 00 C2 9a ee da ca 33-df 5e 04 3f 80 55 f9 62"
    ddb.virtualHWVersion = "10"
    

    откройте свой файл и убедитесь в этом

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

  17. 2 минуты назад, Kizilkum сказал:

    мягко говоря вы не правы.

    я заменил только .img файл.

    после чего обновил хренолоджи штатно.

    даже чисто логически: vmdk файл вообще не знает что будет загружено в реале.

    просто при создании виртуальной машины у вас было сделано что то специфичное.

    и это специфичное помешало загрузиться виртуальной машине.

    еще раз повторяю: файл vmdk вообще считает что будет загружен линукс, про хренолоджи он даже не подозревает, и значит влиять может лишь косвенно.

    но в этом случае вопросы скорее к создателю виртуальной машины, чем к простому текстовому файлу.

    и кстати, его размер зависит исключительно от того что будет сконфигурировано в виртуальной машине, и никак не зависит от хренолоджи

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

    P.S.

    Лучше ходить по чужим граблям. Для этого и написал.

  18. В 28.06.2017 в 20:59, Kizilkum сказал:

    не надо туда лезть. этот файл, описание конфигурации виртуальной машины, причем в простом текстовом формате.

    к Хренолоджи он прямого отношения не имеет.

    в нем находится только указание где расположен загрузчик, и прочие параметры виртуальной машины

    все что касается загрузчика Хренолоджи, находится в образе с расширением .img

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

  19. В 20.06.2017 в 11:59, sstyle сказал:

    http://www.osforensics.com/tools/mount-disk-images.html 

     

    открываем .img OSFMount, монтируем 15Мб раздел, не забудьте снять галочку read only. В проводнике появится новый раздел. Идем туда. Заходим в папку grub, и видим файл «grub.cfg», вот его открываем Notepad++, там будут строки вверху

     

    Снимок экрана 2017-06-20 в 12.01.12.png

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

×
×
  • Create New...