New to imaging Macs through FOG
-
@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.
