Apple Rosetta 1

[Gaetan Boren]

errorIt says installed successfully, but if I rerun the script it tries again with the same result. If i try to run a policy that installs an Intel package it still errors out saying I need Rosetta.

I thought it might be because at one point I removed Rosetta on this one so I could use it as a test laptop. So I completely reinstalled Big Sur on it and tried again, but I still get the error. Any solutions?

Yes, this is one of the scripts that I tried. I still get the error that it's missing InstallKBytes attribute.

I've seen a couple of other people post that they've gotten this error. Someone said that manually double clicking /System/Library/CoreServices/Rosetta 2 Updater fixes it, but for me that comes back saying an error has occurred, please try again later.

I made a smart group called Macs with ARM Chip so that only those get the package installed.

I just did the command in terminal on a Macbook Pro with a M1 Pro chip. I get the exact same error when entering

I'm on an M1 mini on Monterey. I have multiple Rosetta apps running. There is no "/Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist", and there is no process with "oahd" running. There is a "/Library/Apple/usr/share/rosetta/" directory. Every Rosetta install script I have found so far looks for things that do not exist on my mini. At this point I'm not even convinced Apple will allow Rosetta to be command line installed anymore. It seems like unless someone is available to dismiss a GUI dialog box the install fails. Either way, none of the popular install scripts seem to work anymore.

I've been having issues as well with Rosetta over the last week, it's just not getting installed properly by any jamf terminal command or script. So I made a pkg of the installer instead and deploy it at as the only pkg at enrolment to ensure it gets installed. To build the Rosetta pkg do this:

Managed to get hold of the RosettaUpdateAuto.pkg.

Quick question...

We currently run a script to determine if a device is M1 or not - if yes, then "softwareupdate --install-rosetta --agree-to-license". It's set to 'Enrolment'

If I were to create a policy that's set to 'Ongoing' with the RosettaUpdateAuto.pkg as a payload - if I call its trigger from inside our Enrolment script, will it be able to run the policy even though it hasn't finished running the Enrolment policies?

Via 'sudo jamf policy -trigger rosetta' (for example).

To summarise:

In the enrollment script, I'm suggesting replace "softwareupdate --install-rosetta --agree-to-license", with "sudo jamf policy -trigger rosetta"

'rosetta' being the trigger for a policy that is 'Ongoing'

I excluded an m1 mac from the script on enrollment so that rosetta does not get installed that way anymore. Then I ran just the basic command shown below; same error. So it's not the script. I'm on jss version 10.36.1

I do think Rosetta is installing via the old softwareupdate command, if it wasn't then following policies would've failed to run also (even stuff as standard as deploying basic desktop wallpapers).

I will still test deploying our own PKG though. I've seen our DEP script halt a couple of times on M1 Pro Max devices recently. I suspected it was related to our AntiVirus (because I've already recorrected the /usr/bin/python line). Just conscious that something has changed and would rather nothing was missing from Rosetta :D

(b) I will also run a second package to deploy DEP Notify, along with the script and custom triggers.

This process has worked flawlessly on our M1 devices. I like the idea of creating a Rosetta package also, which @tommyandersson provided above. Both methods should be solid.

Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.

This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.

One such example is numpy. To provide context, I installed Python 3.9 and pip3 and then decided to use pip to install numpy. To test if Python 3.9 and numpy have been properly installed, I type in terminal python3. I next try importing numpy using the statement import numpy

I have the exact same error when trying to open other applications (eg. SonicWall Mobile Connect) from the apple app store. If anyone has any insight to how to resolve this rosetta error it would be very much appreciated.

I had the same issue on Apple Silicon (M1Pro) running on Mac OS Monterey (12.0). I installed Rosetta2 and problem persisted. I deleted and reinstalled Docker but that did not fix the problem. After reading other answers on this question, I realized that for some people, OS upgrade was solving the problem.

