MacBook(s) and FOG:
-
@sebastian-roth said in MacBook(s) and FOG::
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.
-
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.
-
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.
-
@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…
-
@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 @Sebastian-Roth Just saw this… Disregard prior message.
-
@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.
-
@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
matchclause 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. -
@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
-
@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?