We currently have hardware netboot servers on the same subnet, and we've made all the appropriate helper address changes to accomodate this new appliance in our VMWare environment, yet we can't get it to show the netboot in system preferences on the mac. This is a 7.3 imac, and made the netboot image from the same machine.
I am having the same issue, the process works when I run the VM in Virtual Box , however once I place the VM in VMWare and assign it a static it does not work. I also have the IP helpers in the switches and have removed the spaces from the netboot folder name. The ext test is to place a mac on the same VLAN and see if I can see the server.
I have tested this on a VirtualBox VM and found clients netboot fine when you run the command manually to netboot from this server. Can't netboot a client from Option+boot or pressing "N" from the keyboard.Also image is not visible in Startup Disk preference.
I have a Mac server in the same subnet and I can netboot it by Option+boot and also the netboot image visible in Startup Disk preference.
This is a corporate network and netboot servers and clients are on different subnets. ip-helpers are already in place.
Also the new Macs do not work (2011 models) with latest EFI frimware update (v2.7). New macs netboot fine with Apple NetBoot server.
Same issue here.
Initial tests in VirtualBox on my workstation went fine. Migration to ESX and put into place and everything went bust. The service no longer starts.
I had to convert the image and hand it over to someone else, so I'm not sure what happened after the image left my share. So, I'm considering rebuilding from scratch from a vanilla VM install and pulling the appliance specific pieces from github this week.
Not sure if proper settings, but the following example is working in our environment (ESXi4.1):
Appliance IP: 10.66.4.60
Listen on these subnets:
Subnet: 10.66.4.0 Netmask: 255.255.255.0
Still can't "see" Faux NetBoot image via StartupDisk, N Key or Option boot, but can successfully use sudo bless to get off the ground. Helper addresses are in place.
Did you use the basic netboot command or with -kernelcache?
Not sure if proper settings, but the following example is working in our environment (ESXi4.1): Appliance IP: 10.66.4.60 Listen on these subnets: Subnet: 10.66.4.0 Netmask: 255.255.255.0 Still can't "see" Faux NetBoot image via StartupDisk, N Key or Option boot, but can successfully use sudo bless to get off the ground. Helper addresses are in place.
Just using the basic command:
sudo bless --netboot --server bsdp://10.66.4.60 --nextonly
I should mention that I also created a Subnet/NetMask entry for the target subnet (ex 10.141.88.0/255.255.255.0), but that entry was not needed to enable/start NetBoot service on the appliance.
We'll likely just use the appliance to supplement our physical NetBoot servers at this time. Not as useful for one-offs, but good for managing peak imaging periods in our organization (labs, sites).
We have been looking into the reason why NetBooting across subnets works for some individuals and not for others. We believe we have identified a scenario that causes the NetBoot appliance to not function as expected. Encapsulated requests are not currently being handled by the appliance. Basically, if the client IP listed in the request is the IP of the router instead of the clients real IP, then the appliance does not respond in a way to support that configuration. We are looking into ways to handle that scenario and will keep everyone posted if there is an update.
NetSUS is working if client is in the same subnet (VLAN) but not if in a different subnet (VLAN) with ip-helper in place.
Same issue here we are have IP Helpers set up and if we use the bless command it will work, but will not show up in startup prefs or option-n boot.
We are running the appliance ova on ESXi 5.
Any one got this working across subnets where it appears in the Startup prefs or Option N?
Jamf have put development on hold for this while the concentrate on Mountain Lion.
We didn't find a solution yet. But I would like to test with our DHCP specialists if it's possible to use the DHCP servers to give the Macs the netboot options they need pointing to the NetSUS Server.
I found this article which looks like it's possible (depending on the possibilities of your DHCP servers):
If anyone already has tested this DHCP way I would like to hear if it worked. Are the DHCP options in the linked article everything it needs?
Please let us know if you have any luck with the DHCP method above.
It all works fine for us using bless command but not via Startup Pref or holding down N key.
May try it on a standalone PC and see if that makes any difference perhaps it is the ESXi 5 causing it?
Does anybody have it working across subnets where it appears in startup items or holding down N?
If so what is your setup? ie. What are your running the appliance on? What routers do you use? etc..
So a few months have passed since the last post on this discussion. Does anybody have any updates regarding their scenarios?
I am running my NetBoot Appliance on VMware workstation on a 2008 R2 server which is located at the center of our network. NetBoot is configured as it should be in the webadmin and it shows as enabled. My .nbi does not show in Startup Disk, booting holding N or Option+N, or by using the bless command. Our network is huge here, but our separating is done with VLANs rather than Subnets. Is anybody else having trouble booting across VLANs with this appliance? I'm using a specific test VLAN with an IP helper to the appliance. It is a mirror test environment to the same setup we have with our Xserve using DeployStudio, which is working flawlessly.
Any updates and info is appreciated. Thank you.
+1: no NetBooting cross subnets sans that *really* complicated bless command. As far as I can tell, this also prevents any use of a NetBoot-based Casper Imaging workflow for factory/bare metal installs, is that correct? Outside of entering a 100+ character bless command on first boot single user mode that is.
Hi @eric.krause was the encapsulated packets issue you mentioned above resolved with version 3.x of the NetSUS appliance? We are still dead in the water getting the appliance to show up in Startup Disk across subnets with IPHelpers in place and it would be helpful to know if that might be a factor in the failures.
We believe we have identified a scenario that causes the NetBoot appliance to not function as expected. Encapsulated requests are not currently being handled by the appliance. Basically, if the client IP listed in the request is the IP of the router instead of the clients real IP, then the appliance does not respond in a way to support that configuration. We are looking into ways to handle that scenario and will keep everyone posted if there is an update.