FFP not starting after reboot on NAS542

feco800

Hello Community,

I have some experience with my NSA325-v2 NAS, including FFP install and configuration, and I just started to work with a NAS542.

Metarepository and FFP setup was successful with some tricks (disable default zyxel ftp source in metarepo cfg, etc.), but realized that after rebooting the NAS, the configured services are not available, like SSH, minidlna, and so on.

I have found a workaround, I need to log in to the web interface, and in the App Center I disable and re-enable FFP, then it is starting, and services are available.

It is not a huge effort, but I would like to avoid this. Anyone has any idea why it happens, that FFP is not starting after reboot, and how could I fix it?

Thanks!

Zyxel_Barry

Hi @feco800,

I understand that you're experiencing an issue with FFP not starting automatically after a reboot on your Zyxel NAS542, requiring you to manually disable and re-enable it in the App Center.

The behavior you're describing, where services configured through FFP are not available after a reboot until FFP is manually toggled, suggests that the FFP startup script or its integration with the NAS's boot process might not be executing correctly. While direct solutions for FFP autostart on NAS542 are not readily available in the search results, issues related to boot processes and environment variables on Zyxel NAS devices are common.

Here are some potential areas to investigate and information to gather:

• Review FFP Installation and Startup Scripts:

  • Carefully check the FFP installation guide specific to the NAS542, if available, for any post-installation steps related to autostarting services.
  • Examine the FFP startup script(s) for any errors, incorrect paths, or missing dependencies that might prevent it from executing properly during the boot sequence.
  • Look for any init.d or rc.d style scripts that FFP might be using to start its services and ensure they have the correct permissions and are linked appropriately for autostart.

• Check Bootloader Environment Variables (Advanced):

  • Some Zyxel NAS models use bootloader environment variables to manage boot processes. Incorrect or missing variables can lead to unexpected boot behavior. This would require advanced access, potentially via serial console or SSH if available after a partial boot.
  • Commands like /firmware/sbin/info_printenv and /firmware/sbin/info_setenv might be relevant for inspecting and modifying these variables, though caution is advised as incorrect changes can lead to boot loops.

• System Logs:

  • Check system logs on your NAS for any errors or warnings related to FFP or service startup during the boot process. You might be able to access these via SSH or the web interface.
  • The /tmp/boot-config-error.log file might contain relevant information if there's a boot configuration issue.

To help us further diagnose the issue, please provide the following information:

• NAS542 Firmware Version: This can be found in the web interface of your NAS.

• Screenshots: If possible, provide screenshots of:

  • The FFP configuration in your App Center.
  • Any relevant log entries you find after a reboot.

• FFP Installation Method: Details on how FFP was installed (e.g., specific guide followed, custom scripts used).

• Network Topology: A simple diagram or description of how your NAS542 is connected to your network.

Mijzelf

Wow! Blast from the past. In your admin share there should be a directory ffp, containing logfiles. Each call of 'ffp startup' should produce a logfile.

Maybe you can find here why ffp doesn't start on boot.

feco800

https://community.zyxel.com/en/discussion/comment/83086#Comment_83086

There is no new logfile after rebooting the NAS, only when I manually re-enable FFP in the App Center, but that is just a normal FFP starting log, logrotate messages, NAS identification, starting services, etc., but no errors at all.

For some reason FFP is not auto-starting after device reboot, but I'm unable to find any possible reasons, or even any error messages around.

Mijzelf

Looking in the FFP startscript, when no logfile is created, then either

1. The script is not executed.
2. The script is not executed with an argument 'startup'.
3. The package is disabled.

I don't think 2. is possible. The first one might be caused when the script is not executable. Don't know if the package management via the webinterface cares about that, but the bootup startscript does.

When I remember well the ffp startscript is /i-data/.system/zy-pkgs/ffp/etc/init.d/ffp. Executing

ls -l /i-data/.system/zy-pkgs/ffp/etc/init.d/ffp

should reveal if the execute bit is set. About disabled, the packages have to keep their own enabled flag, and ffp does that in the file /i-data/.system/zy-pkgs/ffp/config/ffp. It should contain the string 'Enabled', else the package won't start.

(If you disable it in the webinterface, it should contain 'Disabled')

feco800

