IG-88

virtio drivers are part of libvirt? as there is a (beta) virtualization package vom synology with libvirt, qemu(KVM) i'd expect that to part of dsm or that package? https://xpenology.com/forum/viewtopic.php?f=2&t=32744

not excatly what i thougt, the spk format is sorted into platforms (processor/chipset) with cetain name the spk istself can be opend like a zip file and inside is a file INFO there you find things like arch="broadwell" or arch="bromolow broadwell" or arch="x86 cedarview avoton bromolow evansport" it ssems that arch="x86_64" is universal? at least synology packages contain that if your packeage in question does not contain the "bromolow" it will not show up on 3617xs if you look here you will see the names of the plattfoems supported by dsm 6.1 https://sourceforge.net/projects/dsgpl/ ... 047branch/ so if a new platfoem is introduced and the package is not maintained it might happen that the new device does not offer the package, even if it would run on that plattform (hardware/processor), it will depend on how the package was created - at least as i understand it it might work to manualy modify the package by writing the plattform into the INFO file, but i expect it will break the signirure of the file und i dont konw how such a spk file will be handled if installed be the manual install button in package center (never tryed that) so as the 3615xs is longer around, it might be the better choice (at the moment) wenn it comes to packages

well i took you word for granted that the mobo has 6 ports, if there are 8 (6+2) and they are found before the lsi it will look different in the mapping the bits/ports in the mapping have to tke all "visible" sata ports into account so if its 6+2+8 the correct mapping will look like this 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1100 0000 = esataportcfg 0000 0000 0000 0000 0000 0000 0011 1111 0000 0000 0000 0000 = usbportcfg 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 0011 1111 = internalportcfg esataportcfg="0xc0" usbportcfg="0x‭3f0000‬" internalportcfg="0x‭ff3f" maxdisks="14"

https://www.synology.com/en-global/know ... d_RAID_SHR https://www.synology.com/en-global/supp ... calculator

the date is the date inside the synology (bios date), check if that is correct if he still has valid user accounts, maybe one with admin rights? then you can try to login with this do a sudo -i and you are root

