IG-88

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

alx.ko would be the driver you need for this, 918+ uses a newer kernel (4.4.59) so it might not work with 3615/17 (kernel) 3.10.105 the driver would be mvsas.ko - jun does not have this driver in his default extra.lzma but its part of my extension, you can try to boot with it https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ if you still looking for a replacement then i'd suggest using a ahci 4 or 8 port sata ahci card, ahci support is build into dsm kernel, no extra drivers needed and synology cant remove it as there own hardware uses ahci i wrote about 8-ports sata cards here: https://xpenology.com/forum/topic/19854-sata-controllers-not-recognized/?do=findComment&comment=122709

so 916+ or 918+ (loader 1.04b) will not work, no need to test (4th gen intel aka haswell is minimum) atl1c.ko realtek 8168e chip -> r8168.ko Intel 82571GB -> e1000e.ko the e1000e is part of dsm's native driver set for 3615/17 and the atheros and realtek are part og jun's default driver set all 3 should work Marvell - 88SE9230, AHCI, no problems to expect nullmodem cable and on the terminal side you can use a usb2serial adapter if there is no serial that way you should see whats going on

habe bisher nur den umgekehrten fall erlebt welche hardware? board, cpu, storage controller, netzwerkkarte welcher loader?

yes, but also check your cables and dhcp server also try the synology assistant (program you can download from synology) to find your system in network what the systemboard and processor? what loader did you try you might start with 1.02b loader for testing, that has been used a lot so its reliable for testing too (also the additional extra.lzma has been tested more) edit: for finding it in network you even dont need to change the vid/pid, that is checked when installing the *.pat file to disk, so for just trying out loader and extra.lzma you can throw on the unmodded imgae to usb

160 GB - SATA 1.5Gb/s, ok die ist nicht so ganz frisch aber deine theorie bezüglich 1.5Gb/s ... lsi 9211-8i datenblatt: "Supports SATA and SAS link rates of 1.5Gb/s, 3.0Gb/s, and 6.0Gb/s" (der controller ist auch schon ziemlich alt) wenn sie am onboard läuft sollte sie es eigentlich auch am lsi 9211, ist aber bei der grö´ße eher akademisch, außer zum testen wird man die nicht mehr nutzen, mach einen aufklber mit kommentar drauf oder entsorge sie, so was kann 1-2 jahren wieder eine menge unnötige arbeit bedeuten

if just want to test you dont need to set the mac, only if you want to use wake on lan then the real mac is needed in grub.cfg in some cases (hardware transcoding?, some plugins like surveillance station) you need a valid serial number an a matching mac address things like mac and serial can be changed later if needed just install with vid/pid of you usb in grub.cfg and find out what you want to do with dsm

was für eine platte ist es denn genau?