I just checked the above on NAS542, this is the location where I found the startscript:

root@NAS542 :~# ls -l /i-data/2953d86e/.PKG/ffp/etc/init.d/ffp
-rwxr--r-- 1 root root 8412 Jan 25 12:26 /i-data/2953d86e/.PKG/ffp/etc/init.d/ffp
root@NAS542 :~#

Slightly different than on the NSA325-v2, which is very close what you mentioned:

root@NSA325-v2 :~ # ls -l /i-data/.system/zy-pkgs/etc/init.d/ffp
-rwxr--r-- 1 root root 8402 Dec 3 2017 /i-data/.system/zy-pkgs/etc/init.d/ffp
root@NSA325-v2 :~ #

Anyway, ffp script is executable on the NAS542 as well, also I just checked the config file, it has Enabled in it:

root@NAS542 :~# cat /i-data/2953d86e/.PKG/ffp/config/ffp/config
Enabled
root@NAS542 :~#

Not sure if the startup script is affected by the different folder structure…?

Another thing I found, disk volumes are mounted another way on NAS542 (see my highlights with ←):

root@NAS542 :/# df -h
Filesystem Size Used Avail Use% Mounted on
ubi5:ubi_rootfs1 91M 52M 35M 61% /firmware/mnt/nand
/dev/md0 1.9G 190M 1.6G 11% /firmware/mnt/sysdisk ←sysdisk is mounted as md0
/dev/loop0 151M 134M 17M 90% /ram_bin
/dev/ram0 5.0M 4.0K 5.0M 1% /tmp/tmpfs
ubi3:ubi_config 2.4M 104K 2.1M 5% /etc/zyxel
/dev/md2 3.6T 19G 3.6T 1% /i-data/2953d86e ←disk vol1 (systemdisk) is mounted as md2
root@NAS542 :/#

While this is it on NSA325-v2:

root@NSA325-v2 :~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mtdblock8 48M 44M 4.6M 91% /zyxel/mnt/nand
/dev/sda1 487M 479M 7.3M 99% /zyxel/mnt/sysdisk ←sysdisk is mounted as sda1
/dev/loop0 136M 120M 16M 89% /ram_bin
/dev/loop0 136M 120M 16M 89% /usr
/dev/loop0 136M 120M 16M 89% /lib/security
/dev/loop0 136M 120M 16M 89% /lib/modules
/dev/ram0 5.0M 4.0K 5.0M 1% /tmp/tmpfs
/dev/ram0 5.0M 4.0K 5.0M 1% /usr/local/etc
/dev/ram0 5.0M 4.0K 5.0M 1% /usr/local/var
/dev/mtdblock4 10M 1.5M 8.6M 15% /etc/zyxel
/dev/md0 917G 730G 187G 80% /i-data/a7476f8a ←disk vol1 (systemdisk) is mounted as md0
/dev/md1 1.8T 1.7T 187G 90% /i-data/78fda26d ←disk vol2 is mounted as md1
/dev/md0 917G 730G 187G 80% /usr/local/zy-pkgs
/dev/md0 917G 730G 187G 80% /etc/zyxel/zy-pkgs
/dev/md0 917G 730G 187G 80% /usr/local/apache/htdocs/adv,/pkg
/dev/md0 917G 730G 187G 80% /usr/local/apache/web_framework/data/cache
/dev/mtdblock4 10M 1.5M 8.6M 15% /usr/local/apache/web_framework/data/config
root@NSA325-v2 :~ #

Maybe startup script expecting different mount points…?

Mijzelf

Maybe startup script expecting different mount points…?

No. The fact that dis- and enabling the package will start it, proves that it can handle the filestructure. There is no difference in starting when enabling the script and bootup. So either the structures are not ready yet when the script is started, or it's not called at all on bootup.

The latter could be checked. If you look in the startscript, almost at the end you see the line

[ -f /tmp/ffp.log ] && echo date $0 $@ >>/tmp/ffp.log

That is a debugging line. If the file /tmp/ffp.log exists, it will add a line for each call of the script. Of course it doesn't exist on boot (/tmp is a ramdrive), so it won't log. But if you change the line to

echo date $0 $@ >>/tmp/ffp.log

it will log unconditionally.