IG-88

sas9211-8i (and oem's flashed to this) are the most common ones but you can also use a ahci controller for this

sorry if want to you need to do it on your own there will be a hpsa driver from the kernel in the next extra.lzma for 3615/17 and thats from my side for now maybe you change to open media vault?

i installed the last packed and after installing replaced the button.ko and evdev.ko with the files belonging to 6.2.2 the installer in the package replaces the files of a 6.2.2 system with the files in the package and they belong to 6.2.(0), everything else is fine, you just have to bring the kernel driver files back to the version they need to be (/usr/lib/modules/) as final solution the package needs to be modified to be aware of 6.2.2 and have extra *.ko files for this version postinst () { chown -R root:root ${SYNOPKG_PKGDEST} cp -R ${SYNOPKG_PKGDEST}/files/* / cp -R ${SYNOPKG_PKGDEST}/modules/$DSM_VERSION/$DSM_PACKAGE/* /usr/lib/modules/ exit 0

part of curcumventing the dsm protection is to use the original kernel and hyper-v support is not compiled into the dsm kernel, without that the hyper-v driver dont work

already happend for 3615/17 but still not released yet and will be done in the next weeks for 918+ too when restarting work in 918+ after finishing with 3615/17 there was a change in kernel config in 6.2.2 making most driver incompatible https://xpenology.com/forum/topic/7187-how-to-build-and-inject-missing-drivers-in-jun-loader-102a/?do=findComment&comment=122631 i also found a "good" kernel config and have documented some steps i did to adapt to 6.2.2, but that extension need some more writing and i dont have much time, if you are interested i can send you what i have, its not fool proof but if you know how to compile a kernel you will find your way i guess

polanskiman changed the topic a while ago (original war just 1.04b),it takes more time then expected (new problems with sas/scsi drivers found) and i don't have much time left atm (kind of end of the year rumble at work) also installing needed more testing as you can't just copy the new extra.lzma to jun's loader 1.03b (for now it seems best to extract zImage and rd.gz from 6.2.2 DSM *.pat file and copy it together with the extra.lzma to usb)

that's what's left (old extra.lzma v3.0 and 3.2) http://s000.tinyupload.com/?file_id=09441430823897482943 might not work at all, no support, no further tests from my side as i don't have the old 6.1 build environment and it takes more time to work for 6.2 then expected when it comes to "more universal" then the 6.0 was capable of more hardware then 6.1/6.2 and when in comes to a recent DSM (6.2) then ahci controllers are the way to go (imho) https://xpenology.com/forum/topic/19854-sata-controllers-not-recognized/?tab=comments#comment-122709

the hpsa driver from kernel 3.10.105 is in the extra.lzma but there seems to be something wrong with most sas/scsi drivers my compiled mpt/mpt2/mpt3 drivers dont work, also vmw_pvscsi (vmware paravirtual scsi) does not work, synology might have changed the kernel code in the sas/scsi area preventing us having new drivers because they did not publish any new kernel source since the 6.0 beta over 2 years ago, maybe we cant do much and from the feedback of some testers i dont have much hope that the the (yet untested) hpsa driver will work (also it does not support newer controllers and we had a lot of trouble with the external drivers too already) for now the is no mpt / vmware driver and mpt2 will be use what comes with dsm (3617 also has a mpt3) as long as i cant compile a working mpt2sas driver from the kernel source there is not much hope to get other sas/scsi drivers working after 3615/17 release i will try whats possible with the 4.4.x kernel from 918+ for people wanting to buy a controller my recommendation is ahci not sas https://xpenology.com/forum/topic/19854-sata-controllers-not-recognized/?tab=comments#comment-122709

no, that would prevent installing at all (error on install) can you try to remove the internal 512MB flash module?

i'd recommand a ahci card, sas and scsi seems to get more of a problem with later versions like 6.2.2 3615 hat mpt2sas and 3617 has mpt2sas and mpt3sas but i would not count on drivers beyond what dsm provides, ahci seems a safer bet by now as is is already part of dsm by default https://xpenology.com/forum/topic/19854-sata-controllers-not-recognized/?do=findComment&comment=122709

if seen logically, the driver is still all the same snce you installed, external sources like cable and switch port are checked then it leaves only the nic hardware i'd suggest to try a additional nic but with your hardware ... no pcie slot my way would be to use a recent live linux (newer driver) booted from usb (or a windows booted from usb) and try to find out if the problem persists if it does work better with different driver then trying a newer driver with dsm might help, but afair i had problems with that particular driver then doing the last extra.lzma for 6.2.2 ("experimental") so i used jun's in it, i think i know why but as i'm on testing for 3615/17 now it will take 2 weeks before i will do 918+ again you can try a usb nic but dsm is picky about that (not as much drivers as usual linux distributions have) a alternative could also be to user a usb drive with open media vault on it in the meantime, thats my plan "B" when dsm should have hickups and i need to use my data on the dsm data partition (omv should automatically detect the data raid partition on boot - at least it did as i tested it) edit: heat can be a factor too, try to push cold air into the narrow housing or leave it open and use a fan from above to have planty of cooling to test if that helps

i'd check cabels and switch port and if the switch is managed the log of the switch, there are things like STP (spanning tree protocol) that can block a port on the switch, but there can be other reasons too why a (managed) switch cut's off a port (like intrusion or fault detection)

maybe its checking for web service and if that is not running then its not available (as DS "service") and not shown that's what ping and ssh are for and in worst case you might need a recovery/rescue linux to boot from to get your data btw. good time to think about buying a UPS and checking if the backup is recent enough (and what data needs to be backed up) i also have plan "B" like DSM is unsuable after a update and i need access to my data, in my case i know i can boot up OMV and access the raid volume (its just mdadm and lvm) over network, also a option could be to access files from the backup you spotted problems with your way of running things? try to eliminate the cause or at least mitigate the effects usually the private NAS data should be treated similar as business data, planning and backup is needed too for your own data (having a broken raid made me thinking too years ago)

atm you would loose the internal network as of driver incompatibility between these versions, only dsm native driver would be working https://xpenology.com/forum/topic/13922-guide-to-native-drivers-dsm-617-and-621-on-ds3615/ if you wait 1 or 2 weeks you might be able ti use the new driver package containing the driver for your braodcom nic if you are willing to test (spare usb and disk for a separate test install with new driver package - before trying anything with your running installation) i could send you the latest test version (needs at least until tomorrow as i spend time lately with 3615 testing, 3617 needs recompiling drivers)

ich habe hier noch keinen gesehen der sowas überhaupt probiert hat oder gar am laufen das müsstest du dann selbst in detail testen/rausfinde, setzt linux kenntnisse voraus und man muss sich damit beschäftigen wie das mit der diskanzahl in der synoinfo.conf funktioniert (ein bit für jede platte und in hex umrechnen - gibts auch videos auf youtube zu) ich vermute man muss den usb bereich nicht auf 0 seten sondern evtl. absichtlich mit den disks überlappen lassen das ist alles total undokumentiert, ohne funktionsgarantie und wird von synology selbst so nicht benutzt/unterstützt - ziemlich hohes risiko im betrieb und bei updates keine ahnung warum du so eine zboc nehmen willst, vekauf das ding und besord dir was anders auf ebay (oder sonst wo) - dein ansatz wäre, sportlich, gut wenn man was lernen will und viel zeit hat - meiner erfahrung nach wollen das die meisten nicht evtl. ist es auch einfacher den gleichen ansatz mit open media vault zu versuchen, ist nicht so eingeschränkt und kompliziert wie dsm (das ist eine appliance), OMV ist eine normale open source linux distribution

if you install with 1.03b then you have to use 6.2 (0) https://archive.synology.com/download/DSM/release/6.2/23739/DSM_DS3615xs_23739.pat if you update to 6.2 or use web install then at least atheros and realtek driver will fail so try 23739 and for later version wait for the new driver package that is compatible with 6.2.2 (24922)

i think i remember something about crashes of hardware transcoding when a monitor is connected

its part of jun's loader 1.04b already https://xpenology.com/forum/topic/12952-dsm-62-loader/ A new ds918 loader support 6.2/6.21 is uploaded. whats new: uefi issue fixed. i915 driver updated. monitor connected?

that needs to be red an bold !!!

cpu for 918+ needs min. 4th gen intel aka haswell, gen8 can't handel that

as far as i have seen/read he removed jun's drivers for the internal intel gpu, leaving the system in question using the drivers coming directly with dsm afair jun did made new drivers to support newer hardware (?) but thats one of the things i wanted to look into and test in theory its the same hardware as the original 918+, J3445 cpu, ahci storage and realtek nic it does contain the driver from jun but the loading order is different @olegin seemed to have success with that so i took it int my test version (seemed better then to just remove it), that needs testing with different hardware, we can make test versions with one or the other method what do you mean by that, dont you have /dev/dri after booting up to use hardware trancoding? in general the original driver should work for you

we will see in about 2 weeks, i have got ideas what to try with 918+ when redoing the driver and i have a good kernel config to try out good to know same names now being able to test ixgbe and even i40e i will stop trying to get sas/scsi drivers working for 3615/16 on 6.2.2, network drivers seem to work fine and 3615 has mpt2sas and 3617 has mpt2sas and mpt3sas, good enough

if you can wait then you can test again when i redo then 918+ in december and if you can't then go ahci when i see the problems with sas/scsi with 1.03b/6.2.2 3615/17 then i think there might be a change in the kernel source (we don't have) preventing any sas/scsi based drivers beside the ones coming with dsm, if that's true then i wont be able to get working drivers for 918+ i will know in about 2 weeks, i have a lsi 9211-8i controller using mpt2sas so i can test drivers if you want to prevent any certainties then buy a ahci controller, that's sure to work with 918+ 6.2.2

that and other things are part of "libsas.ko", that needs to be loaded before mvsas.ko (-> rc.modules in extra.lzma) if you load it manually try this sequence scsi_transport_spi.ko scsi_transport_sas.ko libsas.ko raid_class.ko mvsas.ko

versuch doch mal ob das hilft https://xpenology.com/forum/topic/14093-hw-transcoding-fix-v104b-ds918/?do=findComment&comment=112816