that depends on what you are planing to do, if its more nas and server role (use docker instead of vm's) then its baremetal if its more about experimenting with virtualization like training for a professional environment and nas is just same small part then its esxi it might also depend on how you plan to do backups for your nas, or if the hardware in question supports vt-d and you want to use a that to have the whole controller with its disk inside the dsm vm (or do you accept to have virtual disks on esxi to have them in dsm) also a factor is the user base of the nas, if its the whole family the a less experimental dedicated baremetal would be the choice virtualization can also be handled on a desktop with virtualbox and if the nas storage is connected with 10G network you can use this with vm's keeping a good performance (in most cases 1-2TB local ssd storage on that desktop can do better)

versuch doch einfach mal 1.02b (3615 oder 3617) loader und dsm 6.1 ob es denn überhaupt geht

you might read the following to get a glimpse what other people using don't be so quick, if you find people with 9th gen gpu and working transcoding a 9th gen might be a better choice my choice for gigabyte was mostly because of the dimensions (and having 2 or more pci-e slots) https://xpenology.com/forum/topic/12867-user-reported-compatibility-thread-for-dsm-62/page/2/#comments https://xpenology.com/forum/topic/22482-dsm-622-24922-update-4/page/3/?tab=comments#comment-126408

mine was chosen because its only slightly deeper then a mini-itx board (special because of my case) and 9th gen is working too (with B360M) the B365 is pretty much the same, i'd not expect problems (afair the 365 was not entirely better then 360, more or less the same) B365M board will be at least one year newer so longer bios support

the driver is alx.ko and thats part of jun's driver set in theory juns 1.03b loader should bring up network and v23739 should work too

waste of hardware and energy, with dsm you can only user intel gpu features, so just leave it out and use the cpu integrated gpu also you won't miss anything on the monitor out, its just used for the bootloader, anything after that will go to a serial console 8th gen cpu with gpu will be fine, intel gpu is needed to have hardware transcoding, so not "F" type cpu as they are without gpu, you might think about a "T" type to save energy and heat (less heat = more silent) try to have more then one pci-e slots (extra sata ports and 10G nic) so something bigger then mini-ITX might be good i use a gigabyte B360M HD3

ixgbe is the driver, i added the latest to 918+ but can't say if it will work, as i could not test it i tested the tehuti 10G and bnx2x 10g driver

da würde ich nichts drauf geben, für den ist ein storage adapter mit eigenem bios einfach nur was anderes und es wird sysi genannt aber das mit den platten vom controller korrekt eingebunden (oder vid/pid korrwkt) kommt nach netzwerk erat mal das netzwerk problem lösen, dann bei den platten weiter machen lad die mal den synology assistant bei synology runter und such mit dem, oder schau mal auf dem dhcp server (der internet router?) ob dein gerät eine adresse abgerufen hat, auch mal die lan kabel auf korrekten sitz testen und nach den led's des nic schauen

indeed, as the 918+ does not have a pcie slot they dont budle drivers for optional cards, but a added tehuti und aquantia drivers (both 10G nic's) to the extra/extra2 i could only test tehuti, the aquantia driver might not work, some drivers load when the hardware is not present but crash when the hardware for the driver is present i will defiantly redo the drivers for aquantia in the next iteration but that will be in december

newer kernel means newer and more driver, longer support (3615/17 might not get 7.0? next year), native nvme support (but for now no one found out how use it in xpenology) shr will also be recognised on 3615/17 but you can't create a new shr without the change from the faq, so no worry's when updating

yes, i'd suggest to install first to a single empty disk to make sure everything is working after this you can disconnect the disk and use the same usb with out old disks, it will suggest to migrate if you want you can also test loader 1.04b and 918+ with a single disk, 918+ has kernel 4.4.59 as base for your board: nic is realtek (r8169), sata should work as ahci (at least with the right bios settings)

wie man die vid/pid vom usb ermittelt und in der grub.cfg einträgt wird im tutorial für die installtion erklärt https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/ ich habe für den controller nachgesehen, in deinem link war dazu nichts aber ich habe dann noch mal ein paar minuten nach dem namen des controllers gesucht und eine seite schrieb marvell 9215, das ist ein 4port controller und sollte problemlos gehen

it seems that removing jun's newer drivers in favor of the original drivers (that then will be loaded) might break it for other people needs more data collection on why ist fails on some systems and works on others, in theory it should depend an the processor generation, containing different gpu cores that will have to wait until 3615/17 is in a usable state and has a tutorial

try to the extra/extra2 with the originals fro m jun and reboot you might also try to remove the e10g18-t1 (btw thats a aquantia aqc107 based card, driver is atlantic.ko) if it worked before and you hat a synology natively supported nic, why did you use my extra/extra2 at all? my suggestion is to install it for testing on a single empty disk and if that works with the hardware then it might be ok to use it with a active installation containing data

wait for the next iteration, i will work on this in december when i'm done with 3615/17 i think i know how to get things right/better in your case the driver is igb and the driver in the 1st post's list is commented with latest crashed so it uses the synology default driver and that one seems to be to old for your hardware can you provide a lspci vendor id of the nic hardware?

what loader are you using, jun's default is 30MB