I’ve already resolved the issue, but just in case someone else runs into this.
I did a full backup to ISO and installed it on a new device (to replace my existing IPFire device). When I finished configuring the new interfaces (only RED and GREEN on both) to match the new adapters after a reboot the DHCP server was not starting.
What was missing was the symbolic link in the rc3.d directory:
# ls -l /etc/rc.d/rc3.d/S30dhcp
lrwxrwxrwx 1 root root 14 Feb 15 22:40 /etc/rc.d/rc3.d/S30dhcp -> ../init.d/dhcp
All of the others were present and after adding the link everything works correctly now.
Thanks! I just hit exactly the same issue. I assume it happens when one does not enable dhcpd in the initial console setup (since I didn’t want ipfire handing out random leases before the static ones were restored from backup).
Having a quick grep of the githib source:
src/misc-progs/dhcpctrl.c:
which suggests the easiest workaround in the GUI is to disable the dhcp service and then reenable it, and the actual bug fix may be to call this program from the backup restore script.
first, welcome to the IPFire community and sorry for the tardy reply.
Could you please raise a bug for this at https://bugzilla.ipfire.org/ (your login credentials work there as well) so we can keep track of this one and fix it? Please refer to this wiki page for further information on bug reporting, if necessary.
My apologies, I have been tied up with other bugs and patch updates and some personal aspects and that bug dropped off my radar.
I will try and have a look at it in the next week or two and see if I can get a fix in for CU172 although that might be a bit tight, depending on when it will go for testing. If it doesn’t make CU172 then it should make it into CU173.