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.

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

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

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

https://gist.github.com/e9ed319226c6da30dd633725e48a97b0

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

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

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

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)

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

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

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

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.

And the Jamfcloud upload failed...

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

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

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/

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.

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?

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 ?

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

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.

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

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

@MLBZ521 I already have. :)

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?

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

@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