@whereiswaldo7 FOG version 1.5.1 has been released, and it includes the official release for 0.11.16 of the client.

Thanks again for reporting and testing!

@Cris13 From the things you posted it seems you have the exact same issue than others using the same NIC model. The issue is specific to that NIC. I have spend hours of work over weeks to look into this and digging through the iPXE and Linux kernel code - source code of both drivers are very similar to some extend but only the iPXE code seems to have the issue.
I was unable to work on this in the last weeks but I still hope we can somehow figure this out and make it work again. It’s just a matter of finding the right needle in the hay stack (more than 8500 lines of C code). Are you keen to get into this. I can give you instructions on how to compile and debug iPXE.

Just for reference:
http://forum.ipxe.org/showthread.php?tid=8296
https://forums.fogproject.org/topic/10261/macos-update-broke-ipxe
https://forums.fogproject.org/topic/10289/boot-from-usb-problem
https://forums.fogproject.org/topic/10043/netboot-problem-new-mac
https://forums.fogproject.org/topic/9269/imac-27-ipxe-boot
https://forums.fogproject.org/topic/9278/fog-1-3-0-pb-with-mac-netboot
https://forums.fogproject.org/topic/10810/multicast-error-with-fog-usb-new-imac
https://forums.fogproject.org/topic/10879/ipxe-boot-with-imac-late-2013

And again… 😄

I confirm it is solved.

Notice:
timeout is -1, so it boot the first os if no esc key is pressed.

I’ve been working on the on and off over the last weeks. This is what I just sent to iPXE dev Michael Brown:

Tried looking at the NIC registers as suggested by NiKiZe in the forums a while back. Added ethtool code to dump registers to iPXE but from my tests it looks like many registers are different on every reboot and I have no idea which registers mean what. For now I don’t think this is getting us anywhere. But I am open to suggestions.
Digging through the tg3*.c code I figured that there might be some auto negotiation issue on the iMac model I have. Curtis did not seem to have that and got that sort of fixed. Now I am seeing the same thing as Curtis, interface comes up and it tries to send packets to wire but fails so. As far as I know Curtis has been onto this together with you on a IRC chat.
On the other lane I have tested the Linux code a fair bit. Tested 4.13.4, early 3.9 and the very first commit that added 57766 NIC support to the Linux kernel. I did test those early versions as I hoped to clarify if the later added binary firmware blob is playing a role or if any commit in the kernel code did fix an issue with Macs. Turns out it’s not from my tests. They all worked like a charm on the iMac that cannot send packets within iPXE.

Hope we’ll find some time to give me some hints on where to dig next.

@Seb-B As well if you have ideas and suggestions on how to diff the tg3 code of iPXE and the Linux kernel to figure out what’s up. I have started to but there seem to be too many minor differences making it really hard to diff. Though I have the feeling that we should be able to solve this soon as Linux kernel is working great.

Hi,
try setting this parameter in /var/www/html/fog/service/ipxe/refind.conf:

# Delay for the specified number of seconds before scanning disks. # This can help some users who find that some of their disks # (usually external or optical discs) aren't detected initially, # but are detected after pressing Esc. # The default is 0. # scan_delay 5

and, if you need, this:

# Timeout in seconds for the main menu screen. Setting the timeout to 0 # disables automatic booting (i.e., no timeout). Setting it to -1 causes # an immediate boot to the default OS *UNLESS* a keypress is in the buffer # when rEFInd launches, in which case that keypress is interpreted as a # shortcut key. If no matching shortcut is found, rEFInd displays its # menu with no timeout. # timeout 5

@rboan bump

Added to the list in the other thread so we don’t loose track of this here.

@hancocza Most probably your windows PCs have the CA certificate (imported) that was used to sign the other certificates. To be more concrete - the .NET keystore has the right CA cert to verify the other certs. But probably the Mac OS X mono keystore doesn’t!

Edit: Which version of mono did you install and which version of Mac OS X do you use?

@sebastian-roth OK now that we’ve identified that iPXE is having an issue init’ing the tigon driver, how about trying plan “B” booting directly info FOG? Its not the cleanest solution but it might allow the OP the ability to image these computers???

@SlimJim Maybe Apple’s “System Integrity Protection” broke this? Try the other methods of PXE booting described here: https://wiki.fogproject.org/wiki/index.php/FOG_on_a_MAC

@sebastian-roth Just saw your message ! I will try next week 😉

I also sent a pull request the the official partclone developer so hopefully this will be fixed as well.

EDIT: Done… https://github.com/Thomas-Tsai/partclone/commit/c0629e1a8e73dbdd165d7ac102b8bc9f6f44dac7

Just cross-linking this here: https://forums.fogproject.org/topic/10615/ipxe-booting-possibly-broken-on-os-x-sierra-update

Just cross-linking this here: https://forums.fogproject.org/topic/10615/ipxe-booting-possibly-broken-on-os-x-sierra-update

Just cross-linking this here: https://forums.fogproject.org/topic/10615/ipxe-booting-possibly-broken-on-os-x-sierra-update

@slimjim Our issue was solved with this

@george1421

Yes Solved!

@Sebastian-Roth

Yes, sorry for wasting time!

@msnyder Maybe this will be of interest to you? https://forums.fogproject.org/topic/7261/mac-os-x-resizeable-disk-support