Skip to main content

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.

Here are the settings on the appliance:
external image link
external image link

At this time the folder containing the NetBoot image can not contain any spaces. Can you try connecting up to the NetBoot share and removing the spaces from the folder containing the NetBoot image and then enable the "new" image in the web interface.


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.


Me too.

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.


I have this working on ESX 4.1. What version are you guys on?


Would someone mind posting the proper net boot settings for the appliance? Should we be using CIDR notation when defining the subnets? I can't get the NetBoot to activate. I've removed the spaces from the .nbi folder. I'm using the latest build.


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.


jhbush1973:

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.


Curtis,

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).


I can't get to working with OS X Lion though. Does anyone have any luck using NetBoot command with -kernelcache?


We are having the same issue here. NetSUS is working if client is in the same subnet (VLAN) but not if in a different subnet (VLAN) with ip-helper in place.

Any ideas or solutions?


Same issue is going on here. I'm trying to get it set up for and enterprise network and setting up a net boot on every vlan is not feasible.


Has anyone figured this out? I have been asked by Cisco if the appliance is running multicasting. If it is not, this may be the reason for it not being seen on other VLANS.


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.


Thanks Eric. Pleade keep us posted with any updates.

Another user having the same issue;
https://jamfnation.jamfsoftware.com/discussion.html?id=4182


Just to add, I'm having the same issue as well. I cannot NetBoot across subnets even with ip helper addresses.


Did anyone ever come up with a solution to this problem?


BUMP - if there's been any progress on this, would be good to know


I wonder if this has something to do with DHCP. Is the Netboot/SUS application supposed to be handing out DHCP? I notice that it is on. We have another device doing DHCP.


McAdams - we originally had the Netboot/SUS setup to hand out DHCP (unintentionally) and turned it off, but still have the same problems identified in this thread. We don't use Cisco routers, and are wondering how many of you are using Cisco?


We're having the same issue as well. The NetBoot will not turn on even in our lab which is a flat network. Hopefully a fix can be found soon.


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):

http://forums.networkinfrastructure.info/general-discussion/netboot-with-a-mac-and-infoblox-as-dhcp-server/

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?


Hi fritz.schlapbach,

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..

Thanks again.


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.