jamf binary deleted during 9.81 update

AVmcclint
Honored Contributor

I upgraded to 9.81 this week and I've found that when a couple Macs login for the first time, it looks like something goes wonky while updating the jamf binary on the machines. The first time login on the desktop since the upgrade on the server takes an extremely long time. When I am finally at the desktop I wait a few minutes just to make sure all the background stuff happens then I launch Self Service and verify the version is 9.81. Then I try to run ANY policy and it fails. There's a progress bar but it doesn't say "mounting server..." or whatever. After several minutes of waiting it eventually fails. One error indicates "This computer is not managed" However the MDM profile is present. When I go to terminal and run the jamf command it tells me "command not found" I've manually looked in /usr/local and there is no old or new jamf directory! I searched all over the drive on the computers affected and there is no jamf binary anywhere, but Self Service does indicate the new 9.81 version. So far it appears to have only happened on 2 or 3 Macs, but there are still a few that haven't been powered on yet since the upgrade.

  • My question is How do I reinstall the binary without having to re-enroll (and not trigger all the enrollment event policies)?
  • Question 2: Is this a known bug?
12 REPLIES 12

McJee
New Contributor II

Hi AVmcclnt,

We're currently at 9.73 and are cautiously watching Slack and JAMF Nation posts to learn what are the risks of upgrading. We don't like being this conservative, our employees really want to start using El Capitan and Casper is the primary reason for us to hold back.

I've heard some noise about losing endpoints during the upgrade and am wondering whether there is a pattern so that we can do some targeted testing of our own. The systems whose binary couldn't be found: are they 10.11 or 10.10? Do you see any patterns there?

AVmcclint
Honored Contributor

we haven't gone to 10.11 yet. So far the machines I've seen this happen to are on 10.10.5. I'll have to post the jamf.log file from the computer on Monday when I can get my hands on one of those computers again. The log file is interesting.

hkabik
Valued Contributor

What were you upgrading from? 9.8?

Gonzalez
New Contributor III

We've also seen this on 10.10.x and 10.11.x systems going from 9.8 to 9.81. Fortunately re-enrolling does not have a negative impact on forced policies.

hkabik
Valued Contributor

Ugh... I was about to update tonight. Not sure it's worth the hassle since we have no 10.11 yet.

sgoetz
Contributor

The JAMF binary gets moved to /usr/local/bin/jamf on version 9.81.

AVmcclint
Honored Contributor

We upgraded from 9.65 to 9.81.

I checked /usr/local/ and there is no bin nor jamf subdirectories. I'm telling you the jamf binary wasn't just moved, they have been completely deleted from these affected machines. Luckily the upgrade appears have been successful on at least 50 other computers. I just need to wait for the users of the remaining computers to get in and power their computers on.

Here's the contents of /var/log/jamf.log from an affected Mac with the entire section starting with when it tried to upgrade.

