Package Big Sur installer with Composer issue

[glpi-ios]

Hello,

I downloaded and got the Big Sur installer which is 12.21 GB.
When I try to package it with Composer, the pkg is only 15.6MB and damaged.

I tried with Composer versions 10.25.1 and 10.26 beta.

Do you have the same problem ?

Thank you for your help

[glpi-ios · Accepted solution]

Ok, sorry. I have the answer :

Signed system volume
macOS Big Sur introduces a cryptographically signed system volume to protect against malicious tampering, which replaces the separate system volume introduced in macOS 10.15.
For IT admins, this new volume makes for a very large macOS Installer file that native macOS tools or Jamf Composer can’t build as a .pkg file, which is the most common method to deliver macOS applications. If you have Jamf or are using Jamf Composer to package the macOS Big Sur Installer to deliver via a policy, choose the option to “Create as DMG” instead of a .pkg file. macOS Big Sur’s signed system volume (SSV) raises protection of key system files beyond the reach of all current malware and should withstand the most determined attacker from altering them after the OS has booted. It also guards against inadvertent corruption and guarantees system integrity.

[Anonymous]

same here, composer made a 15.6 MB lage pkg. dmg is working well. Jamf Pro 10.25.1

[Cayde-6]

That’s a pain, so policies will need to drop the DMG and then a command to extract it 😫

[garybidwell]

Talkingmoose's MegaPKGr script will sort this out and keep it as a familiar .pkg format

https://gist.github.com/e9ed319226c6da30dd633725e48a97b0

[ctarbox]

I've been using the MegaPKGr script for a few years now with much success. Today trying to create a PKG for Ventura 13.6.1, the script is failing at this point.

*********

Succeeded creating temporary working directory

Failed creating DMG archive of Install macOS Ventura.appura.app"...

Aborting script

*******

I have tried on two systems running Sonoma and Ventura with the same results. Has anyone seen this, and hopefully, have a resolution?

[ctarbox]

To be more specifric, this is the command in the script where it is failing:

# create dmg from the app to create a single file

logmessage "Creating disk image (DMG) archive of \"$app\"..."

/usr/bin/hdiutil create -quiet "$tempDirectory/$app.dmg" -ov -volname MegaPKGr -fs APFS -srcfolder "$appPath"

logresult "Succeeded creating DMG archive of $app" "Failed creating DMG archive of $app"

[ctarbox]

I found my resolution, which was to run this script on Big Sur with HFS+

[sdagley]

Please please please don't create your own packages for macOS installers when Apple already provides them for you...

macOS Sonoma installer links: https://mrmacintosh.com/macos-sonoma-full-installer-database-download-directly-from-apple/

macOS Ventura installer links: https://mrmacintosh.com/macos-ventura-13-full-installer-database-download-directly-from-apple/

macOS Monterey installer links: https://mrmacintosh.com/macos-12-monterey-full-installer-database-download-directly-from-apple/

And thanks to Mr. Macintosh for curating those links!

[cecotter]

@garybidwell Thank you for this. It helped out so much. I had the same issues with Composer and could not figure out what I was doing wrong.

[MLBZ521]

@Cayde-6 A .dmg built with Composer should just drop the contents into the folder directory matching what you configure in Composer. No extraction needed. Unless you're attempting to use the Cache functionality or something?

[Cayde-6]

No I forgot about the options flags you set once you’ve uploaded the DMG file

[fgonzale]

Composer usually craps out on me on super big packages so last year I had to use pkgbuild to make a PKG of the Catalina installer. However, this year even pkgbuild could not handle it and it turns out that there is file limit of 8GBs for making flat packages. Trying to make a pkg of an application bundle bigger than 8GBs is fine as long as no file within is bigger than 8GBs. Unfortunately in Big Sur there is a 12GB file within the bundle.

So the easiest way, and you can skip using composer honestly, is just to make a folder on the desktop then add another folder within called Applications and drop the Big Sur installer inside that Applications folder. Go to Disk Utility and select File > New Image > New Image from Folder
Select the folder you created on the Desktop and click Choose
Click Save (leave the option as compressed and the encryption as none)

Then, just use Jamf Admin to upload that resulting DMG to Jamf and you can select that DMG as a package for your policy (it will install the Big Sur installer in the applications folder).

Of course, you still need to associate a script or a command string from files and processes to run the installer with whatever options you want (I usually do this as a separate policy to prevent blowing away the company)

[mhasman]

What about to zip .pkg manually, then upload to JSS?

And - is .pkg.zip deployment any better than .dmg?

[kvnsmn]

@garybidwell

Talkingmoose's MegaPKGr script will sort this out and keep it as a familiar .pkg format https://gist.github.com/e9ed319226c6da30dd633725e48a97b0

