Leaderboard

When setting up an XPEnology system, you must first select a DSM platform and version. XPEnology supports a few specific DSM platforms that enable certain hardware and software features. All support a minimum of 4 CPU cores, 64GB of RAM, 10Gbe network cards and 12-disk arrays. When you choose a platform and the desired DSM software version, you must download the correct corresponding loader. That may not be the "newest" loader available. The last 6.x version (6.2.4-25556) is functional only with the TCRP loader. TCRP is very different than the Jun loader. If you want to learn more, or if you are interested in deploying the latest 7.x versions, see the 7.x Loaders and Platforms thread. Be advised that installing 6.2.4 with TCRP is basically the same procedure as installing 7.x. Each of these combinations can be run "baremetal" as a stand-alone operating system OR as a virtual machine within a hypervisor (VMWare ESXi is most popular and best documented, but other hypervisors can be used if desired). Review the table and decision tree below to help you navigate the options. 6.x Loaders and Platforms as of 16-May-2022 Options Ranked DSM Platform DSM Version Loader Boot Methods*** Hardware Transcode Support NVMe Cache Support RAIDF1 Support Oldest CPU Supported Max CPU Threads Notes 1,3a DS918+ 6.2.0 to 6.2.3-25426 Jun 1.04b UEFI, BIOS/CSM Yes Yes No Haswell ** 8 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* 2,3b DS3617xs 6.2.0 to 6.2.3-25426 Jun 1.03b BIOS/CSM only No No Yes any x86-64 16 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* DS3615xs 6.2.0 to 6.2.3-25426 Jun 1.03b BIOS/CSM only No No Yes any x86-64 8 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* DS918+ 6.2.4-25556 TCRP 0.4.6 UEFI, BIOS/CSM Yes Yes No Haswell ** 8 recommend 7.x instead DS3615xs 6.2.4-25556 TCRP 0.4.6 UEFI, BIOS/CSM No No Yes any x86-64 8 recommend 7.x instead DS916+ 6.0.3 to 6.1.7 Jun 1.02b UEFI, BIOS/CSM Yes No No Haswell ** 8 obsolete, use DS918+ instead DS3617xs 6.0.3 to 6.1.6 Jun 1.02b UEFI, BIOS/CSM No No Yes any x86-64 16 6.1.7 may kernel panic on ESXi 4 DS3615xs 6.0.3 to 6.1.7 Jun 1.02b UEFI, BIOS/CSM No No Yes any x86-64 8 best compatibility on 6.1.x * 6.2.1 and 6.2.2 have a unique kernel signature causing issues with most kernel driver modules, including those included in the loader. Hardware compatibility is limited. ** FMA3 instruction support required. All Haswell Core processors or later support it. Only a select few Pentium, and no Celeron CPUs do. ** Piledriver is believed to be the minimum AMD CPU architecture to support the DS916+ and DS918+ DSM platforms. *** If you need an MBR version of the boot loader because your system does not support a modern boot methodology, follow this procedure. CURRENT LOADER/PLATFORM RECOMMENDATIONS/SAMPLE DECISION POINTS: 1. DEFAULT install DS918+ 6.2.3 - also if hardware transcoding or NVMe cache support is desired, or if your system only support UEFI boot Prerequisite: Intel Haswell (aka 4th generation) or newer CPU architecture (or AMD equivalent) Configuration: baremetal loader 1.04b, DSM platform DS918+ version 6.2.3 Compatibility troubleshooting options: extra.lzma or ESXi 2. ALTERNATE install DS3617xs 6.2.3 - if RAIDF1, 16-thread or best SAS support is desired, or your CPU is too old for DS918+ Prerequisite: USB key boot mode must be set to BIOS/CSM/Legacy Boot Configuration: baremetal loader 1.03b, DSM platform DS3617xs version 6.2.3 Compatibility troubleshooting options: extra.lzma, DS3615xs platform, or ESXi 3. ESXi (or other hypervisor) virtual machine install - generally, if hardware is unsupported by DSM but works with a hypervisor Prerequisites: ESXi hardware compatibility, free or full ESXi 6.x or 7.x license Use case examples: virtualize unsupported NIC, virtualize SAS/NVMe disks and present as SATA, run other ESXi VM's instead of Synology VMM Option 3a: 1.04b loader, DSM platform DS918+ version 6.2.3 Option 3b: 1.03b loader, DSM platform DS3617xs version 6.2.3 (VM must be set to BIOS Firmware) Preferred configurations: passthrough SATA controller and disks, and/or configure RDM/RAW disks 4. FALLBACK install DS3615xs 6.1.7 - if you can't get anything else to work Prerequisite: none Configuration: baremetal loader 1.02b, DSM platform DS3615xs version 6.1.7 SPECIAL NOTE for Intel 8th generation+ (Coffee Lake, Comet Lake, Ice Lake, etc.) motherboards with embedded Intel network controllers: Each time Intel releases a new chipset, it updates the PCI id for the embedded NIC. This means there is a driver update required to support it, which may or may not be available with an extra.lzma update. Alternatively, disable the onboard NIC and install a compatible PCIe NIC such as the Intel CT gigabit card.

