DHCP server not starting by default after restore

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:

} else if (strcmp(argv[1], "enable") == 0) {
             safe_system("ln -fs ../init.d/dhcp /etc/rc.d/rc3.d/S30dhcp >/dev/null 2>&1");
             safe_system("ln -fs ../init.d/dhcp /etc/rc.d/rc0.d/K30dhcp >/dev/null 2>&1");
             safe_system("ln -fs ../init.d/dhcp /etc/rc.d/rc6.d/K30dhcp >/dev/null 2>&1");
} else if (strcmp(argv[1], "disable") == 0) {
             safe_system("rm -f /etc/rc.d/rc*.d/*dhcp >/dev/null 2>&1");

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.

Hi,

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.

Thanks in advance, and best regards,
Peter Müller

Thanks Peter - here is the bug 12757 – DHCP server not starting after full ISO restore

1 Like

This bug is still present in 169, and even in 171.

To reproduce. create full backup ISO using WUI, and restore from ISO booting up and installing, even unattended install

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.

1 Like

For anyone interested in the status of this bug please follow it in the IPFire bugzilla.

Bug link is earlier in this thread.

2 Likes