Unable to Enable Netboot Image in Netboot/SUS Appliance

For starters, see if you can enable NetBoot on an OS X server as a test (just to validate the nbi).

Do you see anything in your logs? On Ubuntu, DHCP logs to /var/log/syslog but I'm not sure if this is the same on CentOS.

Also, do you have netboot configured to listen on the subnet that your netsus is on?

The NBI I am using is currently also running on an OS X Server so the NBI itself should be good.

The IP address of my server is included in the subnet and netmask i included in my first post (that subnet and netmask pretty includes everything on our network)

I was able to find something interesting in /var/log/messages: /etc/dhcpd.conf line 22: expecting hexadecimal number.
Feb 19 16:31:11 netbootsus dhcpd: option vendor-encapsulated-options 01:01:02:08:04:01:00:02:0E:80:17:61:66:
Feb 19 16:31:11 netbootsus dhcpd: /etc/dhcpd.conf line 23: right brace expected.
Feb 19 16:31:11 netbootsus dhcpd: next-server
Feb 19 16:31:11 netbootsus dhcpd: ^
Feb 19 16:31:11 netbootsus dhcpd: /etc/dhcpd.conf line 27: expecting a declaration
Feb 19 16:31:11 netbootsus dhcpd: }
Feb 19 16:31:11 netbootsus dhcpd: ^
Feb 19 16:31:11 netbootsus dhcpd: Configuration file errors encountered -- exiting

Here is my dhcp.conf file from the server:

ddns-update-style none;
ddns-updates off;
ignore client-updates;
allow booting;

class "AppleNBI-i386" {
match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";

if (option dhcp-message-type = 8) {
option vendor-class-identifier "AAPLBSDPC"; if (substring (option vendor-encapsulated-options, 0, 6) = 01:01:01:02:02:01) { option dhcp-parameter-request-list 60, 43; option vendor-encapsulated-options 01:01:01:04:02:FF:FF:07:04:01:00:02:0E:08:04:01:00:02:0E:09:11:01:00:02:0E:0C:46:61:75:78:20:4E:65:74:42:6F:6F:74; }

if ((substring (option vendor-encapsulated-options, 0, 6) = 01:01:02:02:02:01 and substring (option vendor-encapsulated-options, 7, 12) = 08:04:01:00:02:0E:03:04:0A:83:02:25) or (substring (option vendor-encapsulated-options, 0, 6) = 01:01:02:02:02:01 and substring (option vendor-encapsulated-options, 7, 12) = 03:04:0A:83:02:25:08:04:01:00:02:0E)) { option dhcp-parameter-request-list 17, 43, 60; option vendor-encapsulated-options 01:01:02:08:04:01:00:02:0E:80:17:61:66:70:3A:2F:2F:61:66:70:75:73:65:72:3A::40::2F:4E:65:74:42:6F:6F:74:81:11:4E:65:74:42:6F:6F:74:30:30:31:2F:53:68:61:64:6F:77; next-server (My Server IP, the correct one is listed); filename "IT_Support_10.9.nbi/i386/booter"; option root-path "(My Server IP, the correct one is listed)/NetBoot/NetBootSP0/IT_Support_10.9.nbi/NetBoot.dmg"; }
}
}

