NetBoot not working with latest hardware

Question

Level 1

6 points

NetBoot not working with latest hardware

Hi everyone,

I am running a Lion NetBoot server on a different VLAN as my clients.

Reimaing has been working fine till recently when we received a new fleet of iMacs (mid 2011 model). These new iMacs are not netbooting anymore. I don't even see the globe coming up. I usually use "sudo bless --netboot --server bsdp://IPAddress" to restart.

I have recreated the NBI on the latest hardware with fully patched OS X Lion. I have also updated the clients and made sure it has the latest firmware. Unfortnately I am still not getting anywhere. The new NBI works on the old iMacs still. So I don't think it is the NBI causing the problem anymore. I also asked Network guy to trace the traffic and he suggested there is nothing blocked for DHCP. The iMac also sees the NetBoot server no problem.

Anyone has similar problem? Any suggestions are welcome!!!

iMac, Mac OS X (10.7.3)

Posted on Apr 1, 2012 8:23 PM

Reply

Answer 1

Top-ranking reply

aaron.shegrud

Level 1

5 points

Apr 12, 2012 12:38 PM in response to L.W

I'm having a similar if not the same situation.

I have two systems bought recently I am trying to image. The image server has been working flawlessly for a while I was even able to netinstall lion to an older (hold n to netboot) machine today.

I know the server is working because when I boot into the restore partition I can tell it to selectively boot to the netboot image. but when I restart the new MBP, it can't find the server and then boots onto the local drive.

it looks like it's just not pulling an IP from the DHCP until it actually loads the OS but I don't know how to test this.

Reply

Answer 2

L.W Author

Level 1

6 points

Apr 14, 2012 5:34 AM in response to aaron.shegrud

Hi Aaron,

Thanks for sharing this with me. I am currently working with Apple Care to sort things out. Apple does not admit there is such problem. But we all know there must be something changed, or it won't just stop working with the new iMac only.

Can I ask whether your NetBoot is in the same subnet as the clients you try to image?

My NetBoot server is in different VLAN and it has been working fine in the past. Now since the problem occured, I placed a second NetBoot server in the same subnet as the clients and I worked around the problem. But we still don't know why it's doing this or what has changed. As you mentioned, it looks like the way the new iMac handles DHCP is changed.

I will keep you posted.

Thanks.

Reply

Answer 3

bhanes

Level 1

0 points

Apr 17, 2012 1:29 PM in response to L.W

Hi all,

I am experiencing the same problem. In my case the DHCP servers are Windows 2003 and 2008 servers in a different subnet. Everything worked fine until I tried using the new iMac hardware as a netboot client. They will not get DHCP from a Windows server in another subnet, or their own! I can, however, get the new iMacs to get their DHCP address and boot properly if I use an OSX server as the DHCP server...even across subnets. I enabled DHCP on an old 10.5 server and had things working again in a couple of minutes. The problem here is we can't use OSX as the DHCP server in our multi platform environment. We have been looking at this for weeks now...it's not the netboot servers, it's not the images. Something has changed on a hardware level in the way the new macs make their DHCP request. Are they requesting different options? Is it an IPv6 thing? I do feel some comfort in that it is not just me...

I'll post back if our port scans come up with anything useful

Thanks!

Reply

Answer 4

L.W Author

Level 1

6 points

Apr 18, 2012 6:43 AM in response to bhanes

Hi Bhanes,

I agree with you. Things must changed in the way how iMac handles DHCP when it NetBoots. I have been working with Apple Care and their Enterprise Support for Education. I have not been given any useful advice. And Apple also does not admit there is anything changed in the new iMac when it NetBoots.

The last piece of advice from Apple is to place the NetBoot Server in the same subnet as the clients. It works of course, which does not surprise me at all.After I provided the feedback, Apple told me this will not be supported by Apple Care and if we want to proceed, field support need to be scheduled and will cost minumum $700 USD.

They are hopelessly useless.

Our Network team also did a scan when the new iMac NetBoots. They found there is no request sent out from clients to NetBoot server at all. There is also no other blocks found, which means it also did not send out request to DHCP server.

Can I ask how do you NetBoot your clients?

I use Sudo Bless --netboot --server bsdp://serverIPaddress and restart the computer.

Reply

Answer 5

bhanes

Level 1

0 points

Apr 18, 2012 8:39 AM in response to L.W

LW,

My Netboot clients are all diskless (not even a cd/dvd drive). I build my images on a disk full machine then use the Apple System Image Utility to create the netboot image. I do nothing special to bless the system, just start the machine and hold down the "N" key to initially start the network boot option. Do this once and it is set in the PRAM. Different boot servers can be selected by holding down the "Option" key during startup, which will return a list of each server the client is enabled on. Our port scans do show the initial DHCP request being sent out but we have yet to identify what is different such that the DHCP (Windows) servers will no longer respond. Like I said, it seems to all work if I use an OSX DHCP server.

Thanks,

Bruce

Reply

Answer 6

bhanes

Level 1

0 points

May 21, 2012 10:31 AM in response to bhanes

Hello,

As a followup, we were able to solve this particular issue by updating our iMacs (mid 2011 models) to the latest EFI firmware version (1.9). This created a bit of a problem in that our Macs are diskless and the firmware updater will only work correctly if run from an internal drive (Apple...are you listening...you already know about this). I still cannot pinpoint what has changed but since we are now back running I guess I don't care...until the next time.

Thanks.

Reply