IG-88

jun wrote in his "whats new.txt" with 1.03a2 DS918+ may need a reasonable recent cpu instruction set to run properly. so we dont know for sure whats working with 918+ lmage we should start collecting and summarizing information about that 918+ is not just interesting because of supported apollo lake and hardware transcoding it also uses kernel 4.4 and we might have more luck with additional drivers (dead ends with dsm 6.1 for hpsa and sata/pata drivers) so lets have a limbo contest about "how low can you go" collected information might look like this in the end (i've already started collecting, so things below are based on users and my own tests) for now i will extend this list here in this place Edit: the CPU list is now maintained with the extended extra drivers see here for latest list https://en.wikipedia.org/wiki/Silvermont#Roadmap edit: but from "non working" feedback it looks like Haswell (4th gen intel core) might be the minimum for desktop cpu's, afair that was the same with the 916+ image i'm planning to do a driver package like we had for 6.1 so we could maintain a driver and cpu support list with it

i'd suggest using my extra.lzma as a first try (before trying to use your own package) the broadcom (bcm, tg3) nic's should work with this depending on how you created your own extra.lzma there can be a lot of problems, so first try if the tested extra.lzma works with your hardware

i guess if you try this you will fail dsm 6.2 seems to have even more protections then 6.1 and we always used jun's 6.1 loader (hack) and the original synology kernel (remember the never compiled hyper-v and amd support because it was missing in syno's kernel?), beside this i have'nt seen a recent 6.2 kernel source from synology, just the old beta 6.2 was released https://sourceforge.net/projects/dsgpl/files/Synology NAS GPL Source/ why do we need INTEL_PSTATE?

depends on the nic, in most cases its a cheap realtek and jun provided r8168/r8169 drivers, so its likely to work no, thats not the entirely correct, may be your nic did work but jun's extra.lzma does not contain "all" network drivers we used before on 6.0 and 6.1 there are intel drivers present (e1000, e1000e, igb, ixgbe) but my Intel Gigabit CT Desktop Adapter did came up on 1st booting 1.03a2, but after installing dsm and rebooting i lost the connection and had to use a different hardware to finish the installation - so my experience was a little flawed also there are firmware files missing for bnx2 driver (like with loader 1.02x the mips *.fw files are missing) we would need more effort in documenting what hardware is ootb working with 1.03a2 (cpu amd drivers) and also start a driver list/package like we have for 6.0/6.1 its still to early to say "everything works", i would not rush people into using that early version, there might even be hidden bugs that come up on first dsm update (we had this last year, when after updating dsm support for all additional drivers from extra.lzma where lost on some systems)

you don't give much information what loader and dsm version you tried, but if its 1.02b, dsm 6.1 ds3615 then its not going to work, if you have a look into the driver list where you loaded the addition extra.lzma (if you have) the you will see that via nic ist still orange as not used yet and not pesent yet also makes not that much sense as this ist 10/100 Mbit/s so the best perfoamance to expect is 11 MByte/s and that so low the use of this will be extremely limited i'd suggest you insert a 1GBit nic and try again

hi, downgrade is still the same as with 6.0/6.1, you mount the system partitions (raid1, partition on every disk) and modify the version file it should also be possible to empty (format) that mounted raid1 partition you also need 6.1 usb flash drive (with vid/pid changed propperly) if you still have xour original version then the dsm version on the usb is the last dsm version-updte you installed if you use jun's 1.02b release you should keep in mind that it contains the 1st dsm 6.1 version (15047) the flowing two links give you direction how to mount the raid1 system partition and how to downgrade btw. it would be good to know what hardware was used on unsuccessful try's (CPU, Network, Storage) there can be different reasons as to old cpu, missing driver, misc. problems i did had a strange install experiance too, but got it running after all, it's still alpha (thats befor it's even called beta) so if you don't know much about xpenology and linux better stay off for a while, there is not much you can gain atm with 918+ and dsm 6.2 (maybe people with apollo lake hardware will be eager to try to use hardware acceleration) i'm about to start a list of 918+ capable hardware and also a driver list and package as jun's extra.lzma is missing a 10G nic driver i'd need for my primary nas i guess we will start this in the "Developer Discussion Room" section