Sorry to chime in, how do you proceed after you have created the pkg? I ran the script, the installer was located under applications. I already updated the pkg to JAMF.

Do I deploy this with a policy and running a script afterwards? Like this: https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/ Or is the installer being executed once I deploy the package?

[tomt]

Posted: 11/13/2020 at 10:59 AM CST by garybidwell Talkingmoose's MegaPKGr script will sort this out and keep it as a familiar .pkg format https://gist.github.com/e9ed319226c6da30dd633725e48a97b0

Thanks a ton for recommending this @garybidwell . Thanks also to @talkingmoose for putting it together.

My first test attempt with a small .app failed saying not enough space available (which made no sense). This was on a Mojave machine. Moved the script to a Catalina machine and it worked flawlessly on the macOS 11 installer.

Uploading the package to Jamf Cloud for the final testing.

[tomt]

And the Jamfcloud upload failed...

Edit: Pre-zipped the file and it uploaded successfully. Testing deployment now.

[Anonymous]

@garybidwell thank you for this golden hint !! It works like a charm. With the script, written by William Smith, I was able to build a pkg from the "Install macOS Big Sur.app". But now, I am on a new challenge: Loading up the 12 GB package to our JamfPro Server (self hosted) with Jamf Admin 10.25.1 will crash the Jamf Admin Application. I found no way to upload the package with the admin-tool. Do I have to upload it manually or will there be a way to do this with Jamf Admin ?

[garybidwell]

I'm afraid im still halfway through testing my Erase & Install for Big Sur workflows to share my current method - its all work in progress still. Getting the installer on the device (without using VPP) was just the first hurdle.
I'm using Jamf Cloud and it uploaded first time then distributed then on to all our local SMB (Mac based) distribution points over the weekend
regarding Jamf Admin crashing, there may be a 8GB file limit for certain older filesystems so it could be dependent what your are using as a DP.

However what I am find is the the gatekeeper code signing check is leaving a really bad user experience when trying to do it via Self Service as even once the Big Sur installer in place im finding on a old 2013 MacBook it can take over 10-15 minutes for this process to complete even before the installer starts, which without user feedback looks like its hung.
At least double-clicking the installer in the GUI you can see the icon bounce.

From reading another Mac Admin's (Babo D's) blog I found a script to pre-check the installer but have yet had any free time since the weekend to do any further testing
(Sorry Babo/bp88, I don't know if your on jamfnation to credit directly your findings)

https://github.com/bp88/JSS-Scripts/blob/master/Trigger_Validation_For_macOS_Installer.sh

https://babodee.wordpress.com/2020/11/05/waiting-for-the-macos-big-sur-installer-to-launch/

[mherbster]

In response to NOVELLUS. I used the same script and was getting the same error. The script outputs a file called 'Install macOS Big Sur.app.pkg'. I took out the .app. I changed it to 'Install_macOS_Big_Sur.pkg' and then it uploaded for me.

[djrory]

taniguti's pull request here claims to have fixed the workflow for Big Sur upgrades

He has adjusted the "prepare-jamf-policy.sh" script to build a .DMG rather than a .pkg but I can't tell if this changes anything in the workflow, he has updated the "macOSUpgrade.sh" script as well so I am assuming this change allows for a .DMG rather than a .pkg but I'm not certain.

I've never worked with .DMGs and JAMF previously, do I need to create my own script to mount the .DMG then move the .app file to the Applications folder?

[arnoldtaw]

Thanks @mherbster

In response to NOVELLUS. I used the same script and was getting the same error. The script outputs a file called 'Install macOS Big Sur.app.pkg'. I took out the .app. I changed it to 'Install_macOS_Big_Sur.pkg' and then it uploaded for me.

I was having the same issue as @NOVELLUS and renaming the package works!

@garybidwell thank you for this golden hint !! It works like a charm. With the script, written by William Smith, I was able to build a pkg from the "Install macOS Big Sur.app". But now, I am on a new challenge: Loading up the 12 GB package to our JamfPro Server (self hosted) with Jamf Admin 10.25.1 will crash the Jamf Admin Application. I found no way to upload the package with the admin-tool. Do I have to upload it manually or will there be a way to do this with Jamf Admin ?

[luke_reagor]

It appears that Jamf Admin will crash with @NOVELLUS's error in 10.25+ if the upload has an .app.zip extension.

[arnoldtaw]

It appears that Jamf Admin will crash with @NOVELLUS's error in 10.25+ if the upload has an .app.zip extension.

@luke.reagor Not "Install_macOS_Big_Sur.app.zip". Not "Install_macOS_Big_Sur.app.pkg".

Try "Install_macOS_Big_Sur.pkg" I was able to upload it to my Jamf Admin.

[luke_reagor]

@arnoldtaw If it has an .app extension, even if it's not the only extension, then the upload will fail.
Ex. file.app.zip or file.app.dmg or file.app.pkg will all fail on the upload. The .app part needs to be removed. It appears to be a bug in Jamf Admin that needs to be fixed. Hopefully there are some official Jamf people watching this that can help get this bug squashed.

[MLBZ521]

@luke.reagor I wouldn't expect that. I would submit a support case to Jamf Support detailing the issue.

[luke_reagor]

@MLBZ521 I already have. :)

