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.

edit 14.05.2020: 6.2.3 is back online as v25426, for newer coffeelake cpu's with problems using hardware transcoding (dev/dri present after boot) there is a new videostation that fixes the problem https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/?do=findComment&comment=144918 edit2 02.06.2020: as @richv31 pointed out here https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/?do=findComment&comment=148564 there seems to be a serious problem with 918+ and scsi/sas drivers, at least with mpt2sas/mpt3sas, not just with 6.2.2/6.2.3 it also happens with jun's original loader 1.04b and dsm 6.2.0 (23824), breaking raid sets after not properly waking up from hdd hibernation means potential data loss i had a two disk raid1 set on a lsi 9211-8i and after disks spinning down only one came up and i saw some really worrying messages on the serial console, i was not able to log in to the system, not on the web gui, even not on the serial console, the whole system was in lock down and only switching off seemed to work as of the problems with not getting s.m.a.r.t. values i used juns old original raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko to get the old state back (replacing my newly made ones from more recent synology kernel source 24922 ) in 0.11/0.12 - these version inherit the problem that seems to be present since the beginning with loader 1.04b anyone using mpt2sas/mpt3sas and disk hibernation on 918+ should disable it for now to not risk any data loss the new 0.13 for 918+ will have the raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko from kernel source 24922, that version did work on testing on my system without breaking anything and without such alarming errors on wakeup of disks, there will be no smart data but at least it seems safer then disks not waking up properly for "proper" lsi sas controller support i'd suggest using 3615 or 3617 as it is "native" in these units and should work better, maybe there are kernel options missing in the 918+ kernel and that cant be fixed, if anyone finds out more just add a comment (i might not have the time to dig into this) the other alternative is to use sata/ahci instead of scsi/sas with 918+, that works without problems on my system using 918+ (12 disks), JMB585 based controller seem to be the best choice atm as they support pcie 3.0 and can have up to 2000 MByte/s for its 5 sata ports (the older marvell and asm chips use only pcie 2.0 limiting the data rate to 500 MB/s or 1000 MB/s, even 8 port controller with two of the older chips use a pcie bridge chip with just two lanes making them terrible choice for a high port count - might be ok with just one or two 1GBit nic's but will at least limit the rebuild speed and ssd's should be kept away from these controllers and place in internal sata ports) for Instructions about installing or updating please read "Driver extension jun 1.03b/1.04b for DSM6.2.2 for 3615xs / 3617xs / 918+" if i have time i will write more in this place the new package is not well tested i just did some tests with hardware i have at hand (ahci, e1000e, r8168, igb, bnx2x, mpt2sas/mpt3sas) and tested update from 6.2.2 to 6.2.3 basically synology reverted the kernel config change made in 6.2.2 back to what was before so old drivers from original 1.04b loader (and older driver i made before 6.2.2) should work again - but as synology also introduced there own new i915 driver with 6.2.3 there will be a conflict when jun's i915 driver is loaded with 6.2.3 there are two positive new things, synology released a nearly recent kernel source code (24922) and 6.2.3 has a new i915 driver supporting as much gpu hardware as jun's backported i915 driver in loader 1.04b - so there is no need for jun's i915 driver anymore and in theory we should have good support for apollo lake, gemini lake and other newer hardware but it seems not all new UHD630 is supported as there is dev id "3E98" unsupported (i5-9400, i5-9600k, i7-9700t, i7-9700), ark.intel.com and wikichip.og are usually good sources to check the id https://ark.intel.com/content/www/us/en/ark/products/134898/intel-core-i5-9400-processor-9m-cache-up-to-4-10-ghz.html edit: there seems to be versions of the i5-9400 with a "3E92" GPU this versions don t need the patched driver, they will run with the default driver, /dev/dri should be present ootb, it also can be checked in /var/log/dmesg when searching for "[8086:3e92]" https://en.wikichip.org/wiki/intel/core_i5/i5-9400 there is also a good document from intel listing all coffeelake's https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-cfl-vol01-configurations.pdf coffeelake cup's without driver support (no hardware transcoding), SKU numbers should be listed when buying and can be checked on the box i9 SKU S82 i7 SKU S82 i5 SKU S6f2 a new 10th gen i5-10500 / i3-10300 have device id's "9BC8" and there are no "9xxx" numbers in the driver we use so don't expect any newer gen10 cpu to work with hardware transcoding even when it "only" has UHD630 igpu edit: there are also even lower end 10th gen cpus (2 core) with a different GPU device id "9BA8" like G5920, G5925, G6400 with a iGPU UHD 610, the equivalent in the 9th gen would be a G5400 and that comes with pci device id's 3E90/3E93, so we need to edit a different entry when patching for this edit: i made a modded i915 driver were the pci device id of the 9th gen UHD 630 iGPU (3E92/3E93) is replaces with the device id's of the newer/different UHD 610/630 iGPU's that are unsupported 8086:3E92 => iGPU UHD 630, Low End Desktop 9 Series (original driver) -> 8086:3E98 => iGPU UHD 630, High End Desktop 9 Series (i5-9400, i5-9600k, i7-9700t, i7-9700) 8086:9BC8 => iGPU UHD 630, Low End Desktop i5-10500, i5-10600T and lower 8086:9BC5 => iGPU UHD 630, High End Desktop i510600K and higher 8086:3E93 => iGPU UHD 610, Low End Desktop 9 Series -> 8086:9BA8 => iGPU UHD 610, low End Desktop Series like G6400 the zip file contains 3 versions in every one is 3E92 replaced with the one we want to get working, as its just a crude binary patch i choose 3E92 as it seemed the most similar device, was tested for 3E98 iGPU and seemed to work, for the 10th there is at least one positive feedback with plex its intended to be used with the extra/extra2 from this thread as this removes jun's old i915 driver (not just one file) that will prevent synologys new driver to work properly the patched i915.ko file is supposed to be copied to /usr/lib/modules/ and replaces the original file from synology for 6.2.3 Update3 (added 9BA8 support) https://gofile.io/d/4fFJA5 https://dailyuploads.net/x3e0nkxk6p0e https://usersdrive.com/zfl9csl91xwr.html https://www34.zippyshare.com/v/304gfbnO/file.html SHA256: EC2447F47FEE6457FE3F409E26B83E5BF73023310E10A624575A822FDBC10642 a little warning, in worst case the system might crash or freeze when transcoding and and such undefined states and hard resets can result i data loss (cache) or damaged raids (depending on the load of the system at this time) so until its more tested it should not be used on system with "important" data and a recent backup - ok i know its a little over cautious but i dont like the thought someone looses data because of this nice to have feature (software mdadm raids can be repaired in most cases if the worst happens) -> positive feedback for a i5-9400, i5-9600K, i9-9900T (8086:3E98) to fully working -> positive feedback for a G6400 (8086:9BA8) to have /dev/dri -> one user positive feedback for a i5-10600T (8086:9BC8) to fully working with plex -> one user negative feedback for a i5-10500 (8086:9BC8) to get /dev/dri devices but no transcoding with emby -> one user negative feedback for a i9-10900 (8086:9BC5) system does not boot anymore - seems to be a solid hands off? edit: there is a driver source patch for 10th gen that came up along 7.x and 9BC5 was confirmed to work with this new driver, so anyone with a 10th gen gpu and trouble can change to 7.x (tc rp loader) ot can try these 6.2.3 modules from this link (i915_918_623.7z) https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/?do=findComment&comment=277236 i completely removed jun's i915 drivers from the extra/extra2 and changed/added the i915 firmware needed, also i took care of the "old" i915 drivers on the installed system in /usr/lib/modules/update/, they are now deleted on boot so if you come from 6.2.2 and used extra/extra2 std or recovery or you did already used juns original 1.04b extra/extra2, it should work as soon as you boot up (when drivers in "update" are not present then the default drivers from synology will be used and with the added i915 in place it will work on most intel gpu's up to coffee lake) the driver versions are the same as in the 6.2.2 extra/extra2 but are newly compiled, as every driver from 6.2.2 is renewed all the old drivers are overwritten and there should be no crashing drivers on boot (which can prevent proper shutdown or reboot) we now have one universal i915 driver (and not jun's and synologys) its back to one package for all cpu/gpu, if needed there will be a recovery version too i only did test a new created loader from 1.04b image file with zImage and rd.gz from "DSM_DS918+_25426.pat" and the new extra.extra2, it will also work with the 6.2.0 kernel that is by default in the 1.04b image if there are problems getting hardware transcoding to work it might help to disable vt-x/vt-d in bios (reported on a J5005 Gemini Lake), but there are other possible reasons because of the licensing thats needed for this to work, but at least it will not hurt as as lon as you dint intent to use the vmm package if you accidentally updated 6.2.2 to 6.2.3 and now have problems like no network after boot, no proper shutdown/reboot or missing /dev/dri (hardware transcoding) then you just copy the new extra/extra2 to your already updated usb drive (the update to 6.2.3 already installed the new kernel on it) with latest updates of win10 there is no drive letter anymore, its possible to still do it with the tools already used for creating the usb drive, read the usb to a imgae file with "Win32DiskImager 1.0" (activate "read only allocated partitions"), mount that image with osfmount (like in the tutorial section), overwrite old /extra/extra2.lzma and write the image back to usb with Win32DiskImager extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.9 some intel and realtek driver updated so hopefully more onboard nic's will work (like realtek 8125), also realtek 8152 is newer so all 2.5G usb solutions from realtek schould work, there is still no way for the intel 2.5G nic as there is no standalone driver for older kernel versions, removed fireware, added bnxt_en and sr_mod/cdrom, nic Killer E2500, added *vf.ko in rc.modules https://pixeldrain.com/u/jHa2eYrc 1CED32FCF63EB54DAA44335FA1EFBCE408D41A3E16D55771D35B0FD423F0B9CF extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.3 scsi/sas disks will have no s.m.a.r.t. infos with lsi sas controllers (see edit2 above), newer atlantic.ko driver 2.3.4, r8125 added to rc.modules, used latest source for realtek drivers r8101/r8125/r8152/r8168/r8169, bna.ko firmware corrected https://pixeldrain.com/u/pkBY9XjC SHA256: EF6F26999C006A29B3B37A7D40C694943100F0A9F53EC22D50E749F729347EC6 for special purpose and tests, extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.12.1 - this version shows s.m.a.r.t. info and serial of disks for lsi scsi/sas but might corrupt the raid when disk hibernation is active (see warning above) https://pixeldrain.com/u/kZJdPj1H SHA256: 9089D38A4975AB212553DA7E35CE54027DE4F84D526A74A46A089FC7E88C1693 extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.12.1_test, added virtio/9p, CDROM drivers, nic Killer E2500 https://pixeldrain.com/u/Rx4tV6ay SHA256: E72820BF648CFD7F6075DEEB1208A3E0D8A61F38289AE17AC7E355910B9B0E0E extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.11_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... https://pixeldrain.com/u/5aN77nWf SHA256: 5DE93F95841CC01F9E87EE4EE2A330084B447E44EBAA6013A575A935D227D4AF extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.12_test (2/2022), added virtio/9p, CDROM drivers, nic Killer E2500 https://pixeldrain.com/u/xmhCVxck SHA256: B9AC8705D5D9DCEED1C0315346E4F2C7C4CD07C4ED519FC9901E8E368A3AE448 extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.11.2_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... (0.11.2 because i forgot bnx2/bnx2x firmware and mpt2/mp3 driver problem when updating from 6.2.2 in 0.11) https://pixeldrain.com/u/zwAJzKa9 SHA256: D467914E55582D238AC5EC4D31750F47AEB5347240F2EAE54F1866E58A8BD1C9

