Slow pkg "Install on boot drive after imaging"

I've experienced the same thing. Please keep me posted on any updates you find. In testing I've deployed a base image and one <1 MB file and it took about 5-10 minutes to finish the first boot install.

@tommyday & @cstout

That is curious behavior; does it seem to be specific to that particular .pkg?

A couple things that might be useful for narrowing it down:

- See if it does it with any .pkg, regardless of size.

- See if it seems to only happen with .pkg files under a certain size.

- Does it seem specific to .pkg files, or is it happening with .dmg files as well?

- What are we using for the distribution point? File share (AFP or SMB?), JDS, HTTP? I seem to recall @cstout having an SMB sharepoint set up due to problems that were going on with AFP chewing up resources, is that still the case?

- Pretty sure I remember @cstout being on 9.32, what version are you on, @tommyday?

- Which OS is the JSS running on?

In some quick testing here, on 9.32, with an AFP file share on a 10.9.3 server I'm not seeing the behavior described, so narrowing environments down could at least let me tweak my test environment to be closer to what you two have set up.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff I will test another pkg but in the mean time, answers to your other questions:

- DS points are afp
- We are running JSS v9.32
- JSS is on Mac OS 10.9.3

@amanda.wulff
JSS 9.32 on Windows Server 2012
Distribution share using SMB (no more JDS's being used)
-No AFP

I haven't dived into any logs on this particular issue since everything ends up working in the end, but I have noticed this when testing the installation of a first-boot install of an application.

@amanda.wulff Some more testing complete.

I tried numerous pkgs with the same long install time result, file sizes range between 38kb and 51mb. I also tried a dmg which is 571mb, same result of long install time. I timed the dmg and it took 22 minutes.

-Tom

@tommyday ,

Thanks for testing that out!

I do have a couple more things to ask to narrow it down just a bit further (as I've still been unlucky in replicating it so far!):

If we go into Casper Admin and UNcheck the box that says "Install on boot drive after imaging", then go ahead and image as usual (and if that package not being included as part of a config isn't 'usual', do what we need to do to have it be included) does it seem to affect the behavior at all?

Ah, and I do know it's kind of a ridiculous thing to ask, but as it's something I've overlooked myself before: We are running Imaging 9.32 as well, correct?

I'll continue testing on this end to see if I can get the behavior to happen, but do let me know what you find out with the above; if we haven't come up with any good reason after that, I'll go ahead and grab your Technical Account Manager as we'll probably need to look into it a bit more than we can on the forums.

Thanks!
Amanda Wulff
JAMF Software Support

Hey @tommyday

Just a quick update: I finally got it to misbehave for me.

Installed a base image + Firefox with "Install on boot drive after imaging" checked.

I've been staring at the "The imaging process is finishing installing software" screen for a good 15 minutes now; when it finally finishes, I'll give it a shot again with that box unticked.

Amanda Wulff
JAMF Software Support

Thx @amanda.wulff for the update, good to see it can be replicated. Confirming that I am running 9.32 Imaging. Any of the packages run as normal without the box unticked "Install on boot drive after imaging"

@tommyday

Yeah, that's what I'm seeing as well; tried it with 9.31 and 9.32.

In some specific cases it may be "expected" due to D-006627 if we're using Thunderbolt Ethernet adapters to image as that defect revolves around the OS not immediately detecting that it's connected via Ethernet after reimaging when Thunderbolt adapters are in use and if any packages needed to have Internet or network connectivity to properly run/install it could cause a delay due to that.

However, I'm not imaging via Thunderbolt Ethernet, just by straight up Ethernet and I know the packages I'm installing don't require Internet connectivity to install (Text Wrangler, Gimp, and Firefox) so D-006627 is obviously not the root cause.

I'm going to take a look this morning and see if I can find any reference to this behavior being a known issue that I might have missed; if I don't find anything I'll open up a new defect on it and post back with the ID for reference.

For now, I'd say the workaround is just going to be not checking that box.

Thanks!

Amanda Wulff
JAMF Software Support

Interested to hear what you come up with. Problem is with this pkg is that if I dont have this option set, it doesn't install properly to the OS

@tommyday

Had a quick chat with one of our PSEs, and I'm going to re-image mine again and kill the jamfhelper process this time so I can launch console to look at the jamf.log and system.log (and install.log for pkgs, as we call the installer.app for those) and see what on earth the system thinks it's doing during that long pause.
If that doesn't show anything, I'll see if ssh-ing into the machine shows anything more useful.

I'm also going to see if changing the priority from its default of 10 makes any difference at all; I can't think of a good reason that it would, but then, I can't think of a good reason why checking that box would cause such a massive 'pause' in the imaging process either.

We did dig up a very, very, very old (8.6 beta) defect (D-003011) that showed similar behavior, though that behavior was only with scripts set to run before and there were policies set to run after the script had run, and the workaround was to kill the jamfHelper process; I doubt that they're the same thing, but if the behavior is similar I'll be sure to reference that old defect for development's reference in a new one if a new one needs to be created.

Amanda Wulff
JAMF Software Support

Hey @tommyday & @cstout

I went ahead and got a new defect opened up ( D-007139 ) with a link to this thread as well as details of testing.

It seems, when we have that box checked, to be just hanging until the jamfHelper process gets moving (after that 20 minutes or so) or we kill the jamfHelper process, at which point the package install kicks off almost immediately.

There are three ways I've found that get around it:

1) Uncheck the "Install on boot drive after imaging" box. Not viable for your particular situation, however.

2) Wait it out. Not viable at all, in my view; that's a LONG wait, especially if you're imaging dozens (or hundreds) of computers.

3) ssh into the affected machine(s), do a ps -A | grep jamfHelper, get the PID, and kill it with a sudo kill -9. Click back on the screen on the affected machine if the jamfHelper doesn't disappear on its own and it'll go away. Everything appears to wrap up at that point if it hasn't already.

