MacBook(s) and FOG:

BardWood

Running latest FOG

Through my research I see this is an unresolved issue (perhaps due to firmware) but the short version is that I now work at a place which is primarily a Mac\Linux shop with some W10. The W10 + Linux machines can PXE and image without issue. I’m using the ISC-DHCP server which comes tied to FOG as an option on a single broadcast domain. FOG + clients are the only devices on this network. I can press ‘Alt’ on a macbook 11,4 and it sees ‘IPXE.ORG’ as a boot option. Attempting to boot off of this causes the screen to go black (brief pause) then it boots High Sierra. If I try the ‘n’ boot. I see the globe for a (long pause), then black screen, then boots to MacOS.

I’ve tried the extended DHCP config found here:https://forums.fogproject.org/topic/5790/boot-pxe-macbook-imac/16

But I’m not sure what to try next. I gather that this may be out of the hands of the FOG & IPXE dev’s hands. But I’m hoping someone has it working. I’ve really only tried this MacBook and a newer model with the Touch Strip. Same results on both.

Wayne Workman

@bardwood Generally we want to know exact FOG versions because you saying ‘latest FOG’ does not help the next person who reads your thread. Please provide an exact version.

FOG has had an isc-dhcp configuration that supports Macs for a year or two now. You may need to play around with the boot file to find one that works. All of the available boot files are in /tftpboot. You will find this article of interest: https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC
Also asking @Sebastian-Roth to take a look at this thread when he has some time.

BardWood

@wayne-workman

Using FOG 1.5.0

The canned ISC-DHCP conf didn’t boot this macbook. I also tried the alt config I referenced in my first post. If I ‘ALT’ boot, I see IPXE.ORG as a boot option but it doesn’t boot, nor does ‘N’ boot. Via TCPDUMP, I do see the Mac getting an IP assigned but it doesn’t do anything after that except boot the OS.

I downloaded and compiled the IPXE release from IPXE.ORG and attempted to boot from a USB thumb drive. I can get an EFI shell this way but the nic doesn’t get an IP or more specifically, the nic drops it’s IP once it loads the IPXE\EFI shell. If I assign a static IP inside the EFI shell the nic will come up but won’t talk to the DHCP\FOG server. That may be a simple misconfig of our subnet mask (/21 not /24).

I’m willing and able to do any required troubleshooting but am requesting guidance. This is my actual day job so I have full-time hours to devote to this and many misc. models of Apple computers.

What should I try next?

Sebastian Roth

@BardWood Sorry for the late reply. I have been pretty busy in the last days and weeks. Have you had a look at the wiki article yet? See any differences between your config and the one shown in the wiki? If you can’t make it work and want us to help you need to provide more information. Please post your full isc-dhcp config here. As well you might want to look into capturing a network packet dump to see what exactly is being communicated between server and client on boot up. Run this in your FOG server just before starting the MacBook (holding down ‘n’): tcpdump -w bootup.pcap port 67 or port 68 or port 69 or port 4011 (this is only DHCP and tftp traffic)… Upload the bootup.pcap file to a cloud drive and send me the link in a private message.

BardWood

@bardwood

I have went through several Wiki articles but before I take up your time I will double-check that link just as a verify step. After that, I will gather the requested info in your post.

Sebastian Roth

@BardWood Taking up my time is not an issue if you provide valuable information to work with! From my experience a packet dump (tcpdump) is helping a lot in seeing what exactly is going wrong.

BardWood

[root@sffog dhcp]# cat dhcpd.conf
# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 10.0.0.0 netmask 255.255.255.0{
    option subnet-mask 255.255.255.0;
    authoritative;
    range dynamic-bootp 10.0.0.10 10.0.0.254;
    default-lease-time 21600;
    max-lease-time 43200;
    #option routers 0.0.0.0
    option domain-name-servers 127.0.0.1;
    next-server 10.0.0.2;
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
    class "SURFACE-PRO-4" {
        match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
        filename "ipxe7156.efi";
    }
    class "Apple-Intel-Netboot" {
        match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
        option dhcp-parameter-request-list 1,3,17,43,60;
        if (option dhcp-message-type = 8) {
            option vendor-class-identifier "AAPLBSDPC";
            if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
                # BSDP List
                option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47;
                filename "ipxe.efi";
            }
        }
    }
}
[root@sffog dhcp]#```

BardWood

@bardwood

It’s mostly the stock FOG-supplied ISC conf file that comes with FOG’s installer but I’ve added the ‘authoritative’ directive. Working on the other piece you asked for re:tcpdump

BardWood

0_1525288727046_bootup.pcap

pcap file uploaded here. There’s nothing identifiable in here (re:security) and it’s small. Dropbox wanted me to enter your email address for sharing so I figured this was a better option.

Sebastian Roth

@BardWood Thanks for the packet dump. Though I don’t have any old dump at hand I am pretty sure there is something missing in your case. Not saying that you missed out - I just don’t have a clue why that is.
See the DHCP config you posted. That last class Apple-Intel-Netboot is defined to only match DHCP discover/request packets if they have a vendor class set to “AAPLBSDPC/i386” - which should be the case for all Apple Macs as far as I have seen - check on wikipedia as well.

