Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: bartron
bartron Author
User level: Level 1
9 points

Netboot on 2011 mini broken?

I'm having issues netbooting the 2011 mini. So far most other macs will netboot off our systems perfectly fine (with the exception of a recent MacBook Pro that seems to have the same issue but I haven't tested it yet)


We don't use OS X server, instead we use Linux to handle the DHCP/BSDP stuff. This has worked sucessfully for several years. We have many sites and this setup makes it easier to host a distributed system that can serve Windows, Mac and Linux clients. (the process we use is the same as outlined in this article http://www.fogproject.org/wiki/index.php?title=How_to_get_Macintosh's_Netboot_wo rking_with_your_FOG_server)


Anyway, I did a packet trace on the DHCP server and recorded the packets as I netbooted both a 2011 Mac Mini and 2011 iMac.



This is the DHCP:DISCOVER as sent by a 2011 iMac



14:11:19.051973 IP (tos 0x0, ttl 253, id 65119, offset 0, flags [none], proto: UDP (17), length: 576) xxx.xxx.228.1.67 > xxx.xxx.3.220.67: [udp sum ok] BOOTP/DHCP, Request from c8:2a:14:1f:6a:54, length: 548, hops:1, xid:0x2511, secs:5, flags: [none] (0x0000)

Gateway IP: xxx.xxx.228.1

Client Ethernet Address: c8:2a:14:1f:6a:54

Vendor-rfc1048:

DHCP:DISCOVER

PR:SM+DG+BF+VO+VC

MSZ:1500

CID:[ether]c8:2a:14:1f:6a:54

VC:"AAPLBSDPC/i386/iMac12,1"

VO:2.2.1.1



And this is the response by the DHCP/BSDP server



14:11:19.052280 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 405) xxx.xxx.3.220.67 > xxx.xxx.228.1.67: [bad udp cksum b876!] BOOTP/DHCP, Reply, length: 377, hops:1, xid:0x2511, secs:5, flags: [none] (0x0000)

Your IP: xxx.xxx.229.245

Server IP: xxx.xxx.3.118

Gateway IP: xxx.xxx.228.1

Client Ethernet Address: c8:2a:14:1f:6a:54

file "mac107/booter"

Vendor-rfc1048:

DHCP:OFFER

SID:xxx.xxx.3.220

LT:86400

SM:255.255.252.0

DG:xxx.xxx.228.1

RP:"http://xxx.xxx.3.118/NetRestore107.nbi/NetInstall.dmg"

VO:8.4.129.0.0.103

VC:"AAPLBSDPC/i386"



As the iMac has identified itself using the vendor class identifier the DHCP server is able to respond with the correct file and location to boot the Mac from. This setup has been successfully used to net boot intel Macs for the purposes of restoring a standard images.


The folowing is a capture of the same process but this time recording the packets from a 2011 Mac Mini.




This is the DHCP:DISCOVER as sent by the Mid 2011 Mac Mini



15:43:15.914048 IP (tos 0x0, ttl 253, id 26327, offset 0, flags [none], proto: UDP (17), length: 320) xxx.xxx.228.1.67 > xxx.xxx.3.220.67: [udp sum ok] BOOTP/DHCP, Request from c8:2a:14:55:5f:b9, length: 292, hops:1, xid:0xae50136a, secs:4, flags: [Broadcast] (0x8000)

Gateway IP: xxx.xxx.228.1

Client Ethernet Address: c8:2a:14:55:5f:b9

Vendor-rfc1048:

DHCP:DISCOVER

PR:SM+DG+NS+DN+BF+VO+VC

CID:[ether]c8:2a:14:55:5f:b9:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00:00:00:00:00

MSZ:1500





And this is the result as send back by the DHCP/BSDP server.



15:43:15.914275 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) xxx.xxx.3.220.67 > xxx.xxx.228.1.67: [bad udp cksum f0c8!] BOOTP/DHCP, Reply, length: 300, hops:1, xid:0xae50136a, secs:4, flags: [Broadcast] (0x8000)

Your IP: xxx.xxx.230.94

Server IP: xxx.xxx.3.118

Gateway IP: xxx.xxx.228.1

Client Ethernet Address: c8:2a:14:55:5f:b9

