IG-88

naja, soweit ich wüßte orientiert sich das an der /etc.defaults/VERSION datei die man sich mit einem editor ansehen kann, wird in der regel verändert wenn man downgrades durchführen will (gibts einige beshreibungen dazu) in der pat datei (kann man u.a. mit 7zip öffne) gibts ein gegenstück "VERSION" poste doch mal den inhalt der beiden hier zum vergleichen

ich habe kaum praktische erfahrung mit der reparatur von linux dateisystemen und raids (so viel linux umgang habe ich nicht und da kam das bisher kaum vor, waren wenn eher defekte sektoren auf einfachen platten ohne lvm und mdadm oder trockenübungen) aber mal so aus der theorie wie das funktioniert heraus wenn man aus einem raid platten entfernt und sie mit "force" wieder "reinzwingt" dann muss man mit inkonsistenz rechnen (raid prüfsummen die "vealtet" sind weil daten geschrieben wurden aber ohne die prüfsumme) und sollte wohl die prüfsummen neu erzeugen/überprüfen so das alle sektoren der platten auch eine passende prüfsumme haben und natürlich sollte man das in dem raid liegende dateisystem auf konsistenz prüfen bzw. reparieren - gibt ja einen grund warum ein mdadm raid nicht automatisch beim "zusammengesetzt" wird beim boot bzw. ein dateisystem nicht gemountet wird und diese günde muss man beseitigen, es gibt für sowas in der regel auch dirty flags und die werden bei einer überprüfung, neu berechnung der prüfsummen dann auch zurückgesetzt da sowohl mdadm als auch ext4/btrfs standard linux sachen sind findet man dazu auch jede menge infos und howto's im netz, ist nichts was sysnology erfunden hat und nur für dsm gilt

hi, dsm 6.0.2/loader 1.01 - polanskiman's extra.lzma dsm 6.1/loader 1.02a/b - my extra.lzma according to your log the driver (*.ko) is loading and "only" fimrware file is missing you can copy the *.fw files of this arcive to /lib/modules/firmware/bnx2 after the next boot (or manual loading by insmod) the bnx2 driver will find the firmware after loading the driver and the nic will proably work http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-bnx2_0.36+wheezy.1_all.deb jun took only 3 rv2p firmware files into his loader and i only added 2 mips files people ask for to my extra.lzma, next version will may contain all the fw as it looks like depending on the hardware they all might by used (rvp2 and mips are likely chip/processors used on different version of a nic running under the same name)

windows driver are not so useful, if you can provide source that can be compiled with kerne 3.10.102 i will try to compile it, did it already with the realtek r8168, that was easy to get on realteks homepage found this one from 2015, according to the change log the 57788 was added https://docs.broadcom.com/docs/12358337 if i find time i can try to compile it an provide a extra.lzma for testing

nein, ich werde mich nicht extra mit dvb treibern beschäftigen, es gib genug probleme mit den brot und butter treibern für netzwerk und storage und die zeit die ich hier im forum reinstecken kann ist durchaus begrenzt ich habe zumindest versucht mit der howto zum treiber compilieren etwas zu liefern damit mehr leute an sowas basteln und helfen das einzige was mir in letzter zeit hier in sachen dvb untergekommen ist waren ein paar leute die das für tbs karten gemacht haben und da immerhin für dsm 6.0

as much as i can find with google the linux kernel module for this will be mvsas.ko that one is part of the driver extension i made for jun's 1.02 loader, so try to insert the extra.lzma and create a boot stick with it that kind of rings a bell there was already someone askink for that type of controller

try this extra.lzma with 6.1_15047 http://s000.tinyupload.com/?file_id=62938352906352581851

