@george1421 It looks like the apple T2 chips encrypt the drives at rest, but only 2 or 3 of the 5 partitions for the apfs volume. not sure if anyone knew of a way to bypass this from happening. I am able to boot the mac after transferring but looks like it loses all user information and can not login.

@saftkartoffel @kudlab While I can’t test USB booting here in my VM setup quickly I would ask you guys to try out using the last menu point from your USB key GRUB menu 8. FOG iPXE Jumpstart EFI after you’ve scheduled a multicast task.

I don’t think this is a FOG problem. FOG is moving the files from the source computer to the target computer and the target computer boots OK. The problem you see is inside OSX itself. FOG doesn’t step inside the target OS. The only way it can do this is with the FOG Client and that is only to change the workstation name or deploy applications.

Understand the next thing I say is a guess because I don’t know. Its possible that Microsoft has connected user management or maybe password management to the T2 chip. Its possible with a different T2 chip it also protects/encrypts the password file. It may also be possible that changing the computer name does something unexpected with the user accounts. I don’t use Apple computers so I don’t have any experience with them.

From a debugging standpoint, we know that FOS Linux can access the hard drive of the Apple computer (because it can send a computer image). You may be able to use debug mode to access files on the target computer. I don’t know what you can do to reset the password externally but if you need to do things on a file level you can do this with FOS Linux. If you find a solution in debug mode then possibly you can write a FOG Post Install Script to apply those same settings during image deployment.

@zyzhang That is good news. It took us a while to get success and joy but now it sounds like its working as it should.

@george1421 好的，非常感谢

You can also redown load it from the github site and then run the files command on that file right away. You should also see what I discussed in my last post.

捕获镜像后会出现这种报错，捕获的镜像大小为28G大小，
D-Chat20200630161724.png

@Norm said in Help with Mac imaging:

When I upgraded to Fog 1.5.8 it broke.

Can you please give us some more details on where it breaks. Please take a picture of the screen and post here.

Bonjours,
Mon problème est résolu, un grand merci à @george1421 pour son aide.

@Daniel-Miller

I am at this specific point with regards to attempting to download the cert.

@GaboGrobier We just recently hat another question on Mac OS X in the forums: https://forums.fogproject.org/topic/13795/server-fog-configuration

As well use the forum search. Feel free to ask more specific questions here.

@rathan While you can. You shouldn’t. Apple has made imaging a dead workflow through a number of things, the most important being the T2 chip preventing netboot/external boot. MDM and DEP is the appropriate way to now provision MacOS devices. Erasing would be done via CMD+R in recovery or by pushing an erase and install from your MDM.

@rhulet Ok, nice! You will find the new kernel binary in fos/kernelsourcex64/arch/x86/boot/bzImage. Copy that to your FOG server in /var/www/html/fog/service/ipxe/ but I suggest you rename the original bzImage in that directory instead of overwriting it. Just so you have a surely working backup copy of the kernel.

Now, applying the patch I notice that I gave you instructions for building our current kernel version. But for this stuff you need to use a newer one. Sorry for that. Move that 4.19.64 code out of the way, you might want to use it some other time:

cd fos mv kernelsourcex64 kernelsourcex64_4.19.64

Now add the patch and build the newer kernel:

export KERNEL_VERSION=5.1.16 ./build.sh -kn -a x64 wget https://ozlabs.org/~benh/nvme-mac-5.1.16.diff cd kernelsourcex64 patch -p1 < ../nvme-mac-5.1.16.diff make

This will get you the same kernel version I built for you some days ago. But there also seems to be a patch for kernel 5.2. If you want to give that a try instead:

export KERNEL_VERSION=5.2 ./build.sh -kn -a x64 wget https://ozlabs.org/~benh/nvme-mac.diff cd kernelsourcex64 patch -p1 < ../nvme-mac.diff make

This last one is untested.

@Christopher-Drew Are you still active in the forums? Would be great to actually have people around who can test things when I get to work on a fix.

https://isimagingdead.com/

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.

I would be interested in seeing a pcap (network capture) from this device as its booting to make sure our wiki still contains accurate info: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@hernani Look at the FOG forum chat (upper right corner of the window) for some additional hints.

@NeedLessMacs So far we only seemed to have this issue with Sierra and later versions. See here:

It seems as if the ones that came with Sierra (10.12) pre-installed will not work with iPXE while the ones that had El Capitan (10.11) are OK.

Possibly a Sierra update came out that also broke it. Or we are looking at a different issue here. So far I have only heard of onboard NICs having that issue but if it’s the exact same chip could also be a problem with the thunderbold adapter.

Please read the whole iPXE from above and start by compiling your own debug iPXE binary to test.

@louis-csusa @George1

Hi Louis,

George1421 created a great post, scroll down to part 2a. You will see the info you need. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/3 I added George Incase there’s any new info. Maybe Fog will support APFS? Since I seen reports that Clonezilla can imaged using DD. Also this usb script does not support the new T2 15inch MacBook Pro keyboard. However using a usb hub to connect an usb Ethernet, keyboard I was able to pxe boot and register it. Please note you will need to disable secured boot on an T2 chip Mac.