HeXagon

Confirmed this only happens on the 3617xs image. I reverted to a 3615xs Image and it doesn't have this same issue.

I think there's a serious problem with v1.02a. During a RAID 5 initial build, data is getting randomly written over segments of the md0 and md1 arrays rendering the Synology unusable. This is using ESXi 6.5 as a backend with a PCI passthrough of an LSI 9211-8i card. It happens when the RAID 5 rebuild gets to about 25%. This has happened on multiple ESXi hosts in various configurations, storage controllers, drive sizes and drives. It looks like one of the drivers injected may have a massive kernel memory corruption bug. Here's the dmesg from the VM. https://pastebin.com/raw/pLtNvVCb

I have 6.0.2 Working under XenServer 7 w/Jun's bootloader. I had to edit the wrapper script to force the NIC to be e1000 emulation. I used this patch here: https://blogs.serioustek.net/post/2016/ ... enserver-7 . You have to apply it by hand due to that being for an older version but it does work. The limitation here is it will see a maximum of 4 disks without Xen support built into the kernel. It also has performance penalties since the disks are emulated as IDE devices. Once support is built into the kernel for Xen (it requires a full kernel recompile to enable it) there's still some challenges of renaming xvd* devices to sd* although I think that can easily be done by hacking at the xen-blkfront driver code and changing the prefix to sd from xvd. @quicknick: if you want help hacking at xen I'd like to see about putting together a xensever-tools SPK file once you've got the xen support built in.