New to imaging Macs through FOG
-
@CoolbluHat as Sebastian Roth said, you need to bless your clients (SIP must be disabled) or you can create a bootable usb
- Format USB as FAT32
- create folders in USB drive EFI\BOOT
- Copy ipxe.efi in your tftpboot directory in your FOG server to EFI\boot and rename this file to bootx64.efi (try different *.efi files if this one does not work)
Prepare to upload image:
Like you do for Windows machines, create a standard image, add a new host for this Mac
create a new image in Image Management. Select Apple Mac OS, Multiple Partition Image - Single Disk
Schedule an image capture
Boot up this Mac using USB (hold down alt and select EFI).You might need to grow the disk if you download the image to a bigger drive.
This method does not work for all Macs at least does not work on my MacBook Air early 2014 but worked on MacBook Air late 2015 using thunderbolt to ethernet with ssd formatted in 4K cluster size and most of the models with a built-in Ethernet card.
-
@TaTa @Sebastian-Roth Thank you for this help so far. After I attempted the steps above, I receive an error on the laptop:
iPXE 1.0.0+ (356f) – Open Source Network Boot Firmware – http://ipxe.org
Features: DNS FTP HTTP HTTPS iSCSI NFS TFTP SRP VLAN AoE EFI Menu
Configuring (net0 aa:bb:cc:dd:ee:ff)…ok
Received DHCP answer on interface net0
Please enter tftp server: xx.xx.xx.xx (I entered the ip address of our fog server)
tftp://xx.xx.xx.xx/default.ipxe…Connection timed out (http://ipxe.org/4c126092)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 secondsI’ve also blessed the laptop before attempting to boot to the EFI USB device, after running csrutil on Recovery-boot startup. Both commands completed successfully when I ran them; so are my next step(s) to try the other *.efi files in the tftpboot directory of the server and re-name them to bootx64.efi?
Thank you all in advance for this help.
-
@CoolbluHat Wohooo, you are on the right track I reckon! So far to me this looks like you don’t have that special Mac OS X issue where a firmware update broke the network card. At least you seem to get an IP address via DHCP which is definitely a first great step. To get one step further you need to add option 66 (next server) to your Windows DHCP server because iPXE is using that information to find your FOG server and go ahead. Check out this wiki article on how to configure your Windows DHCP server.
Don’t get confused by it saying that you should set option 67 (boot file name). By blessing your client you kind of made the first hurdle without having to provide option 67. I think you could even go without the vendor class policy if you only PXE boot those Mac OS X clients. But I guess it’s definitely worth doing it right from scratch as described in the wiki.
The
tftp://xx.xx.xx.xx/default.ipxe…Connection timed outis strange. Is your FOG server on a different subnet? Or maybe you just had a typo in the IP?Please let us know if you need more information or assistance. As well it would be great to hear if you got it working.
-
@Sebastian-Roth Thank you for the tips and tricks. So I’ve gotten past the TFTP failures, it’s finding the server now. To answer your question, yes they are on two different subnets. I tried an ethernet to thunderbolt network connection, but the boot up doesn’t try to set up a DHCP address through that network method. It forces me to use a wireless connection, which I’ve set up to be available and connected when I start the boot-up process on the laptop. What I did to resolve the TFTP issue was use the secondary NIC on our Ubuntu server, set the static ip address to match that of the subnet that the laptop is connecting to via WiFi. But now I’m running into an http Timeout, it’s pointing to the primary NIC that I created the server on. Is it possible for FOG to utilize two Ip addresses for web management? I only see the ability to change it to one IP address, but if it can manage multiple addresses on it’s respective NICs, I might just be able to get this Mac fully connected to FOG.
Many thanks again in advance.
-
@CoolbluHat Good to hear that you got a little further. I might ask you to stop there and think it all over. Imaging the laptops over wireless? Do you really want this? Plus all the mess with two interfaces in the FOG server which you already see is causing a headache.
In case you really wanna go the wireless way I’d recommend setting up your FOG server to only have one leg - in that wireless network segment. Up till now we’ve never had anyone trying to image over wireless and we don’t have the wireless drivers included in the FOS kernel. So you will hit a wall there too.I tried an ethernet to thunderbolt network connection, but the boot up doesn’t try to set up a DHCP address through that network method.
What going wrong when you try PXE booting on the thunderbolt NIC? Please describe what’s happening and possibly also post a picture of the error if you run into one. Seems to work: https://vimeo.com/95132633
-
After doing extensive testing with attempting to PXE boot Macs to a fog server, I created a solution which has worked for me so far (I had to make changes to the iPXE.iso found from iPXE website). Ultimately I was able to image over 30 lab machines running dual boot Mac OS and Windows 10
I had to create a bootable iPXE USB in order to get the Mac hardware to PXE boot to my server
Note that your mac must either have an Ethernet port built in, or you must use an Apple thunderbolt to Ethernet adapter
All the necessary files and a detailed READ ME can be found with this link
https://drive.google.com/file/d/1PDxx8qmN9UGKXMaUhy0xy3K4bvPh48KE/view?usp=sharingHappy deploying
-
@drewklein22 Thanks for you post and the information you provided. You are right, there are a couple different ways to boot up clients and image them. Booting Macs via ISO/USB is one of them.
-
@drewklein22 said in New to imaging Macs through FOG:
(I had to make changes to the iPXE.iso found from iPXE website)
Thank you for posting your solution. Can you explain a bit more about what you needed to change to the ipxe.iso file to make it work in your environment?
The second part (depending on what you changed) do you have the time to test an alternate method? I understand what you have is working for you, but if there is an easier process people can follow that don’t have your skills of building the iso image I would like to find it.
-
@george1421 Have you followed the link I attached and tried the process of creating the USB? I made numerous attempts at creating a USB that allowed Macs to PXE boot. But here’s what I ended up having to change on the iPXE.iso taken from the iPXE website.
First I was able to open the iPXE.iso with winrar, then I logged onto my fog server and went to the /tftpboot folder. I then copied the IPXE.krn, and replaced the existing one on the iso. For whatever reason, the fog’s /tftpboot folder had a newer version of the file which allowed my devices to correctly boot.
The link I attached has the iso with the changes I made attached as well as the steps for creating a bootable usb for it.
-
@drewklein22 I just gave your USB method a shot and it seems to be working which is fantastic!
Couple of questions however:
-
Are you having to go non resizable with your images to capture the image? I’m trying this right now and the Mac HDD is 500gb which from the looks of things, means it’s going to back up 500gb worth of data even though it’s only using say 30-50gb. Is this an issue for you or do you have a work around? When I tried to select single disk resizable I got 'invalid operating system id: Apple Mac OS (8) (validResizeOS).
-
I did test with a Apple ethernet to USB along with a Microsoft and neither of those worked as you said, only ethernet to thunderbolt. Have you tried this with the USB - C devices? I plan on trying the next time I get a spare one for a period but it will be a bit of a hurdle if it’s only working via thunderbolt.
Anyways, I’ll likely report back on the second one, curious to hear about your results with the top one though (or anyone else).
-
-
Just tested and it didn’t take up 500GB of data as such although it still wants to push down 500gb as such so it is a little more time consuming than usual to back up so interested to hear how you’re making images of your machines.
Edit: Not really working though, it seems to reach about 10% before it has a “WRITE FPDMA QUEUED” type issue followed by saying “rejecting I/O to offline device”.
Will keep playing though.
-
@dylan123 let me know how you figure this out - i actually did this yesterday as well and was able to capture a 37gb live usable image and transfer it over no issues. it was 500gb to 500gb HDD’s, but still finished around 7 minutes.
no idea how to shrink the partition yet but i’m sure its not too difficult i’m not a mac guru tho. also it sucks for higher versions (10.12 +) because of firmware changes. -
@p4cm4n Out of curiosity, once it finished transferring the 37gb and had the other ~473gb to go, did it just go about it’s business or did it stop? Mine seems to bug out and go to a black screen with white text with the rejecting I/O to offline device kind of thing. That being said, when I actually boot the laptop it works with the image it took down.
-
@dylan123 said in New to imaging Macs through FOG:
WRITE FPDMA QUEUED
Have you searched the web for that error yet? When I do so I see people talking about faulty connections between drive and mainboard quite often. Possibly it’s in a stage where Mac OS X kernel is still happy with it but the Linux kernel is not. What kind of Mac do you have? Possibly you can open it and check the cable connection and better even replace the SATA cable with a new one?!
EDIT: Reading a bit more I found Mac specific answers:
https://forums.fedoraforum.org/showthread.php?295319-Macbook-pro-freezes-with-WRITE-FPDMA-QUEUED-failedTo try out that you can schedule a debug task (as you normally create a task in the web UI but just before you hit the button check the box “Schedule as debug task”). Let the client boot up and hit ENTER twice to get to the shell. Then run the commands:
echo 1 > /sys/block/sda/device/queue_depth fogStep through and see if it deploys the full way this time.
If that doesn’t work there is a kernel parameter you can set in the client’s host settings:
libata.force=1:noncq(reference) -
@dylan123 it completes, and goes through its normal completion process. it looks exactly as any other machine i’ve imaged actually, boots up the same, except for throwing a few more ACPI errors after booting the kernel.
it brings up the same imaging window, 500gb HDD, 37GB in use, finishes as it should, updates database, restarts. -
@Sebastian-Roth Might be right about the computer as it has been faulty with a lot of crashing. I tried to open it up however once I took the back off (~2015 MacBook Pro) I didn’t really have access to anything without taking the keyboard off which I didn’t want to attempt to do.
I tried on an alternative Mac however I was unable to get it to show the USB on boot - tried a hard restart, ram clear, fully reformatted etc but couldn’t get it to play.
Will try another mac the next time I get my hands on one.
-
@dylan123 My apologies for just now replying. I don’t check this very often! I have to go with raw capture because the organization I work at has bootcamped macs (very frustrating I know), and the only way to keep both partitions is to capture the disk as a whole. This is extremely limiting for fog, but it’s better than having to reinstall mac os and windows on each mac we have. Another issue I’ve come along is that Mac OS High Sierra and above forces APFS for ssds. Which I’m pretty certain is an issue for Fog. As far as the usb-c dongle, I’d bet that it would work as well if it’s made by Apple.
-
If you are managing Macs I would highly recommend moving away from Imaging as that is NOT the workflow going forward. Invest in DEP+MDM and netinstalls / internet recovery + Caching.