But looking at the packet dump I don’t see a vendor client option being sent from the client. To me it seems like the Macbook is not doing a proper BOOTP discovery. Take a look at the in depth description here: https://static.afp548.com/mactips/bootpd.html

What kind of Macbook is this exactly? Model number? Serial? Is it brand new?

BardWood

@sebastian-roth said in MacBook(s) and FOG::

https://static.afp548.com/mactips/bootpd.html

No, it’s not that new. MBP 11,4. Whatever the cause of BOOTP not doing proper discovery, it’s unlikely to be the hardware because I’ve tried multiple MBPs and they all behave the same way. Perhaps I’m missing some options on the DHCP config or perhaps the switch is misconfigured (possible?). The managed switch is ‘owned’ by several groups internally which means there’s no owner acting as a goalie for other groups. I’ll just plug in a workgroup switch with only the FOG server and a client if you think this would be a useful test.

I’ve seen that afp548.com link when I was troubleshooting last week and generally have a good overview of how BSDP functions but am still rather novice when it comes down to nuts and bolts of BSDP.

First question, is my ISC-DHCP config sane? I only made a few changes from the FOG installer’s version of the config but the only reason I made any changes was because it wasn’t working (but works fine on Windows, definitely seems BSDP\BOOTP related.

I’ll report back with my results from my workgroup switch test.

BardWood

@Sebastian-Roth

My isolated switch test made no difference. If it matters, all of our MacbookPROs are running ‘High Sierra’. This has caused them to also be incompatible with existing Deploy Studio images. Don’t know much about High Sierra but am reading that it introduces a new filesystem called APFS in lieu of HFS+. I’m not sure how much that matters for the EFI\pre-boot image environment but am also unsure what else to try.

BardWood

@Sebastian-Roth

Doing more research, I see that all major paid solutions are also struggling with High Sierra. The JAMF forums have many related threads, same with Deploy Studio. Apple’s official guidance is that they don’t want you to use monolithic imaging solutions. They want you to script deploys ala SCCM. High Sierra also included a firmware update which may explain the odd BSDP behavior.

Although FOG worked great with pre-HS Macs and I have used FOG with Sierra, has anyone from the FOG dev team actually gotten it to work with HS? If so, consider yourselves market leaders since it seems no one else has been able to consistently do this. There’s posts I’ve seen on the JAMF forums where a combo of AutoDMG, scripts, and an image repo were able to image an HS Mac but it doesn’t seem to work every time.

Also, APFS requires new images to be created regardless of imaging software used. An additional annoyance is that any Mac with an SSD is automatically converted to APFS upon HS boot.

Sebastian Roth

@BardWood Sorry for my late reply. Haven’t had much time lately. You are right, there are some unresolved issues with High Sierra but I know people having had different problems than you have reported. Colleagues from my old working place asked me about issues with exit type (boot from disk if there is no task scheduled). But I am unsure about the current state of affairs with that. What I know is that they were able to PXE boot and clone High Sierra Macminis!

To circumnavigate the whole DHCP/BOOTP/NetBoot hell you can try “blessing” your installation to load the iPXE binary straight from the TFTP server without asking for information on bootup. Take a look here: https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC#Using_bless (haven’t done this on High Sierra myself, so might work or might not)

About the new APFS. People are working on this. Here you can find some details on the FS itself: https://blog.cugu.eu/post/apfs/ and here is a project to add a FUSE driver for APFS: https://github.com/sgan81/apfs-fuse (though I have not tried it myself yet)

PS: I looked at the PCAP several more times and just can’t make sense of why the vendor information is completely missing from the client request…

BardWood

@Sebastian-Roth @Wayne-Workman

Guys, any progress here? I’m really chalking this up to High Sierra but would be good if you guys could verify that FOG doesn’t work with High Sierra on MacBook PRO and APFS. If it does work for you and not me, I would be thrilled to troubleshoot and resolve as this would mean I don’t have to switch to a different process\package.

BardWood

@bardwood @Sebastian-Roth Just saw this… Disregard prior message.

BardWood

@sebastian-roth 0_1525808908051_bootup-no-port-filter.pcap

This is a capture with no port filter. The client and FOG server are the only 2 devices on this private subnet. It does have other communications, mainly with FOG’s ‘bandwidth.php’ and is a much bigger file in general.

Sebastian Roth

@BardWood Tried my suggestion on blessing the client? I’ll look into the PCAP now.

EDIT: Sorry but there is no news in that packet dump. Still the client does not send DHCP option 60 (vendor class identification) and therefore cannot be properly seen as Mac client by the DHCP server. Sure you could remove the match clause from the DHCP config but it could possibly screw up PXE booting for other clients doing that. As well I kind of doubt that it will work as the client’s behavior is just weird from my point of view.

BardWood

@sebastian-roth 0_1525813248279_bootup-no-ipv6-no-filter.pcap

I disabled IPv6 on the server and re-ran a full cap\no port filters

Sebastian Roth

@BardWood Sorry, no change there. I don’t see any vendor class identification in the PCAP. I have searched the web up and down to see if others report similar issues but couldn’t find anything yet.

I really wonder if there is some kind of intermediate switch/router/firewall modifying the DHCP packets?!? Have you had FOG server and Mac client on the same switch yet?

MacBook(s) and FOG:

259

11.6k

17.1k

154.6k