High Sierra Imaging: How-To

chrisdaggett
Contributor II

First: This is not Apple approved. I know that, you know that, do it at your own risk. I do, this works fine.
UPDATE: I have added my imager for download to the bottom of this post with instructions

This is not a discussion about why or opinions :). Some of us have this need, this is a solution!

Thought I would share as I have seen a number of folks looking for these answers. Some of you are just looking for a certain piece of this, and thats great. Some of you are looking for a way to make an imager and that is here too. If you want to take the whole thing and make a fully automated USB Imager than that is also here :). If you don't like imaging, don't want to use this, or don't like it. That is okay! We each have our own thoughts and way of doing things, this isn't for you :).

If you are interested, dabble in this, or have other thoughts/ways to make it better PLEASE post and share below!

APFS / High Sierra Imaging: (Steps 1 and 3 are assuming your machines have never been on 10.13 and are missing the new firmware. If they are already upgraded you can skip Step 1 and 3)

STEP 1: Make a Firmware update Package for/from the device you want to deploy:

From the type of device you want to deploy to, have full High Sierra install App in application folder and run: (doesn't have to be from a 10.13 machine)

#!/bin/sh
# Based on investigations and work by Pepijn Bruienne
# Expects a single /Applications/Install macOS High Sierra*.app on disk

IDENTIFIER="com.foo.FirmwareUpdateStandalone"
VERSION=1.0

# find the Install macOS High Sierra.app and mount the embedded InstallESD disk image
echo "Mounting High Sierra ESD disk image..."
/usr/bin/hdiutil mount /Applications/Install macOS High Sierra*.app/Contents/SharedSupport/InstallESD.dmg

# expand the FirmwareUpdate.pkg so we can copy resources from it
echo "Expanding FirmwareUpdate.pkg"
/usr/sbin/pkgutil --expand /Volumes/InstallESD/Packages/FirmwareUpdate.pkg /tmp/FirmwareUpdate

# we don't need the disk image any more
echo "Ejecting disk image..."
/usr/bin/hdiutil eject /Volumes/InstallESD

# make a place to stage our pkg resources
/bin/mkdir -p /tmp/FirmwareUpdateStandalone/scripts

# copy the needed resources
echo "Copying package resources..."
/bin/cp /tmp/FirmwareUpdate/Scripts/postinstall_actions/update /tmp/FirmwareUpdateStandalone/scripts/postinstall
# add an exit 0 at the end of the script
echo "" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
echo "" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
echo "exit 0" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
/bin/cp -R /tmp/FirmwareUpdate/Scripts/Tools /tmp/FirmwareUpdateStandalone/scripts/

# build the package
echo "Building standalone package..."
/usr/bin/pkgbuild --nopayload --scripts /tmp/FirmwareUpdateStandalone/scripts --identifier "$IDENTIFIER" --version "$VERSION" /tmp/FirmwareUpdateStandalone/FirmwareUpdateStandalone.pkg

# clean up
/bin/rm -r /tmp/FirmwareUpdate
/bin/rm -r /tmp/FirmwareUpdateStandalone/scripts

Firmware package will be located at:

/tmp/FirmwareUpdateStandalone/FirmwareUpdateStandalone.pkg

AGAIN THAT IS DEVICE SPECIFIC
(supposedly, I haven't tested it and don't plan to for obvious reasons)

Step 2: Making an AFPS Image:
Have a good 10.13 master machine. in Disk utility resize partition to smallest size if you want to have an image that isn't the entire size of the hard drive (It will expand on restore)

Apple has made this no longer work. Instead use terminal to resize the Container.
diskutil apfs resize Container disk2s2 30g
(change disk2s2 to the partition of the container you want to shrink and 30g to whatever size you can shrink to)

Target disk Master to another machine or use USB drive.

In Disk Utility (must be High Sierra UPDATE: Must be 10.13.3 or Lower. Apple botched something in 10.13.4+ for capturing a container image) - View - Show all devices

Unmount APFS Volume under Container of drive you want to make image

File - New image - from Container (DO NOT COMPRESS)

Don't forget to scan image for restore

Other Random Details:

You Will not see any volumes when Alt-Booting etc.. until Firmware is updated, APFS volumes will not show at all.

After running Firmware package, firmware updates on next boot (Typical apple loading slider), then reboots into startup disk

You can update firmware on a 10.12 machine and 10.12 will still boot fine.

STEP 3: Making an Imager USB without APFS: (super important if you want to boot to your "imager" on a machine that does not yet have the firmware!)

Need a machine with SIP Disabled
(boot to recovery / MacOS install USB and in terminal: "csrutil disable" , then reboot)

Boot to good OS of SIP Disabled machine (doesn't have to be 10.13) and download High Sierra installer App / copy from USB to Applications folder.

From terminal Run:

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --converttoapfs NO --volume /Volumes/DestinationDriveName

STEP 4: IMAGING!

Either make sure you run the Firmware package on the machine before you image it (you can install at in 10.12 before you image it), or use a USB drive to boot to a good OS (again doesn't have to be 10.13) and run the firmware package you made originally .

First Manually:

From Disk Utility on 10.13 machine/usb - erase drive to APFS
Unmount Volume Under Container
Click on Container and choose restore and Choose image made originally

SCRIPT:
Here is the script I use from a USB Drive. Fully automated. Drive does not have to be prepped in any way script will erase the entire drive and make it APFS with correct containers from Image and upgrade the firmware, as well as set startup disk. It also copies a FirstBoot script to enroll using QuickAdd. (Uses Applescript to set startup disk VIA System Preferences. No longer able to set startup disk via Bless or systemsetup due to SIP)

If you want it to be truly automated, you need to run the script as the root user. Otherwise there is user interaction. (To Enable Root: Directory Utility - unlock button - Edit in menu - Enable Root). With High Sierra you can no longer set Root as auto login in OSX. If, like me, you want the USB fully automated you can set root as auto login with the following:

sudo defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser root  
sudo defaults write /Library/Preferences/com.apple.loginwindow autoLoginUserUID 0 

Script assumes that A.) you have the image you want to use in /Configurations B.) The Firmware is in /Packages C.) In order for startup disk via Applescript to work you must put Terminal in Security - Privacy - Accessibility on your "imager", and you must be Root user (otherwise you would have to unlock the preference pane) - OPTIONAL D.) If you want to have it enroll on firstboot you must put quickadd.pkg in /Data

