mdkCrash

забыл ссылку указать на статью Hyper-V DSM 6 Там на коррейском сайт, но встроенный в Chrome перевеодчик отлично переводит на английский.

Предварительные результаты по Hyper-V: 1. Испробован вариант по ссылке Конвертируем виртуальные машины VMWare в Hyper-V и обратно. ковертировал VMDK synoboot.vmdk от v.1.02b в два формата VHD и VHDX -> в обоих случаях лоадер стартует но получять IP по DHCP не хочет, следовательно не видется в сети При чем с VHD загрузка проходит дальше, чем с VHDX 2. На просторах интернета найдена статейка и архивчик (610Мб) с установленной 6.0.1 на Hyper-V: успешно скачан, распакован, создана машинка в Hyper-V успешно стартует, получает IP по DHCP, в общем жива и работает при подключении, режим первого старта после установки DSM c нуля: вводим имя DSM, логин, пароль и т.п. итого: работает, обновлять пока не пробовал, но думаю не прокатит ПруФФ в аттаче Дальнейшие шаги для себя вижу такие: Установить DSM на VMWare и дальше сконвертировать не только VMDK а целиком виртуалку со всеми порохами Проверить обновление этого 6.0.1 до например 6.1.1 или 6.1.2 и посмотреть что будет, кирпич/не керпич Расковырять/сравнить образ диска лоадера от Jun v1.02b и от этой сборки, по возможно адаптировать Продолжение следует Скрин, раскрыть Hide

Hyper-V на прямую не работает с VMDK, но есть возможность сконвертировать. Вот две статейки: - Конвертируем виртуальные машины VMWare в Hyper-V и обратно. - Преобразование виртуальных машин VMware и виртуальные диски с помощью Windows PowerShell Другими словами, есть поле для проб. (сейчас попробую... заняться с Hyper-V "любовью", о результатах отпишусь)

VMDK - продукт/разработка VMWare образ виртуального HDD, но в нашем случае он ссылка img "наш случай" - я иммею ввиду использующих VMWare/ESXi VirtualBox с VMDK работает: "... VirtualBox позволяет работать с разными форматами файлов виртуальных дисков. Помимо собственного VDI, поддерживаются VMDK (VMware), VHD (Microsoft), Parallels version 2 HDD format (Parallels). ... "

Тут все просто с img идет vmdk файл в нем ссылка/указатель на img файл. Считайте что нашем случае vmdk это просто ссылка (как ссылка на файл в системе) С загрузчиком v1.02b не идет vmdk возьмите его от v1.02a (там ничего нового) соедержимое (развернуть спойлер, указатель на ->RW 102400 VMFS "synoboot.img"): synoboot.vmdk # Disk DescriptorFile version=1 CID=6ccf51e5 parentCID=ffffffff isNativeSnapshot="no" createType="vmfs" # Extent description RW 102400 VMFS "synoboot.img" 0 # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.deletable = "true" ddb.encoding = "UTF-8" ddb.longContentID = "7e24a756b77e33e24ac940cc6ccf51e5" ddb.thinProvisioned = "1" ddb.uuid = "60 00 C2 9a ee da ca 33-df 5e 04 3f 80 55 f9 62" ddb.virtualHWVersion = "10" Hide

VID/PID - прописывал реальные от своей флешки, с левыми не хотел грузиться до конца (LAN не стартовала), но это еще было на DSM 5.0 (после прописывания реальных, все завелось, может совпадение) SERIAL № - только для QUICKCONNECT MAC - для QUICKCONNECT + это MAC сетевухи хоторый будет при старте DSM и получении динамического IP при использовании DHCP (реальный MAC вашей сетевой карты будет переопределятся при запуске лоадера)

Я провел тесты. Ваш вариант будет 2 если еще не кирпич и 3 если уже кирпич. Если я Вас правильно понял.

