filippo333

So, does your system automatically turn off and on?

Is anyone able to test auto-power on? Since the latest update, this feature is no longer working for me. Shutting down automatically however still does work fine.

Question: Why on earth would you want a second system to manage docker containers when there's a perfectly good one built into DSM?

Works fine on my config! Only after the latest VMM update (2.3.4-9027). Before this Windows would BSOD in a loop upon booting up the VM, Linux also kernel panic'd. I've not tested Linux yet but Windows 10 1809 installs and runs perfectly.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 Update 2 - Loader version and model: Jun's Loader v1.04b - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - Intel i3 6100

Currently using the DS918+ loader (was previously using the DS3615xs on my i3 baremetal) and so far it's a mixed bag. Windows 10 1809 installs fine, whereas Ubuntu and Xubuntu boot but won't install. I can see and format the disks without a problem, but as soon as I get to the disk selection step of the installer, the setup window goes into an infinite loading screen. It doesn't matter if I switch the disk mode from VirtIO to SATA or IDE the result is the same. CentOS has it the worst, using the minimal installation ISO I get a kernel panic and there is no way around it that I was able to see. The official compatibility list is quite out of date, I did try a certified build of CentOS but get the same problem. VMM might be putting some incompatible instruction in the Qemu VM config or maybe it's just really broken (which I find hard to believe). I'm lead to believe that this is the case as in my previous post I mentioned that enabling CPU compatibility mode with VMM Pro resolved the issue whilst on my DS3615xs loader (in which VMM was even more broken than it is on the loader I'm currently using )

Thanks again dude!

Is there a DS918+ loader version of the DSM 6.2? For previous loader releases this was an option.

Does changing model require a re-import of your data? It's possible VMM is fine tuned for the CPUs it's designed for. This is likely why people running as a DS3615xs and DS3617xs have no issues with VMM on enterprise Xeon hardware (as far as I know).

Update: After enabling Core 2 Duo CPU compatibility for the VM (only available with the pro version of VMM) it works perfectly. Unfortunately this isn't an option for most people (me included) as it requires a valid S/N and MAC combo to obtain a trial and or purchase a VMM pro license for $130. Maybe there's some way to force this instruction set in the hyper-visor without a license?

Yeah I'm getting the exact same thing, Windows also gives me a "kmode exception not handled" BSOD. It seems like some sort of Synology kernel incompatibility. Though the odd thing is the beta didn't have this problem when I was first testing it out on my bare-metal NAS.

Does anyone know if the drivers on the bootable medium override any drivers Synology might update?

Agreed, it's worth pointing out that the DS3615xs is based off the regular consumer i3 architecture whereas the DS3617xs is Xeon based. Obviously if you're not using a Xeon of that generation then it's recommended not to use that specific config.

Yeah I have the exact same problem when running the loader from VMware Workstation 12. No network or disk activity whatsoever, not tested on baremetal hardware myself.

Can you please define not working? It's not helpful to developers when people aren't verbose

As far as I know your system is bricked. Major releases such as going from 6.1 to 6.2 almost always cause problems. Always check the forums before doing any updates. Thus far, we need a loader specifically for 6.2 compatibility. Sent from my ONEPLUS A5000 using Tapatalk

That's a very good question, I'm sure there are many others including myself that have a dedicated Synology box. Anything that makes Xpenology more plug and play is certainly good news! I know DSDT patching is what is used in the Hackintosh world to make regular PCs more in-line with Apple hardware. I'd also be interested to know what validity checks exist on genuine Synology hardware. Although I'm pretty sure the devs would want to keep it under wraps to ensure Synology don't catch onto our patching ways!

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.6-15266 Update 1 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: ASUS H110I-Plus (Skylake) - Additional comments: Reboot required, takes longer to install compared to previous updates ~3-4 mins.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.6-15266 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: ASUS H110I-Plus (Skylake) - Additional comments: N/A

You can also get Intel X520-DA cards dirt cheap from China. If you don't mind waiting a few weeks for them to arrive, then they're literally 2-4 times cheaper than getting them locally. I've got two, one in my desktop and the other in my Xpenology box. Both work out of the box and I get around 400-450MB/s throughput copying files from a block-level formatted iSCSI connection (1x SSD drive). I also get just over 2x the performance out of my 3-drive SHR array (7200RPM drives) going from 110MB/s to around 240MB/s. I highly recommend the Intel cards as they "just work" with no configuration whatsoever.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.5 15254 - Update 1 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: ASUS H110I-Plus (Skylake) - Additional comments: Reboot required. Update resets synoinfo.conf!

Hmm good point, let's just hope that the reason for Synology doing this is purely for modernisation and not as an attack on Xpenology. As we are after all niche and hobbyists.

I’ve done a bit of research as to why Synology would be signing their kernel modules. Could it maybe be to allow for Secure Boot as it seems to be a requirement for using this feature? I’m not sure if this is relevant but disabling secure boot may invalidate the need for requiring signed modules? If so this PITA hardening feature can be disabled with a simple kernel flag when recompiling the Synology kernel from source. http:// https://askubuntu.com/questions/773734/how-to-install-module-ko-module-without-kernel-signature-or-kernel-rebuild-in-ub Sent from my iPad using Tapatalk

I don't think anyone can answer that question right now since the loader currently isn't available. In theory if you use the same serial number, mac address and Synology hardware model (ie DX 3615xs), you should be able to just import your drives into a new loader. I managed to successfully import drives from my Xpenology box to my genuine DS 1515+ when I had one, without issues.

Honestly if Synology play that game and make it harder and harder, I'll move to a different OS entirely. Most people with an Xpenology either: a) Can't afford a genuine Synology system. b) Have a more powerful system compared to most of Synology's product range (my case). Synology should be smart and offer their OS at a price for third party systems rather than piss off people that wouldn't/can't use their hardware for various reasons. I'd pay good money for DSM personally.