romracer

1) I haven't looked fully at the details yet, but its clear it uses a GRUB stub boot loader. It appears to do something like booting the stock kernel, inserting any extra modules included and then calling "busybox init" which triggers regular system boot up. 2) In ESXi, you have several options. The easiest is to probably set Serial Port 1 in the VM settings to "Use Network", direction "Server" and a port URI similar to "telnet://:8022". Then you can telnet to the address of the ESXi host the VM is running on and that port number (ex. telnet esxi01.mydomain.com 8022). Don't leave this connected unless you have appropriate network firewalling in place (you can just check and uncheck the connected box as needed). 3) I don't know what this means. There are numerous guides out there on how to open synoboot.img if that's what you mean. If you mean the actual data disks and where the OS is installed, there are also numerous guides on that. Google "Using ubuntu to recover synology data" 4) No wiki I know of. But I'm still new to this stuff (only a few months using it).

This also happened to me somewhere between July 1st and July 2nd. I run 6.1.2 with 1.02b loader in ESXi 6.5 with just virtual disks (no physical pass through). I also happen to have two of these VMs setup and configured with Synology HA. NFS and MariaDB both were still working fine. I was able to reboot the active node and the passive node took over just fine. Its web interface also worked, even though I upgraded both of them on the same day. I hope this info helps. Does that means perhaps the timebomb does not run on the passive node? I reinstalled the node which was not working and rebound it to my HA cluster. Once resync was complete, I made that node the active one again. This was on July 2nd. The problem has not reappeared, yet. What should I look for related to a timebomb the next time it happens? I did not have SSH enabled and my serial console was not working (I think I broke this earlier though because it wasn't working before this) so I had limited visibility into the DSM operating system at the time. I have since enabled SSH and firewalled it appropriately and fixed the serial console, so I should be able to get in and do more investigation if it happens again. Edit: Both of my VMs are emulating DS3617xs.