osfmount asks for elevated rights by itself to run with administrator rights just open the image, selct 2nd partition, ok, unckeck read-only, ok and there is a additionl drive letter with the content /extra.lzma) afair the same a writen in polanskimans howto using 1.02b is better, it fixes a problem that after a major update (6.1 -> 6.1.1) with a complete pat file 1.02a did not load the drivers from the extra.lzma so the system was not working anymore no need for 1.02a and 1.02b does only contain 2 additional driver compared with 1.02a the r8168 (realtek gigabit driver from realtek website, r8169 is the one delivered with the linux kernel) and mpt3sas.ko (for newer lsi 12Gbit controller?) as the one for the hp systems is working for you i could repackage the extra.lma from this and put the pata_via driver in you would just have to exchange the extra.lzma before creating the boot stick and of course using the old/fist 6.1 pat file (15047) i still want to know what mainboard it is, it's not so hard to grab a flashlight and read whats writen on the board

hi, the log entrys you provided just say that the driver was loaded, no indication of an error, anything else in the log like something about a firmware, afaik the dnx2 will need firmware to work did you try my extra.lzma (containing additional bnx2 firmware) or just the one that came with 1.02b? without any error i dont see how to help if you have a running system you can just copy the firmware files to you system or swap a *.ko file and try to load/unload manualy (insmod/rmmod)

i can only take the information you give and from "n36l-n54l.zip which has another LZMA that at least includes my realtek ethernet card " i took that hte named bootimage dooes not contain the r8168 (checked by extracting) and as you wrote the realtek and it was working ... what board exatly is it, whats written on the board an mayby have a look whats the lan chip on the board, on such older bords it will be a extra chip only use information verifyed the chip you metioned should work with the e1000 driver and thats part of jun's loader (it extremly common), we know that we have a driver for pata_via for 6.1_15047 so next is to find out why lan is not workind as expected the "n36l-n54l.zip" you found lan working contains a e1000.ko 154184 bytes, 2017-25-02 18:20, that seems to be the same driver as in "6.1 Jun's Mod V1.02-alpha", the e1000.ko in jun 1.02b has the same sie but newer date, migt also identical - so at first look it does not look plausible that the e1000 driver is used, maybe its something different? so its important to stick to whats 100% proofed

from what i read you will need the r8169 and the pata_via together, both where part of the first version of the extra.lzma i released only that the r8168 was loaded instead of the r8169 (rc.modules), i can repackage this and send you a link to it for testing, you will have to use the mentiond "first" dsm 6.1 version 15047 for installtion and you would be cut off from further 6.1 versions (or loose pata_via funnctionality) but at least you would have 6.1 with all the nice funktionalitys and from security point of view it would not be as bad as 5.x

hi, I remember that there was someone with a dell and the log did say something about missing firmware files https://packages.debian.org/wheezy/firmware-bnx2 so i added 2 or 3 files to my extra.lzma can you check the log (serial cable), or try my extra.lzma

whats the hardware? what oem? any driver (source) from the manufracturer?

hi, it's more like to give you the right direction what you are looking for (here or with google), the way dsm works is single disks with software raid, the raid (normal) firmware does not give the disks "directly" to the drivers/system, the IT (initiator/target) firmware just gives the disk as single devices to the system as they where every disk on sata port (that way you can have serial number, SMART information like temp from every disk) LSI (now broadcom) delivers IT firmware for there own branded controllers, there are a lot of howto and guides about it because it's not just for synology, its also used for other NAS and SAN systems (like whren using ZFS) i only did it twice in the last 2 years and in both cases used a new lsi branded controllers and flashed them to it mode using howto's i foud with google, ibm and dell controllers are often used as cheap sorce from ebay and crossflached to lsi firmware for using the IT firmware (what ibm and dell usualy not provide)

if you are willing to test i could make 2 versions of the extra.lzma from jun's 1.02b, its just removing oen file, modyfing a text file and repacked it, doe ony take a few minutes to do this, you just have to put it in the boot stick imge yourself (as there is the need of modifying the grub config, you are already using osfmount so no extra knowlage needed)

i'm not that certain, if using a hardware matching to those of a 916+ and using the jun 1.02b and 916+ image it could work, at least in the fashin a normal (original) 916+ synology system is doing it, have to read about it that someone realy tryed that, everyone just writes about ffmpeg and plex

as xpenology is running an Oracle VM VirtualBox and this is freely availible for MacOS, maybe this is your way?

