@Tom-Elliott I tried both snp and snponly and neither supported a deploy operation. The Mac Mini uses Broadcom, so I tried building a tg3.efi iPXE, and that seems to be working. If other Macs don’t use a tg3.efi driver, is there a way to build multiple drivers into one EFI that’s not ipxe.efi?

@Tom-Elliott rEFInd works (I just had to set it using the web interface). However, if snp.efi and snponly.efi don’t work, I’m back where I started with it not working without the wifi card pulled.

@Tom-Elliott Setting “EFI Exit Type” to “EXIT” (in the host settings, in global settings, and in group settings) didn’t work. Also, I noticed an issue with the snponly.efi solution: trying to deploy an image results in nothing happening after it says “bzImage loaded” and “init.xy” (it just stays on that screen).

@Wayne-Workman It was booting to ipxe.efi fine; the issue was that once ipxe.efi loaded it didn’t work right.

@Tom-Elliott snponly.efi worked on a Mini with the wifi card still in. It showed the same error message (with DUView.c and AppleBootUI.c) that net1 showed in ipxe.efi, but it tried net0 first instead of net1 and successfully loaded the menu.

Once it reached the menu, “Boot from hard drive” failed with a “chainloading failed” message. Should I use this thread for that question or start a new one?

On a hunch, I physically pulled the Wi-Fi card out of the Mac Mini. It no longer tries booting to net1, and ipxe.efi works (though it does pop up error messages initially). Unfortunately, pulling the Wi-Fi card from all computers isn’t necessarily a viable option. It seems, though, that it’s trying the Wi-Fi card before the Ethernet for some reason.

@Sebastian-Roth My test environment uses a normal desktop switch, so I don’t think I can do that. I did look at a tcpdump on the FOG server, and didn’t see any traffic from iPXE before it tries net1.

@Quazz My ultimate goal is centralized management of computers across a large campus, so I’d prefer something that let me reimage a lot of computers without running all around campus. If I want to do that, is it possible to do without setting netboot as the default?

@Tom-Elliott Blessing ipxe.efi directly leads to it not even loading iPXE.

@Quazz I was under the impression that FOG is supposed to be the default boot option for machines (so that they’ll complete any assigned tasks automatically on startup). Is that wrong? (although if that’s how it’s supposed to work, there’s another issue that should maybe be a separate question: the menu’s “boot from hard drive” option leads to a “chainload failed” message).

@Sebastian-Roth The weird thing is that if I launch it from the boot menu, after net1 fails it then tries net0 (which works).

@Tom-Elliott I can try that tomorrow and post the results, but as far as BSDP goes it is getting to iPXE successfully (the failure happens once iPXE has loaded), and I can successfully boot using BSDP from the Mac boot menu.

Attached are images of the failed boot sequence using BSDP. There’s some activity, then it hangs on the first screenshot for a sec, then it scrolls through the second and third screenshots (the third screenshot is what it shows immediately before failing and booting the internal hard drive).

Server

• FOG Version: 1.3
• OS: RHEL 7

Client

• Service Version:
• OS: OS X 10.11

Description

I’m trying to set up a Mac Mini (Macmini7,1) to automatically boot from my Fog server. I used csrutil to authorize the Fog server as a netboot source, and then used bless --netboot --server bsdp://192.168.1.10 to tell the Mac to boot from that server. When I reboot, it loads iPXE, which then says “Could not open net1: input/output error”. It then very briefly displays a hex dump of some sort before booting from the hard drive.

When I hold Alt at boot to access startup options and select Fog from there, the same thing happens, except that it doesn’t boot from the hard drive. After the hex dump goes on for a bit, it successfully boots using net0 and pulls up the Fog menu.

Any idea what’s going on? I have a video of the failed autoboot I can upload if it’d help.

@george1421 The issue seems to only apply to a 32-bit VM; changing to 64-bit makes registration work. Is that something expected? (the server is 64-bit)