Slow pkg "Install on boot drive after imaging"

@boettchs I didn't see this issue in previous revisions of 9, but I think I started noticing splash screen issues after 9.2. It could also be around the time Mavericks came out. I'm not convinced this whole thing isn't a conflict with new loginwindow handling in Mavericks. I also have another defect I'm working with JAMF on regarding the imaging splash screen not loading at all.

@amanda.wulff][/url: Thank you much. I will not upgrade from 8.73 to a lesser version of 9.xx so I guess we'll wait on trying out this feature. Who knows, by the time we get the JSS upgraded, it may be 10.33 ;)

@cstout: Thanks as well. Good info to have. I try to balance between paranoia over upgrading and just dealing with it...

@cstout

That's also a possibility; I know we have a few open issues revolving around Mavericks not playing nice with parts of the JSS, though nothing was specific to the issue that started this particular thread.

We did have a few loginwindow defects that were specific to Mavericks (those are listed as fixed as of 9.31), and we do still have an open defect in which login/logout hooks don't always work (D-006636) that is specific to Mavericks, even more specific to the 10.9.3 version.

Looks like the majority were taken care of by 9.31, but the ones that are open appear to be issues between the OS and the JSS with development looking into how to get our stuff working nicely with Mavericks while not breaking it for earlier versions of the OS that we still support.

That does make me curious though: For this particular issue, are the computers being imaged all Mavericks computers, or do we have a mix of Mavericks and older versions of the OS that have the same problem?

If it's just Mavericks, that'll narrow things down a bit more. If it's a mix, that should be noted.
I can certainly test it here, but it's also helpful to know what's being seen in live environments as well.

Thanks!
Amanda Wulff
JAMF Software Support

HI!
Just thought I'd chime in here:
I am booting to a 10.7.5 netboot image, using Casper Imaging 9.3.2 and JSS 9.3.2
Laying down a 10.9.2 image, and almost ALL my packages are installing after reboot using the checkbox: "install to boot drive after imaging", including the 10.9.3 update. I do this routinely with anything in .pkg format.
I am imaging Airs using TB Ethernet adapters.
I have it set this way in part to get past the net booted portion, since that is my imaging bottle neck.
I am not seeing this issue. My JAMF Helper screen comes up, and once everything completes goes away, temp profile is deleted, machine reboots, and I can tell everything is complete when the WIFI policy activates the local SSID
The only Configuration Profile I'm running is a login window profile, which is in effect at reboot, and all policy history is flushing as expected and policies are running on their triggers.
Thought this may be helpful in determining where the issue lies.
Sandy

@amanda.wulff Nearly all of the issues that I am working with JAMF on are defects that have been previously closed. We're all pulling our hair out over it because I keep reporting issues that were resolved in previous versions. I'm running the latest JSS and suite apps (9.32). My various configurations are all running Mavericks.

I used to see this back in the day when having multiple installers in a config that had architecture limits.

Not sure if it still applies, but does the pkg taking time have itself set to only install if a certain OS or Processor?

@Sandy

Thanks for the additional input!

I just wrapped up testing with my 10.8.4 image, and didn’t see the behavior there either, so it’s possible that this may be specific to 10.9.3.

One of my co-workers tested with 10.8.5 and it seemed to work as expected in that version of the OS as well.

If nothing else, it certainly helps narrow things down for development and QA when it gets into their hands.

The defect has been updated to reflect new info from this thread, and the thread is linked in the defect notes itself so it’ll be easy for anyone to find and look through if need be.

Amanda Wulff
JAMF Software Support

@tommyday @cstout @smb_samba

So, I’ve got some updates from dev on this one!

The long, detailed version is that it’s expected behavior as of 9.31.

No, wait, don’t stop reading! Explanation of what’s going on on the backend follows:

In 9.31 we changed the way the post install items/scripts run to take care of all the old Device Signature Error related defects from 9.2x and 9.30; in the cases of those defects, it was a timing issue that was causing them, in many cases the enrollment not being finished before a machine rebooted, the enrollment process trying to kick off at the same time as something else and butting heads with it, or the enrollment process not getting a chance to kick off before things rebooted.

We do know, if Thunderbolt Ethernet is involved in imaging, we can see a 5-10 minute delay before the OS realizes it has network connectivity (D-006627), which is why I’d thought in a previous comment there might be some relation there.

The way the enrollment portion of the post install works in 9.31 and 9.32: It polls 6 times every 5 minutes to look for a connection to the JSS connect. If it finds it, great, it continues on. If it doesn’t find it, it goes idle for 4 1/2 minutes, then tries again, and repeats until it gets a valid response from running the jamf checkJSSconnection command.

So, in 9.31 they switched it so nothing else can start in the post install until enrollment is complete; in my test machine’s case, we found that it was taking 2 1/2 minutes to set the home page (specified in the configuration I was using) and another 3 minutes for the enrollment to actually finish, so the end result is that it ended up being between 6-8 minutes total (depending on when it polled again for a JSS connection) before the entire enrollment process finished and it continued on on its own.

During that time, I just got to sit and look at the splash screen that the jamfHelper puts up; we sat here, ssh’d into the test machine, and just ran tail -f on /var/log/jamf.log every couple of seconds to see what it was doing and to see if we could find out what seemed to be ‘hanging’ it.

We also checked to see if the enrollment portion was still going with ps -auxx | grep jamf. In my case here, that was a running process for just over three minutes (which seems a bit long, but I’m more inclined to think that’s just my test environment needing a good cleaning up).

The above two things are things we can easily check in other environments to see if yours is seeming to stall on the enrollment or if there’s something else there that’s causing it.
Once a computer gets to the splash screen, ssh in and monitor the jamf processes with:

ps -auxx | grep jamf

If it’s sticking on enrollment taking a long time we’ll see the enroll command with an invitation attached; hard process to miss since it’s a long one.

And, every few seconds, run a tail -f /var/log/jamf.log to see if anything there has changed or looks odd/off.

I did have a bit of a chat about how, while I understand why the change was made, we do need to take a look at it again to see if there is any way we can make it more efficient to cut down on the wait time (or to speed up the enroll time) or, at the very least, modify the splash screen that shows up to indicate what part of the process is going on in the background instead of just the, “Please wait…” style splash screen we have right now.

If you already have a case open with your TAM, I’d recommend going through the above and letting your TAM know what you found as we are still trying to determine the exact root cause of the behavior and/or to verify if it is the result of the fixes for the Device Signature Error defect or if it’s something else.
We’re still looking into that, primarily because we’re only seeing the problem show up in 10.9.3.

If you don’t have a case open with your TAM already and are experiencing this issue, please do consider opening one up; feel free to reference this thread, the defect, etc…and attach either the jamf.log or screenshots of the above to the case as well.

Having information from live customer environments can help dev & QA (not to mention support!) out with testing.

Thanks so much for your patience and assistance while we get the cause of this behavior pinpointed!

Amanda Wulff
JAMF Software Support

Amanda,
I can confirm exactly what you said in your last post. I imaged 265+ MacBook Airs in December last year running JSS 9.22 (I believe) and did not experience any issues with the Post Install packages. Now on 9.32 I am experiencing wait times which are not acceptable...miniumum of 8 minutes. I say this because when you are handing out a new laptop to a student and you are walking them through it 8 minutes feels like an eternity. When I dug into the jamf.log in /var I noticed what you were seeing regarding it taking a couple minutes to set homepage or management framework. The actual install packages didn't take that long it was the jss processes slowing it down at the beginning. We use Thunderbolt to Ethernet adapters and they worked great in 9.22....not sure if it was an improvement to make the process change described above in 9.32 as you could get around the enrollment issues by making an enrollment package including the QuickAdd and changing its priority to be last? That is at least how we did it. It is definitely making life harder here!