UNSOLVED Blessing Fog server doesn't work on Macmini7,1
- FOG Version: 1.3
- OS: RHEL 7
- Service Version:
- OS: OS X 10.11
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.10to 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
net0and 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.
@cpast : Were you able to fix netboot?
Could you be a bit more specific on which exact model you are having those issues on. AFAIK there are at least four different models called ‘Macmini7,1’ - possibly more:
As well it would be great if you could give us the vendor and product ID of those ethernet and wireless cards build into your Macminis…!
@Tom-Elliott I looked through the rom-o-matic for the iPXE kernels and I didn’t specifically see a tc3 or tigon3 card called out specifically. BUT, if you can use a specific iPXE kernel with only the driver for the tigon broadcom network interface, you may luck out and the wireless adapter may not be seen at all by the iPXE kernel as it would if you use one of the general purpose efi kernels.
Once you can narrow it down to a specific ipxe kernel that will only see the ethernet adapter then we have options for us to use. If you dhcp server is isc-dhcp (linux), dnsmasq (linux) or windows 2012 dhcp we can create a custom filter to only send the tc3.efi kernel name to the booting efi device when a MAC is detected. That part is a bit more complex but it is possible and we can make it all automatic, but the key is finding an iPXE efi kernel that only sees the broadcom network adapter.
@cpast if you built tg3.efi, you can build intel, realtek, etc… just by choosing to do so when building.
@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?
@cpast You tried both? What about specifying intel or realtek? I don’t know what type apple uses.
@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.
@cpast So using snponly.efi wasn’t expected to work, just was hoping to see if it would try the wifi address.
If exit type isn’t working (and obviously sanboot isn’t) then I think the only option left for mac’s is to use the rEFInd exit type (though you may need to edit the config for yourself as I don’t know it’s inner workings yet.)
@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).
@cpast Change the registered host’s “exit” type. You can do this globally too.
Exit doesn’t know how to release properly and sanboot is the “default” but sanboot uses the “legacy” machinisms. YOu can try setting exit for efi exit type though.
@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?
Wayne Workman last edited by
@cpast THis shouldn’t even be possible. Why? There are 0 wireless drivers built in with the ipxe binaries that I’m providing. At the least, we don’t have the wireless capabilities even enabled though either.
Maybe if you try snponly.efi?
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?
@cpast Depends on how you configure the client. You’d need to tell the client to have PXE boot as primary boot.
Otherwise, you can simply go in the boot menu during boot and it should be one of the boot options.
Very few of the menu options work properly on Mac though, I find. I’ve been able to capture and deploy but that’s about the extend.
@cpast Possibly net0 is not ready on first boot? Do you have spanning tree protocol configured on your (managed) switch? Could you try setting “port fast” for that switch port?
@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).
Linking another post here as it seems related (but unfortunately unsolved): https://forums.fogproject.org/topic/7818/could-not-open-net1
Still I am wondering why it is saying “net1” as iPXE usually starts counting the NICs from zero.