Issues with 2011 Macs and netboot.

[Bartron]

So, I’ve been having this issue with the post Lion 2011 macs (Mini and Air and with a firmware update, now the MacBook Pro)

Damn things won’t netboot. 🙁 and I’ve been pouring over all the netboot documentation I can find to try and sus out why these new Macs won’t netboot.

Anyway, we are hosting netboot from a distributed network of ]linux DHCP servers (https://www.afp548.com/article.php?story=20061220102102611) and for the last 5 years or so this has worked perfectly fine (and still does for pre July 2001 machines). I did a packet trace on the new Macs and it appears that during the DHCP DISCOVER the macs no longer send the vendor class identifier. This causes the macs to be offered our standard linux PXE boot environment (that we use for the PC fleet) at which point the machine defaults to booting from the local disk.

So far I’m at a loss as to what to do here. We are in the process of re-writing parts of the code so that we can specify “option root-path” on a per MAC address basis but I’m not confident it will solve the issue (not to mention we’ll need to enter in these options every time we add a new machine rather than rely on a class). I have a thread on apple discussions here https://discussions.apple.com/thread/3433338?tstart=60 but no replies so far.

I have also tried setting up a netboot server using Lion server. The client machines will see it and I can select it from the startup disk pref pane but still won’t boot. From what I can tell it gets as far as DHCP SELECT (or something to that effect…don’t have it in front of me at the moment) and then boots from local disk.

Any thoughts on the issue would be greatly appreciated. 🙂

[airlocksniffer]

Same issue here. We are running Lion Server 10.7.2 on a mid-2010 Mac Mini. I can see the netboot images fine but the machine will quickly boot to the internal disk after the large flashing globe. This machine is a late 2011 iMac (iMac 12,1). Older C2D MacBook Pro will boot to the lion image created off of the iMac fine. Here is a portion of what I get when logging the verbose boot when trying to Netboot the iMac:

MAC Framework successfully initialized
using 10485 buffer headers and 4096 cluster IO buffer headers
IOAPIC: Version 0x20 Vectors 64:87
ACPI: System State [S0 S3 S4 S5] (S3)
PFM64 0xf10000000, 0xf0000000
[ PCI configuration begin ]
console relocated to 0xf10010000
PCI configuration changed (bridge=2 device=3 cardbus=0)
[ PCI configuration end, bridges 5 devices 16 ]
AppleIntelCPUPowerManagement: Turbo Ratios 0000
AppleIntelCPUPowerManagement: (built 16:44:42 Jun 7 2011) initialization complete
mbinit: done (64 MB memory set for mbuf pool)
rooting via boot-uuid from /chosen: 6F2D14F2-6EAB-3DD9-9C59-20D4FFE0134C
Waiting on IOProviderClassIOResourcesIOResourceMatchboot-uuid-media
com.apple.AppleFSCompressionTypeZlib kmod start
com.apple.AppleFSCompressionTypeZlib load succeeded
AppleIntelCPUPowerManagementClient: ready
Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/SATA@1F,2/AppleIntelPchSeriesAHCI/PRT0@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD2500AAKS-402AA0 Media/IOGUIDPartitionScheme/Customer@2
BSD root: disk0s2, major 14, minor 2
FireWire (OHCI) Lucent ID 5901 built-in now active, GUID c82a14fffef06e7e; max speed s800.
Kernel is LP64
USBMSC Identifier (non-unique): 000000009833 0x5ac 0x8403 0x9833
systemShutdown false
Waiting for DSMOS…
Previous Shutdown Cause: 5
DSMOS has arrived

And the same log when successfully netbooting with a MacBook Pro:

MAC Framework successfully initialized
using 16384 buffer headers and 10240 cluster IO buffer headers
IOAPIC: Version 0x20 Vectors 64:87
ACPI: System State [S0 S3 S4 S5] (S3)
PFM64 (36 cpu) 0xf10000000, 0xf0000000
[ PCI configuration begin ]
console relocated to 0xf10030000
AppleIntelCPUPowerManagement: (built 21:08:10 Aug 9 2011) initialization complete
PCI configuration changed (bridge=5 device=1 cardbus=0)
[ PCI configuration end, bridges 7 devices 17 ]
FireWire (OHCI) TI ID 8025 built-in now active, GUID 001ff3fffe7db2e0; max speed s800.
mbinit: done [64 MB total pool size, (42/21) split]
Pthread support ABORTS when sync kernel primitives misused
com.apple.AppleFSCompressionTypeZlib kmod start
com.apple.AppleFSCompressionTypeDataless kmod start
com.apple.AppleFSCompressionTypeZlib load succeeded
com.apple.AppleFSCompressionTypeDataless load succeeded
AppleIntelCPUPowerManagementClient: ready
BTCOEXIST off
wl0: Broadcom BCM4328 802.11 Wireless Controller
5.10.131.36
[IOBluetoothHCIController::setConfigState] calling registerService
From path: “IOProviderClassIONetworkInterfaceIOParentMatchIOPropertyMatchIOMACAddress001ff3cf2166“, Waiting on IOProviderClassIONetworkInterfaceIOParentMatchIOPropertyMatchIOMACAddressAB/zzyFm
AppleYukon2: Marvell Yukon Gigabit Adapter 88E8055 Singleport Copper SA
AppleYukon2: RxRingSize <= 1024, TxRingSize 256, RX_MAX_LE 1024, TX_MAX_LE 768, ST_MAX_LE 3328 yukon: Ethernet address xx:xx:xx:xx:xx:xx Got boot device = IOService:/AppleACPIPlatformExpert/PCI0/AppleACPIPCI/RP06@1C,5/IOPCI2PCIBridge/GIGE@0/yukon2osx/yukon/IOEthernetInterface BSD root: en0 netboot: using network interface 'en0' netboot: retrieving IP information from DHCP response netboot: IP address xx.xxx.xxx.xxx netmask 255.255.255.0 router xx.xxx.xxx.xx netboot: adding default route xx.xxx.xx.xxx netboot: retrieving root path from BSDP response netboot: NFS Server xx.xxx.xxx.xx Mount /Library/NetBoot/NetBootSP0 Image /Lion Netboot.nbi/NetBoot.dmg Ethernet [AppleYukon2]: Link up on en0, 1-Gigabit, Full-duplex, No flow-control, Debug [796d,ac08,0de1,0200,c1e1,2800] root on xx.xxx.xx.xxx:/Library/NetBoot/NetBootSP0 netboot_setup: calling imageboot_mount_image IOHDIXController: NOTE: administrator is creating non-ejectable disk image KDIFileBackingStore::_handleStart: initial R/W vn_open returned 30 imageboot_mount_image: root device 0xe000006 Kernel is LP64 jnl: disk0s2: replay_journal: from: 15992320 to: 1140736 (joffset 0xe8e000) jnl: disk0s2: journal replay done. hfs: Removed 4 orphaned / unlinked files and 0 directories macx_swapon SUCCESS Previous Shutdown Cause: -128 Waiting for DSMOS... WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for MacBookPro4,1 with 8 p-states, using default stepper instead nstat_lookup_entry failed: 2 NVDANV50HAL loaded and registered. DSMOS has arrived We have some newer MBP's and Mac Mini's coming soon so I be able to see if this is machine specific or all late 2011 Macs. Hopefully not the latter.

[hjuutilainen]

Same issue here. The most recent macs just flash the globe and then go on to boot from local disk. Can’t think of any other quick solution than to create preconfigured DeployStudio USB sticks for our support staff…

Did you create bugreports for this issue?

[Bartron]

Yup, I’m essentially going through the process of working out alternate solution.

I don’t use deploy studio (I use a modified version of the recovery hd) but I’m in the process of sorting out a dozen or so USB sticks to distribute around to the various sites. As our image is hosted on a http server so I can use the default recovery hd to do a restore but this is hardly ideal (especially since I went to the effort of hacking the recovery hd, made it net bootable and installed some custom apps…works well on older hardware at least).

I have reported the issue to apple via bug track but I’m sorely tempted to write an email and sent it to Tim Cook directly (and CC in half a dozen other SVP’s) as communicating with Apple via normal channels is about as productive to talking to a wall.

[airlocksniffer]

I just got off the phone with AppleCare and was told this is a known issue by senior engineers. We have this symptom with the mid-2011 Mac Mini, late 2011 MacBook Pro and late 2011 iMac, seems like any machine that ships with Lion. Hopefully a firmware update will fix this soon.

[electrowave]

I had this same issue, I was able to overcome it. I don’t remember how at the moment. I will look into it and post back if I come up with something.

[bpcruz]

Has anyone here heard any updates regarding this problem or found any solutions? I’m unable to NetBoot most recently purchased Macs (though I can load my NetBoot sets by holding down the Option key and selecting them via the Startup Manager).

After much testing, I’ve isolated the issue to Macs that ship with Apple’s latest firmware updates. Among other things, these updates enable the Internet Recovery feature, which at least appears to be something akin to downloading a NetBoot set hosted by Apple (the environment, once downloaded, is essentially the same as the hard disk’s hidden Lion Recovery partition).

Here are links to the updates that have caused problems for me:

http://support.apple.com/kb/DL1470

http://support.apple.com/kb/DL1450

To verify that this firmware update caused the issue, I tried loading a DeployStudio NetBoot set stored on my laptop from an Early-2011 MacBook Pro using the previous firmware update (Boot ROM version MBP81.0047.B0E) by pressing the “N” key at startup. NetBoot was enabled on my laptop’s ethernet interface, to which the MacBook Pro was directly connected. The NetBoot set loaded just fine, and I was able to automatically log into the DeployStudio Runtime on the NetBoot set without issue.

I then upgraded that same Early-2011 MacBook Pro to the latest firmware version (MBP81.0047.B24) and tried loading my laptop’s NetBoot set in the same manner (by pressing the “N” key). The globe flashed for a few seconds before failing and booting the system partition on MBP’s hard disk instead.

Below is the a comparison of the bootstrap protocol data from the DCHP discover packet sent by the same machine before and after the update. First, the packet issued before the update:

Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x00000555
Seconds elapsed: 4
[b] Bootp flags: 0x0000 (Unicast)
0… …. …. …. = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000[/b]
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
Option: (t=55,l=5) Parameter Request List
Option: (55) Parameter Request List
Length: 5
Value: 0103432b3c
1 = Subnet Mask
3 = Router
67 = Bootfile name
43 = Vendor-Specific Information
60 = Vendor class identifier
Option: (t=57,l=2) Maximum DHCP Message Size = 1500
Option: (57) Maximum DHCP Message Size
Length: 2
Value: 05dc
Option: (t=61,l=7) Client identifier
Option: (61) Client identifier
Length: 7
Value: 013c07541b1400
Hardware type: Ethernet
Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
[b] Option: (t=60,l=28) Vendor class identifier = “AAPLBSDPC/i386/MacBookPro8,1”
Option: (60) Vendor class identifier
Length: 28
Value: 4141504c42534450432f693338362f4d6163426f6f6b5072…[/b]
Option: (t=43,l=4) Vendor-Specific Information
Option: (43) Vendor-Specific Information
Length: 4
Value: 02020101
End Option
Padding

Now, after the update:

Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x18553443
Seconds elapsed: 0
[b] Bootp flags: 0x8000 (Broadcast)
1… …. …. …. = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000[/b]
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
Option: (t=55,l=7) Parameter Request List
Option: (55) Parameter Request List
Length: 7
Value: 0103060f432b3c
1 = Subnet Mask
3 = Router
6 = Domain Name Server
15 = Domain Name
67 = Bootfile name
43 = Vendor-Specific Information
60 = Vendor class identifier
Option: (t=61,l=33) Client identifier
Option: (61) Client identifier
Length: 33
Value: 013c07541b14000000000000000000000000000000000000…
Option: (t=57,l=2) Maximum DHCP Message Size = 1500
Option: (57) Maximum DHCP Message Size
Length: 2
Value: 05dc
End Option

Besides the absence of the vendor class identifier noted above, another notable difference between this packet and the one I captured before the update is the bootp flag. The packet after the update has the broadcast flag set. The one before is unicast.

The DHCP offer packet sent by my laptop also has the unicast bootp flag set in the exchange made before the firmware update:

Ethernet II, Src: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8), Dst: Apple_1b:14:00 (3c:07:54:1b:14:00)
Destination: Apple_1b:14:00 (3c:07:54:1b:14:00)
Address: Apple_1b:14:00 (3c:07:54:1b:14:00)
…. …0 …. …. …. …. = IG bit: Individual address (unicast)
…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
Source: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
Address: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
…. …0 …. …. …. …. = IG bit: Individual address (unicast)
…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
Type: IP (0x0800)

