mdkCrash

Members
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    2

mdkCrash last won the day on June 19 2017

mdkCrash had the most liked content!

Community Reputation

5 Neutral

About mdkCrash

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. забыл ссылку указать на статью Hyper-V DSM 6 Там на коррейском сайт, но встроенный в Chrome перевеодчик отлично переводит на английский.
  2. Предварительные результаты по 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, в общем жива и работает
  3. Hyper-V на прямую не работает с VMDK, но есть возможность сконвертировать. Вот две статейки: - Конвертируем виртуальные машины VMWare в Hyper-V и обратно. - Преобразование виртуальных машин VMware и виртуальные диски с помощью Windows PowerShell Другими словами, есть поле для проб. (сейчас попробую... заняться с Hyper-V "любовью", о результатах отпишусь)
  4. VMDK - продукт/разработка VMWare образ виртуального HDD, но в нашем случае он ссылка img "наш случай" - я иммею ввиду использующих VMWare/ESXi VirtualBox с VMDK работает: "... VirtualBox позволяет работать с разными форматами файлов виртуальных дисков. Помимо собственного VDI, поддерживаются VMDK (VMware), VHD (Microsoft), Parallels version 2 HDD format (Parallels). ... "
  5. Тут все просто с 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
  6. VID/PID - прописывал реальные от своей флешки, с левыми не хотел грузиться до конца (LAN не стартовала), но это еще было на DSM 5.0 (после прописывания реальных, все завелось, может совпадение) SERIAL № - только для QUICKCONNECT MAC - для QUICKCONNECT + это MAC сетевухи хоторый будет при старте DSM и получении динамического IP при использовании DHCP (реальный MAC вашей сетевой карты будет переопределятся при запуске лоадера)
  7. Я провел тесты. Ваш вариант будет 2 если еще не кирпич и 3 если уже кирпич. Если я Вас правильно понял.
  8. Выполнял эксперименты с 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 и "вылечилось" в ручную через обновление м
  9. забыл дополнить: ... - пост на действия после успешного подключения по КомПорту (named pipe) After connect to COM (очень важна последовательность, чтобы HyperTerminal или pytty успешно подцепились к "named pipe" DSM: 1. Создаем соединие/коннектимся к виртуальному COM на WinXP 2. Стартуем/рестартуем DSM, если DSM уже запущена, то соединение не создастся.
  10. На 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 &
  11. 3615 по личному мнению и сообщениям других Хрено-водов стабильная. На счет VID/PID, серийника, МАСа - DSM 6.0 ( Jun’s Mod ) Свой DS не регал, так-как QC не использую, хватает "проброса портов" на роутере. По этому с серийником не заморачивался.
  12. 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 в архиве образ с загрузчиком
  13. Действительно что-то странное... Попробуйте 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_
  14. На счет ОЗУ/Буфера/Кеша в 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 [||