9.7 and imaging

sardesm
New Contributor III

Anyone else notice if 9.7 broke their imaging process, machine logged in under temp adobe account but nothing going on.

35 REPLIES 35

CorpTech
New Contributor III

Yep, it broke mine. It tries to install the OS dmg as a package rather than doing a block copy. I've already alerted my TAM.

nessts
Valued Contributor II

I just did a block copy image, in target imaging mode from SMB share. seemed to work well to me.

jwojda
Valued Contributor II

where has the QA team gone? that seems like a pretty big bug (checking an image workflow now).

were_wulff
Valued Contributor II

@sardesm

I’ve let your Technical Account Manager know that you’re having difficulties with this, and he should be reaching out to you soon.

We’ll want to get some more information on what workflows are in place and dig into the details a bit more, and since a lot of that could contain identifying information, it’s not something I’d want to ask that you post here.

I did find an older thread revolving around the Adobe Temporary Installer account seeming to hang the imaging process; if you haven’t seen it already, I’d recommend taking a look as the workarounds mentioned in those threads may help here:

Image Reboot Logs Into Temporary Adobe Install Account

Thanks!
Amanda Wulff
JAMF Software Support

jwojda
Valued Contributor II

my quick test worked, but I used an older C.Imaging app.

CGundersen
Contributor III

I've noticed lack of block copy (SMB) in 2 test environments using Casper Imaging 9.7 and 10.10.2. The NBI(s) were created using AutoCasperNBI v1.1.4

I haven't been able to test more recent builds of AutoCasperNBI or NBI's created using manual methods. Older builds using version 9.65 of Casper Imaging working as expected.

Chris_Hafner
Valued Contributor II

FYI, I am using 9.7 (Both JSS and imaging) on a 10.10.2 NBI and all is working very very well. Block copy works, complied images work, and the new ability to create and deliver restore partitions. This is via AFP though. I have also tested all of these versions against AutoCasperNBI (1.1.7 pre-release) and they're 100% good to go.

jwojda
Valued Contributor II

Just had this issue on a 2012 MBAir w/ 10.10.2 (rebooted, and it seemed to have patch to 10.10.3 though) and 9.7. Got around it by going back to C. Imaging 9.6

CGundersen
Contributor III

I've been out of the office, so haven't had a chance to work with our test environment. However, I did a bit of work in my home lab ...

After running the latest 10.10.3 release through AutoDMG, and updating AutoCasperNBI-created .nbi to match (i.e from aforementioned 10.10.3 AutoDMG build), block copies are good to go with JSS v9.7, Casper Imaging v9.7 and SMB (and AFP) shares. I'm testing/successful with both NetSUS and BSDPy for NetBoot service.