….

Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x00000555
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0… …. …. …. = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 192.168.1.1 (192.168.1.1)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
Client hardware address padding: 00000000000000000000
Server host name: C701-ML-FSPT-20.local
Boot file name: /private/tftpboot/NetBoot/NetBootSP0/10.7.2_Combo_Intel_NB111213.nbi/i386/booter
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Option: (53) DHCP Message Type
Length: 1
Value: 02
Option: (t=54,l=4) DHCP Server Identifier = 192.168.1.1
Option: (54) DHCP Server Identifier
Length: 4
Value: c0a80101
Option: (t=60,l=9) Vendor class identifier = “AAPLBSDPC”
Option: (60) Vendor class identifier
Length: 9
Value: 4141504c4253445043
Option: (t=17,l=90) Root Path = “nfs:192.168.1.1:/Library/NetBoot/NetBootSP0:10.7.2_Combo_Intel_NB111213.nbi/NetInstall.dmg”
Option: (17) Root Path
Length: 90
Value: 6e66733a3139322e3136382e312e313a2f4c696272617279…
Option: (t=43,l=18) Vendor-Specific Information
Option: (43) Vendor-Specific Information
Length: 18
Value: 08048200006e820a4e6574426f6f74363330
End Option

Below are the same sections from the discover packet sent by laptop to the MBP after the update:

