Imac 27" ipxe boot

[Seb B]

@george1421

George,

I ran this command on the Fog server while running a dhcp net0 on the client and got no result

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

With a 24ko wireshark file with no visible data.
I also tried with another efi file with no difference in the tcpdump results.

I can’t try on the dhcp sever right now as it is in use for something else. I’ll give it a shot tomorrow morning.

Thanks again to both of you.

[george1421]

@Seb-B Now I don’t know OSX so this instructions may be a bit off.

From a command prompt is there a lspci command? If so what is the output (from within OSX) of lspci -nn|grep ernet What is the output. I’m looking for hex numbers inside square brackets i.e. [8086:12df] (totally made up number). I think we are almost at a point where we need to contact the iPXE group to see if their kernel supports this hardware. I can find no references to iPXE not working with Late 2015 Macs (but its also possible I’m not searching for the right thing too).

[Seb B]

@george1421

Hi George,

the venID:devID of the ethernet card is 14e4:1686 (there’s no lspci command on osx but I had if already written down somewhere).

I’m still waiting for the dhcp server to be available for the tcpdump but I reckon you could be right about the ipxe kernell not supporting this device yet …

[Seb B]

So I was able to launch tcpdump on the dhcp server while running a dhcp net0 command on the ipxe kernell command prompt.

There is no result which can be linked with our host (some dhcp requests but from another subnet with diferent MAC addresses).

[Sebastian Roth]

@Seb-B We seem to do rounds and rounds without getting a step forward. From what I remember net0 should be the wireless interface, right?!?

14e4:1686 is supposed to be a Broadcom netXtreme BCM57766 ethernet card. I was able to PXE boot Macminis having the exact same ethernet card, see here: https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC#Working_devices

[Sebastian Roth]

As we seem to have another iMac user with PXE issue I want to ask you to give us more information on the exact model of your iMac you have Please have a look on this website and tell us the exact model you have: http://www.everymac.com/systems/apple/imac/index-imac.html

