@mwu1876 That is what I did as well, I made Rosetta run initially and reported it installed successfully. The policies after still fails to install and says Rosetta is required and needs to be installed. Not sure if a computer needs to be rebooted first after a Rosetta install.
@pbowden I did not update the OS, testing this out a fresh out of the box M1

What criteria did you guys use to flag apple m1 chip macs for your smart group?

@txhaflaire how would you package the scrip on prestage? So this will ignore intel machines and only install on m1. looks good

!/bin/bash

arch=$(/usr/bin/arch)
if [ "$arch" == "arm64" ]; then echo "Apple Silicon - Installing Rosetta" /usr/sbin/softwareupdate --install-rosetta --agree-to-license
elif [ "$arch" == "i386" ]; then echo "Intel - Skipping Rosetta"
else echo "Unknown Architecture"
fi

@mwu1876 What criteria did you use to flag apple m1 chip macs for your smart group?

you can try the criteria Architecture Type is arm64

@dmiguel Just set it as a postinstall script when creating your package and that simply it is.

@dmiguel @ccliff is correct. I only have one criteria in the smart group and it's to look for anything with an Architecture Type of "arm64". I use that smart group for several things including installing Rosetta but also for apps like Chrome which have a specific version for M1 processors.

I really hope Rosetta becoming dysfunctional after an OS update is a bug, not a feature.

You can make a smart group that filters ARM Architecture.

@mwu1876 can you describe your event trigger that kicks off after the enrollment policy installs rosetta?

is the event trigger a policy with a script, and the script then calls each policy using the (jamf policy -id ????)

You know why Self Service in M1 already with Rosetta Installed does not work when installing Intel Apps, it remains in a loop but does not install anything.

I don't know how big Rosetta2 is but if it is less than 1GB arguably it should be installed as standard, especially as all other OS components are. (Apple has not had a customisable OS installer for a very long time.)

The issue about it being 'broken' again when the OS is update is a bigger problem and frankly I consider this to be a bug, it should see it already installed and do an update for Rosetta2 as part of the OS update. Just like an OS update may also update Safari.

To fix Apple's mess here, does anyone know how to check the version of Rosetta2 that is installed? We could then have a script which compares the version to the OS version and hence then if needed trigger another Rosetta2 install command. Perhaps looking at a date stamp of an OS file would be a way? That is if the OS file is 'newer' than the Rosetta2 file then trigger another Rosetta2 install.

It would be helpful if someone could list the file paths for the various Rosetta2 components.

Sure. So here's how I have everything work. 1. Smart Group with the criteria for Architecture Type is arm64
2. You will want to create two scripts. The first is simple script to install Rosetta

#!/bin/sh
/usr/sbin/softwareupdate --install-rosetta --agree-to-license

3. The second script is to trigger all the remainder policies using sudo jamf policy -event trigger unless you're using DEPNotify.
4. Next I created a policy that only runs with the smart group for M1 processors. The triggers are Enrollment and a Custom Event called install-rosetta (just in case I need to use it manually or via another script).
5. Then I created a second policy to run after Rosetta is installed which fires off the second script that runs the remainder of the policies. That one is only set to run via Custom Event start-enrollmentinstallers.

So far everything is working. I'm testing out DEPNotify which does change how this is done but for now, it's fine.

@txhaflaire

For prestage enrollments you can create a prestage package which runs a simple script with something like below for instance

Did you actually try this?
I used Composer to create an "empty" package with a preinstall script inside. However when running this on an M1 mac without Rosetta, it says:

To install "package", you need to install Rosetta. Do you want to install it now?

so I'm back to square one.

@michael.madsen I use the following script (credit to rtrouton) in a Policy with the "Enrollment" trigger. This is scoped to all machines as the script has logic to exit if it detects an intel Mac. The policy name begins with < _00 - > forcing it to run 1st in our enrollment process. Seems to work extremely well, but of course more testing is needed. Hope this helps.

#!/bin/bash

# Installs Rosetta as needed on Apple Silicon Macs.

exitcode=0

# Determine OS version
# Save current IFS state

OLDIFS=$IFS

IFS='.' read osvers_major osvers_minor osvers_dot_version <<< "$(/usr/bin/sw_vers -productVersion)"

# restore IFS to previous state

IFS=$OLDIFS

# Check to see if the Mac is reporting itself as running macOS 11

