IG-88

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

the downgrade script might work too, but you also have to assemble the raid1 partitions with mdadm you can also modify the /etc.defaults/VERSION manualy with a editor of your choice, there is not much the script does, its more important to choose the right numbers in my case i had a 6.1 15047 and the udpate to 6.1.1 15101 is not possible so i had to clean the system partition /dev/md0 to cleanly install 6.1.1 15101, for downgrade the changing of version numbers might be an option too in the end by formating with ext4 its 100% sure you will loose the configuration an plugins and start with clean defaults

hi, there is no "tandem" its just software raid on sata ports, if there is more then one controller providing the ports the order of the controller/ports might be important (depending on how you specify it in the syno config file, the default is 12 ports in a row, behind that the sata ports and then the usb ports) you might take thist into consideration if you want to move your drives directly to a new hardware viewtopic.php?f=2&t=16933 afaik the SataPortMap is about how the ports are spread over the controllers and the order of the ports in the case of your board (you have not specifiyd the brand) it might be SataPortMap=242 or SataPortMap=62 the 88SE9128 chip has only 2 ports so the 2 external ports you mention might have a diffrent (additional) controller you did not specify or there are "switchable" from 2 internal to 2 extrenal (sometimes seen this with controller cards, not so often on boards - provide more/exaxt information and the predictions get better) for 9 disks/ports you still missing ports so you will need a additional controller with at least 2 ports if you have all ports in a row, fill the "slots" (ports) without a gap and specify the ports (internal sata, external sata, usb ports, -> ) in the config correctly, then to set SataPortMap might be of no importance you should realy be carefull if you do this without a backup and tranfering the drives directly, if you do you should map the order of the drives from the "old" system and should do a test installtion on the new system with one drive (test-installing the dsm 6.x) and map the ports with a additional drive so you know exactly the order of the ports in you new system, after you are shure about the port mapping you could put in your 9 drives and install the new dsm to it (keeping the data raid) imho you should be prepared that the synology dsm riad fails and you have to use an live linux trom usb to manualy reasemble/recover your data raid and backup/offload it (after your first attempt of directly migarting fails spectecular) beside putting in all 9 drives in install the new dsm (without the option to modify the configuration first, the first boot will be with the 12 drive default of the 3615/3617) there is also the option to install one addtional (10th) drive first, modify the config according to the new hadware, put the 9 old drives in and see if the system comes up booting from the one drive and "spreading" the working system to the 9 "additional" drives (expanding the system partition raid1 from 1 drive to 10 drives) if that works you will have the system on all 10 drives an can remove the 10th drive it might be possible to test all this in a vm (virtualbox) before doing it with the baremetal but it will take some time its much safer and easyer to have a backup of all date

people her talking about a 6.1 15101 clean install and update to u1,u2 did this in vm and baremetal, no problems you updated from what version?

you can format the (raid) system partition, it's a raid1 over all disks with mdadm boot from a usb live linux, use mdadm to "assemble" the /dev/md0 and format it with ext4 (data on other raid aprtitions will be untouched and found after install, so harm done, you just loose the configuration und plugins) its a very clean solution (tryed it myself), no risk of cating any iffy stuff from prevois attempts after "cleaning" the system partition (raid1) you just plugin usb stick with jun 1.01 and install 6.0.2, you might even restore a backup of you previosly working configuration https://xpenology.com/forum/viewtopic.php?f=2&t=30805