Package Big Sur installer with Composer issue

glpi-ios
Contributor II

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

1 ACCEPTED SOLUTION

glpi-ios
Contributor II

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.

View solution in original post

42 REPLIES 42

glpi-ios
Contributor II

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.

View solution in original post

NOVELLUS
Contributor

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

Cayde-6
Valued Contributor

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

garybidwell
Contributor II

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

https://gist.github.com/e9ed319226c6da30dd633725e48a97b0

cecotter
New Contributor

@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
Contributor III

@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
Valued Contributor

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

fernando_gonzal
Contributor

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
Valued Contributor

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

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

kvnsmn
New Contributor II

@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
Valued Contributor
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
Valued Contributor

And the Jamfcloud upload failed...

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

NOVELLUS
Contributor

@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 ?
6648e63289c74a7c98f29a836dfa1a14

garybidwell
Contributor II

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
New Contributor II

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
Contributor

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
New Contributor II

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
Contributor II

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

arnoldtaw
New Contributor II
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
Contributor II

@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
Contributor III

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

luke_reagor
Contributor II

@MLBZ521 I already have. 🙂

Matt_Ellis
Contributor II

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
Valued Contributor

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

NOVELLUS
Contributor

@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
Contributor II

@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'

ckruter
New Contributor

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
Contributor

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?

NOVELLUS
Contributor

@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
New Contributor III

@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.

fernando_gonzal
Contributor

@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"?
1c1504cbcdad4589a4e0d547d3dca815

emadams
New Contributor III

@fernando.gonzalez

I will take a look.

emadams
New Contributor III

@fernando.gonzalez

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

jimmy-swings
Contributor II

@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.

nsbickhart
Contributor

@NOVELLUS I ended up packaging as a .dmg and using a policy to cache and then a policy to install. With the help of smart groups, when the installer is in the applications directory, the install will show up in self service for the user to initiate at their leisure.

The package is 12GB. I'm wondering how that will go if mass deployed. We have users on and off network (mainly off) due to the pandemic. Wondering if they'll have any issues if their on a mi-fi or DSL other than taking forever to cache or failing.

NOVELLUS
Contributor

Hi @nsbickhart , the PKG-File won't be smaller than a dmg-file, but it is easier to deploy it. That's my opinion. We deploy Big Sur (and other versions of MacOS) only inside our network enviroment, so there is no need to deploy it via DSL. Exept that, deploy by DSL would be no problem, because, our employees do have most a line from 50 MBit up to 100 MBit and more. Deploying at WAN won't be a problem anyway, too. We only have 60 clients to run and most of them are running on Big Sur, so the amount of clients to be updated to Big Sur is small.

swhps
Contributor III

Seems obvious now that I am typing it but the MegaPKGr.zsh of Big Sur did not work on my Catalina machine and did when ran on the Big Sur machine.

Musicmaker
New Contributor III

@MLBZ521 I made a DMG with the Big Sur installer. As you said; normally it should just drop the contents into the folder directory matching what you configure in Composer. It does drop the file in Applications but it's only 'zero bytes'. Unless the DMG is around 12,3GB.

arnoldtaw
New Contributor II

What if we use the full installer from Apple, which gives you a .pkg file?

Mr Macintosh has full database of all macOS Big Sur Beta and Final installers here > https://mrmacintosh.com/macos-big-sur-full-installer-database-download-directly-from-apple/