Verify that Rosetta is installed on your Mac. Rosetta should be installed automatically when you try to run an Intel-based application on an Apple Silicon Mac. If it's not installed, you can manually install Rosetta using the following command:

The same problem has occurred for me as well, but with Big Sur 11.5 update as another comment has pointed out before me.

What I did to fix the error was to update from Big Sur 11.5 to Big Sur 11.6.

From there the issue resolved itself for me.

I am using M1 Mac Monterey 12.3.1, I had to switch over to using Docker Compose V2. After I did this and restarted the Docker for Mac engine client app, the CLI started working again (though the buttons in the app still gave errors).

As it turns out this was an Apple software issue. (I believe it was update 11.4, but I am not 100% sure.) After doing the software update the rosetta issue disappeared and all of the software that was having problems with it earlier now function properly.

I don't notice a huge performance difference between running natively or under Rosetta, largely I suspect because I'm GPU-limited, not CPU limited - so a slightly less performant CPU doesn't impact the frame rates much at all.

On the Max, you have a much more beefy GPU (probably 32 cores, versus 16 for me), and you are probably running the CPU-based tasks on high/maximum. You aren't GPU limited like I am, so reduced CPU performance will have a more noticeable impact on your frame rates - probably bringing it down to my level of performance, and negating some of the advantages of a more powerful GPU.

I just ordered a Mac M1 Ultra (20 core cpu/48 core GPU) with 64GB memory. Wondering if I will be happy running Rosetta on it? I love the Tollis products and have most of the common plugins (AVITAB, Betterpushback, e.g.)?

I'll take the reports of significant FPS loss while running under rosetta at face value...however, that has not been my experience. based on a sterile, default install of XP12 I notice a minimal-1-2 fps- difference under every condition tested. Plugins under Rosetta may indeed make a difference;I haven't tried to find native vs intel plugins to test that possibility.

I'm running XP12 in Rosetta with essentially the same plugins as Xp11 and after tuning the settings it runs pretty well for me. I do notice the GPU is getting hit much, much harder than in XP11 at least on my install/settings- to the point where it appears to be the limiting factor- the reverse of the situation I was in with XP11 with this and my other Mac.

LR has made comments suggesting they really haven't done much performance tweaking yet, focusing on taking care of bugs and implementing new features- giving the impression there may be some improvement at some point in the future when they have the resources to look at this area.

The XP12 world is in its infancy yet...difficult to compare it to the fully matured XP11. We will just have to see where things lead as far as performance, and ARM compatible plugins. That pretty much goes for most areas of XP12 though. Sometimes hard to wait for but exciting to think of how things will advance with XP12.

The people that are reporting bigger FPS losses in Rosetta all seem to have plenty of GPU cores (higher end systems), and so are CPU bound (there is no difference in CPU performance, in the case of single-threaded apps like X-Plane, between a lowish-end M1, an M1 Pro, an M1 Max/Studio, or M1 Ultra. You just get more cores as you scale up, so the bigger machines can do more work in parallel, but single threaded performance is more or les the same across the board, and that's what counts in this use case).

On lower end machines, with less GPU cores (16 on my M1 Pro), I'm more GPU constrained - it's the GPU that's holding things back. See other threads to determine whether you are CPU or GPU constrained. So if the CPU loses performance, the GPU is still working flat-out the same, so you get very little noticeable FPS loss - these are generally the people, like me, who are saying "Huh? I definitely don't get a 25% performance drop here", and it gets a bit confusing to decode.

(Especially when you factor in that changing your graphics settings can change whether you are being CPU or GPU bound - If I reduce the GPU load, at some point I become CPU bound, and then the Rosetta FPS loss starts to affect me more in the way previously described.)

So when people specify a performance loss, make sure that people understand this is what *you see on your system with the specs you have*, it doesn't mean *everyone* will experience the same performance drops - it's a bit more nuanced than that. Someone with a similar system can expect to get similar results, but it's not a "you always lose 25% FPS running under Rosetta" thing.

3a8082e126