Ethernet II, Src: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
…. …1 …. …. …. …. = IG bit: Group address (multicast/broadcast)
…. ..1. …. …. …. …. = LG bit: Locally administered address (this is NOT the factory default)
Source: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
Address: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
…. …0 …. …. …. …. = IG bit: Individual address (unicast)
…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
Type: IP (0x0800)

….

Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x18553443
Seconds elapsed: 0
Bootp flags: 0x8000 (Broadcast)
1… …. …. …. = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.1.13 (192.168.1.13)
Next server IP address: 192.168.1.1 (192.168.1.1)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
Client hardware address padding: 00000000000000000000
Server host name: C701-ML-FSPT-20.local
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Option: (53) DHCP Message Type
Length: 1
Value: 02
Option: (t=54,l=4) DHCP Server Identifier = 192.168.1.1
Option: (54) DHCP Server Identifier
Length: 4
Value: c0a80101
Option: (t=51,l=4) IP Address Lease Time = 59 minutes, 24 seconds
Option: (51) IP Address Lease Time
Length: 4
Value: 00000dec
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: ffffff00
Option: (t=3,l=4) Router = 192.168.1.1
Option: (3) Router
Length: 4
Value: c0a80101
Option: (t=67,l=19) Bootfile name = “pxelinux/pxelinux.0”
Option: (67) Bootfile name
Length: 19
Value: 7078656c696e75782f7078656c696e75782e30
End Option
Padding

