r4930 - Fedora 21, Unable to "Ignore MAC for imaging"
I click the checkbox on that second MAC below, hit update, it says updated, but the checkbox becomes unchecked.
Has this been fixed in the latest svn revision? Because I’m having this problem as well (2 NICS and a forever sending discover loop).
I think what you need to do is see if you can disable pxe boot for the individual NIC in bios.
The ignore Mac for imaging does not remove the ip definitions for a specific interface, at least not yet. All nics that are valid and have a link up indicator will attempt to receive an IP. It should fail out at some point though. What ignore for imaging does is make sure that nic does not get used as the method for checkin and progress.
I believe I have the same problem described here: https://forums.fogproject.org/topic/5159/2-nic-in-host-problem-loops-at-sending-discovery
I’m not sure I can call this fixed… it’s probably an edge case and quite silly but…
The two NICs in this machine - they are on two different networks. This machine literally serves as a router in my house.
One interface gets DHCP, the other gives DHCP (when the server is operational).
It seems like even though I enable the “Ignore MAC”, it still tries to startup that NIC when it starts the imaging process. This happens when the other NIC is connected to a live switch or access point. When I disconnect the line from the second NIC, FOG briefly tries to start the interface and then moves on (detecting that it’s unplugged).
See the attached screen shot:
I suppose what I’m asking for is… doing more than simply checking the MAC of the device that is network booting for a matching MAC, but actually ignoring the interface for the “Ignored MAC”, and not attempting to start that interface. Because right now, while I can image (and it took me a while to figure it out), it’s not hands free. and that’s kinda a large selling point of FOG is the hands free aspect.
If even the “Sending Discover” could be limited to… idk… 5, that would solve this problem. and I think that would be a simple fix. The more complex but clean solution is obviously to never even try to start the interface of the “ignored MAC”.
This should now be fixed. Thanks for reporting.