dual core should do for handling data with 1 or 2 GBIt/s network speed, dont expect it to transcode hd or 4k with plex, but just streaming that stuff without transcoding should work realy? "s" so more then one, mmhhh what just only 3, yeah that's a poor man's equipment maybe a VR headset laying around somewhere collection dust most people on budget dont have those in numbers laying around just read the tutorial and use the 3615 image

i dint know if pass-through works without any kernel support, i dont use hyper-v in any way but cant be that hard to try if you have win10 or server 2016, tell us how it went

found this patch https://marc.info/?l=linux-scsi&m=146005515401214 i will change the kernel source and compile a new driver, new extra.lzma version 4.8 should be ready later this evening

the driver crashed on load, try to install dsm 6.1.3 (thats the version the source for the drivers is used) also try to use the new 4.8 version (it will contain a frehly compiled version, but i dont think that will fix it, the drivers seemed to be compiled in a way that thea where working, could also be a incompatibility from synology or a general one that was fixed in later kernel versions)

nein, die internalports musst du auf jeden fall ehöhen da du die 12 ports die der default sind überschreitest (6+8+2), die kernel befehle mappen ja nur etwas um die anzahl bleibt gleich ob die kernel paramter gehen weiß ich nicht, das ist nur rein theoretisch auf gund der doku und den werten die man in dem link von den originalen syno boxen sieht (ich muss ja nicht alles selber testen, soviel zeit habe ich auch nicht immer übrig) die grub.cfg werte sind immer vorhanden auch nach einem dsm update, aber die werte in der synoinfo.conf die du manuell anpasst gehen bei den großen updates verloren da immer das image der ersten partition (dsm system) erneuert wird (wenn man in das 200MB pat file mit 7zip reinschaut sieht man eine hda1.tgz, das ist besagtes image, die grundinstalltion der version die man installiert) so wie ich das verstanden habe und in juns loader sehe werden dateien bei jedem start mit dem patch file verglichen (diff) und wenn es passt wird geändert da beim 3615/3617 image der default von synology schon 12 ist kommt in jun's patch da nichts vor, der patch im 916+ loader verändert die werte des grundimage da die von synology her nur auf 4 steht, was auch dazu führt das nach den großen updates wieder eine 12 reinkommt wenn man das gleiche mit dem 3615/3617 patch machen würde und dden default 12 auf 24 ändert würde das vermutlich die probleme der meisten leute mit >12 lösen da in dem fall auch nach jedem update geprüft wird ob der 12 -> 24 patch passt und nach einem großen update steht wieder 12 drin und das wird sofort geändert da die entsprechende datei in der extra.lzma ist wäre eine integration an sich kein großer aufwand, man müsste nur ein diff dafür erstellen und in juns patch datei einfügen, ich fang das erst an wenn klar ist was mit der 6.2 wird, aber jemand anderes hat schon mal angefangen das zu versuchen, wenn er es hinbekommt kann ich es testweise integrieren (oder er modded meine extra.lzma selbst, ist noch nicht raus) wenn es erst mal einträge im patch file gibt, dann kann man (vorausgesetzt man ist willens die extra.lzma auszupacken und neu einzupacken - was ich dokumentiert habe) auch seine eigenen custom einstellungen in den patch eintragen dann wird die default 12 halt in was anders umgepatcht und das wäre dann "update-sicher" theoretisch ist sowas (anpassung des patches mit eigenr config) auch in quicknicks 3.0 loader integriert, wenn man sich die doku zum 2.2 loader ansieht hat man einen anfang aber da es keine ofiizielles release war/ist gibts auch keine doku für die 3.0 - aber das die platten anpassung beim 3.0 auch große updates übersteht habe ich nicht getestet, als klar war das quicknick nicht releasen wird habe ich die tests eingestellt

there are two howto/tutorials in the "Tutorials and Guides" section i use the chmod environment of my tutorial on a regular base to create drivers for my extra.lzma so its capable of producing drivers depending on drivers from external source it might be different how they detect the kernel source installed, so it can be necessary to look into compile scripts or makefiles to see why they cant find the kernel source or have problems detecting the kernel version