The after the update, the boot file location is missing–further, the destination of this offer packet is a broadcast address, not the MBP address as before.

My problem is, I have very little idea what any of this means. I’m not sure how to interpret this data, nor do I have any idea what I can do to have my clients properly load the NetBoot set when pressing the “N” key. And the issue doesn’t even stop there–after applying the firmware update, even though I can load NetBoot set through the Startup Manager, strange error messages and drops in connection occur once the DeployStudio NetBoot set loads.

Thoughts?

[Bartron]

After trying and looking at several solutions from custom USB boot drives, mucking about with the DHCP server, arcane terminal commands etc I had the bright idea of just forgetting about the whole “master image” concept.

So I did. B)

And here’s what Ive come up with instead:

I originally had a set of shell scripts that would set up a master image of OS X. Nothing flash, but they did the job of automating my workflow. I have now extended those and wrapped them up in a nice piece of applescript that launches them all. Now my roll-out process involves pulling the Mac out of the box, going through the new user wizard (what the user is called is irrelevant) browsing to a simple web site hosting a DMG with the applescript application within. After authenticating the scripts go ahead and one after the other configure everything that needs to be configured and install all the apps that need installing, downloading packages from our distributed file system without further interaction (the whole ‘back end’ runs on Windows Server 2008 R2). The last thing it does is call an application I wrote to automate joining to our domain. Once re-booted the system is a fully configured and AD authenticated OS X workstation. The whole process takes about 9 minutes 51 seconds (I timed it) not including unboxing and creating the first user account.