All three of the above are listed in the workarounds for the new defect; if it would be possible for you to open up a case with your Technical Account Manager and reference this thread and that defect (D-007139) that'd be great for tracking and would let us attach the case to the defect (your TAM can get that done).

Wish I had a better answer instead of 'new defect', but at least we now know that the behavior is obviously not something that's intended!

Thanks!
Amanda Wulff
JAMF Software Support

@amanda.wulff Your support on this issue has been fantastic, thanks very much. I will do as you have requested with my TAM.

Best, Tom

I agree completely with @tommyday. @amanda.wulff, you've helped me out of sticky situations way too many times. As always, I greatly appreciate your help and effort to resolve problems as fast as possible.

@tommyday & @cstout

Thanks guys! Glad to be of assistance!

Amanda Wulff
JAMF Software Support

Hope to meet you at #JNUC2014 if you'll be there @amanda.wulff

@tommyday

Pretty sure I’ll be there! I got to go for two days last year, and I’m guessing I’ll get at least two this year as well.

Hey guys,

Just wanted to chime in here. I've seen similar behavior where sometimes it looks like that dialog "The imaging process is finishing installing software" is just stuck. I have on occasion seen that doing a CMD + Q quits out of that dialog box and at least gets me to the desktop (assuming it's not actually doing anything). If I do interrupt something, a reboot will usually result in the dialog appearing again.

@smb_samba, thank you for mentioning that. I forgot about that particular issue. I have seen this as well in my imaging. Probably 1 out of every 10 will not quit the imaging splash screen and I'm unable to quit it which forces me to do a hard shut down.

@smb_samba & @cstout

Are we seeing that when the "install to boot drive after imaging" box is checked, or does it not seem to matter?

If it's just when that box is checked, I'll update the defect to note that.

Amanda Wulff
JAMF Software Support

@amanda.wulff All of my various images require packages/applications to be installed to the boot drive after imaging. I don't believe I've come across that issue with no first-boot install apps selected.

@amanda.wulff I'm in pretty much the same situation as @cstout . we have many packages that require a reboot to work so yes, the box is checked. I don't know that I've encountered super slow install times for something as simple as a few items requiring to be installed after imaging (because we have many that would understandably take a bit to install), but the "The imaging process is finishing installing software" has definitely been stuck for me before.

@smb_samba & @cstout

Updated the defect to note that, and to note that if we kill the jamfHelper 'too soon' (or whatever the system thinks is too soon) we can end up in a situation where it reboots and gets stuck in the same loop again.

We've never used this option, but have been looking at it just recently. Has this issue just appeared in the 9.xx or 9.3x versions? We're still on 8.73, but the plan is still to go to 9.3x soon.

@boettchs

In the testing I did, it was on 9.31 and 9.32; haven't tested the earlier versions of 9.x just yet.