#!/bin/bash
sleep 2
#   Restore AFPS Image to internal container from /Configurations
asr restore -s /Configurations/*.dmg -t /dev/disk0s2 -erase -noverify -noprompt

#   Install Firmware package from /Packages IF needed
current_efi_version=$(/usr/libexec/efiupdater | grep "Raw" | cut -d ':' -f2 | sed 's/ //') 
echo "current_efi_version $current_efi_version"
latest_efi_version=$(ls -La /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/ | grep "$current_efi_version")
echo "latest_efi_version $latest_efi_version"
if [ "$latest_efi_version" == "" ]; then
echo "EFI Outdated"
installer -pkg /Packages/*.pkg -target / -allowUntrusted
else echo "EFI Current"
fi

#mount Volume - MUST CHANGE VOLUME NAME TO NAME OF YOUR IMAGE
Diskutil mount "VOLUMENAME"
Sleep 2

#Copy Firstboot Files so that machine Automatically Enrolls on First Boot - MUST CHANGE VOLUME NAME TO VOLUME NAME OF YOUR IMAGE
cp /Volumes/Imager18/Data/com.imager.firstboot.plist /Volumes/VOLUMENAME/Library/LaunchDaemons/
mkdir /Volumes/VOLUMENAME/usr/local/data
cp /Volumes/Imager18/Data/firstboot.sh /Volumes/VOLUMENAME/usr/local/data/
cp /Volumes/Imager18/Data/quickadd.pkg /Volumes/VOLUMENAME/usr/local/data/
chmod 644 /Volumes/VOLUMENAME/Library/LaunchDaemons/com.imager.firstboot.plist
chmod 777 /Volumes/VOLUMENAME/usr/local/data/firstboot.sh
chmod +x /Volumes/VOLUMENAME/usr/local/data/firstboot.sh

#Set Startup disk using AppleScript
#Requires Terminal in Security - Privacy - Accessibility
#DO NOT TOUCH MACHINE WHILE THIS IS HAPPENING

osascript -e 'tell app "System Preferences" to Activate'
Sleep 2
osascript -e 'tell app "System Preferences" to set current pane to pane id "com.apple.preference.startupdisk"'
Sleep 3
osascript -e 'tell app "System Events" to tell process "System Preferences" to click radio button 2 of radio group 1 of scroll area 1 of group 1 of splitter group 1 of window 1'
osascript -e 'tell application "System Events" to tell process "System Preferences" to click button 1 of window "Startup Disk"'
Sleep 1
osascript -e 'tell app "System Events" to tell process "System Preferences" to set frontmost to true'
Sleep 2
osascript -e 'tell app "System Events" to keystroke return'
exit 0

Fully Automated Checklist:
1.) USB Drive with HFS+ High Sierra Installed (NOT APFS)
2.) Root Enabled
3.) Root set to Autologin
4.) Script set to run on Login (Easiest way is just drag it in to login items)
5.) APFS Image in /Configurations
6.) Firmware Package in /Packages
7.) Optional: quickadd.pkg in /Data

Congratulations you have a USB that you will boot to and 4-5 minutes later when it is done you will have a freshly imaged machine on 10.13 with the correct Firmware and APFS!

MY IMAGER: https://tinyurl.com/APFSimager
LINK FIXED

To use: Download DMG and restore to USB Thumb drive.
Place Firmware package in /Packages
Place quickadd.pkg in /Data
Place APFS Container image in /Configurations

If you do not want to use Quickadd portion of imager simply delete the /Data folder.

1 ACCEPTED SOLUTION

cruncx
New Contributor

Thanks for this

can you upload your image again

View solution in original post

40 REPLIES 40

chrisdaggett
Contributor II

Updated so it does not care about image name or package name for simplicity and fix Setting startup disk. **(Setting startup disk no longer works via scripting using bless or systemsetup due to SIP. Workaround created using Applescript. Requires Terminal is in Security - Privacy - Accessibility on imager)

a_stonham
Contributor II

Hi Chris, how do you handle non SSD (Fusion, Spinning disks etc) based macs as APFS is only supported on SSDs. Would you not be better of doing an in place upgrade in an Apple supported fashion to get to 10.13. Then you can reimage directly to 10.13 as needed.

Or just creating a bootable USB installer.

With /Applications/Install macOS High Sierra.app/Contents/Resources/createinstallmedia

chrisdaggett
Contributor II

@a.stonham The only Apple computers we have that are non-ssd are 2009 White macbooks, those are 100% imaged (and can't take 10.13 anyway).

If I were to image HFS+ 10.13 I would use a 10.11 USB Imager (pre-SIP) this allows you to things like use bless for setting startup disk. (what I did previous to 10.13 / HS) and works perfectly fine for imaging HFS partitions anyway. You wouldn't have to deal with APFS or containers, or the firmware as that only applies to APFS.

Doing an in-place upgrade is a ludicrous amount of time when you are talking 950 machines for one building :).

georgecm12
Contributor III

Very interesting. While admittedly frowned on by Apple, they really haven't given any good alternatives at this time for large volume lab/classroom deployments, so this may help get us by until they do. I'll have to give this a try in our tech lab.

Thanks!

scottlep
Contributor II

For the different device firmware packages, has anyone been able to determine how specific they are in regards to the hardware? Meaning is the firmware package the same across each Model Identifier, or can it vary amongst the same Model Identifier depending on the components that are used like brand or size of SSD drive, etc?

chrisdaggett
Contributor II

@scottlep In my testing it has not made a difference regarding size or brand of SSD, only SSD vs Fusion vs Mechanical. (since mechanical and Fusion drives do not support AFP and do not require the firmware update)

Nix4Life
Valued Contributor

Hi nation, We are setting this up for someone that wanted one solution for thin and re-image to High Sierra, Working with gregnagle's bootstrappr, we modified the script to support re-imaging and thin imaging. This is all done from recovery mode. For re-imaging we are restoring 10.13 hfs dmg created with autodmg(w/localadmin and 1st boot pkg) via http, entering in the device name and rebooting. For thin imaging, use bootstrappr as per original documentation. restores are taking between 4/6 mins. We are right now in the process of testing APFS, will update post once we are done.This is working well until Apple releases the promised changes

chrisdaggett
Contributor II

@Nix4Life Would definitely love to see what you have come up with to compare. 1st boot package via HTTP is interesting as well :).

For me the biggest factor was full automation. My goal (mostly completed) is to boot a machine to USB, and in a few minutes have a freshly installed 10.13, and enrolled in MDM, with no user interaction.

Nix4Life
Valued Contributor

hey @chrisdaggett,
just to circle back. We were able to get apfs restored and working. we are piecing this together. I cant take full credit as its a mashup of Greg N's bootstrappr and Rich T's first boot generator and a bunch of admins around the world figuring this out. we will script it to be 99% automated, minimal input by the techs(mount dmg, enter hostname). So the steps are the same: create autodmg afps with (localadmin,munki,first boot). boot into recovery. do a http restore(4-6 mins),mount volume/containers, reboot, pull down packages. They are still looking at MDM solutions, so once they have it we will bake that in. both restores were tested on 10.12.6 machines. They are not in rush, we just wanted to get something ready if and when they decide. As always until Apple makes changes or breaks things.

mkulin11
New Contributor

FYI in my testing as of 02/28/2018 I updated to the latest version of Sierra 10.12.6 and the firmware update was pushed from the app store. (This method may still potentially work if you don't have time to update to 10.12.6 or are running El Cap, although I have not tried the standalone firmware update in El Cap. (Now, with the latest firmware, NetResotre of High Sierra 10.13.3 works like a charm.)

Nix4Life
Valued Contributor

Hi Nation, just a FYI,

the above method is still working for us using 10.13.4 with AutoDmg 559beta

L

ryan_er
New Contributor II

Hi Nation,

Does anybody know, if I wanted to get a non 10.13 computer onto 10.13 with a fresh install, will I still need to use the above methods?

Use case: We are currently upgrading everybody to 10.13, but for those computers sitting in the stock room that are 10.12, I want to deploy it with 10.13 (fresh image like a brand new computer). I'd hate to have to format the drive with a fresh 10.12, and then run the high sierra install from the app store, this would take forever.

Thoughts?

Thanks!
Ryan

CasperSally
Valued Contributor II

@ryan.er If you have SSD drives, I'd suggest getting to APFS so you can take advantage of future benefits APFS brings (at least startosinstall -erasedisk). Here Apple lays out their supported methods of installation for macOS.

Netinstall works, but you have to support netinstall which Apple is pushing off to open source projects. Apple did publish a migration guide for getting Netinstall to work on macOS, but I'd hate to support that long term. At least with 10.13.4, don't waste your time trying to use automated netinstall as in my testing it left some SSD machines HFS.

We have a few thousand macs we need to get from 10.12 --> 10.13 (APFS) this summer. We want to stick with apple supported methods, so we're using bootable installers on USB drives. macOS install time varies from 25-45 minutes depending on the hardware (for us, 2014/2017 Airs are 25 minutes and 2015/2016 8GB Airs are 35-45 minutes).

What really is frustrating is jamf doesn't support startosinstall so far in any way with their tools. We're paying a lot of money for jamfs tools and open source tool imagr has supported a wipe of the drive, convert to APFS, and loading macOS via supported startosinstall command (which updates firmware) since OCTOBER. Here we are in April and jamf still is shrugging every time I ask them how they're going to support startosinstall.

You can use the above methods that @chrisdaggett and @Nix4Life have put a lot of time into get working. They're not supported by Apple, but probably will work great and are faster. imagr is another (albeit slower option), but it is using apple approved methods to get clients to APFS and 10.13.

I really hope no matter what 3rd party option people are using to get to 10.13, they are asking their jamf reps where they are with startosinstall support.

PS - there's this blog post that could be used once you get machines to 10.13 to "erase all contents and settings." It requires you're APFS, and again, I'd like to see some supported documentation from the jamf side on supporting something like this.

marklamont
Contributor III

I can not get autologon with root to work on a build disk. i tried using the commands above with no luck. tried with and without a password, anyone got any good ideas? My disk is 10.13.3 at the moment.

jjbauer81
New Contributor

I was able to extract and build the FirmwareUpdateStandalone.pkg. But upon installation, I get an error, the installation failed. "The installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance." What did I do wrong?

daniel_behan
Contributor III

@CasperSally I have the script from that blog set in a policy with a custom trigger for "reimage"

I packaged an AppleScript application and left it in /Library/CompanyName for support techs to run. The AppleScript simply runs the shell command to run the custom trigger. The Application is set to warn all that the machine will be reimaged.

marklamont
Contributor III

@chrisdaggett a useful check to build into your script would be to check if the firmware update is already applied. I found this somewhere else a while back and it seems to work. This will be run from the boot disk and inside the script used to install the firmware, just use the output in an if statement.

testEFIState () { current_efi_version=$(/usr/libexec/efiupdater | grep "Raw" | cut -d ':' -f2 | sed 's/ //') echo "current_efi_version $current_efi_version" latest_efi_version=$(ls -La /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/ | grep "$current_efi_version") echo "latest_efi_version $latest_efi_version" if [ "$latest_efi_version" == "" ]; then echo "EFI not upto date" efiCheck="pass" else echo "EFI upto date" efiCheck "fail" fi }

psousa
New Contributor

Having the same issue as @jjbauer81 . I was able to extract and build the FirmwareUpdateStandalone.pkg. But when I go to install it on a 10.12 machine, I get the same error he/she did.

mulcahyaudio
New Contributor

i had this working on friday when i left work, i reimaged my computer with it, it works very well! now this morning with 0 changes now it wont lay down my image it's saying there isnt enough space to lay down the image. so frustrated!!!

chrisdaggett
Contributor II

One update, When capturing the image make sure you do it form a machine using 10.13.3 or lower. Apple has botched something in 10.13.4+ with HDutil/Diskutil and it will fail to scan/restore!

Also realized after some further testing that I had to make some tweaks to the imaging script so that has bee updated in the OP.

upworkadmin
New Contributor

@chrisdaggett I'm having a difficult time wrapping my head around this:

"you will have a freshly imaged machine on 10.13 with the correct Firmware and APFS!"

Do you mean a factory version of the image? Or an image with apps, settings, etc.
What's the purpose of doing this way?
What issues or pain points is this method addressing?

chrisdaggett
Contributor II

@upworkadmin I mean with apps, settings etc.. You could just as easily use this method for a factory image though (just do a fresh install and take an image before doing anything else)

When you run as many customizations as we do, with 2000+ laptops, it makes things much easier and smoother. It saves enormous amounts of time and alleviates MANY points of failure. Every time you have a seperate package, or script, etc.

I can have a machine fully reimaged exactly the way we need them in under 5 minutes. Simply can not be done with fresh install/packages/etc.. As discussed if this isn't your cup of tea that is perfectly fine, for many of us this is the best way to get what we need done. I am not doing a fresh install on 2k machines at 40m a wack (before customization/packages/etc). Doing it the Apple approved method would take me over an hour per run. Right now I can do ~50-60 machines at a time (by myself) and have an entire round done in about 5 minutes. Not an hour+ to get the same 50-60 done. When you are doing this on 2k machines, by yourself, that matters :-D. Literally have had ZERO issues with imaging across any version of OSX/macOS, regardless of what Apple states. Like the OP says though, this is not approved, and not for everyone. I just share for others that want/need some of this method.

AVmcclint
Honored Contributor

@chrisdaggett DILLY DILLY! Apple has lost the focus on Enterprise. This is evidenced by the fact that they keep removing all the tools that make Mac admin's lives better. "Having true server grade hardware to run a Server version of OSX makes IT managers happy? too bad we're killing the XServe. Your Server software (10.6.8) does exactly what you need and is stable as hell? Too bad we're going to start the long painful road of crippling it. Having your own DNS, Mail, Netboot, Software Update server with easy to use management is perfect for small IT departments? Too bad we're just going to toss those out the window. 5 minute imaging saves you time and money? You can kiss that goodbye too."

chrisdaggett
Contributor II

@marklamont In case anyone else goes to use it there is an Equal sign missing in the script :).

Also the up to date, and not up to date, are backwards. (the pass and fail are correct)

Should be:

efiCheck="fail"

chrisdaggett
Contributor II

I uploaded my new imager for those that want to mess with it or take a peak. Also updated OP with script updates and updated instructions. https://tinyurl.com/yacat44e

To use: Download DMG and restore to USB Thumb drive.
Place Firmware package in /Packages
Place quickadd.pkg in /Data
Place APFS Container image in /Configurations

If you do not want to use Quickadd portion of imager simply delete the /Data folder.

pfrancois
New Contributor II

Hey Chris,

First of all...thanks for this resource! Now, for the newbie question. I'm new to Jamf and unfamiliar with their imaging process. I used Deploystudio in the past.

So I have mostly iMacs from Late 2013 to present. Most are running Fusion drives, but a few have mechanical drives. So no SSDs. I just want to wipe the iMacs and get them to a fresh copy of 10.13 and get picked up by the Jamf server via Apple's School Manager, that way they get enrolled and ready to deploy the Jamf configurations/policies. Does your method here work for that? ;)

Thanks for any assistance you can offer.

chrisdaggett
Contributor II

@pfrancois That is a situation! Normally I would use the startos --eraseinstall command but that only works for APFS and only once you are already on 10.13.4+

In your case I THINK the best bet is to use AutoDMG. This will give you your clean install of 10.13 and if you are using DEP/ASM for enrollment anyway you don't need anything packaged for that. https://github.com/MagerValp/AutoDMG Obviously that isn't 100% automated since you will have to click through the User creation and enrollment, but it sounds like what you are looking for.

pfrancois
New Contributor II

@chrisdaggett That does sound best. Do you think once I drag the High Sierra installer in AutoDMG and build it, I can upload to Deploystudio and push it from there?

chrisdaggett
Contributor II

@pfrancois Absolutely, should be no issues at all there.

chrisdaggett
Contributor II

Reminder - do not compress images or it will not work. I have made images through 10.13.6 with no issues. Apple has made it so you can not resize partitions using disk util for APFS drives, so you must use:

diskutil apfs resize Container disk2s2 30g

This assumes Disk2s2 is the APFS contrainer you want to resize and 30g is the smallest you can make it, obviously YMMV.

FutureFacinLuke
Contributor II
#!/bin/sh

@pfrancois We're in a similar position to you, a mix of Fusion, HDD and SSD devices that need flattening for this years Lab Builds.

I built the installer package containing the installer .app renamed without the version number in Composer. This can be deployed and scripted either Via JAMF or to follow a 10.12 install done with DeployStudio, this method means I can effectively Image to 10.13.6 with DeployStudio

For Fusion Macs:

#!/bin/bash

# Bless Boot Drive
bless -mount /Volumes/"$2" -setBoot #Reduces the incidence of Kernel Panics during Fusion Upgrades.

# install-macOS
/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense --nointeraction --converttoapfs NO

$2 needs to be replaced with the Volume name your Mac will have when this runs, I use ${DS_COMPUTERNAME} in DeployStudioafter renaming the boot-drive the the Computer name.

For SSD or HDD Macs:

#!/bin/bash
# install-macOS
/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense --nointeraction --converttoapfs YES

I've made these available to staff as Self Service policies. For Lab Macs we now have an APFS work around for Fusion Macs.

jmcmahon1
New Contributor III

Why do I have no 'postinstall_action' directory inside of my FirmwareUpdate.pkg? Did Apple change something?

Austin_Hicks
New Contributor II

Hello @chrisdaggett ,

First off THANK YOU for putting this thing together. This is going to be a huge help, and a great solution, while we are trying to build out our thin imaging solution.

That being said I am running into the same issue as @jmcmahon1 where I am getting an error in the script that says "cp: /tmp/FirmwareUpdate/Scripts/postinstall_actions/update: No such file or directory"

Here is the whole thing if it helps:

Mounting High Sierra ESD disk image...
/dev/disk2              GUID_partition_scheme           
/dev/disk2s1            EFI                             
/dev/disk2s2            Apple_HFS                       /Volumes/InstallESD
Expanding FirmwareUpdate.pkg
Ejecting disk image...
"disk2" unmounted.
"disk2" ejected.
Copying package resources...
cp: /tmp/FirmwareUpdate/Scripts/postinstall_actions/update: No such file or directory
Building standalone package...
pkgbuild: Adding top-level postinstall script
pkgbuild: Wrote package to /tmp/FirmwareUpdateStandalone/FirmwareUpdateStandalone.pkg

It appears that the pkg is created without issue, however I just wanted to make sure that this is not something that we need to be concerned about.

chrisdaggett
Contributor II

@Austin.Hicks I apologize I just saw your post. I just tried it again and I do not get any errors.

Mounting High Sierra ESD disk image...
expected   CRC32 $1D0A7164
/dev/disk4              GUID_partition_scheme           
/dev/disk4s1            EFI                             
/dev/disk4s2            Apple_HFS                       /Volumes/InstallESD
Expanding FirmwareUpdate.pkg
Ejecting disk image...
"disk4" unmounted.
"disk4" ejected.
Copying package resources...
Building standalone package...
pkgbuild: Adding top-level postinstall script
pkgbuild: Wrote package to /tmp/FirmwareUpdateStandalone/FirmwareUpdateStandalone.pkg

Using. My current test was on 10.13.6 machine (my machine) using a 10.13.3 Install App.

I will try it again with a 10.13.6 fresh download and see if I get any errors.

#!/bin/sh
# Based on investigations and work by Pepijn Bruienne
# Expects a single /Applications/Install macOS High Sierra*.app on disk

IDENTIFIER="com.foo.FirmwareUpdateStandalone"
VERSION=1.0

# find the Install macOS High Sierra.app and mount the embedded InstallESD disk image
echo "Mounting High Sierra ESD disk image..."
/usr/bin/hdiutil mount /Applications/Install macOS High Sierra*.app/Contents/SharedSupport/InstallESD.dmg

# expand the FirmwareUpdate.pkg so we can copy resources from it
echo "Expanding FirmwareUpdate.pkg"
/usr/sbin/pkgutil --expand /Volumes/InstallESD/Packages/FirmwareUpdate.pkg /tmp/FirmwareUpdate

# we don't need the disk image any more
echo "Ejecting disk image..."
/usr/bin/hdiutil eject /Volumes/InstallESD

# make a place to stage our pkg resources
/bin/mkdir -p /tmp/FirmwareUpdateStandalone/scripts

# copy the needed resources
echo "Copying package resources..."
/bin/cp /tmp/FirmwareUpdate/Scripts/postinstall_actions/update /tmp/FirmwareUpdateStandalone/scripts/postinstall
# add an exit 0 at the end of the script
echo "" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
echo "" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
echo "exit 0" >> /tmp/FirmwareUpdateStandalone/scripts/postinstall
/bin/cp -R /tmp/FirmwareUpdate/Scripts/Tools /tmp/FirmwareUpdateStandalone/scripts/

# build the package
echo "Building standalone package..."
/usr/bin/pkgbuild --nopayload --scripts /tmp/FirmwareUpdateStandalone/scripts --identifier "$IDENTIFIER" --version "$VERSION" /tmp/FirmwareUpdateStandalone/FirmwareUpdateStandalone.pkg

# clean up
/bin/rm -r /tmp/FirmwareUpdate
/bin/rm -r /tmp/FirmwareUpdateStandalone/scripts

chrisdaggett
Contributor II

@Austin.Hicks @jmcmahon1 Confirmed the Script to build the firmware package does get an error with anything above 10.13.3 (same time Imaging stopped working as well. Seems obvious apple is trying to botch this method IMO)

So you need a 10.13.0-10.13.3 Install App to use that script.

I am going to look at it when I get back from a meeting and see if it is possible to update the script to work with newer installer apps.

jerdill
New Contributor III

I was also having the same issue where the postinstall_actions folder doesn't exist. Are we able to just use the "/tmp/FirmwareUpdate/Scripts/Postintall" instead? Whats the difference between the root postinstall and the postinstall_actions subfolder? Also what happens if we just run the Firmware Package straight out of the InstallESD file instead of going through the extra steps?

cruncx
New Contributor

Thanks for this

can you upload your image again

chrisdaggett
Contributor II

@cruncx Link fixed! Sorry about that. https://tinyurl.com/APFSimager

chrisdaggett
Contributor II

I have begun creating a Mojave 10.14.4 imager. So far it APPEARS 10.14.4 will make an image OF and Image 10.14.4 just fine. Lot of testing to do though. So far it is looking positive.

Once I have fully tested and had success I will make a new, similar, post with the link to a full imager as well as instructions for those who want to modify/create/etc..