For me, the issue seemed to be with 10.10.2 (at least the 10.10.2 builds I've been using) and Casper Imaging v9.7 (v9.65 worked as expected). It didn't seem to be an issue of AFP vs SMB, as I created an AFP share, replicated and still didn't have any block copy love. That said, previous 10.10.x were such a bag of hurt that I'm just going to focus on 10.10.3 and not look back.

gokoudes
New Contributor III

For what it's worth, I had to roll back Composer and Casper Imaging to 9.65. Re-created my 10.10.3 BaseOS in Composer 9.65 (no Recovery Partition in dmg), laid down new BaseOS image using Casper Imaging 9.65. That worked.

guidotti
Contributor II

I am having this issue with using Casper Imaging from an external Thunderbolt drive.
Booting to a primary partition on the external (updated to 10.10.3 as was on 10.9.4, didn't help).
I'm using Casper Imaging 9.7, and it says: Block copying (takes about .5 seconds), then goes to erasing drive after the block copy, even though it is supposed to erase before the block copy. Then it tries to install my AutoDMG created 10.10.3 installer after the erase. I'm sort of at a loss, as I have never experienced this before. I will try rolling back to Casper Imaging 9.65 and see what happens.

guidotti
Contributor II

So I rolled back to 9.65 as suggested, and it works fine...
So there is some sort of defect with 9.7 in my case.

CGundersen
Contributor III

So much for not looking back, lol ...

Back at work, I found that with iTunes 12.1.2 added to AutoDMG build, block copies would fail (pattern that @guidotti lists above would take place). The success I was having at home with 10.10.3 and Casper Imaging 9.7 didn't include any additional updates or software. As soon as I removed iTunes from build, block copies were good. I didn't get a chance to swap out Casper Imaging (revert to 9.65), but I expect that will be the workaround for now.

update: replaced Casper Imaging v9.7 w/ 9.65 in NBI's and all OS configurations block copy

glopez1
New Contributor II

Running Casper 9.7 JSS, JDS, and Imaging:

It seems during the imaging workflow, any packages added to the FirstRun section of the process (packages marked "Install on reboot") spontaneously change from the original PKG icon to the Adobe Install PKG icon during the FirstRun preparation. I also noticed that "defaults read /Library/Preferences/com.apple.loginwindow "autoLoginUser"" returns "adobeinstall" as the autologin user. I install no adobe products during my imaging workflow.

This broke my actual autologin user I created with CreateUserPkg to facilitate the rest of my imaging process. I now have to install this user pkg "At reboot" (during FirstRun) rather than during imaging because the user account does not get created properly otherwise.

I have since added a script to be run "At reboot" during the FirstRun that corrects '/Library/Preferences/com.apple.loginwindow "autoLoginUser"' to my intended user and autologin is functional again. This is a pretty serious bug. I am unaware of what other effects installing regular packages as "Adobe Install" packages there might be.

sardesm
New Contributor III

They need to fix this asap, killing my workflow process.

guidotti
Contributor II

I had to go back to Casper Imaging 9.65 on everything and also change my SMB distribution point URL to use the IP address instead of the DNS name. After that, all my stuff started working properly again...for now...

bentoms
Release Candidate Programs Tester

@gtucker that's normal.

PKG's set to be installed at reboot do change icon to be Adobe style when cached locally, & the account that Casper creates to install items marked as "Install At Boot Volume During Imaging" is called "adobeInstall" & is set to auto-login as it.

So what you're seeing as a serious bug is normal behaviour of the suite.

glopez1
New Contributor II

@bentoms

Oh really? Interesting. I was forced into installing my createuserpkg's on the FirstRun because casper 9.7 would not install any createuserpkg's that were configured for autologin. The pkg install would fail during the workflow and derail the rest of the process. Imaging with 9.65 installs the createuserpkgs fine during imaging and not during FIrstRun.

Josh_S
Contributor III

Also completely broken for imaging from a pure JDS environment where you haven't enabled AFP. In our case, this is a deal breaker. We've decided to abandon Casper Imaging completely at this point. Our NetBoot image now includes a custom scripted process, utilizing cocoaDialog, to use asr to image the drive (if needed) directly over https and a custom ultra-thin provisioning package that utilizes the First Boot Package Install hosted on @rtrouton git repository.

First Boot Package Install: https://github.com/rtrouton/First-Boot-Package-Install

asr restore --source https://jds.server.com/CasperShare/os_image.dmg --target /dev/disk0s2 --erase --noprompt

Edit: Quick warning about the above ASR command. Make sure you know what you're doing when you run it. It erases and re-images a drive (disk0s2) without asking for any confirmation.

bentoms
Release Candidate Programs Tester

@gtucker I'm not sure of the difference between 9.65 & 9.7, & what you were doing with CreateUserPKG.. But I've followed an unchanged workflow since v7.

Another option many be to install the CreateUserPKG PKG & then as part of a post install policy set the autologin to that user in the com.apple.LoginWindow.plist.

TreeMan
New Contributor

@guidotti

Having the exact same issue you described with 9.7

going back to 9.65

KarmaIT
New Contributor

This is very frustrating - not getting anywhere fast. The posts by @CGundersen looked hopeful so I followed a similar pattern:

  • Casper server running 9.71
  • Downloaded 10.10.3 install from AppStore
  • Ran installer App through AutoDMG, excluding the download for iTunes 12.1.2
  • Ran output from above through AutoCasperNBI (associated with Casper 9.65 as per above posts)
  • Deployed to NetBoot Server

When I fire up the NetBoot and deploy a config through Imaging, the OSX build that is in that config goes to "Installing" rather than the block copy mode with associated progress indicator.

Aside from it being slower to deploy the image, I just don't trust the Install mode as much (rightly or wrongly).

KarmaIT
New Contributor

An update to this with 2 findings.

We are in the process of deploying 25 new iMacs.

I've noticed that:

  1. The new iMacs ship with their disks showing as being set up as a Logical Volume Group (I believe this might be something to do with CoreStorage?). Each iMac contains a single 500GB SSD. Selecting the option in Casper to erase the disk prior to install nukes the Logical Volume Group and the disks then just show up normal hard drives. I mention this just in passing and is possibly not particularly pertinent to this thread.

  2. Secondly, with the setup that I describe in my post above, if I wipe the drive using Disk Utility and then deploy the configuration from NetBooted Casper, I get the "installing" mode of OS DMS deployment. However, to my relief, if I select the option within Casper to wipe the disk prior to deploying, the block copy works fine. Happy Days. That is with Casper 9.65 (as mentioned in previous post). I will try with Casper 7.1 and report back.

bentoms
Release Candidate Programs Tester

@KarmaIT so when erasing 1st, it's block copying? Otherwise it's installing?

KarmaIT
New Contributor

Hurrah. All working beautifully again now on both 9.65 and 9.71.

Fully up to date on every front:
- brand new spanky Retina5k iMacs
- Casper 9.71
- OS on Netboot and for Deployment = 10.10.3

I can pick up where I was with this deployment configuration setup about 3 days ago. Fix for me seems to simply be ticking on the "erase drive before install option" rather than using the Disk Utility erase. Perhaps it is well known that this is the required process.

I'm interested to investigate the CoreStorage part (mentioned in 1 above) as this is new to me but as far as the issue on this thread goes, all is good here.

bentoms
Release Candidate Programs Tester

@KarmaIT i've some ramblings about CoreStorage here.

But JAMF have put stuff in place that negates the issues I encountered then with Casper Imaging.

We always erase via Imaging. So perhaps there is some logic in imaging that proceeds differently depending on installing post wipe via imaging.

KarmaIT
New Contributor

@bentoms If I erase with Disk Utility and then deploy it goes to "installing" method. If I use in-built erase in Casper Imaging, block copy works fine.

johnnasset
Contributor

Just tested with Casper Imaging 9.7 and NetBooted via the NetSUS appliance to a 10.10.3 NBI.. Used Casper to erase prior to laying out a base 10.10.3 image. Worked fine.

guidotti
Contributor II

Guys, Casper Imaging has always worked that way as long as I can remember.
I always have to check erase disk or it will not do a block copy.
I thought that was just how it worked.
Does 9.71 imaging fix those issues we were having with 10.10.3 or do we still need to bake in 9.65 imaging?

bentoms
Release Candidate Programs Tester

@guidotti thanks for confirming. That's what I was trying to get at. :)

KarmaIT
New Contributor

Fair enough. I still think it was worth spelling out my situation as there are people above (e.g CGundersen) having problems with 9.7 and also here https://jamfnation.jamfsoftware.com/discussion.html?id=13184 whereas it seems to work fine for me. Perhaps they are falling into the same trap.

guidotti
Contributor II

Right, so the issue there is twofold. There were problems with Casper Imaging prior to 9.65, and there were also problems with OS X 10.10.2. Their interaction was catastrophic for some folks, including me. Once we got to 10.10.3, Casper Imaging 9.65 worked straightaway, but 9.7 fails. That's why I was wondering if 9.71 fixed anything. I am out of the office today and can't test until Monday.

CGundersen
Contributor III

I've found that 9.71 Casper Imaging does indeed fix issue I was having with block copies (e.g AutoDMG with updates/extra software as part of build). Testing was with SMB distro, BSDPy hosted NetBoot and AutoCasperNBI-generated NBI.

edit: block copies good with 9.72 as well

sardesm
New Contributor III

just got this.

Michael

I hope that this email finds you doing well!

I wanted to reach out regarding our 9.71 release that came out yesterday afternoon. It has come to our attention that there are a couple of items that were intended to be in the 9.71 release that were marked as resolved in the release notes that are not fixed. These items are D-008880 and D-008907. Both of these items are related to the http download of packages and scripts from a traditional file share. We are currently working on determining how this occurred and also working to get an updated release out to you as soon as possible. Though we do not have an exact timeframe, this is currently of the utmost importance. We should have a new release available within the coming days that will address these items.

Please feel free to let me know if there are any questions on this. JAMF Software sincerely apologizes for the inconvenience that this has created. We just wanted to bring this to your attention as soon as we could.

Sincerely,

Joel Peasley
Manager, Commercial Accounts

johnnasset
Contributor

Just tried netboot imaging with 9.71. Erase with Disk Utility and install base image and it hangs at Installing Package. Erase drive with Casper Imaging, block copy and all is well. Only seems to affect the imaging of a newly erased drive as I can apply my thin image configuration normally. Images on the NetSUS appliance served over AFP (I think, not sure if AFP is the default on the NetSUS appliance. Doesn't seem to be a setting that can be changed.)