Ok. I am reading this now.

Install FixSynoboot.sh on your current system, then write new clean 1.03b DS3617xs loader, reboot your machine and do a migration install selecting DS3617xs PAT file. This has some risk to your system configuration if it goes wrong, but not your data as long as you don't select an installation option to clear your data disks. It would be a great candidate for a full backup of your data and/or simulation of the migration on non-production installation. Note that DS3617xs platform has no hardware transcoding or NVMe features, so be sure you are not relying on those services, such as NVMe cache.

Not a hardware limitation, it's a kernel compile-time parameter. Until such time as we can compile a Synology kernel, there is nothing to be done about it aside from selecting DS3617xs for more threads, or other platforms for features. https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

So..... how about 6.2.3 and Built in NIC? Seems like there are people who don't use extra LMZA and yet it works? And then there's this guy who uses the 0.11v of the extra.lzma which seems like a safer method. But going from this sentence it might really work without?

as you dont have any too special hardware jun's original extra.lzma from the loader 1.03b would also have done the job (can be extracted with 7zip and just needs to copied to the 2nd partition of the usb in use)

на слабом пк будет падать фпс https://www.synology.com/ru-ru/knowledgebase/Surveillance/tutorial/Live_View/How_do_I_choose_the_right_PC_for_Surveillance_Station_Live_View