Выполнял эксперименты с v1.02b для 3615 на VMWare (проблем с железными хрюшами я думаю быть не должно, свободно железа нет для проверки) Вводная: 1. Создаю VM и ставлю DSM 6.1.1-15101 на загрузчик v1.02a в ручную с использованием pat 2. Далее обновляю с использованием pat до DSM 6.1.1-15101-Update 4 3. Далее в итоге имеем DSM 6.1.1-15101-Update 4 4. Делаю клон VM (для проведения 3 экспериментов) Эксперимент 1: 1. Делаю обновление до 6.1.2 с v1.02a, результат "крипич" (что у меня было ранее на EXSi и "вылечилось" в ручную через обновление модулей) Эксперимент 2: 1. В исходной VM DSM 6.1.1-15101-Update 4 (ранее слокированной) заменяю img c загрузчиком v1.02b (не забываем для порятку подправить/сверить SN, PID, VID на свои с исходной исталяции) 2. Старутем, в загрузочном меню (1-й пункт по умоланию) 3. DSM появляется в сети, WebUI доступен, но говорит что необходимо "восстановиться", всего одна кнопка. 4. Подверждаем "восстановление", которое пробигает, DSM рестатуется, после загрузки обычное приглашение авторизоваться 5. Авторизовались, все работает как и при v1.02a, но мы уже используем v1.02b 6. Штатно обновляемся на 6.1.2 7. DSM перегружается, доступен в сети и мы радуемся обновленной системе. Эксперимент 3 (самый интересный, для тех кто обновлялся до 6.1.2 с использованием v1.02a и получил "кирпич"): 1. Возвращаемся к нашей "окирпиченой" DSM из "Эксперимента 1" 2. Заменяем img с v1.02a на v1.02b (не забываем для порятку подправить/сверить SN, PID, VID на свои с исходной исталяции) 3. Старутем, в загрузочном меню (1-й пункт по умоланию) 3. DSM появляется в сети, WebUI доступен, но говорит что необходимо "восстановиться", всего одна кнопка. 4. Подверждаем "восстановление", которое быстренько пробигает 5. DSM перегружается, доступен в сети, после загрузки обычное приглашение авторизоваться 6. радуемся обновленной системе. P.S.: Устновка 6.1.2 с v1.02b "в чистую" проходит без проблем и каких либо "танцев". Все стандартно