[Matt_Ellis]

I used @talkingmoose MegaPKGr script, it completed fine, but i for the life of me cannot find the .pkg it supposedly made. anyone else run into this?

[Cayde-6]

@Matt.Ellis I had that, I modified script to output the file into a specific folder instead

[Anonymous]

@Matt.Ellis and @Cayde-6 :

I ran into the same situation and found the solution:
As written in the header of the script, to get a .pkg - file, You have to call the script with the full pathnames to the script and to where the installer is stored.

"To run the script, open Terminal and enter: /path/to/MegaPKGr.zsh /path/to/large.app"

for example: sudo /Volumes/Macintosh HD/Users/username/MegaPKGr.zsh /Volumes/Macintosh HD/Applications/Install macOS Big Sur.app without any path arguments, the script will not create the pkg-file.
The pkg - file is stored at the same directory as the script is stored. (The first pathname). after the package was created successful, you have to rename it from '<filename>.app.pkg' to '<filename>.pkg' to be able to upload it with Jamf Admin to the server

[Matt_Ellis]

@Cayde-6 i was bale to get it to work after some assistance on the Git Hub page. Below is what did it for me

Not sure this is the issue but you have to follow the first comment from dev-yeet. Let’s assume your script file is in ~/Desktop/MegaPKGr.zsh and your pkg is /Applications/Install macOS Big Sur.pkg DO: 1) Open Terminal 2) Execute ’sudo /Desktop/MegaPKGr.zsh /Application/Install macOS Big Sur.pkg' DONT: 1) Open Terminal 2) cd Desktop (or cd into some folder counting the zsh file) 2) Execute ’sudo MegaPKGr.zsh /Application/Install macOS Big Sur.pkg'

[NisarFawad]

im getting this error any idea?

2021-11-20 00:23:31 Chosen folder is writable
2021-11-20 00:23:35 Disk has enough free space to build "macos.app.pkg"
2021-11-20 00:23:37 Succeeded creating temporary working directory
2021-11-20 00:23:41 Failed creating DMG archive of macos.app
2021-11-20 00:23:41 Aborting script
2021-11-20 00:23:42 Succeeded removing temporary items
2021-11-20 00:31:02 Chosen folder is writable
2021-11-20 00:31:06 Disk has enough free space to build "Install.pkg"
2021-11-20 00:31:08 Succeeded creating temporary working directory
2021-11-20 00:31:12 Failed creating DMG archive of Install
2021-11-20 00:31:12 Aborting script
2021-11-20 00:31:13 Succeeded removing temporary items

[ckruter]

Great Script! This is much more straight forward than using Composer for large packages. I'll be using this as a way to cleanly package Catalina and later Big Sur for deployment to our end users. We still have a few who are still on Mojave and need to be updated.

[nsbickhart]

I have everything working with a .dmg and the cache option. My issue is that my self service policy will initiate the upgrade from the cache and will provide a start notification and then restart and upgrade after 5 minutes. It will not show the complete notification, and it also completely ignores my maintenance and restart payload, and the jamf.log never shows the self service policy as being run.

Anybody have a solution for this method?

[Anonymous]

@nsbickhart maybe it would be good, to create two jobs. One for deploying the dmg to the client and one for running the installer. I did not test this way, because I use the "pkg-method" . The job is not for updating the client, but for reset. Because of this, I delete the whole partition and install Big Sur "from scratch".

[emadams]

@fernando.gonzalez What command string from files and processes did you use to automatically run the DMG after it drops it in the designated folder?

I can deploy the policy and the installer file will drop in the Applications folder and I have it run this script '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense' but it will not run. I tried to launch the install file manually and it will not run because it says that Apple can't identify the developer.

[fgonzale]

@emadams Oh, I would definitely make sure that when trying to run the Big Sur installer manually that you don't get a "can't identify the developer" message. It shouldn't do that. You may want to re-download your installer.

Out of curiosity do you have a Configuration Profile for Security & Privacy scoped and if so is Gatekeeper set to "Anywhere"?

[emadams]

@fernando.gonzalez

I will take a look.

[emadams]

@fernando.gonzalez

That change worked perfectly! Thank you for the profile idea.

[jimmy-swings]

@emadams

That change worked perfectly! Thank you for the profile idea.

I would not recommend reducing your security posture in this way as it allows the use of any application increasing the likelihood of malware and virus’s proliferating across your estate.