Replies: 7 comments 19 replies
-
|
Hi Rob, Would you mind showing some more steps to reproduce this? I.e. how do you enroll a VM and install an MDM profile? |
Beta Was this translation helpful? Give feedback.
-
I've tried the following, making sure that no other local VMs are present on the host before running this: tart pull ghcr.io/cirruslabs/macos-sequoia-vanilla:latest
tart clone ghcr.io/cirruslabs/macos-sequoia-vanilla:latest macos1
tart clone ghcr.io/cirruslabs/macos-sequoia-vanilla:latest macos2
tart run macos1 &
tart run macos2 &( The two VMs started and had different MAC-addresses, but identical serial number, hardware UUID and a provisioning UUID. Now, if I re-try with All three identifiers are different, just as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Haha thank you @edigaryev I was about to post something exactly like this. I have built my own packer template to "prep" and image so when pulled it has things in place for the test enrolment. How do you build yours so they can be different? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
These are the templates that I am using! And yet I have the same hardware ID while the ones I pull from ghcr.io/cirruslabs/macos-sequoia-vanilla:latest, when cloned do not have the same hardware ID |
Beta Was this translation helpful? Give feedback.
-
|
OK, would you mind going through a checklist in #958 (reply in thread) and reporting your findings? |
Beta Was this translation helpful? Give feedback.
-
|
So when I pull the tart image from ghcr.io/cirruslabs/macos-sequoia-vanilla:latest Looking at the config.json at the root of ghcr.io/cirruslabs/macos-sequoia-vanilla:latest the hardware ID: "YnBsaXN0MDDTAQIDBA-blabla-AAAAAAAAAkAAAAAAAAAAAAAAAAAAABt" I clone from ghcr.io/cirruslabs/macos-sequoia-vanilla:latest to Looking at the config.json at the root of macos2 the hardware ID is different!! I clone my packer image the hardware id of my OCI and my clone are the same. That is the error I am getting and I am wondering what makes your image different than mine @edigaryev Any insight to this issue would help me out! What you do vs what I am doing! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
thanks @edigaryev we are confusing the ECID and the id that is associated with the hardwareModel when enrolling into a MDM server we need a unique UUID and the hardwareModel seems to be the key here. Steps I do to clone are: I do a then I do a the hardwareModel will be different for both VMs... and I can only get that to work with your images and I am using your packer templates but any clone I make from my finished packer build will have the same hardwareModel and will not enroll. Really I have no idea what makes your images different when I do a clone and get a new hardwareModel |
Beta Was this translation helpful? Give feedback.
-
|
my fault too calling it 'hardware id' |
Beta Was this translation helpful? Give feedback.
-
Are you talking about If so, then I'm not seeing this behavior on my machine: % tart pull ghcr.io/cirruslabs/macos-sequoia-vanilla:latest
pulling ghcr.io/cirruslabs/macos-sequoia-vanilla:latest...
pulling manifest...
ghcr.io/cirruslabs/macos-sequoia-vanilla@sha256:55ec8579335884de600c515ae210b9c264cbb0949c771a88ba62264735dcfc9d image is already cached and linked!
% cat ~/.tart/cache/OCIs/ghcr.io/cirruslabs/macos-sequoia-vanilla/latest/config.json | jq -r '.hardwareModel' | base64 -d | plutil -convert json - -o - | jq
{
"DataRepresentationVersion": 1,
"PlatformVersion": 2,
"MinimumSupportedOS": [
13,
0,
0
]
}
% tart clone ghcr.io/cirruslabs/macos-sequoia-vanilla:latest macos
% tart set --random-mac --random-serial macos
% cat ~/.tart/vms/macos/config.json | jq -r '.hardwareModel' | base64 -d | plutil -convert json - -o - | jq
{
"DataRepresentationVersion": 1,
"PlatformVersion": 2,
"MinimumSupportedOS": [
13,
0,
0
]
}Could you reproduce these exact steps on yours and post results? |
Beta Was this translation helpful? Give feedback.
-
|
Yes! Deleted everything that I had locally so a Step 1) Step 2) Step 3) Step 4) That is the steps I take and the images that I get form you are the only ones that change the |
Beta Was this translation helpful? Give feedback.
-
|
how do we create a new |
Beta Was this translation helpful? Give feedback.
-
|
OK, now I see. The new It could be stuffing some host-specific data and whatnot, we don't know. However, I doubt this is the the root-cause here because the the Here are two VMs with the same 
Above you've said that:
|
Beta Was this translation helpful? Give feedback.
-
|
It's the UUID that you can find in system settings or about this mac. I will dig further into this and see what I can find! But the only difference I can find was this. Out for the day will tackle this tomorrow morning. Thank you so much for your help. I wish I was a bit smarter on this subject matter so not to waste your time. Again thank you |
Beta Was this translation helpful? Give feedback.
-
Then If you observe a different behavior, please describe how you've arrived there, and we'll take a look. |
Beta Was this translation helpful? Give feedback.
-
|
@edigaryev Thank you for all your help I did a bunch of testing. There is no problem with the I think I found the reason and wonder why it doesn't affect your packer images but there is a keychain issue. Within the system there are: /Library/Keychains/apsd.keychain When I manually delete all these files and do a reboot, I can enrol the device with a MDM profile. I just now added a shell provisioner to my packer build file to delete the files and then will see if I can enrol the device. |
Beta Was this translation helpful? Give feedback.
-
|
@edigaryev its the keychains for some reason.. Once I blow away all the keychains i can reboot and enroll. With your packer images, do you do anything with the keychains? What hardware builds them? Thanks |
Beta Was this translation helpful? Give feedback.
-
Which We do some certificate-related modifications for Xcode images. We also install CA certificates in base images. All of the Packer templates we use for building these images are available here: https://github.com/cirruslabs/macos-image-templates. |
Beta Was this translation helpful? Give feedback.
-
|
I am using your templates and when I build from your template vanilla or base, just build one now and I have the enrolment issue with the keychains that I do not when pulling from the OCI repo... SO STRANGE |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Used this template https://github.com/cirruslabs/macos-image-templates/blob/master/templates/vanilla-sequoia.pkr.hcl |
Beta Was this translation helpful? Give feedback.
-
|
If I pull this image from the repo, no issues with the enrollment, as in don't have to delete the keychain. If build locally issues |
Beta Was this translation helpful? Give feedback.
-
|
Could you try with a vanilla image? Or by just manually creating a macOS VM from IPSW, using Would the issue still persist? |
Beta Was this translation helpful? Give feedback.
-
|
Tried base and vanilla manually creating a VM with an IPSW, its like packer. No enrolment due to keychains I am going to try something else. I am going to build a packer image on a different computer, upload it my OCI host and then pull it down on another computer, maybe it has to do with some odd certificate signing, since running on a different computer.. the specific certificate is MOOT and it then will jsut create a new one? Going to try |
Beta Was this translation helpful? Give feedback.
-
Context:
Building Custom Packer Image with Tart Provisioner
Following the completion and upload of the build to the OCI repository, the image is downloaded, cloned, and then configured with Tart to create a new Mac and serial number for the virtual machine.
tart set --random-mac --random-serial <nameofvm>The VM is enrolled, but an issue arises. Although the MDM profile is installed, it is stalled. Upon a reboot, the following startup message is displayed: after this message, the MDM profile is functional, but the device is incompletely enrolled.
This behaviour does not occur when using VM images from the Tart public registry.
Could anyone provide an explanation or have encountered this issue before?
Beta Was this translation helpful? Give feedback.
All reactions