4 Replies Latest reply: Dec 4, 2012 4:38 PM by d.carpenter
d.carpenter Level 1 Level 1 (0 points)

I use JAMF's Casper Suite to manage our company's Macs. In this suite there is an application called Self Service that allows users to choose what they want to download from our company's store. After a user has been migrated using these steps, we see this show in the application's log after trying to install something:


Error loading /System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl: dlopen(/System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl, 262): no suitable image found.  Did find:

/System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl: mach-o, but wrong architecture


This is causing the Self Service app to report to the user that their installation failed, eventhough it actually did install successfully. I suspect that it may be caused by the UID changing from a standard 3 digit to a directory based 10 digit number, but I'm not sure. I've verified that the network user is the owner of their home folder (we keep their home folders local, not on the server).


Does anyone have any thoughts on something to try?

MacBook Pro, OS X Mountain Lion (10.8.2)
  • MrHoffman Level 6 Level 6 (13,270 points)

    If you're on the current version, contact JAMF for assistance.  If you're not on the current version of JAMF, consider an update.  As a guess, they may have some code that's expecting 32-bit.  But in any case, their code has something that's either a bug or an incompatibility.

  • d.carpenter Level 1 Level 1 (0 points)

    I've contacted both JAMF support and AppleCare Engineering, both were more or less stumpted. What has you believe that the cide is expecting 32-bit?


    I'll be sure to pass along any insight to JAMF for my ticket.

  • MrHoffman Level 6 Level 6 (13,270 points)

    I've seen cases where code was expecting 32-bit or 64-bit executable, and got handed a binary with only 64-bit or 32-bit build, and that triggered an architecture error.


    The following will tell you how the tool was built...


    file {filename}

    otool -hV -arch all {filename}


    Based on a quick check of a local Mountain Lion box, that file is built as 64-bit, so the caller should be (needs to be) expecting a 64-bit build.


    I don't know of an easy way to see what the caller is expecting, short of rummaging around inside that executable.


    (This stuff is pretty obvious, so I'd expect the support folks would have thought of this already...)

  • d.carpenter Level 1 Level 1 (0 points)

    Thanks! I've passed that observation on to JAMF. Hopefully they can find a solution in a future release.