jukolaut

hi again, sorry for my absence! Noticed that my esxi install image has been downloaded over 26000 times, I thought it would interest about 10 people in the world As my system running that is stable I'm not that keen on doing new versions but that might change when synology releases a new major version. Unfortunately it seems that upgrading an exising installation will be difficult. I've packaged the kernel source code here: http://yadi.sk/d/rqFVaQhb4yFtu The package includes the source to the fake synobios module (in drivers/synobios/synobios.c) and other modifications described in this post. happy hacking!

yeah, I did port it for the esxi build, was not that tough to do. There were some extra ioctls for the newer kernel that I added. Removed all fan control functionality etc. access to the actual hardware and return fake values for sensors.

I don't see any problem in the screenshot. The SYNOIO_ -messages are normal. Try looking at the system logs from the web console. I don't have a HA setup myself so I have no idea if that works or not, sorry

Well, thats bad! I'm not able to offer much support but can you tell about your setup: how many disks do you use for data? raw or vmdk? In esxi, does it show high cpu usage even when idle?

Ok, do you need sources or binaries? The binaries are here(v2): http://yadi.sk/d/fTRkFMyU3D8Yc This is based on odie82544's DS3612xs_3202-Repack images, so thanks for those! Only the kernel, modules and linuxrc.syno are modified so far. The archive contains both the .pat file for installation and .vmdk file for boot. Create the virtual machine to esxi and add hardware: IDE controller with single harddisk (vmdk file in archive). Boot from this. PVSCSI controller and raw harddisks or vmdk files for data. I've tested with 3 disks so far. VMXNET3 network. Only single interface in bridged mode is tested so far. MAC address can be anything. Follow the installation instructions elsewhere in this forum to install the pat file. I wouldn't use this for anything else than evaluation yet.

While looking at the kernel sources and the os image contents I've come up with these "issues": 1. The kernel could use the gpio pins in the southbridge for controlling the hardware (leds, buzzers, fans) with the serial ports. If your motherboard is not the same as in the original synology box (very unlikely) they could be used something important. Most likely not but if your motherboard catches fire, this is the likely culprit 2. The operating system will contact synology's servers in many places, at least in every boot. If you're paranoid about this, I would consider running behind a firewall. So nothing major here, but at least you know now.

synology's opensource package for kernel 2.6.32 contains the sources for synobios kernel module... not directly compatible with 3.2.30 and no support for bromolow but handy anyway!

Most, quite possibly all of the userspace of DS 4.2 is 32-bit and only the kernel is 64-bit (which is strange). Like this: $ file bin/busybox bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.4.3, stripped $ file lib/libc.so.6 lib/libc.so.6: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.3, stripped So by compiling the opensource kernel as i686 it could be possible to run the whole thing in 32-bit computer. Synobios is the only binary module that is 64-bit but it's possible overcome that. But sorry, I don't have such a build...

After some hours of hacking I now have fully working ESXi 5.1 virtual machine setup with DS 4.2 (3202). To get PVSCSI and VMXNET3 working a new kernel needs to be compiled. To make matters worse, scsi drives are not supported at all. So some steps need to be done: scsi disk support must be added to drivers/scsi/sd.c so that they are marked as SYNO_DISK_SATA instead of SYNO_DISK_UNKNOWN disks must be marked as system disks so that the md will autodetect the system raid partition (gd->systemDisk = 1) having ata as well as scsi disks will not work. quick workaround is to disable sata support from the kernel. this has the added benefit of hiding the boot disk partitions if sata is disabled some important symbols are not compiled in and synobios.ko module will not load, causing scemd to halt the system implement dummy synobios kernel module that keeps scemd happy Performance seems to be excellent, quite possibly due to paravirtualized drivers. S.M.A.R.T. is not working, but that was expected. Some things are still in todo-list: compile in open-vm-tools to keep esxi from nagging about installing tools clean up kernel from unneeded device drivers, also clean modules from hd image try to get scemd not to constantly poll SYNOIO_SET_DISK_LED and SYNOIO_GET_EUNIT_TYPE investigate if using stock kernel is possible with dummy synobios and CONFIG_EXT4_FS_SYNO_ACL

I can also confirm the same issue. After adding the PVSCSI to the kernel, recompiling and installing, the boot process will display: want_idx 1 index 3 want_idx 1 index 3. delay and reget many times, after that want_idx 1 index 4 want_idx 1 index 4. delay and reget again many times. Then the boot process resumes and after a while: BUG: Unable to handle kernel NULL pointer dereference at 0000000000000068 That happens in syno_libata_index_get_by_map+0x2c/0xb0 And even more after that: scemd[3738]: segfault at 8 ip ......... sp .............. error 4 in scemd And the system shutdowns after that. I guess there is some kind of watchdog that checks that the scemd is alive. My hypothesis is that there is some kind of enumeration of ata disks in drivers/scsi/sd.c that prints out the want_idx errors. I guess the index starts at 3 if because I have 2 ide devices and 3 pvscsi devices and the ide devices get the first slots? When initializing the pvscsi devices it expects them to start at index 1?