Here are some early notes on making and restoring a High Sierra deployment image to an iMac Pro.
“Wait, I thought imaging was dead! Especially imaging the iMac Pro with Secure Boot!” you may be thinking. My reply: “We’ll see, won’t we?” It’s early days here: we’re experimenting. Our experiments might lead to dead ends, or they might lead to useful results.
Continue reading “Early notes on deploying images to iMac Pro”
A little while ago, I made a new Mac deployment tool available:
Bootstrappr is really nothing more than a Bash script that installs any packages it finds in an adjacent packages directory. There’s no GUI, no bells and whistles.
What is it for? Why would you use it?
You’d use it for installation-based deployment workflows on iMac Pro (and potentially any Mac).
Continue reading “Bootstrappr”
Perhaps you are starting to worry about the future of “imaging” as a deployment/initial configuration method for Macs.
(I’ll define “imaging” as block-copying the contents of a disk image file to a disk volume, and resulting in a bootable, fully-functional machine.)
If you are concerned about the future of imaging, you might want to start investigating macOS installation-based workflows for deployment/initial configuration.
The basic idea is this: a workflow that either installs macOS, or starts with the factory os installation. It then installs additional packages that serve to enroll the Mac in whatever your ongoing management system is (Jamf Pro, Filewave, Munki, etc). It then becomes the management system’s job to finish the initial setup of the machine.
Here are a few things you might want to look at:
Continue reading “macOS installation-based workflows”
startosinstall tool in the High Sierra installer supports adding additional packages that will be installed after macOS is installed, via the
bash-3.2$ /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/startosinstall --usage
--applicationpath, a path to copy of the OS installer application to start the install with.
--license, prints the user license agreement only.
--agreetolicense, agree to license the license you printed with --license.
--rebootdelay, how long to delay the reboot at the end of preparing. This delay is in seconds and has a maximum of 300 (5 minutes).
--pidtosignal, Specify a PID to which to send SIGUSR1 upon completion of the prepare phase. To bypass "rebootdelay" send SIGUSR1 back to startosinstall.
--converttoapfs, specify either YES or NO on if you wish to convert to APFS.
--installpackage, the path of a package to install after the OS installation is complete; this option can be specified multiple times.
--usage, prints this message.
Example: startosinstall --converttoapfs YES
A High Sierra NetInstall image built with System Image Utility has a similar option: you can add additional packages to the install:
Unfortunately, under both 10.13 and 10.13.1, both methods have a similar issue: if you try to install multiple packages, in some/many cases the installer will not properly cache all the intended packages and the install of macOS will fail with the message “The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged.” It tells you to restart and try again (which won’t work…).
Continue reading “Customized High Sierra Install issues and workarounds”
When you upgrade to High Sierra, not only are you getting a new OS, but if your Mac has all-SSD storage, you are getting an all-new filesystem: APFS. This means your startup disk gets converted from HFS+ to APFS during the High Sierra upgrade.
More changes means more chances for things to go wrong. A colleague walked into my office today: he’d just upgraded his Mac to High Sierra, and now it was sitting at the Filevault pre-boot authentication screen. But instead of an icon for his account, there was a hard drive icon and the label “Disk Password”. His account password did not work to unlock this disk, and neither did the Personal Recovery Key.
Looked like the APFS conversion didn’t do everything it needed…
Fortunately Nick McSpadden had seen this before and let me in on a fix:
- Boot into Recovery HD
- Open Terminal.app
diskutil apfs list to get the ‘regular’ boot drive (disk2s1 in this case)
diskutil apfs unlockvolume disk2s1 to unlock the drive. The user’s normal password worked here.
diskutil apfs updatePreboot disk2s1
This last command sprayed a ton of text to the screen. After this, we rebooted, and the expected disk unlock screen came up, with an icon for the user’s account. He was able to successfully authenticate and the Mac proceeded to boot. Crisis adverted!