maybe this infos are intrsting? its possible to build hyper-v drivers (like nic driver) but i expect them to be useless without the matching kernel, but if anyone is willing to invest time to realy find out i can provide the drivers (*.ko files)

i was not complaining about using older hardware (might be unreliable at some point and PATA/IDE disk are max. 750GB) it was about the fact that if the patch is this old and was taken into linux kernel it hast to be alredy in the kernel synology uses for dsm 6.1 as for using 6.1 with your hardware, as as long as you would stick to 6.1_15047 U2 from 3/2017 it will work and if thee are newer sources released from synology there will also be the option to use newer versions, as long as you need this driver you could not install newer versions of 6.1 but you could at least use 6.1 (if the old hardware supports 64bit) and features like docker support http://download.synology.com/download/DSM/release/6.1/15047/ + http://download.synology.com/download/DSM/criticalupdate/update_pack/15047-2/ and nothing newer (disable autoupdate of dsm)

this controller is based on LSI SA2208, with a IT firmware (and cross flashed to LSI?) it shoud work with the already existing drivers?

no thats not what it was about, its about that qsv (as ffmpeg using it) does need kernel support and this has to be patched in with a lot of effort (if even possible for the "old" 3.10.102 kernel synology uses) and then rhe whole kernel has to be recompiled (including the things jun deos for using it on non synology hardware) so a different ffmpeg will not do (at least thats what i found out) synology does use a different aprouch in the 916+ image (not ffmepg) " The DS216play with STiH412 Monaco SoC uses a specialised build of Gstreamer for the Synology transcoding solution, so its hardware features cannot be used by FFmpeg. It seems likely that Synology is also using Gstreamer for the Intel Braswell or newer generation CPUs with QuikSync, since DSM ships with an older FFmpeg (2.7.1) than the version which introduced QuikSync support (2.8.0). To implement FFmpeg QuikSync hardware transcoding support requires Linux kernel patches for libmfx support which is not currently included in DSM 6.x, so Serviio support for Intel QuikSync on Synology is unlikely unless Synology in future switches to using FFmpeg for its own hardware transcoding solution. " "i had a look into the MediaServerStudioEssentials2017R2.tar.gz there are 147 patches in that directory and you only have kernel 3.10.102 with dsm 6.1 and not 4.4" imho atm the only way is to use a compatible cpu and use the transcoding as synology intends it to be used not shure if anyone was able to at least do this with the 916+ image on a qsv capable hardware, imho first step use it the synology way after that thinking about how to put that to use, everything else looks like pointless dreaming (?)

maybe this can help with the RTL8111 (1.02b does contain two drivers for this hardware)

as much as i can see the extra.lzma from polansikiman does not mention a driver for RTL8111 (10/100/1000 PCIe) the original extra.lzma from jun 1.02a contains the r8169, that just the normal driver from the kernel 3.10.102, realtek does provide source code for those cards, but it has to be comiled for the kernel manualy, i did this with and placed it in my extra.lzma, the module is named r8168 (and about 10 times bigger then the one from the kernel, maybe it contains more special code for different version af the 10/100/1000 PCIe chips), i replced the modulname in rc.modules with r8168 so the additional kernel module should be loaded (as i dont have this hardware i could not test it) jun also provides this driver with his 1.02b loader but in his rc.modules both are in "r8168" and "r8169", as those are for the same hardware i can not predict what driver is used when the image starts with the tutorial i wrote aboute creating the extra.lzma its possible to extract it and make two versions from the 1.02b extra.lzma, each one only containing one driver for the rtl8111 (r8168 OR r8169), with that you can test both drivers seperatly, at least one of this drivers should work

if you are know some things about linux you can look inside the SPK (its just an archive) package and find the script where the security settings are made and reproduce it manualy (there is a folder scrips with things like installer, preinst, postinst) if the package is installed you will find them extracted in /var/packages/%packagename%/scripts/

did you read this? might give you a hint why QSV support with ffmpeg does not work (and the normal cpu cores and instructions are used)