I added the 4sag.ru repository to my package center. Afterwards you search for the hp-ams package and install it and reboot. Alternatively you can downloaded the file and install it using the manual install in the package center. After the reboot everything was running. If the link is not working for you attached is the spk file. hp_ams-5.2_2.5.0-1.spk

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922 Update 6 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: YES - Installation type: HP Microserver Gen 8 CPU Xeon E31260 - Additional comments: Becareful ... you have to create a new usb key ! I spend 2 hour to understand! if you use extra.lzma, you have to download the version 0.11 for 6.3 (http://s000.tinyupload.com/?file_id=04147311964729253115 for 3615) download also the pat file https://archive.synology.com/download/DSM/release/6.2.3/25426/DSM_DS3615xs_25426.pat extract the zImage file and rd.z and put the 3 files (extra.lzma, zlimage and rd.z) into the usb key. after that... it's working...

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2 update4 - Loader version and model: Jun's v1.03b - DS3615xs - Using custom extra.lzma: Yes, v0.11 for 6.2.3, applyed just before update without reboot - Installation type: BAREMETAL - HP ProLiant Microserver Gen8 (Xeon 1265Lv2) - - Additional comment: (HP NC360T) and enabled the onboard NICs in BIOS.

- Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 - Loader version and model: JUN'S LOADER v1.03b - DS3617xs - Using custom extra.lzma: YES - Installation type: BAREMETAL - HP Microserver Gen8 onborad NIC enabled - Additional comment: NIC is not visible after reboot. ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 - Loader version and model: JUN'S LOADER v1.03b - DS3617xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP Microserver Gen8 onborad NIC enabled - Additional comment: Re-created synoboot.img on a USB memory. Repair after startup. I was able to update safely.