file "pxelinux.0"

Vendor-rfc1048:

DHCP:OFFER

SID:xxx.xxx.3.220

LT:86400

SM:255.255.252.0

DG:xxx.xxx.228.1

NS:xxx.xxx.3.17,xxx.xxx.131.16

DN:"our.domain.com"





As the Mac Mini does not send the vendor class identifier, the server offers the standard linux pxe boot file instead of the mac booter. Thus the Mini falls back to booting off the local drive instead of the network image.


I've open up a bug track to see if any Applle engineers can answer my query. I fear though that these changes may have something to do with the new internet recovery in Lion and thus all macs will gradually exhibit the same behaviour. It may be possible to netboot these (e.g. from an OS X server) but the changes in the new models don't follow what has worked in the past.


If anyone has any ideas as to what is happening or has an alternate method that works for the 2011 Mini and beyond, it would be much apreciated.

Mac mini, Mac OS X (10.7.2)

Posted on Oct 25, 2011 5:14 AM

Reply
7 replies
User profile for user: bartron
bartron Author
User level: Level 1
9 points

Oct 30, 2011 5:29 PM in response to bartron

no-one?


Having a look on the DeployStudio forums here http://www.deploystudio.com/Forums/viewtopic.php?id=3133 it appears to be a similar issue to what I'm having.


On a whim I also set up a mini with Lion Server and it couldn't netboot a 2011 MacBook Air. Either whoever was tasked with implementing Internet Recovery screwed up the netboot porion of EFI by accident or is is done intentionally (I see no reason why. Internet recovery would be trivial to implement as an EFI application without changing the existing code)


Apple changing stuff without notice is completly unsuprising. But it means we can no longer rely on vendor class identifier to recognise Macs on the network.

Reply
User profile for user: Xavier Vasquez
Xavier Vasquez
User level: Level 1
9 points

Dec 14, 2011 7:54 PM in response to bartron

Hello.


I am having a very similar issue. I cannot get my new MacBookPro to Netboot/NetInstall. I have gone back and forth with Apple suppport but they think it is my internal DHCP server. In my logs I see the DHCP Discovery, ACK, and OFFER. I also see the BSDP Discovery, ACK, but there is no OFFER and the system drops immediately to itself and boots. The verbose screens have been almost no help. I have yet to run a packet trace.


I am using DHCPv4 Raw Options off our Blue Cat Linux servers that relate vendor options and vendor class ID's to my Mac clients. This has been working perfectly for over a year now. I will try and send logs tomorrow. I am also going to broaden the scope of my vendor class ID or get rid of it all togther to see if that helps. I am also using a Apple XServe (10.6.8). All my other MBP's, iMac's, MacPro's NetNoot perfectly in fact they use the new image I made from the new system just fine. This is very fustrating.


I also have a MacBookPro 8,2 from mid 2011and it works perfectly. It is a i7 2.2. My new MBP is a i7 2,5 MHZ.


I will try and circle back around after my next round of tests.


Thanks.

Reply
User profile for user: bartron
bartron Author
User level: Level 1
9 points

Apr 16, 2012 5:29 PM in response to csumb_bisc

Install wireshark and do a trace of the packets and see what that MAc is doing. I found that with the new firmware it worked fine with my non-production OS X server but that's just something I have set up for tinkering/testing. We have no intention of rolling out OS X "servers" across the country as Apple have no hardware that satisfies our server room requirements. The new firmware still doesn't advertise the machine on the first DHCP:DISCOVER so our linux DHCP servers aren't offering the booter files.


sigh..


Anyway, I decided that I'm not going to wait for Apple or our linux server guys so making do with what I had I wrote my own scripted install utility using the default install already present on new Macs. So, from my point of view, I don't need netboot at all anymore (we also have the advantage of having high speed "free" access to an ackamai mirror for re-installing so for now we can use internet boot/recovery HD for re-installes as well as USB keys.


On a side note, having ripped apart the Internet Boot process it would be really easy to host internal "internet boot" server(s) if Apple ever allow that. It's literally just "download a Recovery HD image from this http address". There seems to be some key checking process that goes on as well but I'm not sure if that is a requirement or something initiated by the server.

Reply

Netboot on 2011 mini broken?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up