if [[ ${osvers_major} -ge 11 ]]; then

  # Check to see if the Mac needs Rosetta installed by testing the processor

  processor=$(/usr/sbin/sysctl -n machdep.cpu.brand_string | grep -o "Intel")

  if [[ -n "$processor" ]]; then
    echo "$processor processor installed. No need to install Rosetta."
  else

    # Check Rosetta LaunchDaemon. If no LaunchDaemon is found,
    # perform a non-interactive install of Rosetta.

    if [[ ! -f "/Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist" ]]; then
        /usr/sbin/softwareupdate --install-rosetta --agree-to-license

        if [[ $? -eq 0 ]]; then
            echo "Rosetta has been successfully installed."
        else
            echo "Rosetta installation failed!"
            exitcode=1
        fi

    else
        echo "Rosetta is already installed. Nothing to do."
    fi
  fi
  else
    echo "Mac is running macOS $osvers_major.$osvers_minor.$osvers_dot_version."
    echo "No need to install Rosetta on this version of macOS."
fi

exit $exitcode

@mrheathjones Thanks, but I'm not willing to go this route just yet, as it is too much of a "hack" for me.
I honestly don't understand why Jamf didn't provide a solution for this.

For now the best solution I have heard is to put rosetta install script in prestage package

Here is what I did...

I created an "empty" package with a preinstall script like this:

I tried running this on an M1 mac where Rosetta was not installed (just run manually from desktop). However, it complained:

To install "package", you need to install Rosetta. Do you want to install it now?

However I googled for a while and found that I could expand InstallRosetta.pkg with:

pkgutil --expand "InstallRosetta.pkg" "InstallRosetta"

Then I used BBEdit to edit the file: InstallRosetta/Distribution and added: <options hostArchitectures="arm64,x86_64" />

Then I used command:

pkgutil --flatten "InstallRosetta" "InstallRosetta.pkg"

to put files back to a .pkg again.

Now when I ran the package again on the M1 mac, it didn't complain that Rosetta was missing and when it completed, it had actually installed Rosetta.

So I uploaded this package and added it to our prestage enrollment.

However it still doesn't work :(
I'm not sure why.

@michael.madsen The why: pkgbuild on Big Sur creates packages that do NOT require rosetta. pkgs build on Catalina (and older) DO require rosetta (on M1 macs)
This is independent on the content of the pkg....
see https://scriptingosx.com/2020/12/platform-support-in-macos-installer-packages-pkg/

For anyone wanting to make this stateful without using an Extension Attribute, you can create a Smart Group based on "Packages Installed By Installer.app/SWU" "Has" "com.apple.pkg.RosettaUpdateAuto" and exclude your Rosetta policy from that.

@michael.madsen curious how the proposed solution is a hack? i don't know where Jamf fits in resolving an issue that Apple should bake into their OS from the get go.

The problem with a pkg is that it either needs to be built in Big Sur or have some sort of plist/xml intended for the M1 architecture. but having script deploy through Jamf at enrollment is (or should be) a cleaner solution. In my instance I have DEPNotify deploy on enrollment complete for DEP and Manual enrollments, but I put the script as a Before in the same DEPNotify policy just to catch everything at once and it can kick off from there...having it separate may be a more appropriate choice but so far does not seem to be an issue as from the policy logs it appears to run as intended.

@walt I use an enrollment policy which contains:
- Package (DEPNotify 1.1.6)
- Script (the script to make DEPNotify do it's thing)

However DEPNotify.app is not even downloaded to the machine if it's an M1 and Rosetta isn't installed.

I don't want to have to name my policies 0something or *something to make them run before other policies - of course this is a hack.

I want Rosetta to be installed in pre-staging

@michael.madsen definitely file feedback with Apple as it should be installed natively with Big Sur at this point. You could also create a feature request with Jamf that perhaps Jamf deploys/checks for rosetta during DEP/ADE/other user enrollment.

I don't agree with the mentioned method being a hack, I mean look at Jamf in the big picture, everyone does things differently with their Jamf environment as its really choose your own adventure, I know there are feature requests to prioritize policies and other methods..so its definitely a method to accomplish what you want to do.

My suggestion is to simply create a new script with the above rtrouton script and add that to your DEPNotify policy as a Before script and it will run before the package is installed and should take care of the issue you are facing. since it's running purely as a script rather than a package (and similar to the separate policy that was recommended earlier, but my use case is its in a single policy).

Has anyone tried enrolling an M1 mac Big Sur using enrollment quickadd.pkg? And then with enrollment the Rosatta install script gets kicked off?
Does the quickadd.pkg get stopped?

@walt Thank you, this (Add script to policy as "Before") actually worked.
I already sent feedback to Apple to make Rosetta installed by default. Maybe if enough of us do, they will pay attention :-)

I use Ceremony soon to be Octory for my onboarding app, but I ran into the same problem. Rosetta2 not installed throwing an error when installing Ceremony. I made the script its own policy and run that prior to anything else, that way when/if apple decides to bake Rosetta in, I can simply retire the policy that installs it separately rather than re-packaging the Ceremony install. But as was stated, pick your own adventure. Cheers!