yes, if you are interested in hardware transcoding its ok but keep in mind that there are some driver limitations, mainly the use of scsi/sas controllers is not possible, but if you stay with ahci its ok there is a special section for 916+: beside this, even with a running 916+ you can change to 3615 later if you want, just exchange the usb image with the one for 3615 boot it and "migrate" to the other version, the data volumes you created will not be touched in this procedure, you will have to reinstall plugins after this but that's all

XPENOLOGY? how do you define this, basicly "XPENOLOGY" is a DSM that is hacked in way to not recognize that it is not running on a original synology hardware, at least thats how it is now with juns loader and dsm 6.1 (afaik), it uses the original kernel and the whole dsm *.pat file, so its DSM you could say when you set it up you will be asked to participate and send data, if you unchecked this option it will at least be less but i guess when you add plugins from synology or download updates there might be some data (SN?) also things like this can change with every update, as long as its covered with the conditions you signed off by using dsm they can extend the amount of data they transfer, as long as its within the laws in the country you use it, so you might read the small printed staff to see whats possible if you want to be sure then block every internet traffic for the ip address of your dsm system and do udpates and packages install manually by downloading them with a browser and install them as file from your local network

you can check your grub.cfg on the usb set default='0' set timeout='1' also the timeout is stopped when pressing a key (any keyboard connected to the box?)

könntest du prüfen indem du einen usb stick fertig machst, den an die vm durchreichst und statt von dem vmdk vom usb bootest, wenn du vorher alle platten vom 8 port controller abklemmst und eine einzelne leere platte nutzt um zu installieren solltest du sehen ob's geht und nachher kannst du einfach wieder die platten anklemmen und vom vmdk booten, hat sich ja erst mal nichts verändert

