Leaderboard

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/scs 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 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: i made a modded i195 driver were the pci device id of the 9th gen UHD 630 iGPU (3E92) is replaces with the device id's of the newer/different UHD 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 and lower 8086:9BC5 => iGPU UHD 630, High End Desktop i5 10600K and higher 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 gen cpu's it's yet untested but i made the patch anyway so if someone has access to a 10th gen desktop cpu please try it and post your findings here (like devices in /dev/dri present and transcoding working or not) http://s000.tinyupload.com/?file_id=51752805657569869828 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 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.3 scsi/sas disks will have no s.m.a.r.t. infos (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 http://s000.tinyupload.com/?file_id=02983560703604932651 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) http://s000.tinyupload.com/?file_id=00074364916273522754 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, ... http://s000.tinyupload.com/?file_id=04147311964729253115 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) http://s000.tinyupload.com/?file_id=00282289527307524672

Unless you've been hiding under a rock, you will probably have heard about Wireguard - an emerging alternative to OpenVPN for quick, simple and secure VPN access. It's nothing short of amazing and very fast. It's so innovative that Linus Torvalds has cleared it for direct inclusion into the upcoming Linux kernel 5.6. Unfortunately, it's not an option for DSM, even with Docker, because it requires the Wireguard kernel-mode extensions compiled into the kernel (which we can't easily do). Enter an obscure docker module "masipcat/wireguard-go", compiled by an MIT researcher with a userspace (non-kernel) implementation interfacing to the /dev/net/tun device. This isn't as fast as a kernel implementation, but it provides the basis to make Wireguard work on DSM! Unfortunately the documentation and configuration examples are incredibly sparse, and Wireguard is positioned as a microservice whereas OpenVPN artificially embeds routing services (push commands). So it takes some doing to make Wireguard work beyond the most basic implementations. The basis of Wireguard is public/private key exchange. Each node of the VPN generates a private key, from which it then computes a public key. Then you install the public key from node A on node B, and vice-versa. This is a simple and quick configuration. So here are two example use cases where I've been able to make Wireguard work on DSM, exactly as desired, using this dockerfile - they might be of interest to you. Case #1: Remote access to a LAN behind a firewall (which includes a DSM server) Typically, we would install OpenVPN Server from Package Center for this. I'm not a fan of OpenVPN because the code on Synology is quite old, the configuration is unwieldy, and the interface is dumbed down to the simplest configurations. While it could work in this case, the Synology implementation cannot be used for more sophisticated or esoteric configurations. Scenario: Local network: 10.1.1.0/24, Client device 10.1.1.100 Remote LAN: 192.168.1.0/24, DSM server 192.168.1.50 The networks are each connected to consumer Internet (dynamic IP) services using port-forwarding capable firewalls First, download the Wireguard client for your client device (Windows, Mac etc) Create a new tunnel, which will compute a Public/Private key combination. Write down these two keys, which will be for the remote DSM server. Then delete the tunnel and create another one. Note that I call the tunnel "remote" because that is what makes sense in the UI (I'm connecting to the remote site) but the keys are for the local client and network. Now, configure the local client. The [Interface] section refers to the local device, and the [Peer] is the remote device. Use the PublicKey that you saved from the first step for the Peer. I'm arbitrarily picking 192.168.0.0/24 as the VPN network. The only restrictions are that it should use a private address scheme and not overlap any of the local or remote networks. The listen ports are also completely arbitrary; just don't create conflicts with existing services. In the Peer section, note the AllowedIPs. This refers to the networks that the local Wireguard client will intercept and encrypt onto the VPN. We need 192.168.0.1 because it will be the target VPN address on the remote DSM, and 192.168.1.0/24 so that we will be able to access other devices on the remote network. Finally note that we can use a DNS address, DDNS address or a static IP to find the remote endpoint on the Internet. Now we need to configure the Wireguard docker container on the remote DSM server. If you haven't already, install Docker from the Package Center. Unfortunately Synology Docker doesn't expose all the necessary config options in the UI, so we will need to create a container script manually. Once the container is built, it can be monitored, stopped and started from the UI. SSH into your system, elevate to root, and find the docker folder. In this example we will assume docker is installed to Volume 1. Then create a directory for Wireguard and an initiation script. # cd /volume1/docker # mkdir wireguard # cd wireguard # echo "docker run -d --name wireguard --restart=always --cap-drop=ALL --cap-add=NET_ADMIN --network=host -v /dev/net/tun:/dev/net/tun -v /volume1/docker/wireguard/wg0.conf:/etc/wireguard/wg0.conf --sysctl net.ipv4.ip_forward=1 --sysctl net.ipv6.conf.all.disable_ipv6=1 masipcat/wireguard-go" >wireguard.sh # chmod 700 wireguard.sh We do not have access to the capability or sysctl options with the Docker UI. Now, create the remote DSM Wireguard interface configuration /volume1/docker/wireguard/wg0.conf using your choice of editor, using the correct Private and Public keys from our first steps. Note there is no Endpoint configuration, which means that only the client will be able to start the tunnel. The ListenPort must match the Endpoint port on the client, and the remote AllowedIPs entry must match the Interface IP on the client. [Interface] Address = 192.168.0.1 PrivateKey = 0IUlYn3c8DbZDlO2pbVtVerTI4jk7/57ZoMlsC6sOVo= ListenPort = 55556 [Peer] PublicKey = uSB/0i8TW8AV9bu7ums51Rc29jQrCIpWg1XJSok99Xs= AllowedIPs = 192.168.0.2/32 Note that because the Wireguard docker container directly connects to the host DSM network, the ListenPort must not conflict with any services inside DSM. Unless you are already running OpenVPN on DSM, the /dev/net/tun VPN device will not be initialized. Download the attached loadtun.sh script and install in /usr/local/etc/rc.d folder. Set it to executable and run it to create your tun device. It will automatically start on boot from now on. # chmod 700 /usr/local/etc/rc.d/loadtun.sh # /usr/local/etc/rc.d/loadtun.sh start Now you are ready to start up the Wireguard docker container. # /volume1/docker/wireguard/wireguard.sh If all goes well, the container will download, initialize and display a hex string indicating that it is running. If you get error messages, check the wireguard.sh file for completeness and accuracy, referencing step #6. Check to make sure the remote Wireguard is ready for a connection by launching the Docker UI (you should see the wireguard container running). Select the container details, and display the log - it should look something like the image below. If there are errors, check your wg0.conf for correct syntax. The last step is to port-forward the remote firewall to the DSM IP. In this example, port 55556 is forwarded to 192.168.1.50. Now Activate the local client and you should have access to the remote DSM server and everything on its network! loadtun.sh

Hi all:) After a little bit of reverse engineering I was able to bypass the license checking mechanism introduced in DSM 6 successfully with a simple two line binary patch of synocodectool and therefore enable transcoding without a valid serial number[emoji4]. I wrote a little script to make it easier for everyone. For more information please check the github repo: https://github.com/likeadoc/synocodectool-patch HOWTO: 1. wget https://raw.githubusercontent.com/likeadoc/synocodectool-patch/master/patch.sh 2. chmod +x patch.sh 3. ./patch.sh Done:) If things go wrong simply restore the original file: ./patch.sh -r Cheers

NOTE: This problem is consistently manifested when running on ESXi, but many have encountered problems with Synoboot devices on baremetal installs of 6.2.3. The fix can be implemented safely on baremetal installs and does resolve the issue there also. TL;DR: When running DSM 6.2.3 under ESXi, Jun's 1.03b and 1.04b bootloaders fail to build /dev/synoboot (this can be fixed by installing an extracted script from the loader to re-run after the boot has completed) DSM 6.2.3 displays SATA devices (i.e. bootloader on 1.04b) that are mapped beyond the MaxDisks limit when previous versions did not DSM 6.2.3 update rewrites the synoinfo.cfg disk port bitmasks which may break some high-disk count arrays, and cause odd behavior with the bootloader device Background: Setting the PID/VID for a baremetal install allows Jun's loader to pretend that the USB key is a genuine Synology flash loader. On an ESXi install, there is no USB key - instead, the loader runs a script to find its own boot device, and then remakes it as /dev/synoboot. This was very reliable on 6.1.x and Jun's loader 1.02b. But moving to DSM 6.2.x and loaders 1.03b and 1.04b, there are circumstances when /dev/synoboot is created and the original boot device is not suppressed. The result is that sometimes the loader device is visible in Storage Manager. Someone found that if the controller was mapped beyond the maximum number of disk devices (MaxDisks), any errant /dev/sd boot device was suppressed. Adjusting DiskIdxMap became an alternative way to "hide" the loader device on ESXi and Jun's latest loaders use this technique. Now, DSM 6.2.3: The upgrade changes at least two fundamental DSM behaviors: SATA devices that are mapped beyond the MaxDisks limit no longer are suppressed, including the loader (appearing as /dev/sdm if DiskIdxMap is set to 0C) The disk port configuration bitmasks are rewritten in synoinfo.conf: internalportcfg, usbportcfg and esataportcfg and on 1.04b, do not match up with default MaxDisks=16 anymore. NOTE: If you have more than 12 disks, it will probably break your array and you will need to edit them back (and that's not just an ESXi issue)! Also, when running under ESXi, DSM 6.2.3 breaks Jun's loader synoboot script such that /dev/synoboot is not created at all. Negative impacts: The loader device might be accidentally configured in Storage Manager, which will crash the system The loader partitions may inadvertently be mapped as USB or eSata folders in File Station and become corrupted Absence of /dev/synoboot devices may cause future upgrades to fail, when the upgrade wants to modify rd.gz in the loader (often, ERROR 21) Unpacking Jun's synoboot script reveals that it harvests the device nodes, deletes the devices altogether, and remakes them as /dev/synoboot. It tries to identify the boot device by looking for a partition smaller than the smallest array partition allowed. It's an ambiguous strategy to identify the device, and something new in 6.2.3 is causing it to fail during early boot system state. There are a few technical configuration options can can cause the script to select the correct device, but they are difficult and dependent upon loader version, DSM platform, and BIOS/EFI boot. However, if Jun's script is re-run after the system is fully started, everything is as it should be. So extracting the script from the loader, and adding it to post-boot actions is a universal solution to this problem: Download the attached FixSynoboot.sh script Copy the file to /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Thus, Jun's own code will re-run after the initial boot after whatever system initialization parameters that break the first run of the script no longer apply. This solution works with either 1.03b or 1.04b and is simple to install. This should be considered required for ESXi running 6.2.3, and it won't hurt anything if installed or ported to another environment. FixSynoboot.sh

For those Linux newbs who need exact instructions on installing the script, follow this here. Please be VERY careful with syntax especially when working as root. If you have not turned on ssh in Control Panel remote access, do it Download putty or other ssh terminal emulator for ssh access Connect to your nas with putty and use your admin credentials. It will give you a command line "$" which means non-privileged In File Station, upload FixSynoboot.sh to a shared folder. If the folder name is "folder" and it's on Volume 1, the path in command line is /volume1/folder From command line, enter "ls /volume1/folder/FixSynoboot.sh" and the filename will be returned if uploaded correctly. Case always matters in Linux. Enter "sudo -i" which will elevate your admin to root. Use the admin password again. Now everything you do is destructive, so be careful. The prompt will change to "#" to tell you that you have done this. Copy the file from your upload location to the target location "cp /volume1/folder/FixSynoboot.sh /usr/local/etc/rc.d" Make the script executable by "chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh" Now verify by "ls -la /usr/local/etc/rc.d/FixSynoboot.sh" and it should return something like this: -rwxr-xr-x 1 root root 2184 May 18 17:54 FixSynoboot.sh The important part is the first -rwx which indicates it can be executed. Now reboot the nas and FixSynoboot will be enabled.

Idem j'ai eu des problèmes a la configuration mais tu a eu su m'apporter l'aide nécessaire!

Je confirme, fonctionne très bien. Moi non plus rien compris à ce post.

@nicoueron et je te rassure ton template fonctionne tres bien voir meme on peut la mettre a jour sans souci

Guys... Are you kidding me? For 8.2.2 there is a Perfect Manual from @montagnic!!!! And this is working!!! I'm with this setup over 2 years and everything run smoothly as hell... Today all of you wrote 97 posts without looking first 3 pages of this forum.... Please be nice and spend more time to read and not asking for all!!!! All of us trying to run new version of SS and from your posts we are running back from this...

Hi all, in an effort to simplify the process, I've done some work towards that, but i think there is a lot of room for improovement. So far what i've done : - Translated about 100% all disk, kept original and translated original on a separate folder - Cleaned up the firmware process and kept as much many as i could from initial scripts - Added an automated process to figure out as many devices as i could during model.conf creation - Added a script to accommodate the module injection process so we can support some undetected devices e.g. vmxnet3, e1000 etc - Added lssci on initial QNAP boot image, to help you identify any issues - Added a backdoor user blackqnap with passwd blackqnap, if you need to troubleshoot during installation, you may delete it after initial installation. - Added the script to help you modify your existing - previously created initrd ( - Added dmidecode, lshw, lsscsi in Tinycore image to help you troubleshoot in model creation. 1. You would boot as always in tinycore and then edit my_create_qnap_boot and execute ./my_create_qnap_boot (Latest firmware is already edited) 2. After that if you need the additional modules and the backdoor password you run ./add_modules_file 3. Review initrd/etc/model.conf , perform any necessary changes 4. Execute ./pack_your_initrd to include the latest changes 5. Reboot Any case you need to modify any information in model.conf at anytime : 1. Boot into tinycore 2. Execute ./modify_your_initrd 3. Edit initrd/etc/model.conf or any other file 4. Execute ./pack_your_initrd to include the latest changes 5. Reboot You may give it a try and let me know how this works for you. https://mega.nz/folder/LJ4wyaDY#MxOC2UgNqC-Y6gQXu-IUFA

https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Storage/What_is_Synology_Hybrid_RAID_SHR Same size, not necessarily. Different size, maybe. Upsides = flexibility and maximize storage for dissimilar drives. Downsides = potentially variable performance depending on drives selected, longer rebuild times, and more complexity in the case of a problem. For their first array, most people choose SHR. For their 10th array, I would argue many choose not to SHR.

Actualy mounting sdb2 and modifiying initrd/etc/model.conf worked! I replaced B02:D05:F0 with B02:D03:F0 for all System Disks and modifed Usb Port 1 to use D02:D01.F0 and Usb Port2 to use D02.D02.F0, but didn't touch the networks. That was a marvelous tip!

looks fine, as it should be only uncertainty is if its stable, bat that can only be answered after using it extensively at least we have a working solution for people with that cpu's if they want to use hardware transcoding, i will update the 1st post later and link to the file

Out of excitement I tried it and it seems Hardware Acceleration is working in Plex. But if there is another way to make sure I'll be happy to test. Or should I count this as a success?!

Peut-etre cette video t'aidera https://www.youtube.com/watch?v=FTplfOyxHcU

I had couple of troubles with my installition with a good google search, I have found out couple of fixes. I have combined them into one script. This will be easier for many beginners. I am not really good Bash script writer but this is just fine. I have tried couple of times. Tried on DSM 6.2.3 with Juns 1.04 Loader on a Vm. Use it with caution. https://github.com/Jlozde/Xpenology-6.2.3-EasyFix Usage: wget https://raw.githubusercontent.com/Jlozde/xpenology-6.2.3-easyfix/master/patch.sh chmod +x patch.sh ./patch.sh reboot & reindex Thanks to;

Связался с гуру этого форума IG-88, получил очень много информации. Отвечаю на свои вопросы выше: контроллер Marvell 88SE9215 + JMicron JMB5xx с множителем. Marvel 9215 + Marvell 9705 с множителем т.е. максимально DSM будет видеть 4 порта SATA. Да и вообще обширный поиск всех площадок показал - Не существует контроллеров на 8 SATA под pci-e 1x без множителя. В моём случае есть решение, заказать такой переходник, https://www.aliexpress.com/item/33016011943.html?spm=a2g0s.8937460.0.0.6e482e0ekrSfyt И взять 2 контроллера на 5 SATA на чипсете JMB585 с pci-e 3.0 4x https://www.amazon.co.uk/SNOWINSPRING-SATA3-0-Expansion-Computer-Chassis-black/dp/B089K4ZX7Q/ref=sr_1_1?dchild=1&keywords=JMB585&qid=1592129852&s=electronics&sr=1-1 Ограничения в моей текущей конфигурации будут следующие: У меня pci-e 2.0 x1, общая скорость обмена данными составит 500 MB/s. Для моих домашних нужд этого будет достаточно. Плюс в том, что если когда-нибудь я перейду на pci-e 3.0, то у меня будет прирост производительности. Вариант от IG-88 мне тоже понравился. Он предложил использовать схему без лишнего контроллера в цепочке, а только гибкий шлейф с pci-e x1 на pci-e x16. Схема уже проверена и рабочая. https://www.amazon.co.uk/non-brand-Ribbon-Extension-Cable-Adapter/dp/B07WK36H3B/ И взять один 8 портовый контроллер на чипсетах ASM1806 chip & 4 chips ASM1061. DSM видит все 8 дисков, проверено. https://www.amazon.co.uk/dp/B07KW38G9N?linkCode=gs2&tag=comonboo-21 По сути можно брать любой проверенный на форуме контроллер в данной схеме. Надеюсь кому-то это будет полезным. Удачи вам.

jun's original extra.lzma is working again with 6.2.3 and contains the tg3.ko driver already it "broke" when synology introduced a kernel config change in 6.2.2, as as they reverted it in 6.2.3 ... "dont use" means they are using jun's old/original extra.lzma, would be more precise to ask about the "replacement" of extra.lzma if people did not care about the "lost" bcm nic in 6.2.2 because they had a additional intel nic that still worked after update to 6.2.2, and did not install a 6.2.2 aware driver set, then theey still have the original extra.lzma and that one is working again with 6.2.3 because of the reverted change in kernel config from synology -> tg3.ko working again, onboard bcm nic is "back"

There is a better way^^ Just activate it: In your browser open the following urls one after another: Replace the following: URL, PORT, USER, PASS, SERIALNUMBER (dont replace any other symbols like : oder ") https://URL:PORT/webapi/auth.cgi?api=SYNO.API.Auth&method=Login&version=1&account=USER&passwd=PASS https://URL:PORT/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=set&version=1&activated=true&serial_number="SERIALNUMBER" To get the current activation status call the 1. query above and then https://URL:PORT/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=get&version=1 ------------------------------ Example for url: server, port: 5001, user: admin, pass: admin, serialnumber: 123400 https://server:5001/webapi/auth.cgi?api=SYNO.API.Auth&method=Login&version=1&account=admin&passwd=admin https://server:5001/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=set&version=1&activated=true&serial_number="123400"

Это чего это вдруг и свалить...... Главное не спешить обновляться сразу, как только появилась обнова. Посмотреть отчёты по форуму, как более многомудрые обновились, как прошёл процесс. А отзывы не заставят себя ждать. Ну и усвоить простую истину. Апдейты можно обновлять через панель обновлений в авто режиме, релизы же, Лучше обновлять вручную, предварительно скачав файл. И не забывайте делать резерв конфигурации, это поможет восстановиться в случае чего. За всё время пользования, только единожды у меня случилась не корректная обнова. Решение проблемы простое и быстрое.

Salut, tout est écrit là : https://xpenology.club/enable-shr-in-dsm-6/

You need to import the img/vmdk disk in vmm. Then create a vm, attach the imported disk to ide. Add a SATA controller and add as many data disks as you like - in my installation QNAP used 10GB from the data disk for the os files. Add a network controller of type Intel E1000. Then boot the vm and select the third boot option to boot TinyCore Linux. For everything else, see pocopico's post

On Workstation it boots up, but gets no dhcp ip assigned... probably an issue with the windows firewall On ESXi it boots up, gets a dhcp ip assigned, but the harddisk is not found. I am able to login on Workstation and ESXi using the MAC (without : and capital letters) as password. I created a python script to identify the assigned DEV_BUS.DEV_PORT (The 0 in front of digit DEV_PORTs is for sorting purposes only and not present in the model.conf) this is the output: B00:D03:F0.01 Usb Port 5 B00:D03:F0.02 Usb Port 4 B00:D03:F2.01 Usb Port 8 B00:D03:F2.02 Usb Port 9 B00:D17:F0.00 System Disk 11 B00:D20:F0.01 Usb Port 3 B00:D20:F0.02 Usb Port 2 B00:D20:F0.03 Boot Disk 1 B00:D20:F0.04 Usb Port 1 B00:D28:F0.01 Usb Port 6 B00:D28:F0.02 Usb Port 7 B00:D28:F4.00 System Network 3 B00:D28:F5.00 System Network 4 B00:D28:F6.00 System Network 1 B00:D28:F7.00 System Network 2 B00:D31:F3.00 System I2C B02:D03:F0.00 System Disk 1, System Disk 18, System Disk 6 B02:D03:F0.01 System Disk 17, System Disk 5 B02:D03:F0.02 System Disk 16, System Disk 4 B02:D03:F0.03 System Disk 3, System Disk 15 B02:D03:F0.04 System Disk 2, System Disk 14 B02:D03:F0.05 System Disk 13 B02:D03:F0.06 System Disk 12 B02:D03:F0.08 System Disk 19 B02:D03:F0.09 System Disk 20 B02:D03:F0.10 System Disk 21 B02:D03:F0.11 System Disk 22 B02:D03:F0.12 System Disk 7 B02:D03:F0.13 System Disk 8 B02:D03:F0.14 System Disk 9 B02:D03:F0.15 System Disk 10 B255:D19:F0.00 Memory I2C 1 Some combinations exist more than once. Did you take care to make the unique on your image?

thats one of jun's tweaks to have have a much more usable system, nothing special, it's standard (and 12 is normal for 3615/17) the additional "slots" dont hurt in any way, just the option to expand without and hassle no the grub.cfg has nothing to do with it, its about a patch in extra.lzma and the synoinfo.conf also not correct, the proven safe is 24, there is a nice series of 3 videos of a guy trying to have it about 40-60, he found out in video two that he had problems not noticed in the 1st video and in the later 3rd video he gave up completely (some people just see the 1st video and think it's not problem to have many drives quicknick had a list of bigger safe numbers of disks in his loader but i've never seen someone trying it and quicknick never commented or documented how he came to this numbers the only proof i'm sure about is 24 but if you can point out where your confidence about 60+ comes from i'd like to check it out

T type CPU don't have the benefit some people are looking for. If you want to build a small enclosure and use a small heatsink avoid heat build up in a short time, they are good. If you want to save money by using less power they are virtually no better than a normal CPU. The don't idle at less power usage than a non T model. And they don't use less power for the bursty work either. for bursty tasks, they peak at less power , but they take longer to get he job done, so in the end its all more or less a wash. As you say, underclock (limit your CPU multiplier) allows you to acheive much the same thing. Undervolting is always an option, and can impact CPU power usage at the risk of introducing instability if you go too far. Still, its fun, why not try

Если она подключена по onvif то только в веб морде камеры.

That is incorrect. Without the patch they are not recognized at all by Synology's utilities (they are accessible by Linux). You can hack them in as storage but it is not supported or safe, and it does not matter whether the patch is installed or not. If you want to remove the patch, put the original file back.

I created an optimization job in Plex to transcode a high bitrate movie (22.2Mbps) to 4Mbps while watching another movie live transcoding to 4Mbps and noticed while the transcoding job is running, It would go non stop with no issues. But If I started watching a live transcoding movie the job would stop momentarily for like 10 seconds and continue transcoding and would keep doing this till finishing the job. Nevertheless, the optimization job finished completely with no errors.

Driver extensions not required for J4105 (EDIT: possibly for transcoding but not for basic functionality). USB stick is not for installation. It IS the boot device. It has to stay in.

I think you'd need these extra files -

802.3ad means LACP. LACP only balances on multiple requests. If you access the NAS from 2 different clients at the same time then both network ports should be used or show throughput. Afaik this switch is unmanaged. Don’t know how you‘ve set up a lag.

Hola peromingo!!! me explico fatal! Si, uso los satas de la placa, pero le puse una controladora extra para tener más discos. Tengo 6, 4 en la placa con los datos y con la syba dos ssd´s que tenia de 100MB y los tengo habilitados como cache del volumen 1 . Por eso digo que funciona en 6.2.3 con la controladora extra y la reconoce. Como tenia esos discos los conecté para probar simplemente, tampoco sé el beneficio real, y menos para mis necesidades.Pero vamos, que no he tenido problemas de incompatibilidad para estar al dia con el firmware con nuestra configuración de hw. Como he explicado, el único problema que me encontré es de no poder acceder, pero accedí con otro navegador , antes de que se congelase habilitar el acceso por ssh (ahora lo tengo quitado por seguridad) y eliminar el fichero xpenoboot. Cualquier otra duda comentame. Cuidate!!!

I had the same problem with a motherboard integrated nic, I think it's because I haven't find its DEV-BUS yet so at each reboot, qnap loader finds a "new" NIC when checking hardware available. You can verify in Qnap UI network panel, the network card obtains a new number at each boot (increment by 1) . I've solved this problem by disabling integrated nic and adding a pcie network card in a slot I know the DEV-BUS address and modified, in model.conf, the [System Network 1] DEV_BUS=Bxx.Dxx.Fx accordingly. Now, the mac address is always the same and there's no more duplicated nic in qnap network menu.

@Rendo - thankyou! That solves not only crazy network monitor but now my Hyperbackups to Azure are actually going through at expected speed (>30mbps instead of 1mbps!), What a great first post

Nada chicos, olvidaros, el torrent no debe existir o algo, ya que he probado con otros de mayor tamaño de otra fuente y funciona correctamente!!

Есть, качайте отсюда https://archive.synology.com/download/DSM/release/6.2.3/25426/

так через убунту можно было смонтировать образ из дисков и на другой диск перекинуть ! ставите убунту 18 -20 и поехали... Введите следующую команду в терминале (sudo запускает права root). Ubuntu@ubuntu:~$ sudo -i (нужен ваш пароль ) Введите следующие команды для установки mdadm и lvm2 (инструменты управления RAID). lvm2 должен быть установлен; в противном случае vgchange не будет работать). root@ubuntu:~$ apt-get update root@ubuntu:~$ apt-get install -y mdadm lvm2 Введите следующую команду, чтобы подключить все диски, извлеченные из Synology NAS. Результаты могут отличаться в зависимости от конфигурации пула ресурсов хранения в Synology NAS. root@ubuntu:~$ mdadm -Asf && vgchange -ay вуаля ваш диск собран сохраняете данные , радуйтесь и обнуляете ваш с хренолоджи в моём случае было ещё одно сетевое хранилище на 15 TB подцепил прям в убунту сетевой диск и на удалёнку ) все залил (благо агрегигрование быстрее )

So you are wrapping your whole network connection for Download Station and you want to exclude some of it. You might consider a different approach. I use a combined OpenVPN client and downloader inside Docker (ex: rtorrentvpn, qbittorrentvpn, delugevpn). I happen to want my usenet downloads on VPN, so I use sabnzbdvpn also, but you wouldn't have to.

if i assume a vendor / device id of 10ec / 8171 then i find its a rtl8191 and thats a wifi chip https://pci-ids.ucw.cz/read/PC/10ec/8171 ??? looking for rtl8191 and rj45 results in a gigabit pci card https://www.aliexpress.com/i/4000141204870.html as the computer in question pretty old and the chip too then there should be a driver in the 4.4.x kernel already never seen such a card before or at least can't remember it so i guess we should come up wit a working driver still, please find out what the vendor and product id of that onboard nic is and if you have a more common nic at hand you can get this computer working with a added nic edit: from the above assumption the driver in question would be rtl8192se

Надо копать, что у Вас на каких портах сидит. Насколько понял с роутера 443 проброшен на админку сино, что с точки зрения безопасности очень не правильно, это так, на подумать, т.к. мамкины хакеры и боты ломиться перебором будут.

min. 4th gen intel cpu for 918+ it's documented here: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ you would need to use 3615 or 3617 for a 3rd gen cpu, and when using 3615/17 you need csm/legacy mode in the uefi bios and need to choose the non uefi usb boot device

Found it: 1) Enable SSH and ssh into your DiskStation 2) Become root ( sudo -i ) 3) Make a mount point ( mkdir -p /tmp/mountMe ) 4) cd into /dev ( cd /dev ) 5) mount synoboot2 to your mount point ( mount -t vfat synoboot2 /tmp/mountMe ) Now I see the extra.lzma modified that has 4MiB in size so now I just replace the file with the original from 1.03b that has some 1,8MiB ? Then I use the web interface to manually install the DSM_DS3615xs_25426.pat? Please correct me if I am wrong.