kernel modules/drivers are specifically compiled for a kernel (-versions) and even distributions it's not like windows where you can download a driver somewhere and just put it in so don't take any *.ko file, stick it in and expect it to work if you haven't build the *.ko yourself or don't know exactly where it came from, expect it to fail I'm no expert but as there is no how-to here in the forum - lets start one hopefully other will correct and help refine or take over and rewrite it some steps are made in windows (osfmount) but will also possible in the chroot environment on linux basic knowledge about using a linux console and command-line tools (or midnight commander) is needed, if you never used this you should not start with this how-to, choose something easier or invite someone who is able to help (do a workshop) doing all this from scratch will take at least 1-2 hours, in most cases (re-read, google, try, google, try again, ...) much longer, maybe plan a weekend of text-adventure fun edit: i think it also will do for 6.0.2 and loader 1.01 (not tested), kernel sources are available: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/8451branch/bromolow-source/linux-3.10.x.txz/download, extra.lzma is a little differently placed (boot.img\image\DS3615xs\) but the steps will be the same 1. building the kernel module (driver) 1.1 what driver/module i need you will have to find out (google) what the name of the driver/module is that your hardware needs or you will have to know where to find the rigt option in the menu-system of the kernel when configuring it example: nForce 630 chipset with RTL8211E, you might expect it to be a realtek driver like rtl*.ko but it's not its "forcedeth.ko" because the RTL8211 is not a fully working PCIe Network Chip in some cases you might be forced to find out by booting a linux distribution and look in /var/log/, use lspci or other tools it also helps if the hardware provider has already compiled packages for specific distributions like redhat, you can look inside these packages for *.ko files you also can look in the .config file of the kernel (more below) with a text editor to find a section where the module is mentioned, this will also give you a hint where to find it in the menu-system when configuring the kernel 1.2 you need the kernel source in the case of synology that seemed sometimes difficult but at the moment there is kernel source for dsm 6.1 https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/ 15047 is the synology build version and tells you about what dsm version it is (15057 = dsm 6.1) and what kernel was used to build the modules, it !!!might!!! change in a later version so always check for what version your bootloader from usb stick is made for (jun 1.02 is for 15047) edit: dsm 6.1.1 has a new build number 15101 but seems to use the same kernel 3.10.102 as 6.1 so it should work with 6.1.1 too as i write this for ds3615xs it's bromolow as a platform, for ds3617xs it's broadwell and ds916+ is braswell (you usually see that name on the update files for a synology system like "synology_broadwell_3617xs.pat") so for ds3615xs we use this: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/bromolow-source/linux-3.10.x.txz/download edit: it looks like as for building the modules there is no difference for kernels modules build for 3615 and 3617 even if https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/ has extra kernel sources for bromolow and broadwell, there are all intel x86_64, same might go for the 916+ (not testet yet), at least a evdev.ko build from 3615 kernel source did load without problems in a vm with the 3617 image 1.3 setting up a DSM 6.1 ds3615xs test environment with virtualbox (its free) or whatever works with juns loader look in the forum to find something that works, basics for virtualbox are - mac of the nic (intel pro 1000 desktop) in vm and grub.conf need to be the same - boot controller for jun's image (vmdk with reference to img file) is ide, controller for dsm disks is scsi lsi (!!!) - choose esx server option in grub menu 1.4 installing chroot put in http://packages.synocommunity.com for custom packages and change the setting that beside synology packages trusted ones are also to install install debian-chroot plugin (https://synocommunity.com/package/debian-chroot) from community section (some info's about it: https://github.com/SynoCommunity/spksrc/wiki/Debian-Chroot#configure-services) you might also install midnight commander if you are on it, makes things easier if you're not a command-line junky and more used to a graphical environment that give you clues activate ssh in dsm connect with ssh/putty to you dsm, login with user admin (and if you want to be root use "sudo -i") start the chroot with: /var/packages/debian-chroot/scripts/start-stop-status chroot after that you are inside the chroot, check with ls and you won't see "/volume1" or other sysnology specific directory's from the dsm environment, you can leave the chroot environment with "exit" later if you want now we have to update and install tools: apt-get update apt-get upgrade apt-get install locales dpkg-reconfigure locales dpkg-reconfigure tzdata apt-get install mc make gcc build-essential kernel-wedge libncurses5 libncurses5-dev libelf-dev binutils-dev kexec-tools makedumpfile fakeroot linux-kernel-devel lzma bc after that we create a directory (lets say "test") 1.5 copying kernel files and create kernel modules copy the downloaded kernel (linux-3.10.x.txz) to a share on the dsm, open a 2nd putty and copy the linux-3.10.x.txz (/volume1/...) to /volume1/@appstore/debian-chroot/var/chroottarget/test/ (that's where the "test" directory of the chroot environment is located in your real system) change back to your first putty where you are in chroot (the same way can be used to get the created files back to your shared folder on your volume1 which can be accessed from windows) change into "test", extract the linux-3.10.x.txz to a directory named "linux-3.10.x" and change into it the following copy's the kernel config file from synology to the right place for use/build cp synoconfigs/bromolow .config we make a fallback copy make ARCH="x86_64" oldconfig we start the ascii art menu and search for the missing driver to activate cursor/return are your friend in navigating, space selects, we activate the driver to an "M" so its build as module (*.ko file we need) there will be tons of descriptions how to do it, just google if needed make ARCH="x86_64" menuconfig on exit we save the configuration and with the following we make/create the modules (will take a while) make ARCH="x86_64" modules now you have to find your *.ko file (use some nice ls options, to be expanded later) usually you will have to look in /test/linux-3.10.x/drivers/scsi or block copy that file to /test for easy access when we put it in the boot image 2. modify the "synoboot.img" use osfmount (windows) to extract the "extra.lzma" (see dsm 5.2 to 6.0 guide, used there to edit grub.cfg in synoboot.img) in "extra.lzma" are the additional *.ko files and a config file where the files to be loaded on boot are named -> see forum thread "dsm 5.2 to 6.0" with howto to modify jun's loader for usb vid/pid and mac, its basically the same you just open the other partition (30MB) and extract the "extra.lzma" copy the "extra.lzma" to the share of the dsm so we have local access in a putty session on dsm in putty session #2 ("normal" session without chroot) we copy the "extra.lzma" to the "test" directory in the chroot environment go to putty session#1 (in chroot) decompress "extra.lzma" to "extra" ("extra.lzma" is a compressed cpio file) with: lzma -d extra.lzma with ls we can check that "extra.lzma" is now just ""extra" (a cpio file without the extension cpio) create a new directory, copy the "extra" there, change into it and extract it with: cpio -idv < extra delete the remaining file "extra" inside this directory we copy the *.ko file into usr/lib/modules/ and in /etc we edit the file rc.modules (easy with midnight commander, go to file, press F4, internal editor) network drivers seems to be added under EXTRA_MODULES, storage drivers under DISK_MODULES, just go to the end of the line and fill in the name of the *.ko file without the ".ko", what you add is basically a blank and the name rc.modules looks like this: EXTRA_MODULES="mii mdio libphy atl1 atl1e atl1c alx uio ipg jme skge sky2 ptp_pch pch_gbe qla3xxx qlcnic qlge netxen_nic sfc e1000 pcnet32 vmxnet3 bnx2 libcrc32c bnx2x cnic e1000e igb ixgbe r8101 r8168 r8169 tg3 usbnet ax88179_178a button evdev ohci-hcd" DISK_MODULES="BusLogic vmw_pvscsi megaraid_mm megaraid_mbox megaraid scsi_transport_spi mptbase mptscsih mptspi mptsas mptctl ata_piix megaraid_sas mpt2sas mpt3sas" EXTRA_FIRMWARES="bnx2/bnx2-rv2p-09ax-6.0.17.fw bnx2/bnx2-rv2p-09-6.0.17.fw bnx2/bnx2-rv2p-06-6.0.15.fw tigon/tg3_tso5.bin tigon/tg3_tso.bin tigon/tg3.bin" if your controller or nic needs a firmware, you add the file under usr/lib/modules/firmware/ and add the appropriate line in EXTRA_FIRMWARES, if a extra directory inside "firmware" is used it has to be added to the name, see the bnx2 firmware files after everything is in place we recreate the cpio file, re-compress it as lzma and write it in the directory above as "extra.lzma" the command is used inside the directory where we extracted the file "extra" (command line taken from https://github.com/kref/scripts, its what jun uses to create it): (find . -name modprobe && find . \! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma in putty session #2 (without the chroot) we copy "extra.lzma" from the chroot position in filesystem to the location where we can access it from windows if you still have osfmount open to the "synoboot.img" replace the "extra.lzma" with the new one, dismount and close osfmount - our new "synoboot.img" is ready to test it ps: i was asked to make a video - thats much harder to change and i'm to old for this