To many, this may seem a lot like what Puppet can do and it’s actually something we’ll look at in the future. Overall though the scripts I wrote only took a couple of days of the framework. The rest is just modifying individual scripts as new settings/applications are needed.

So that was after about 2 weeks tying everything together. The great thing is that apart from my printer config, everything works on OS X 10.8 without changing anything. This will be handy now that Apple are moving to a yearly release cycle.

So in the end, Apple breaking our net boot environment has actually resulted in my organisation being in a much better position in regards to new versions of OS X as they come out. 🙂

[airlocksniffer]

This seems okay for one or a few macs at a time but netboot is really necessary for rolling out lots of machines in a decent amount of time with as little hands on time as necessary.

[Bartron]

Depends on your setup I guess.

I support roughly 500 macs (a growing number admittedly) that get upgraded on a rolling 3-4 year cycle so the number of macs that need to be imaged is only going to be a handful every week and even then, distributed across the country. Unless something drastic happens I’ll never be in the position where I have to multicast to 50 macs at once. if that were ever to happen on a regular basis I’d invest in the proper hardware to do it. For now though we have something like 6 or 7 distribution servers around the country and each one can easily do 5-10 macs simultaneously. More if you stagger them by a minute or two (the biggest download is office at 900ish Mb but at 30Mb per second it’s only 30 seconds to download. Most of the time spent is installing, not downloading)

So, [b]for me[/b], getting net booting sorted on our mainly windows/Linux network is no longer an issue.

[airlocksniffer]

Just tested the newly released firmware updates for my late 2011 MacBook Pro and can report the issue is not solved. Still cannot netboot to either my own images or Apple Service Diagnostic images. Still quits prematurely and boots to the internal drive:

Feb 23 15:37:58 minixserver bootpd[48442]: BSDP INFORM [en0] 1,xx:xx:xx:xx:xx:xx NetBoot035 arch=i386 sysid=MacBookPro8,2
Feb 23 15:37:58 minixserver bootpd[48442]: NetBoot: [1,xx:xx:xx:xx:xx:xx] BSDP ACK[LIST] sent xx.xx.xxx.xx pktsize 311
Feb 23 15:38:00 minixserver bootpd[48442]: BSDP INFORM [en0] 1,xx:xx:xx:xx:xx:xx NetBoot035 arch=i386 sysid=MacBookPro8,2
Feb 23 15:38:00 minixserver bootpd[48442]: NetBoot: [1,xx:xx:xx:xx:xx:xx] BSDP ACK[LIST] sent xx.xx.xxx.xx pktsize 311

I’ll keep digging but it’s not looking good….. 🙁

[Bartron]

Ditto.

on with my scripted install plan 🙂

[csumb]

anyone have any luck with getting a response from Apple? or figuring out a way around this?

[Bartron]

Other than a request to “try with the new firmware”? No.

I closed my bug ticket though so I don’t expect to hear anything further (still haven’t heard from them about an older bug I found using ARD to unlock your desktop without your password but that’s another story).

Anyway, I implemented an in-house developed scripted install method around 3 weeks ago and so far everyone is impressed. Takes about 10 minutes and the end result is a fully managed, branded, configured, adjusted install with domain authentication and all corporate apps installed and for the most part it’s hands-off (there’s about a 1 minute QnA at the end to name the computer and join the right OU). Bash scripts do the heavy lifting with an AppleScriptObjC app to make it look pretty (progress bar and other feedback). Longest part is installing Office 2011 @ 7 minutes including downloading. Speaking of which, updating the SOE to include SP2 will be as simple as copying the combo installer to the download location and changing the Office install script to point to the updated version..done. Only one component to test and it’s available straight away.

*Bonus Round*
With a slight adjustment to the scripts I already support 10.8 DP2 and should be able to support it on day 1 when it’s released 🙂

[airlocksniffer]

We actually got this to work. What we found is that the newer firmware cannot get an IP address while netbooting when the DHCP server is on another subnet and falls back to the internal drive. We fired up an old HP server for DHCP and put it, the lion server and client on the same subnet and it works fine. I need to test whether or not I can netboot when the client is on one subnet and the dhcp/lion server are on another.

[Author]

Posts