Fri Oct 23 14:42:49 ComputerName jamf[47]: Network state changed, checking for policies...
Fri Oct 23 14:42:49 ComputerName jamf[257]: Checking for policies triggered by "networkStateChange"...
Fri Oct 23 14:43:03 ComputerName jamf[47]: Network state changed, checking for policies...
Fri Oct 23 14:43:03 ComputerName jamf[257]: Could not connect to the JSS. Looking for cached policies...
Fri Oct 23 14:43:03 ComputerName jamf[315]: Checking for policies triggered by "networkStateChange"...
Fri Oct 23 14:43:04 ComputerName jamf[315]: Could not connect to the JSS. Looking for cached policies...
Fri Oct 23 14:43:16 ComputerName jamf[47]: Network state changed, checking for policies...
Fri Oct 23 14:43:17 ComputerName jamf[397]: Checking for policies triggered by "networkStateChange"...
Fri Oct 23 14:43:28 ComputerName jamf[397]: Upgrading jamf binary...
Fri Oct 23 14:43:29 ComputerName jamf[465]: Checking for policies triggered by "startup"...
Fri Oct 23 14:43:31 ComputerName jamf[465]: Upgrading jamf binary...
Fri Oct 23 14:43:35 ComputerName jamf[465]: The management framework will be enforced as soon as all policies are done executing.
Fri Oct 23 14:43:35 ComputerName jamf[465]: Upgrading jamf agent...
Fri Oct 23 14:43:44 ComputerName jamf[397]: Unable to move /Library/Application Support/JAMF/tmp/jamf to /usr/sbin/jamf: Error Domain=NSCocoaErrorDomain Code=4 "“jamf” couldn’t be moved to “sbin” because either the former doesn't exist, or the folder containing the latter doesn't exist." UserInfo=0x7a666940 {NSSourceFilePathErrorKey=/Library/Application Support/JAMF/tmp/jamf, NSUserStringVariant=(
    Move
), NSFilePath=/Library/Application Support/JAMF/tmp/jamf, NSDestinationFilePath=/usr/sbin/jamf, NSUnderlyingError=0x7a64c7c0 "The operation couldn’t be completed. No such file or directory"}
Fri Oct 23 14:43:44 ComputerName jamf[397]: Adding launchd task com.jamfsoftware.task.checkForTasks...
Fri Oct 23 14:43:46 ComputerName jamf[465]: Upgrading jamfHelper.app...
Fri Oct 23 14:44:03 ComputerName jamf[47]: Informing the JSS about login for user rj
Fri Oct 23 14:44:04 ComputerName jamf[465]: The download of /Library/Application Support/JAMF/tmp/jamfHelper.tar.gz failed.
Fri Oct 23 14:44:04 ComputerName jamf[465]: Upgrading JAMF notification service...
Fri Oct 23 14:44:12 ComputerName jamf[465]: Upgrading Self Service.app...
Fri Oct 23 14:44:18 ComputerName jamf[1135]: Error executing command: (
    "/usr/local/jamf/bin/jamf",
    notify
)
Fri Oct 23 14:47:56 ComputerName jamf[1135]: Error executing command: (
    "/usr/local/jamf/bin/jamf",
    policy,
    "-id",
    299,
    "-showSteps",
    "-username",
    "",
    "-selfServiceOnly",
    "-forceNoRecon"
)
Fri Oct 23 14:47:56 ComputerName jamf[47]: Exception thrown while trying to send a message to a daemon observer for notification com.jamfsoftware.jamf.jamfAgentRequestEvent: [NOTE: this exception originated in the server.]
*** -[NSConcreteTask terminationStatus]: task not launched
Fri Oct 23 14:54:35 ComputerName jamf[47]: Network state changed, checking for policies...
Fri Oct 23 14:54:35 ComputerName jamf[47]: Error executing command: (
    "/usr/sbin/jamf",
    policy,
    "-event",
    networkStateChange
)

AVmcclint
Honored Contributor

Fortunately I was able to use ARD to push a QuickAdd package to one of the affected Macs and it seemed to work OK with getting the jamf binary installed and talking to the JSS. This is still a pretty icky bug though.

CasperSally
Valued Contributor II

@AVmcclint - what percentage of clients are you seeing this on? We upgraded from 9.65 to 9.81 as well, but our machines don't check in every day. I've been watching the binary upgrade numbers and so far 90% machines have upgraded their binary successfully (out of 6500 machines).

From what I'm told, the issue others say going to 9.8 with binary drop offs was pretty severe, so I'm hoping most of my remaining 10% not upgraded yet just haven't been powered on since our upgrade. We'll see.

AVmcclint
Honored Contributor

UPDATE: on one of the other Macs that is having problems after the upgrade, I looked closer and verified that the jamf binaries are where they are supposed to be however, the log indicates that the jamf agent is missing. Running the QuickAdd package to re-enroll it seemed to have helped that one too.

@CasperSally So far it's 2 or 3 out of 70+. I can't nail it down if it is 2 or if it is 3 because i'm getting sketchy reports from a remote location, but regardless, it's a relatively small number of affected machines. And I'm glad on 2 of the computers were fixed by a QuickAdd package.

droga5IT
New Contributor

Hello, We have had the same issue upgrading from 9.65 to JSS 9.82. Its been at least 20 clients who need to be re-enrolled. There are more. Is there a way to have a policy retrieve the jamf.log so the machines with the issues can be identified and the re-enrolled via a policy that deploys a quickadd package.
Thanks in advance for any help.

rcantrell
New Contributor II

I wanted to chime in that I see the same thing after upgrading from 9.82 to 9.96. So far I have around ~500 machines out of 9800 that are still reporting the old binary, and I see the same error in the jamf.log from the few machines I looked at that @AVmcclint. I'm sure a lot of those are machines that haven't checked in yet, however, looking at the names I know some are ones that students use almost every day.

I'm kind of bummed about this.