To identify your iMac you can look up important system information via Apple Menu -> About This Mac -> System Report. And while you have this window open may I ask you to also take a screenshot of the Hardware -> Ethernet Cards view (https://www.tonymacx86.com/attachments/fake-screenshot-png.124954/) and post it here.

[Seb B]

@Sebastian-Roth

sure thing. It’s this one.

As for the screenshot, here it is (it’s in french, I can switch the system in english if you need)
![alt text](

Thanks again

[Sebastian Roth]

@Seb-B Sorry for not getting back to you in a while. Have been sick and then working a lot.

Thanks for the information and great that you posted in the iPXE forums as well!!

Have you ever used tcpdump or wireshark? Would you be able to hook up your iMac using a old network hub and get a packet dump of the whole bootup process? I’d love to see if snp.efi actually sends any DHCP request or not.

Other than that I am having a look at the source code as well. Maybe I’ll find something.

[Seb B]

@Sebastian-Roth

Hi.

We did try a tcpdump both on the fog server and the dhcp
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411
and got this answer on both :

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel 

It is not going to be easy to have a readable unfiltered answer as the fog server is in use with several dozens of fog clients and the dhcp server is not only a dhcp a dhcp server but has some other roles as well.

I’m sot sure I understand where you are going with the network hub thingy, could you give me more details as to what you want me to do please?

[george1421]

@Seb-B The output of the tcpdump program is a bit unexpected.

Is the fog server and pxe booting computer(s) in the same broadcast domain (subnet, vlan)? If so the FOG server should see these dhcp requests as long as the firewall has been shut off on the FOG server.

DHCP communications are done via broadcasting, even initially if a dhcp relay service is used. The FOG server should see this communication.

[Seb B]

@george1421

I know it’s not what you’d expect, though it’s the same result as the last time I tried.
The test iMac and both the fog server and dhcp server are in the same server (normally a server dedicated vlan).
It acts as though, once the the ipxe file is downloaded and “launched”, the network interface is unable to send anything out.

As I said, I think it would be tricky to launch an unfiltered tcpdump request on the server vlan and get comprehensible results.

I’m willing to give it a try but I won’t be able to understand the results…

Thanks again for your help.

[Sebastian Roth]

@Seb-B The tcpdump stuff was just an idea of mine to see if the Mac sends out any packet at all. From what we see so far it looks like it does not!

Did you see the new message in the iPXE forums? Would be great if you could try things as suggested there.

Sorry for not being of much help here at the moment. I am just sitting between the chairs and trying to “negotiate”…

[george1421]

@Seb-B said in Imac 27" ipxe boot:

@george1421

I know it’s not what you’d expect, though it’s the same result as the last time I tried.

I don’t know how to say this gently. So I’ll just put it out there…

I suspect your testing results. IF the target computer is getting the iPXE kernel they DHCP requests must be sent. The FOG server and tcpdump should see them. Even if your network is somewhat busy the FOG server should see the dhcp inform announcements from other dhcp clients on the same subnet. Not seeing anything is not a typical response (Mac or Windows).

My intuition is telling me one of 2 things.

1. Your fog server and pxe booting target computer are not on the same IP subnet.
2. Your FOG server still has a firewall enabled (either iptables or firewalld), which is blocking dhcp messages. I find this unlikely since you said the FOG server is also your dhcp server.

Please understand I don’t know your networking situation so I can only guess what I think you’re saying and seeing. Either way you should see some dhcp traffic by tcpdump or by using wireshark on an independent windows (or Mac) box that is connected to the same IP subnet as the fog server and pxe booting client.

[Seb B]

Hi,

I’m going to try and clarify the test setup because I feel we don’t really understand each other here.

• We have on the same vlan which we usually use as the server vlan (172.16.0.xxx/24) :

  • an ISC dhcp server
  • a FOG server
  • The problematic iMac

• The iMac is plugged on a non manageable switch

• there is no firewall enabled on any of these

• Other hosts work just fine with fog and/or the dhcp

Now for the TCPDump request itself :

• We wait for a quieter part of the day (around 5 pm usually) so as not to be “polluted” by other dhcp requests

• we boot the iMac while pressing “alt” which gives us the choice of the boot device

• we choose to boot on the ipxe kernel

• Once on the kernell we get an error message which varies according to the efi file used (it’s either “link status: down” or “no configuration method succeeded”) and get prompted to press a key to get to the ipxe shell

• At this point we launch the tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411 command on the dhcp or the fog server

• back on the iMac we launch a dhcp command from the ipxe shell

• when this dhcp command is over (and has failed) we stop the TCPDump.

At this point, once again, neither the dhcp nor the fog server receive requests. However, if we launch a ipconfig /release and /renew from a windows box, the dhcp does get requests.

I hope it makes all this more understandable. We’re trying to do what the post from the ipxe forums asked us to do as well but we’ve had some difficulties with time management so far.

Once again, thanks to all you who try to help us there.
Have a nice day.

[Sebastian Roth]

@Seb-B Thanks for clarifying. As well great that you tried the suggested debugging steps in the iPXE forums. There is a new suggestion on using an embedded iPXE script. Hopefully we’ll see more useful information this way.

[Sebastian Roth]

@Seb-B Ok, I got some new advice from the iPXE devs. Debugging the actual driver issue won’t be easy and will therefore take too many round trips of “try this binary and report again”.

Nevertheless we ought to try out using the SNP binary (debug enabled - DEBUG=snp:3,nii:3 to start with). So find 01_snp.efi here. Just give it a try and post pictures or video. Make sure when you take those to place the camera or phone on a stack of books in front of the screen so we have a good picture.

[Sebastian Roth]

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

[Seb B]

@sebastian-roth

Hi sorry, I couldn’t answer any sooner.
“Nevertheless we ought to try out using the SNP binary (debug enabled - DEBUG=snp:3,nii:3 to start with). So find 01_snp.efi here. Just give it a try and post pictures or video. Make sure when you take those to place the camera or phone on a stack of books in front of the screen so we have a good picture.”

Here you go, not much to say from my side but here goes: video

Thanks!