if you just want to "empty" your disks completly you can overwrite the master boot record in a instant and it looks like the disk has no partitions/data - !!! ALL data volumes on the disk will be gone, no old data at all after installing dsm !!!! dd if=/dev/zero of=/dev/sda bs=512 count=1 (writes zero's in the first 512 byte block of sda) continue with sdb and so on and after less then a minute everything is unusable/gone if you have more time and want to clean up properly (overwrite all sectors of the disk with zero) dd if=/dev/zero of=/dev/sda

that means the stick is not booting, you should see the menu selection of the grub loader i know the dc 7900, no uefi secure boot, just a classic bios maybe try to put the 5.2 bootloader on one of the not working sticks to proof the new sticks are working or (if you can recreate the 5.2 on the old stick) put the new loader for dsm 6 on the old stick in that bios there are two places where you can influence usb boot, both in the 2nd menu from the left one is a global option (yes(no) to enable boot from removable media, the other is the boot order (if removeble ist disabled the order is not used) - but if you reset the bios to factory defaults usb boot should work ootb

Take a look at this post.This is exactly how I was able to fix it without any personal data loss. However, apps and settings WILL go bye bye: http://xpenology.com/forum/viewtopic.ph ... 70#p100378 Well, I tried to follow your tutorial and came across a problem with partitions sda2, sdb2, sdc2 and so on, as they all come with "key" symbol in GParted and I cannot do anything to them, Partitions with 1 at the end (2.7 GB size) are available to format as ext4 however, so not sure if I should carry on and reformat only those. For the time being I am considering following a tutorial Polanskiman posted and make a backup first. the 3rd partitins (sda2,...) are your actual data volume, tey can be a direct mdadm (when on creation selctet there will be only one volume in the raid) or it is a mdadm with lvm and in there is one or more volume (even if tere is only whan when multi volume is selected it's lvm) - maybe gparted can't handle lvm but as you only wanted to format the system (dsm) you just leaf that sda2,... untouched, if the system is reinstalled to sda0,... the dsm will find the partitions and they will show up, if you still want to kill it you can do it from inside dsm with the gui dsm provides (it does not spell out that "only" mdadm and lvm2 is used, no specials just the normal linux stuff)

if you have a working 1.02a image you can try to extract the *.ko file from the 1.02a image (7zip under windows does the trick, but only for extracting) and can try to use it in the 1.02a2 image by extracting the extra.lzma, putting in the *.ko, extend the conf file for loading that module and rebuilding it as i described here viewtopic.php?f=2&t=32744#p99603 3615 an 3617 are both intel x64 so give it a try (it did work for me with thr evdev.ko for acpi shutdown, why not for the nic driver) - what never will work is a *.ko file fro m1.01 jun loader (dsm 6.0) that uses a different kernel

imho (if i "gap" in the internal sata ports is allowed - never tried that) this would be the configuration to try: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0000 = esataportcfg 0000 0000 0000 0000 0000 0000 0000 1111 1100 0000 0000 0000 = usbportcfg 0000 0000 0000 0000 0000 0000 0000 0000 0011 1111 1100 1111 = internalportcfg esataportcfg="0x0030" usbportcfg="0x‭fc000‬" internalportcfg="0x‭3fcf" maxdisks="12" asumtion on that is the system (dsm) finds the 4+2 (or 4+1+1) onboard first and the lsi is last what you did (with the placeholders for a "1") would correctly "writen" look like this (lis = 8 Ports = 8 x 1, mobo 4 x 1) 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0000 = esataportcfg 0000 0000 0000 0000 0000 0000 0000 0000 0011 1111 1000 0000 = usbportcfg 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 011 1111 1100 1111 = internalportcfg or with additinal "0" from the right side, so its good to read 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0000 = esataportcfg 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1111 1000 0000 = usbportcfg 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1111 1100 1111 = internalportcfg (red marks a error, 3 bit instead of 4, but in this case it does'nt matter it's only the "0" for filling) you see the problem (to "read" from left to right = lower bits first)? internal and usb overlaping - not good

it's "only" what other (like qnap, https://www.qnap.com/solution/virtualization-station/en-us/) alredy have and virtualbox was already used as 3rd party package on synology, but yes it sounds good

in theory dsm 6.1 is offering already exactly what you need, it does support virtual machines with a new package https://www.synology.com/en-us/beta/2017_VMM as far as i understand it thats exactly what was used befor for "virtual DSM" (a virtual DSM inside a hardware Synology DSM) but now it's open for all kinds of VM's, inside the package is libvirt and qemu (+kvm) there seem to be a lot of people using esx server for virtualising xpenology one of the main problems is the acess to controller/disks, if you system supports vt-d then you can hand over the storage controller to the xpenology vm and dsm/xpenology will see the disk and can use smart ans so on, completly like e real xpenology, but esy server will not be able to see or use any of the disks so the hdd space for other vm's need to com from different controller und disks or from virtual disks over nfs from the xpenology vm server (nfs) so you need extra disks or you firewall depends on the runnig of xpenology (providing diskspace by nfs), lots of dependecys and esx is still a addition you will have to handle and update (nothing against esx server, its great in professnial enviroment but not so good for the unexperianced) the other way might be provide rdm (raw disk mapping) devices from esx to the xpenology vm, in that scenario the esx controlls the storage controller, so xpenology does not see the real disks and will not be able so use smart. temperature or anyting - i would not do that i would suggest you set up dsm 6.1 as test with virtualbox an you desktop (howto is here in the forum), try out the new virtualization spk inside with your firewall and check that the hardware is running with dsm 6,1 und jun 1.0.2a/a2 (i still prefer 1.0.2a with 3615xs) - 2nd is best to test with a usb stick loaded with jun's bootloader, un plugging all disks (old dsm) and old usb stick (5.2 loader), using one empty disk as destination und usb stick with jun 1.0.2 for test install of 6.1 (is all hardware like nic, storage controller(s), ... working) after testing just replace the usb stick and reconnect your disks and no harm done to you running system if you decide for dsm 6.1 think about using btrfs, bau as there ist no conversion a complete offload is needed imho there is no good way of upgrading, as the 6.1.1 (the actual 6.1 that gets updates) only runs if cleanly installed, so it might be good to boot a live linux and remove all partitions from all disks (alternative is to assamble the system drive with mdadm and format it as ext4, the ext4 volume(s) with data can be left, after installing dsm 6.1 they will be interated and can be deleted from inside dsm to recreate the space as btrfs volume)

there might by a "easy" solution boot from live linux, use mdadm to assamble the system parttion (raid1 over first partition on all disks, 2nd link) and copy the file(s) from /lib/modules/update/ to /lib/modules/ https://xpenology.com/forum/viewtopic.php?f=2&t=20216&start=2900#p101580 and https://xpenology.com/forum/viewtopic.php?f=2&t=30805 PS: not shure where you have read that but i clearly remember a lot of people here complainig about for 2 weeks that it does not work - hardly to overlook when reading about 6.1.1 more then 5 minutes

RTL8211C(L) is no nic chip, it "only" a transceiver chip, the driver for the nic will be the one from the chipset http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=14&Level=5&Conn=4&ProdID=220 as it is an ION (Nvidia) i'd expect that the nforce driver will be needed (not part of dsm/synology or jun's drivers) https://xpenology.com/forum/topic/7507-tutorial-installmigrate-dsm-52-to-602-juns-loader/?do=findComment&comment=68013 i also used this chip in my writeup on how to compile a driver if you need one https://xpenology.com/forum/viewtopic.php?f=2&t=32744&p=99603&hilit=nforce#p99603 i'm still planning to compose a extra.lzma for 6.1/jun 1.0.2a~a2 with some of the most asked drivers but it does not have priority, my 6.1 is running fine now and whoever is in urgent need can compile it by himself with my howto, so maybe next weekend or the one after that i might do it (and if there is time i will try the same for dsm 6.0/jun 1.0.1)

when looking at the synology beta page it looks like they have replaced it with "Virtual Machine Manager", hosting linux, windows and Virtual DSM https://www.synology.com/en-us/beta/2017_VMM

you footer states as board msi b250i, the manual states Realtek RTL8111H, the realtek website states RTL8111B...RTL8118AS Unix (Linux) Apply to RTL8111H(S)/RTL8118/RTL8119i as well. the driver source provided by realtek, LINUX driver for kernel up to 4.7, contains file r8168.*, so it will be r8168.ko took 5 minutes and just reading websites and manual your bigger problem might be that juns loader only provides r8169.ko and that driver is often mentions to be loaded and causing problems with RTL8111H so a r8168.ko driver comiled for dsm 6.1 is the thing you need (and you have to make shure r8169.ko is not loaded, but instead r8168.ko

hallo, ich hatte das mal nachgelesen und festgestellt das verschieden unterstützt wird und theoretisch würde es wohl gehen, die 1815+ und 3615/17 sind hier gelistet: https://www.synology.com/en-global/know ... gy_servers ob das mit der performance geht hängt vermutlich auch von der last ab, bei wenigen nutzern wird es eher mit asymetrischem SHA laufen

as long as you dont know that an update is working it's red flaged by default you newer if sysnology has done soemthing like bringing in code to prevent xpenology from using the synology images and updates and a forum is not the best form, a wiki might be more up to it maybe the englsih section should be split up into areas for 5.0, 5.5, 6,0 and 6.1?

6.1? jun 1.02a or a2 the later is only for 3617xs its not only about dsm version (5/6) its also about the platform of the hardware 3615xs is broadwell, 3617xs is bromolow if the package is marked for broadwell and not for bromolow it will not show up in packagemanager of 3617xs, even if the both are x86 64bit have seen that for midnight commander package

just doing sudo su once after login and type the password will make you root and you can do all the stuff without typing sudo before every command

https://xpenology.com/forum/viewtopic.php?f=2&t=33043 but what does that list will help you?

jun 1.01 -> 6.0.2 jun 1.0.2a -> 6.1/6.1.1 3615xs jun 1.0.2a2 -> 6.1/6.1.1 3617xs as the 6.1 is not out for so long its still work in progress but does work good for a lot of people, no amd sopport for 1.0.2 yet, but some chipsets seem to work but no "official" support for amd 1.0.2a2 is basicly the same as 1.0.2a but with a fix for the timebomb issue (no data volume after 12h) that came with 3617xs

in the dsm control panel under hardware & power there are point "WOL an LAN1..." check that they are enabled

what board? i can check the specs and doku about the external sata ports btw, there are also 4 port cards, might be better to keep a slot free for later (10GBit nic)

you should be careful about the 6.1 version 6.1_15047 is ok but its not the newest anymore (no further updates), the actual 6.1.1_15101 uses the same kernel, means same botloader as for 15047 works (aka jun 1.0.2a/a2), updating from a older version usualy does'nt work, clean istall does so for you there ist no perfect solution, 6.1 keeps config but its already outdated, 6.1.1 needs a little bit more work to get a clean install