NetRestores Appear in OS, but not in EFI

rstansifer
New Contributor III

So I'm pushing out a new version of our various images (10.10-10.7). I have a few different versions of each, some designed to repartition the drive, some designed to just do an Erase and Install.

I have a handful of Macs that will see my NetRestore server. I can command it to set the startup disk to one of these NetRestores through both Apple Remote Desktop and through the Mac itself. That works fine...and then the Mac just reboots into the OS it was just in.

When I have the user hold option for the EFI Startup Disk, the NetRestore Drives do not appear. However, when they boot into a Recovery HD, they do appear...but having them restart to one of the NetRestores from there ends up with the same result.

The only recent change we've made is setting up IP-HELPER to propagate the bootdp information across multiple VLANs. But all of the Macs in question are on the VLAN that's always worked before the IP-HELPER was ever deployed. I've checked for commonalities between the Macs, but they're different models, different years, and normal IPs.

Anyone have any suggestions?

9 REPLIES 9

davidacland
Honored Contributor II

There are some compatibility limitations between versions and from the netboot server itself. If I remember correctly a 10.7 netboot server might not boot new 10.10 clients.

As a test, you can put one of your clients on the same switch / van as the netboot server, in the same subnet and test it. If it all works, its a networking issue. If it doesn't, its probably a version compatibility issue.

Hope this helps!

yukonluke
New Contributor

Does it work for newer models? I seem to recall having this issue last year and it ended up being the size of the kernel cache file.

If I remember correctly newer NBI images had a kernel cache of about 35.5MB, but any mac pre-2011-ish would only support caches of less than 32MB. Once we stripped out some extra kexts that we didn't need to get the cache size down to below 32, the netboots started working again.

Here is a related post: https://jamfnation.jamfsoftware.com/discussion.html?id=9836

calumhunter
Valued Contributor

What os/build is the netboot image (NBI) on the server?
What version of OS X Server are you using?

rstansifer
New Contributor III

@davidacland - The issue is that there are multiple Macs on the primary VLAN and other VLANs the Server is connected to that are working. I don't think this has to do with the VLAN. I've also tried using the 10.9 Automated Erase and Install, along with multiple versions of the 10.10 Automated Repartition E&I and normal E&I. While I do have a 10.7 NetRestore, most of the Macs aren't getting it.

@yukonluke - The ones that have given me trouble are a Late 2009 27" iMac. I also had issues with a 21.5" Late 2009 that I eventually resolved by having the individual boot to the 10.10 Recovery HD and select the "10.10 Basics" NetRestore, which is one where the user has to select the hard drive instead of the Mac automatically selecting it. Finally, the other one giving me issues is a Early 2009 24" iMac.

However, I have successfully installed these images without trouble on the following: Early 2008 iMac, 21.5" Mid-2011 iMac, Late 2012 Mac Mini, 21.5" Mid-2010 iMac, 21.5 Late 2009 iMac, a Mid 2007 20" iMac and several others. So age as you can see doesn't seem to matter.

@calumhunter - The 10.10 Image (The primary image) is 10.10.2 (14C1510). The Mac Mini running OS X Server is running on the same OS and Build with a Server version of 4.0.3 (14S350).

calumhunter
Valued Contributor

Hmmm maybe im not understanding.

So in order to boot the machines over the network, you need to have a NBI or NetBoot Image, this is stored on the server in /Library/NetBoot/NetBootSP0 ( i think its been a while since i used os x server )
How did you create this NetBoot image? What os build is this?

I have a feeling that this is the reason, certain models will only boot certain OS's. There are also issues with kernel kext cache sizes on some machines.

rstansifer
New Contributor III

@calumhunter - They are indeed located there. And I used System Image Utility, the built in program for them. The build is 14C1510.

We don't have any Macs that won't install 10.10. In fact, the Macs I'm imaging have an old version of 10.10 on them now. 10.10 requires Early 2007 iMac minimum. While we have a few of those, even those are imaging properly (though they take forever).

Any Mac that won't run 10.10 have already been removed from the floor.

bentoms
Release Candidate Programs Tester

The kernelcache issue was with System Image Utility 10.9.0-.3.

Anything above works.

I've not touched NetRestore, so not sure how much it differs from NetBoot.

htse
Contributor III

From what you're describing, I suspect the issue is in the networking layer. Starting the NetBoot process requires getting an IP address, and finding a NetBoot Server. At the OS level, you've probably got an IP address already, so it just go out and see if NetBoot server responds with an acknowledgement.

Unfortunately at the EFI-level, Startup Manager doesn't volunteer a lot of information. I would suggest watching your IP-addressing service to see if it's dishing out an IP to the client, and then watch the NetBoot service to see if it acknowledges a request from the client.

Bruienne
New Contributor II

This sounds like a basic networking issue, one that seems to have become more prevalent with recent firmware versions. The EFI BSDP client has a very short fuse when it comes to the DHCP phase of the overall NetBoot process. In my testing it will request an IP address 3-4 times, with increasing timeouts until giving up, and giving up entirely.

Usually this is due to the network port on the switch the Mac is connected to not coming online quickly enough, thwarting the DHCP requests. The presence of incorrectly configured port features such as Portfast and Spanning Tree Protocol (STP) is normally the cause of these delays. In (much) older Apple firmware versions one would be able to hit the "N" key to retry the BSDP request but sadly Apple removed that feature.

To be more certain that it is indeed a DHCP-related issue you could run Wireshark on a second Mac connected to the same network segment and look for any requests from the failing Mac's MAC address, mainly BOOTP. If you don't see any it's a safe bet the port is not enabled in time. In that case your next move would be to talk to your (It's not the) Network people and determine whether there are any standard features enabled on the network ports that you're testing from that would cause delays in enabling the port.