Commit 6dc5c7ff changed how the /etc/dropbear symlink is detected, by using readlink to resolve the target location. When using coreutils's readlink, "readlink -f /etc/dropbear" will return /var/run/dropbear. However, if using busybox's readlink, the same "readlink -f /etc/dropbear" returns an empty string. I am not sure if this is a bug in the /etc/init.d/S50dropbear script, or if busybox is not honoring the "-f" flag.
Hello, I've tried to reproduce the issue, but it just works for me here. But I've looked, and our default busybox configuration has CONFIG_FEATURE_READLINK_FOLLOW enabled. Did you customise your Busybox configuration? Regards, Yann E. MORIN.
Yes, FEATURE_READLINK_FOLLOW is set. If it makes a difference, this is using the raspberrypi2_defconfig, with uClibc-ng.
I investigated this further, and it may be a difference between Busybox/uClibc and coreutils/glibc. If the target of the symlink does not exist, in coreutils "readlink -f" will display as much as possible. In Busybox, "readlink -f" will result in an error, specifically ENOENT. Test case: ln -s /tmp/no_such_file /tmp/some_symlink On my Debian desktop: $ readlink /tmp/some_symlink /tmp/no_such_file $ readlink -f /tmp/some_symlink /tmp/no_such_file On my Raspberry Pi: # readlink /tmp/some_symlink /tmp/no_such_file # readlink -f /tmp/some_symlink # touch /tmp/no_such_file # readlink -f /tmp/some_symlink /tmp/no_such_file
Created attachment 6141 [details] Fix dropbear when readling is busybox CAre to test the attached patch and report back, please?
Yes, this patch worked for me. Tested-by: Jason Tang <tang@jtang.org>
Bug fixed by http://git.buildroot.net/buildroot/commit/?id=29a0f0557984ccb299426712b71fee5abaaa2ca9.