subnet 10.0.0.0 netmask 255.0.0.0 { allow unknown-clients;

Appears that line 22 has a hexadecimal issue, line 23 needs a right brace and line 27 needs a declaration

if anyone has insight on this I would appreciate it

Thanks!

I did copy this NBI over from my current OS X Netboot Server, does anyone know if the values listed in the lines are provided from the netboot image itself? If so perhaps the OS X server wrote data to the nbi that is specific for that server and is invalid on the appliance. Just a guess, not easy to check myself as I would have to build another netboot image to test.

Yeah I think there's some extra colons in that vendor-encapsulated-options line... maybe try changing "::40::" to ":40:"?

In my dhcp config, I edited that part so that it looks like this:

{    
                option dhcp-parameter-request-list 17, 43, 60;
            option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01;
            next-server x.x.x.x; 
            filename "CasperBoot.nbi/i386/booter";
            option root-path "http://x.x.x.x/NetBoot/NetBoot.dmg";
      }

A couple of things to point out... I'm using the diskless netboot workaround found here: http://www.macos.utah.edu/documentation/administration/setup_netboot_service_on_mac_os_x_10.6.x_client.x_client/setup_netboot_service_on_mac_os_x_10.6.x_client-diskless_netboot.html

This workaround forces netboot to use a RAM disk to store the netboot shadow file, which means I can get away with omitting BSDP options 128 and 129. If you look in that long string of hex in your config, that would be this part

80:17:61:66:70:3A:2F:2F:61:66:70:75:73:65:72:3A::40::2F:4E:65:74:42:6F:6F:74:81:11:4E:65:74:42:6F:6F:74:30:30:31:2F:53:68:61:64:6F:77;

Just for kicks, you can copy and paste this into a hex to ascii converter to see what it's doing. This is the one I use: http://www.dolcevie.com/js/converter.html

Also, I found that if I had my root-path set to http://x.x.x.x/NetBoot/CasperBoot.nbi/NetBoot.dmg then NetBoot would fail. I figured the path was too long, and sure enough when I moved my NetBoot.dmg image up to /srv/NetBoot and updated my root-path it worked.

This works for me but YMMV

BTW wikipedia has a pretty good write up of BSDP if you want to learn what all of these option codes and hex stuff means: http://en.wikipedia.org/wiki/Boot_Service_Discovery_Protocol

Multiple double-colons in that string: 3A::40::2F

I was able to remove the the extra colons and the indicator light in the appliance turned green but it in general still isn't working.

I am going to rebuild my netboot image from scratch and upload that image, I think the one from my current OS X server isn't compatible.

Thanks for the help everyone, I will post to see if that fixes it.

So I completely rebuilt my netboot image from scratch (10.9.2) (literally built a system with Mavericks downloaded from App Store) and uploaded it to the appliance and I am having the same DHCPD configuration errors as before. There are extra colons in line 22, right bracket on line 23, and a declaration on line 27. If I remove the extra colons and click "enable netboot" it writes those colons back into the file.

It seems like there is data in the .nbi that gets written to the DHCPD.conf file in a manner non condusive for DHCP to turn on. I initially captured the OS with JAMF Composer and then used Apple System Image Utility to create a netboot image out of that DMG it creates, but to rule out variables, I just captured it directly from disk using Apple System Image Utility and I still have these problems. Anyone run into this before? what should I do?

The extra colons appear where you would expect the password for afpuser to be, so maybe try resetting that password in the NetSUS?

Did you try narrowing down the subnet and netmask to match that of the netsus appliance?

i.e.,
instead of:
subnet: 10.0.0.0
netmask: 255.0.0.0

try:
subnet: 10.0.123.0
netmask: 255.255.254.0

whatever the router ip and subnet mask for the host, add that as the only subnet and mask in the netsus webadmin (and see if you can then enable netboot). I have not implemented netboot yet, but I have it running in a VM (just to mess around with) and when i moved that host to another subnet, netboot disabled. Add the subnet and netmask which the host resides, netboot will enable. Once I have that added, I can add other subnets into the list...ultimately, it seems like i need to have the subnet and netmask of the host somewhere list for it to enable and add subsequent subnets. I will look into it a bit more post again if I find anything, but have not messed with netsus much thus far...

In case anybody finds this thread, I just had an issue with the exact same symptom and troubleshooted to find that the interface was incorrectly specified in lines 23 and 24 of the /var/appliance/configurefornetboot shell script – it should have been em1 in my case but was in fact eth0.

ip=`ifconfig | grep em1 -A 1 | grep 'inet addr' | awk '{print $2}' | sed 's/addr://g'`
netmask=`ifconfig | grep em1 -A 1 | grep 'inet addr' | awk '{print $4}' | sed 's/Mask://g'`

The doubled-up colons (::) in the hex sequence in /etc/dhcpd.conf mean that a variable in the script is empty and hasn't evaluated correctly – the other reason that I have seen this happen is when one of the tools used in the evaluation of the variables in this script is missing as can happen with minimal installations.

Would someone please post a working dhcpd.conf for RHEL 6.6?

I find that my best bet is to confirm that the NetBoot set works properly in an OS X Server-based NetBoot environment. If so, I then transfer the NBI to the NetSUS box. I configure the Subnets using the web admin tool, and confirm the NBIs are appearing in the drop down. From the shell of the NetSUS box itself, I then manually run the configureForNetboot script with the appropriate parameters:

cd /var/www/html/webadmin
sudo bash -x scripts/adminHelper.sh setnbimages <name of NBI.nbi>

For example:

cd /var/www/html/webadmin
sudo bash -x scripts/adminHelper.sh setnbimages UOAXDeploy.nbi

The script will carry out the necessary bits and pieces to get the job done properly, but also provide much more debug logging than the web admin tool provides. This way, you can isolate your issues with the appliance, whether it is an issue with the way the NBI is developed, or if your dhcpd.conf is malformed.

I also found it important to make certain that the AFP password is set up in the appliance before carrying the above out (Settings > Shares > AFP). This will ensure that all pre-requisites are in place for the dhcpd.conf to be generated properly.

How can you see what version of NetSUS you are using?