ist koreanisch würde ich sagen, hübsche idee er hat eSATA port in Hardware (vermutlich onboard) und die reihen sich als softwaretechnisch interne ports zwischen die 6 sata onboard und den zusätzlich reingestecken controller (8 sata ports), wenn du genau hinschaust hat er dein problem schon vorher gelöst, er hat die internen ports schon von 12 uaf 16 erhöht um die probleme mit den 6+8+2 auszugleichen bringt mich aber auf eine idee, man könnte ja auch versuchen ob man die 2 ports einfach in (software) esata ports von dsm umdefinieren kann, evtl. kann dsm ja auch damit umgehen (aber anbetracht der kernel kommandos die synology zum ummappen von controller und ports eingebaut hat werden die das in ihren eigenen boxen nicht so machen damit wird zwar die durchgehende reihe bei den internen ports unterbrochen (wenn man sich das binär aufschreibt) aber wenns geht ... usbportcfg="0x0" esataportcfg="0xc0" internalportcfg="0xff3f" wenn man das so macht würde es aber bei den größeren updates (6.1.x->6.1.y) verloren gehen und man müsste es neu eintragen

under "STORAGE DRIVERS LIST" HP SA Pxxx is still red so it will not work as baremetal install with 6.1 if you have to use this controller you can install esxi and use the raid5 volume as vmfs datastore and create a virtual disk for the dsm vm, inside dsm vm you use this vdisk as basic disk (no raid inside dsm vm, you alredy have raid 5 by the controller hardware) for baremetal dsm 6.1 you will need a different controller or you have to install dsm 5.2 (or use a different system like open media vault)

in the end there seem to be two scenarios, dvb-t2 usb on shield (using nfs or smb/cifs to record to nas storage) or dvb-t2 usb on nas (with tvheadend, streaming live-tv to shield) as we know about the limits of DSM pretty well it looks like you will have to dig deeper on the shield, maybe changing the software on it to a more open linux that has better/full driver support for dvb usb solutions or just shell out 50 bucks more for a dsm or shield "compatible" dvb-t2 stick and spare yourself days of tinkering (or fun?)

nein mach mal bitte einen neuen thread auf, das ist was anderes

habe ich noch nie getestet aber mal so rein hypothetisch (neben abstellen im bios, was du aber vermutlich schon versucht hast) in grub.cfg folgende werte SataPortMap=628 DiskIdxMap=000E06 wobei ich mit bei DiskIdxMap nicht so sicher bin ob ich das richtig verstanden habe -> weiter unten für doku, selber mal lesen ob du das auch so siehst, wie die in dem beispiel von 06 auf sdq kommen kann ich nicht nachvollziehen, sdq wäre bei mir 10 (hex) sdX a b c d e f g h i j k l m n o p q r s t hex 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 wenn ich mit die sachen die hier mit DiskIdxMap stehen (aus echten syno boxen) so ansehe würde ich meinen ich liege richtig https://forum.synology.com/enu/viewtopic.php?t=95139&start=15 00 für die ersten 6 ports sda-sdf 0E für 2 port mit sdo-sdp 06 für 8 ports sdg-sdn aber das kannst du ja testen indem du den jetzigen usb stick zur seite legst alle platten abklemmst, einen neuen stick nimmst (vid/pid anpassen und die beiden map parameter setzen) auf eine der neuen ssd's dsm installierst und dann mit der 2. ssd überprüffst wie die ports gemapped sind, eigentlich null risiko sollte das funktionieren kannst du es in der grub.cfg deiner laufenden installtion eintragen und mit den platten wieder hochfahren (daumen drücken und klar, du hast natürlich ein backup aller daten ...) quelle: https://github.com/evolver56k/xpenology/blob/master/synoconfigs/Kconfig.devices config SYNO_SATA_PORT_MAP bool "Modify SATA Hosts Port Number" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #18789 Reads Sata-Port-Mapping information and forces the sata hosts to initialize specified number of ports. This makes the disk name not skip some characters. Notice - Do NOT set the port number out of the range that [0-9]. It supports as most 9 ports now. For example, SataPortMap=4233 means the 1st host use 4 ports, the 2nd host use 2 ports, the 3rd and 4th host use 3 ports. config SYNO_DISK_INDEX_MAP bool "Modify Disk Name Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #19604 Add boot argument DiskIdxMap to modify disk name sequence. Each two characters define the start disk index of the sata host. This argument is a hex string and is related with SataPortMap. For example, DiskIdxMap=030600 means the disk name of the first host start from sdd, the second host start from sdq, and the third host start sda.

maybe the shield is the problem? in the end i replaced my htpc with a sat>ip box (digibit r1, quad dvb-s2) and a odroid-c2 (more capable then raspi and ready made image from LibreELEC, also better driver support), recording and streaming is done by the xpenology box (tvheadend), so the xpenology is now the htpc but without the tuners and without the "head" if you ditch your shield and use something like a device with a more open linux distribution your choice of dvb-t2 usb devices might be higher (cheaper devices) but that would not solve your recording problem https://forum.libreelec.tv/thread/998-dvb-t2-usb-stick-advice/ https://libreelec.tv/downloads/odroid-c2/

the only thing i could make out was irq 18 and that one was used by usb but on 3rd look, yeah there are references to ifconfig and atl1c in this one the hardware in question seem pretty dated so the fact that kernel 3.10.102 isnt recent should not be a problem in my extra.lzma is a different one (new compiled, no new version, compared to jun's) of that module good thing to have a change log: [09.12.2017] uploaded v4.2 for all versions ... - replaced alt1c.ko in all three ramdisks with fresh compiled ones from 15152 as i got feedback that this modules where not working in jun's version ... at least it woth a try with my extra.lzma, in the driver thread there was someone in feb. 2018 who used that module successfully so its not broken in general in my extra.lzma so its defiantly a good idea to use my extra.lzma in this case

i was asuming that the realtek would be working as the driver is asigned irq 42 and the eth0 says its using irq 42 also r8168: eth0: link up

from the picture in the manual there is a ar8131, that would be atl1c.ko and that one is already part of juns lloader, so in theory it should work for both nic's ootb on closer look atl1c 0000:03:00.0: version 1.0.1.1-NAPI so it looks like the qualcom/atheros driver is loaded (finds hardware) but des not get a ethX asigned did you change set netif_num=2 in grub.cfg