nsfw

It's working now with Vstation 2 and DSM 5.2 beta. Realtek nic. Convert the image first. qemu-img convert -f raw -O qcow2 XPEnoboot_DS3615xs_5.2-5565.2.img xpe.img

I got it to work now with Vstation 2 and QTS 4.2 beta. I converted the 5565 image with: qemu-img convert -f raw -O qcow2 XPEnoboot_DS3615xs_5.2-5565.2.img xpe.img Created a new VM with the xpe.img and using realtek NIC and created two SATA drives Once I booted up I saw all the init scripts start up and synology assistant found my new device.

Do you have a place to dump your VM so I can try on my TS-451? I was never able to make it work.

I have a TS-451 with 8GB of Ram and I tried to get xpenology to work in Virt Station. Unfortunately it seems to kernel panic and I don't know why. I can launch xpenology from the command line on my Mac using qemu and play it in vmware fusion but just not in the qnap. I really like Surveillance Station in DSM and wanted to run it inside QTS virt station but maybe someone else can try..

Wait.. correct me if I'm wrong but you can't just update DOT or major revisions of DSM since the kernel is updated as well. The only reason this still works is because community folks have packaged this up to support other devices and defeat DSM protection. They actually have to bring over the modules from older versions of DSM to defeat the security protection. What you guys are seeing is the security protection unmount your filesystems. You won't be able to fix this yourself.

worked for me using the usual: sed 's/flashupdateDeb/flashupdateDeb1/' /autoupd@te.info > /autoupd@te.info1 mv /autoupd@te.info1 /autoupd@te.info

Isn't this biggest issue right now the security mechanism put in place that no one has defeated? Basically some kernel modules from older versions have to be brought forward and merged into the newer code/kernel. It's worked OK so far, but at some point we are going to hit a wall of incompatibility between the old and new.

what daemon was compromised and what versions? how do you know this?

I just powered down. Synology will not bail out xpenology of course.

4493 was just released. remember don't update until nanoboot is updated in case the kernel rev was changed

Does ESX have the concept of "snap-shotting" you can go back to a previous state if you screw things up.

Did 4482 work for you as well on your VM of DSM?

what check does it do to know if its real or not? could a pci table file be changed to trick it into thinking it’s a real synology?

Synology doesn't owe you anything & no one is forcing you to update. Just be glad that the previous version is working thanks to Gnoboot & Trantor. If you want a hassle free experience buy a real Synology! I own a real synology! duhh.. but i built one with more storage and bays, however if its going to be unsecured then thats a big problem. I am greatful, but knowing my data is at risk isnt cool, henceforth why i say fuck synology for releasing updates like microsoft every TUESDAY!.. What does Synology have to do with the recent CVE's they fixed in 4482? They rely on several open source packages like SMB, curl, etc that they don't even work on. Be thankful they incorporate the fixes so quickly. I wouldn't lump them in with microsoft that has a web browser they haven't fixed. The CVE's are: Fixed a security issue of Windows File Service to prevent remote attackers from obtaining access. (CVE-2013-4496) Fixed several security issues related to cURL. (CVE-2014-0139, CVE-2014-0015, CVE-2013-6422)

I'm running gnoboot directly on my n54l without VMware. Runs fine.