Ubuntu Server 14, DHCP fails

[Wayne Workman]

r7057 on a freshly built Ubuntu Server 14.04.4 x64, fully updated as of today.

The installer fails here:

* Setting up and starting DHCP Server.........................Failed!

In the error_logs, at the end I found this:

../lib/common/functions.sh: line 1891: /etc/init.d/: Is a directory
../lib/common/functions.sh: line 1893: /etc/init.d/: Is a directory

But I don’t think those errors are related.

I manually started up the isc-dhcp-server service manually without making any changes and it starts just fine. The config file also looks just fine:

# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 10.0.0.0 netmask 255.255.0.0{
    option subnet-mask 255.255.0.0;
    range dynamic-bootp 10.0.0.10 10.0.255.254;
    default-lease-time 21600;
    max-lease-time 43200;
    option routers 10.0.0.1;
    option domain-name-servers 208.67.222.222;
    next-server 10.0.0.9;
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
}

[Wayne Workman]

The second run-through of the installer worked just fine… very weird.

Earlier, I had the exact same phenomena with apache2. The first time through, it failed. Without any changes, the second time through it was fine.

[Wayne Workman]

Tom was able to get this fixed, and I’ve confirmed it’s fixed.