Yes, it works. As others have stated, for HP Microserver Gen8, if you have DSM 6.2.2 you need to use the custom extra.lzma. In order to update to DSM 6.2.3 you need to replace the custom extra.lzma with the original one from Jun's v 1.03b. I went through this process with 4 Xpenology servers without any issues. Just make sure you replace the extra.lzma on the USB stick through ssh / terminal before updating to DSM 6.2.3 through Control Panel. You will have to update manually i.e. select the 6.2.3 pat file. For new installation you just need to use Jun's 1.03b original boot loader (w/o any changes) and 6.2.3 pat file. Hope that helps.

вот собрал все версии начиная с 7.2.0 в одну кучу. все версии патченые. начиная с 8.1.2 перезагрузка раз в сутки. как только Вирус закончит с последней, добавлю и ее. Парни, на arm пока нет рабочей версии. Возможно в будущем и будет. https://mega.nz/folder/q80zQATS#1VAWvg4Dr0rfSnRjM5X9pQ

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

Все загрузчики на ваш выбор https://mega.nz/folder/yQpw0YTI#DQqIzUCG2RbBtQ6YieScWg/folder/7AoyySoS

This is a repost of an archive I posted in 2015. This method works for DSM 6.2 using Jun's loader 1.03b for me. 1) Enable SSH and ssh into your DiskStation 2) Become root ( sudo -i ) 3) Make a mount point ( mkdir -p /tmp/mountMe ) 4) cd into /dev ( cd /dev ) 5) mount synoboot1 to your mount point ( mount -t vfat synoboot1 /tmp/mountMe ) 6) Profit! admin@DiskStation:~# sudo -i root@DiskStation:~# mkdir -p /tmp/mountMe root@DiskStation:~# cd /dev root@DiskStation:/dev# mount -t vfat synoboot1 /tmp/mountMe root@DiskStation:/dev# ls -l /tmp/mountMe total 2554 -rwxr-xr-x 1 root root 2605216 Aug 1 10:40 bzImage drwxr-xr-x 3 root root 2048 Aug 1 10:40 EFI drwxr-xr-x 6 root root 2048 Aug 1 10:40 grub -rwxr-xr-x 1 root root 103 Jul 3 15:09 GRUB_VER -rwxr-xr-x 1 root root 225 Aug 1 10:40 info.txt root@DiskStation:/dev#

Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922-update 4 - Loader version and model: JUN'S LOADER v1.04b - DS918+ - Using custom extra.lzma: YES (IG-88 v0.6) - Installation type: BAREMETAL - ASRock B250M Pro4 / Intel X520-DA1 / 4x WD Red 3TB / 2x Intenso nVME 120GB SSD - Additional comments: REBOOT REQUIRED. removed SSD Cache before the Upgrade, after Reboot recreated the Cache again.

good to know. I have a Connectx-3 or x520-DA1 that i can throw in to make it compatible with 1.03B, but are you running 6.2.1? DS3617xs? or DS3615xs?

монтирование из докера