Skip to main content

Hey Everyone,
Has anyone had success netbooting the latest Apple Hardware (2012 Retina MBP and 2012 MBAs)?

I have tried just about every way I can possibly think of. Even attempting to use a combination of the full Bless and NVRAM commands directly calling out the network interface en1 instead of en0. The system only tries for a couple seconds and then goes to the local HD. If the system is on the same subnet it works by just choosing the drive in Startup Disk or holding down N during boot or holding down option and choosing the netboot server.

This is on a system that is fully up to date on firmware and OS (10.8.2 and 10.8.3 beta). This is on a Netboot server that is also fully up to date and on Apple hardware.

Any thoughts or ideas would be much appreciated.

Sample of the commands I have tried:

bless --netboot --server bsdp://en1@10.36.12.41
bless --netboot --server bsdp://en1@10.36.12.41 --booter tftp://10.36.12.41/NetBoot/NetBootSP0/CasperNetboot.nbi/i386/booter --kernel tftp://10.36.12.41/NetBoot/NetBootSP0/CasperNetboot.nbi/i386/mach.macosx --kernelcache tftp://10.36.12.41/NetBoot/NetBootSP0/CasperNetboot.nbi/i386/x86_64/kernelcache --options "rp=nfs:10.36.12.41:/private/tftpboot/NetBoot/NetBootSP0:CasperNetboot.nbi/NetBoot.dmg" 


nvram boot-args="rp=nfs:10.36.12.41:/private/tftpboot/NetBoot/NetBootSP0:CasperNetboot.nbi/NetBoot.dmg"
nvram efi-boot-kernelcache='<array><dict><key>IOMatch</key><dict><key>BSD Name</key><string>en1</string><key>IOProviderClass</key><string>IONetworkInterface</string></dict><key>BLMACAddress</key><data>QGyPPmI8</data></dict><dict><key>IOEFIDevicePathType</key><string>MessagingIPv4</string><key>RemoteIpAddress</key><string>10.36.12.41</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>NetBoot/NetBootSP0/CasperNetboot.nbi/i386/x86_64/kernelcache</string></dict></array>'
nvram efi-boot-file='<array><dict><key>IOMatch</key><dict><key>BSD Name</key><string>en1</string><key>IOProviderClass</key><string>IONetworkInterface</string></dict><key>BLMACAddress</key><data>QGyPPmI8</data></dict><dict><key>IOEFIDevicePathType</key><string>MessagingIPv4</string><key>RemoteIpAddress</key><string>10.36.12.41</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>NetBoot/NetBootSP0/CasperNetboot.nbi/i386/mach.macosx</string></dict></array>'
nvram efi-boot-device='<array><dict><key>IOMatch</key><dict><key>BSD Name</key><string>en1</string><key>IOProviderClass</key><string>IONetworkInterface</string></dict><key>BLMACAddress</key><data>QGyPPmI8</data></dict><dict><key>IOEFIDevicePathType</key><string>MessagingIPv4</string><key>RemoteIpAddress</key><string>10.36.12.41</string></dict><dict><key>IOEFIBootOption</key><string>rp=nfs:10.36.12.41:/private/tftpboot/NetBoot/NetBootSP0:CasperNetboot.nbi/NetBoot.dmg</string></dict></array>'

Any logging on the server side?

We are 10.7.4 with many 2012 Airs using the Thunderbolt adapters. We use helper addresses though.

Hi Jared,
Server side logs are as follows:
bootpd[4095]: BSDP INFORM [en0] 1,40:6c:8f:3e:62:3c arch=i386 sysid=MacBookPro10,2
bootpd[4095]: NetBoot: [1,40:6c:8f:3e:62:3c] BSDP ACK[LIST] sent 10.36.11.134 pktsize 300

I need to turn up the logging on the server but im not thinking its a server side issue since the same system on the same subnet can boot without issue. Also iMac 2012 systems can netboot without issue across subnets.

In response to CasperSally due to the size of our network and the stance of our networking team I cannot have ip helpers.

Try netbooting into Verbose mode.

Bentoms,
So this may be rookie of me but the info onscreen is only there for a fraction of a second when in verbose mode.

We've been through this with Apple and its working as designed.

When you bless and reboot-
From EFI your packet goes from your machine to the server specified. Assuming its a NetBoot server, it will reply with a list of available NBIs. Then the Mac will choose an NBI and broadcast its response (to 255.255.255.255). It used to be broken in earlier EFI versions so that it actually sent responses to the IP addresses instead of broadcasting.

According to the BSDP specification, the client is supposed to broadcast its reply.

A few years ago, our iMac9,1, MacBookPro5,1, and a bunch of these older ones worked great across subnets without IP helpers. Its the new machines with the new EFI (with the proper adherence to the BSDP spec) that breaks things. Well, "break" from our point of view.

I put in an RFE to have directed BSDP traffic without needing IP helpers. Not holding my breath on this happening any time soon.

Went through this last summer, a couple of months before our Mtn Lion rollout, and we needed to NetBoot. Luckily, our networking team configured the IP helpers to all of our routers. If they didn't.... not sure what we would've done. Less flexibility for our users to upgrade on their own schedule, since we'd have to visit subnets. Or something.

We also have multiple NetBoot servers that I'd love to use again, but since we only have one IP helper, they're fairly useless these days. Would've put our secret and/or dangerous NBIs on there. However, with these new workstations, had to put our dangerous NBI on the main prod server and tell our people to BE *VERY* CAREFUL. Our dangerous NBI is used for user-initiated Mtn Lion upgrades, where it auto logins & runs diskutil that repartitions after 20 seconds of waiting. While completely ideal for upgrades, a bit suboptimal for us to use for troubleshooting. Have our regular safe NBI around, but its not the default. A few years ago, had squirreled the dangerous NBI onto its own server that couldn't get to other than via bless. Then it was optimal, since users went to that one (via a Casper script) and us support people could select the correct one via broadcasting from Startup Disk or EFI boot menu.

You can watch this network traffic by running tcpdump. For the workstation, need to plug it into a hub (not a switch) then run tcpdump on another Mac connected to that hub. Also grab a tcpdump from the NetBoot server.

Terms & ConditionsCookie settingsAccessibility statement