забыл дополнить: ... - пост на действия после успешного подключения по КомПорту (named pipe) After connect to COM (очень важна последовательность, чтобы HyperTerminal или pytty успешно подцепились к "named pipe" DSM: 1. Создаем соединие/коннектимся к виртуальному COM на WinXP 2. Стартуем/рестартуем DSM, если DSM уже запущена, то соединение не создастся.

На ESXi 6.5 ( DS3615xs via Jun’s Mod V1.02a ) Успешно ("с бубном") обновился с 6.1.1-4 до 6.1.2 1. После обновления через DSM, "хрюша" пропадает из сети. Причина в неполном обновлениие драйверов (модулей) на сетевую карту. 2. Варианта дальше все "довести до ума" нашел (вычитал и испробовал) два: через запуск Live Ubuntu (запуск с установочного диска/флешки или iso(для виртуалки/гипервизора)), с последующим монтированием системного раздела (с дисков DSM) и копированием модулей из каталога в каталог ветка на форуме (уже давали выше) Tutorial: How to access DSM's Data & System partitions через подключение к DSM по виртуальному КомПорту (SerialPort / named pipe) оказался легким и удобным для ESXi/VMWare, а кто счастливый обладатель iLO4 тому вообще проще всех. - ветка на форуме DSM 6.1.2-15132 - пост со ссылкой на создание ESXi - Connecting to a named pipe - пост на действия после успешного подключения по КомПорту (named pipe) After connect to COM Были испробованы оба варианта: 1. Вервый вариант у меня не "прокатил", системные разделы с трех дисков (1-ин VMDK + 2-а RDM) не монтировались, как я не пытался (возможно особенности подключения к виртуалке VMDK + RDM дисков или мои "кривые руки") 2. Второй оказался намного проще (для выполнения, если DSM использeтся в виртуальной среде), без проблем создал новую виртуалку, заинсталил WinXP, через HyperTerminal подключился к DSM и скопировал модули из одной папки в другую. Рестарт и все завелось. DSM в сети с 6.1.2 Итого: - кто обладатель "железной хрюши" без iLO4, тому только первый вариант, или второй варинт но если есть компорт на материнке "хрюши" + еще ноут/ПК с компортом или переходником COM -> USB - второй вариант идеален для тех у кого Хренолоджи крутиться в виртуальной среде на ESXi / VMWare (за Hyper-V не скажу, пробовал всего один раз и очень не понравилось ЮзерФрендли)

3615 по личному мнению и сообщениям других Хрено-водов стабильная. На счет VID/PID, серийника, МАСа - DSM 6.0 ( Jun’s Mod ) Свой DS не регал, так-как QC не использую, хватает "проброса портов" на роутере. По этому с серийником не заморачивался.

http://xpenology.com/forum/viewtopic.php?f=2&t=20216 и там ссылки на MEGA https://mega.nz/#F!BtFQ2DgC!JgomNP3X8V9EuwxL4TXbng Далее на MEGA папка v1.02a и архив DS3615xs 6.1 Jun's Mod V1.02-alpha.zip в архиве образ с загрузчиком

Действительно что-то странное... Попробуйте sudo dmidecode --type 17 | more данные из SMB [spoiler=Мой результат с двумя планками по 4Гб:] root@SNTest:~# sudo dmidecode --type 17 | more # dmidecode 2.12 SMBIOS 2.8 present. # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. Handle 0x000D, DMI type 17, 40 bytes Memory Device Array Handle: 0x000B Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: A1_DIMM0 Bank Locator: A1_BANK0 Type: DDR3 Type Detail: Unknown Speed: 1600 MHz Manufacturer: Hynix Semiconduc Serial Number: 1041760E Asset Tag: A1_AssetTagNum0 Part Number: HMT451S6BFR8A-PB Rank: 1 Configured Clock Speed: 1600 MHz Minimum voltage: 1.350 V Maximum voltage: 1.500 V Configured voltage: 1.350 V Handle 0x000F, DMI type 17, 40 bytes Memory Device Array Handle: 0x000B Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: A1_DIMM1 Bank Locator: A1_BANK1 Type: DDR3 Type Detail: Unknown Speed: 1600 MHz Manufacturer: Kingston Serial Number: EB3A89C1 Asset Tag: A1_AssetTagNum1 Part Number: HP16D3LS1KBG/4G Rank: 1 Configured Clock Speed: 1600 MHz Minimum voltage: 1.350 V Maximum voltage: 1.500 V Configured voltage: 1.350 V И еще, если возможно cat /proc/meminfo [spoiler=Мой результат:]root@SNTest:~# cat /proc/meminfo MemTotal: 7655916 kB MemFree: 129300 kB Buffers: 107324 kB Cached: 6570864 kB SwapCached: 10024 kB Active: 3235520 kB Inactive: 3925492 kB Active(anon): 258096 kB Inactive(anon): 291144 kB Active(file): 2977424 kB Inactive(file): 3634348 kB Unevictable: 1836 kB Mlocked: 1836 kB SwapTotal: 6688684 kB SwapFree: 6377724 kB Dirty: 16 kB Writeback: 0 kB AnonPages: 475332 kB Mapped: 139052 kB Shmem: 66360 kB Slab: 171560 kB SReclaimable: 98276 kB SUnreclaim: 73284 kB KernelStack: 6528 kB PageTables: 31672 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 10516640 kB Committed_AS: 3341084 kB VmallocTotal: 34359738367 kB VmallocUsed: 284368 kB VmallocChunk: 34359385044 kB DirectMap4k: 14560 kB DirectMap2M: 7837696 kB

На счет ОЗУ/Буфера/Кеша в Unix подобных системах можно почитать http://rus-linux.net/MyLDP/sys-conf/memory.html Достаточно просто для понимания все расписано. Если в "двух словах": то, что "почти" вся свободная ОЗУ занята (буферы/кэша) это нормальное поведение ОС Мой 3615 6.1-Update 2 с 8Гб: root@SNTest:~# free -h total used free shared buff/cache available Mem: 7.3G 661M 124M 64M 6.5G 6.3G Swap: 6.4G 300M 6.1G root@SNTest:~# htop 0 [|| 1.3%] Tasks: 132, 148 thr, 122 kthr; 1 running 1 [|||| 3.9%] Load average: 0.27 0.38 0.40 2 [||||||||||||||| 17.1%] Uptime: 2 days, 23:40:44 3 [|| 2.6%] Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||797M/7.30G] Swp[||| 300M/6.38G]