You might want to do this: # echo 1000000 >/proc/sys/dev/raid/speed_limit_min # echo 1000000 >/proc/sys/dev/raid/speed_limit_max

Things are promising, yes. All three arrays are set to repair. Don't do anything from Storage Manager. You can monitor progress with cat /proc/mdstat. Post another mdstat when it's all done. It might be awhile.

@Kostian90 Я бы сначала попробовал на чистом винте и с новой флешкой - взлетит или нет, если взлетит, то снова перезаписать флешку, воткнуть ее и старые винты и мигрировать, там все интуитивно понятно. Полезные ссылки тут.

For the community, please note that this critical update does NOT apply to DS3615xs and DS3617xs.

ds.bromolow-6.2.dev.txz \usr\local\x86_64-pc-linux-gnu\x86_64-pc-linux-gnu\sys-root\usr\lib\modules\DSM-6.2\build\.config that should already contain # CONFIG_PCIEASPM is not set instead of CONFIG_PCIEASPM=y i'd suggest to use the file from above as base config

I apologize if this may seem unkind, but you need to get very methodical and organized, and resist the urge to do something quickly. There's a thing that happens, folks sort of throw themselves at this problem and end up potentially doing damage without really doing research. That leads to a low likelihood of data recovery, and at best recovery with a lot of corruption and data loss. If your data is intact, it will patiently wait for you. I don't know why you decided to boot up Ubuntu but you must understand that all the device ID's are probably different and nothing will match up. It actually looks like some of the info you posted is from DSM and some of it is from Ubuntu. So pretty much we have to ignore it and start over to have any chance of figuring things out. If you want help, PUT EVERYTHING BACK EXACTLY THE WAY IT WAS, boot up in DSM, and get shell access. Then: Summarize exactly what potentially destructive steps you took. You posted that you clicked Repair, and then Deactivate. Specifically where, affecting what? Anything else? cat /proc/mdstat Using each of the arrays returned by mdstat: mdadm --detail /dev/<array> ls /dev/sd* ls /dev/md* ls /dev/vg* Please post the results (that is if you want help... on your own you can do what you wish, of course). There is no guarantee that your data is recoverable - there is no concrete evidence of anything yet.

Железка ваша подойдёт.

Различий там оч много. Хом моде просто для меня важен. я думаю, зачем ставить старое если есть новое!? Установи 8.2.2 и настрой как я писал выше и все будет нормально работать.

Там же почитай различия между 8.0.3 и 8.2.2. И сам сделай вывод какая версия тебе нужна.

https://www.synology.com/ru-ru/knowledgebase/Surveillance/tutorial/General/What_do_I_need_to_know_about_Home_Mode_in_Surveillance_Station тут почитай.

@omar According to a Google translate, If you use MicroSD on HP Gen8: VID 0x0424 - PID 0x4030 this is the internal card reader, (located on the USB bus)