disneysw

I should also have mentioned that the way the script is written it only works for physical port eth0.

I can also confirm that installing the Power button app will allow the machine to shutdown using the front panel button. And WOL is working on 6.2.1 using the instructions from CtrlAltDel. This works using the dummy MAC address as defined in the bootloader, for details check his post in ths link: Just in case the link changes here is my quick summary for enabling WOL: Edit /etc/synoinfo.conf as root. Search for wol_options for the lan connection required for WOL (personally I would do this for all of the LAN interfaces). You should fine something like 'eth0_wol_options="d"'. Now change the "d" to "g" i.e. 'eth0_wol_options="g"'. This will set a tick in the WOL for eth0 in the control panel power settings, repeat for eth1, eth2 etc. Also make sure 'wol_enabled_options="g"' is set to "g" not "d" and make sure 'support_wol="yes"'. Make sure WOL is also enabled in the control panel power settings. Copy file or create a file called /usr/local/etc/rc.d/S99ZZZ_Shutdown.sh as root using the attached script. Set execute permission: "chmod +x /usr/local/etc/rc.d/S99ZZZ_Shutdown.sh". S99ZZZ_Shutdown.sh

I also confirm that using a HP NC360T Dual-Port PCI-E Ethernet card and V1.03b bootloader plus disabling CE1 and the internal NIC in the BIOS does work with V6.2.1 running baremetal on a N54L with the 2013 modified BIOS. That includes shutting down correctly. The upgrade wiped my power button mods and probably broke the wake on LAN but they were working with V6.2 and I suspect I can get them to work again by re-applying the normal patches.

Discovered that the blocked services are never receiving the network ready event and are blocking waiting on it. You can manualy release them by using the command "/sbin/initctl emit --no-wait syno.network.ready". This command is normaly sent by "/etc/init/syno-network-check.conf" when it is processed by the upstart boot process. I'm using a fixed IP address which may be part of the problem - need to do more testing.....

Having recently encountered this problem I am pretty sure it has nothing to do with the version being used. I have two boxes both running 5.2-5644-5, one has the problem, the other does not. As people have pointed out the issue is some of the services not starting on boot. This causes a long delay in the boot time and can easily be identified by running "/usr/syno/etc/rc.d/S99zbootok.sh start" which reports services it is waiting on. In my case "service [ "synoindexd" "ntpd-server" "pgsql" "snmp" "synosnmpcd" "findhost" "synovfsd" ] not ready." The kicker is you can manually start the offending services using "start ". Just be aware that some services, like findhostd are reported as findhost. Further investigating shows S99zbootok.sh script uses "synoservicecfg" to determine the status of the services. Using this command "synoservicecfg --status findhost" shows that the status for the problem services is "error" (not sure if the is the cause or symptom): service [findhost] status=[error] required upstart job: [findhostd] is stop. ======================================= Checking the logs for those services shows no reported errors while running "synoservicecfg --start " will start the offending service (just like "start "). Unfortunately the situation will be repeated if the system is rebooted. Checking the "/var/run/synoservice/restart" directory shows files being created that are obviously designed to control the restart process. In my case the offending process files have a zero length which probably explains why the services are not being automatically restarted. Still more to do on this…….

After more investigtion is looks like I have this issue: viewtopic.php?f=2&t=9869&p=49377&hilit=S99zbootok.sh#p49187

Think your right but reinstalling did not solve the problem. It looks like my boot process is not starting all of the necessary services but I have not been able to determine why this is the case. I did find out why the assistant was not finding the box. One of the start-up processes should have been "/usr/syno/bin/findhostd". It is not being started – manually starting it temporarily fixed that problem (at least until I do a restart). This also explains why my postgress was not starting since one of the start-up scripts creates the "/var/run/postgresql" directory which is necessary for the postgress service to start. However my init and rc.d directories seem fine. I have come to the conclusion one of the start-up services/scripts must be hanging and blocking everything that is supposed to run after it. It would help if there was a description of units boot process. It seems convoluted compared to most Linux boxes or perhaps I just don’t know which are real start-up files vs those which are system backup copies!

My NAS is running OK for basics like file sharing and the admin page but some of the additional services such as sshd and webservices fail to start automatically. If I log in and disable/re-enable them will work until I re-boot the device. I have tried: a) Restoring a known working configuration but that did not solve the problem. b) I also looked through the logs but did not found anything that looked significant. c) I removed nearly every add-on package. Which lead to the discovery that the directory /var/run/postgres was missing which stopped a few of the add-on packages from being re-installed. But this had no impact on the initial problem. So at this point I figure I need to re-install the base OS. The issue I currently have is the Assistant app no longer finds this DiskStation (it does find another unit on the same network). Does anyone which service/protocol is used for auto discovery by the assistant and how to manually re-enable it? Alternatively are there any built-in recovery tools to help recover the system? I am running the latest xpeboot and service packs.