gnoboot

It's already default, can you provide dmesg? Nope, but there's a workaround which is a bit ugly or modify the driver but I'm not sure about its side effect. @billy Are you running nested Xen on HyperV? Can you login to console and try running virt-what?

i cannot get into any console/terminal i dd the alpha7.img , it work againt ... and then replace the zImage from alpha8, it boot-up to "DiskStation>", i could login in vb console, however, Cannot going in by the "192.xx.xx.xx:5000" ... any difference between alpha7 and alpha8? only more drivers? Yep. Did you also copy the new GRUB conf? If not, then delete all "initrd rd.gz" lines in your config.

You're right! This is issue also present in alpha10. EDIT: I think changing max CPU other than 8/4 is the culprit, compiling a new kernel and probably upload alpha10.1 later. PM me your email

Move /lib/modules content to another directory. gnoboot> mkdir /lib/modules.backup gnoboot> mv /lib/modules/*.ko /lib/modules.backup gnoboot> reboot If it works then delete the /lib/modules.backup (i.e. rm -rf /lib/modules.backup).

Thanks for your feedback, appreciate it!

hmmm, let me create a new e2fsprogs spk:)

I haven't fully tested/tried disk group, can you create a normal volume instead? Using the latest version (alpha10) might have the same issue because nothing's change in the kernel except the new drivers which has been compiled outside the kernel tree.

All I'm asking is your feedback from the previous releases, then you'll get the password.

Your disk might be sleeping. [spoiler=] /libsynosdk/lib/disk/disk_temperature_get.c /** * Get disk temperature * * @param szDevice : device name. ex: /dev/hda * * @return -1: can't get disk temperature * other: disk temperature */ int SYNODiskTemperatureGet(char *szDevice) { int retval = -1; struct ata_smart_values curval; if (NULL == szDevice) { goto ERROR; } //don't check if device is not running. if (FALSE == SYNODiskIsRunning(szDevice)) { goto ERROR; } if (SYNO_DISK_PROTOCOL_TYPE_SAS == SYNODiskScsiProtocolGet(szDevice)) { retval = ScsiSmartTemperatureGet(szDevice); } else { if (SmartDataRead(szDevice, &curval, NULL)) { SYSLOG(LOG_ERR,"read value %s fail", szDevice); goto ERROR; } retval = SmartTemperatureGet(&curval); if (0 > retval) { retval = SmartAirflowTempGet(&curval); } } //#20062 temperature under 0 degree. sensor would return 6553X. //set temperature as 0 while temperature over 200 degree. if(retval > 200) { retval = 0; } ERROR: return retval; } It's DSM, same reason why I stopped fixing ssd misinformation for VMs.

How big is your vmdk? Can you post a screenshot when it happens or dmesg? You won't be able to poweroff the system while its deleting the volume. The same goes for creating a new volume, you can verify it's still working by runnning `cat /proc/mdstat`. To force power/reboot your system use `poweroff -f` or `reboot -f`, but these commands are dangerous. I have had experienced the same behavior as yours because of improper shutdown.

Are you sure its alpha10? My guess is your using iSCSI lun, and then you're trying to delete it that makes your system unresponsive, right?

How do you get password for alpha 10? I don't understand what the following means on the notes for alpha 10: I've posted comments on your blog, and active in your thread.. but dunno how a password will magically get to me Done, check my pm.

Those users reporting hibernation is working might be using Marvell controllers that is fully supported by the vendor. EDIT: my boot image now supports downgrade option

gnoboot-alpha10 bootable FAT32 image will be available in the next few hours. stay tune!

Are you using tg3 (Broadcom) driver on your ESXi host?

modules.conf is no longer use, all modules configuration are noew stored in modules.d. I will fix it on the next release. Thanks for reporting. What file are you working with? Alpha 9 isn't a disk image, it's a kernel zImage. Some of the prior release were actual disk images that have grub, and a zImage on them. you need to swap out the zImage from one of the older release that was a disk image. Correct, you can still find alpha7 boot image on my blog and replace zImage. Warning: To all ESX5.X users using tg3 driver, check kb2072515.

Yeah, WOL worked just fine in previous version, with the cracked solution. I also have changed the wol options in both /etc/synoinfo.conf and /etc.defaults/synoinfo.conf, and I can confirm the checkbox for WOL is enabled in DSM. But WOL is still not working. I am using the S99ZZZ_Shutdown.sh script solution now. And WOL is working fine, this can be a temp workaround for now. Got a new tg3 driver, wanna try it? I'll think about it...

To force DSM to boot properly, you need to directly login to console and then follow commands below. gnoboot> synobootseq -h Copyright (c) 2003-2012 Synology Inc. All rights reserved. Usage: synobootseq [COMMAND] --set-start-etcrc --set-check-fs --set-start-services --set-boot-done --get --is-ready gnoboot > synobootseq --set-boot-done gnoboot > synobootseq --is-ready gnoboot> /usr/syno/etc/rc.d/S97apache-sys.sh start gnoboot> /usr/syno/etc/rc.d/S95sshd.sh start Fix the broken service...

This is just holder for the next release. You no longer need to fill it up if I already given you access to my shared drive. So what the hell is this form for? It's simple, gives me idea which drivers I need to sync from upstream kernel/vendor, and lastly will publish the results (excluding your email) to help new users what hardware is working properly and whatnot.

Try this KB1008205. BTW, are you using officially supported ESXi5.5 NIC and disk controller? You might be using an unsupported desktop drivers which has been dropped starting from 5.5 release and causing performance issues on your host.

Since you were running fine on baremetal before, and now you're on a virtual machine. There are a lot of factors you need to consider, here are few that I know of: Number of VMs running on host VM vCPU vs pCPU count Proper VM sizing Host swapping VM network (e1000X vs vmxnet3, jumbo frames) There's also a bug on alpha8 that incorrectly sets the IO scheduler which is fix in the next release. Try to manually switch back to cfq IO scheduler for all your attached disks if that helps. echo cfq > /sys/block/sdXX/queue/scheduler If you can get gnoboot to baremetal then we can possibly compare the performance. You can also perform troubleshooting from ESXi host by running esxtop. note: [spoiler=]VCAP-DCA 4/5 here EDIT: You are using iSCSI, right? iSCSI doesn't perform well on writes if you are using file backend. And iSCSI performance has been an issue by many DSM users, try to google it.

You need to patch /etc/rc.network in hda1.gz as well, and stick the sn GRUB option as per don389.

What version are you using? Was it the same setup before you switch? How many green drives do you have? IMHO, green drives doesn't perform well. I'm getting 90+ to 100MB/s for 5.1 VM using virtual LSI parallel SCSI, though, it's running on ssd (raid0) and 9211-8i raid controller. I even tried paravirtual drivers but it doesn't perform well compared to virtual LSI controller.

You don't need to insmod, it's already built-in in the kernel.