Skip to main content
Question

bypassing OS X Setup assistant results in "Disk disappeared" message in install.log when installing from dmg

  • December 12, 2014
  • 2 replies
  • 18 views
A
Forum|alt.badge.img+12

Hi all,

As the title implies, I'm having an issue when building my workflow for upgrading from 10.8.5/10.9.5 to 10.10 when bypassing Setup assistant and trying to install from a dmg. A (any) dmg package will not install correctly, sometimes at all, when the Mac is at the setup assistant screen. The install log shows a repeated error "Disak disappeared", presumably when a dmg is unmounted. Note this error does not occur when installing from a .pkg or when setup assistant has already been run.

The workflow I am working on:
1. Create a 10.10 upgrade package using Greg Neagles createOSXInstalPkg
2. push that package and a custom LaunchDaemon via Casper Remote, both are wrapped in another package that has a pre- and postflight
3. The pre-flight does an rm /var/db/.AppleSetupDone and then 'killall loginwindow' to force the Mac back to the setup assistant (so I can put up a splash screen with useful No Touchy touchy messages)
4. The post-flight then puts up a fs jamfHelper window with the no touchy message and then installs the 10.10 upgrade package. <--- this is where the issue is

the 10.10 upgrade mounts a dmg - presumably InstallESD.dmg - to perform the actual install of the 10.10 upgrade files. For some reason setup assistant causes a premature dismount of the dmg, and the upgrade files never get fully installed. Thus the mac never reboots to the 10.10 upgrade, and instead just reboots to the setup assistant screen.

If I comment out the part of the pre-flight that removes .AppleSetupDone, the install and upgrade process completes just fine, it seems to be just with Setup Assistant running. I've noticed this with ALL dmg style packages as well, not just this one. If I convert them to .pkg, they work fine.

Has anyone seen this before? Is there something simple I'm overlooking here? Note this only became an issue after the upgrade to 10.8.5. When our fleet was running 10.8.2, this was not an issue.

    2 replies

    bentoms
    Forum|alt.badge.img+35
    • bentoms
    • Hall of Fame
    • January 4, 2015

    @acdesigntech, any reason to go this route & not the one outlined at the following? https://jamfnation.jamfsoftware.com/article.html?id=173

    A
    Forum|alt.badge.img+12
    • acdesigntech
    • Author
    • Contributor
    • January 4, 2015

    a few.

    1. Management wants no user interaction whatsoever, so no self service
    2. Packages have to be installable outside of casper, so dmg package is out
    3. Management wants to do these upgrades in the middle of the workday, despite my protestations, leading to the following sub-points: 3a. Since this is being done during the day, there are about a dozen packages and scripts that need to be run immediately in order to produce a fully functional 10.10 Mac in order to let the user continue to work (packages related to SAP, PCI compliance, etc). These have to run immediately after the 10.10.0 upgrade since the expectation is now that the user will continue their workday, just with a Mac running 10.10 now, rather than letting the already-established policies in the JSS do their work overnight, or at logout, etc. 3b. This now requires me to leverage jamf helper in full screen mode so users don't mess with the Mac while it's upgrading, since the post-upgrade scripts I mention above take about an hour to fully complete - cannot do this over the login window, so i have to remove .AppleSetupDone and kill the login window, and I can't rely on users not logging in while the upgrade is happening. And this is where I have the issue.

    I did actually end up working around this though by doing the following:
    1. lay down the 10.10 upgrader package created with createOSXInstallpackage
    2. put the mac into an exception group that blocks all policies (same as we use for when a new Mac is built)
    3. kill the login window to force a logout and install the 10.10 upgrade
    4. we also lay down a launchdaemon to call a policy on first boot
    5. OS X upgrade time
    6. first boot of the new OS calls a policy to finish all of the SAP and post-upgrade packages that are necessary
    7. policy first kills the login window and removes .AppleSetupDone
    8. policy uses JH to put up a full screen "no touchy touchy" message
    9. policy magic
    10. cleanup and reboot

    Terms & ConditionsCookie settingsAccessibility statement