Last active 3 months ago

  1. 3 months ago
    Wed Aug 16 15:12:22 2017
    M MunkiMan started the conversation Trouble uploading iMac 4k image.

    I'm having trouble uploading a new image from a new iMac model 18,2. This is the 4k Retina iMac with USB-C and the dreaded Fusion drive. When attempting to upload a full image I get this error: "/bin/cd_pull: line 354: * 1000 * 1000 : syntax error: operand expected (error token is "* 1000 * 1000")". When attempting to just upload the schema I cannot view the schema in the web interface and if I look at it in a text editor it appears to have no UUID for the drive. Here is what the schema reads:

    {"harddrives": [ {"name":"/dev/sda","size":"1953525168","table":"mbr","boot":"","lbs":"512","pbs":"4096","guid":"","active":"true","partitions": [ ,{"name":"/dev/nvme0n1","size":"6835938","table":"mbr","boot":"","lbs":"4096","pbs":"4096","guid":"","active":"true","partitions": [ ] }

    I've also attached a log from uploading that schema

  2. 7 months ago
    Thu Apr 20 13:52:14 2017

    I dropped this for a bit, but came back to it in the last few days. I finally fixed the issue with MacBook Airs. This fix assumes that all devices have a Wi-Fi network port. I feel this is a pretty safe assumption in 2017 even with older Apple devices. This also assumes that identifying a device by Wi-Fi mac address as opposed to ethernet mac address does not adversely effect how CloneDeploy treats the device.

    I checked to see that the osx_task_list script looks at all mac addresses on a given device before determining if a task has been assigned to that device. Since this is the case CloneDeploy should check for active tasks for Wi-Fi as well as ethernet which means that it should not matter which mac is the primary identifier.

    Next I went back to the osx_register script and changed the entry in line 9 to

    mac=$(networksetup -listallhardwareports | grep -A 3 "Wi-Fi" | grep "Ethernet Address:" | cut -d " " -f 3)

    This will now choose the Wi-Fi network port as the primary mac address when registering a new device. So far in testing it has worked properly.

  3. 8 months ago
    Thu Mar 23 13:54:11 2017

    I have not noticed any pattern which is the most frustrating part about it. It is important to note that these devices will image on an older CloneDeploy server that does not use the Mac imaging environment (version 1.0.1p3). Also important to note that other devices image just fine on our main production server (version 1.2.0).

  4. Thu Mar 23 13:11:26 2017
    M MunkiMan started the conversation SMB Share not mounting for some clients, but not all.

    I'm having trouble with certain devices not being able to image. I get an error upon selecting any image that the smb share could not mount citing an authentication error. These are all apple devices and imaging in the Mac imaging environment.

  5. 10 months ago
    Thu Dec 29 15:04:14 2016
    M MunkiMan posted in Uploading Computer CSV.

    I figured out the format. However I am still having issues assigning an image to a given device. Here is my current csv (changed to txt for upload).

  6. Thu Dec 29 14:02:40 2016
    M MunkiMan started the conversation Uploading Computer CSV.

    I'm trying to import a csv of computers that I exported out of MunkiReport. I keep getting an error on import. Can you provide me with the format that CloneDeploy is expecting? I've removed any superfluous columns leaving only the computer name and mac address. I've attached the CSV for reference.

  7. 11 months ago
    Wed Dec 21 17:00:23 2016
    M MunkiMan posted in Mac Images keeping old name.

    Also it must be reading the target volume properly because it is creating the file set_computer_name with the name given during imaging.

  8. Wed Dec 21 16:57:05 2016
    M MunkiMan posted in Mac Images keeping old name.

    The renaming has not been working. And yes Macintosh HD is the drive name. But it seems that during the upload of an image or deployment it grabs the name from somewhere. The client that I used to create the image still holds the name that I set it to (BaseImage10116) but when imaging the name of the machine is BaseImage10115 (the name that the previous image had).

  9. Wed Dec 21 14:16:56 2016
    M MunkiMan started the conversation Mac Images keeping old name.

    I was recently working on creating a mid-year update to my El Cap image. Creating a "Lazy" image I imaged a machine with my last image and then proceeded to update the necessary software. Before uploading this "New" image I changed the name to reflect the updates and to make sure the name was changed ran scutil --set HostName, scutil --set LocalHostName, scutil --set ComputerName and finished off with dscachutil -flushcache.

    The image uploaded fine, but when testing by imaging new devices they would take the name of the last image. I must note that when I first noticed this new deployments took the name of the device which I created the image on even though I changed the name before hand. After removing all computers from CloneDeploy is when I noticed that the deployments were taking the name of the old image.

    Some things to note: I checked the change_computer_name log which contains whatever name I entered on deployment, but does not reflect the actual name on the device. I have a restricted configuration profile on this image, however the same profile exists on older deployments where I did not run into this issue. Is there some "ghost" location where these devices are pulling the name from? Also this is not a huge issue since naming has not been working from clone deploy and I have a script created for my techs that will change the name along with some other configurations.

  10. Tue Dec 20 19:50:20 2016

    I think I've figured out a way to deal with this issue: If my intuition is correct this information is pulled into CloneDeploy using the osx_register script. If you changed the mac entry from

    networksetup -listallhardwareports | grep "Ethernet Address:" | cut -d " " -f 3 | head -n1


    ifconfig | grep ether | cut -c 8-24 | head -n1

    That way it would always pull en0 which is the ethernet port on any device with one and it's the wi-fi address on devices that do not have an ethernet port (MacBook Airs). I'm going to try and edit that line to see if this helps with our (I work with striderida1) environment.

View more