Rosetta 2 Apple

[Martha Weitz]

HelloI had an error when installing Rosetta to make zoom on Mac installation functional on an MacBook M1 pro 2021 - now uninstalling zoom and reinstall the app does not bring up the original message of installing Rosetta.

so when I attempt to launch zoom after installing - it generated a pop up message saying to allow installation of rosetta 2 - I use the fingerprint to allow it and accidental pressed to hard and end up cancel instead of allow installation - now everytime I try launching the zoom application - the error message is generated. Trying to uninstall zoom and reinstalling does not bring back the message to install rosetta 2 - such a ridiculous issue and I can't seem to be find a way to install rosetta 2 to get zoom to work on the new MacBook M1 pro

So, Smilin, I've got a new Macbook Air and when attempting to join a Zoom, was prompted to install Rosetta Stone 2. The installation failed repeatedly. I tried updating Zoom; unsuccessful and apparently irrelevant. I'm not using a language other than English. Also I haven't uninstalled Zoom, as apparently someone else did, unintentionally.

Sooooo I needed to open or update Installer and couldn't find pw for that. Back to Zoom, loop of unable to upgrade, finally several layers into a Zoom going now, Zoom just let me in in a very low tech way.

error. It 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.

Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. It also supports just-in-time (JIT) translation, but that is used relatively rarely, avoiding both the direct runtime cost of compilation, and any indirect instruction and data cache effects.

[Correction: an earlier version of this post said that every ahead-of-time translated instruction was a valid entry point. While I still believe it would be valid to jump to almost any ahead-of-time translated instruction, the lookup tables used do not allow for this. I believe this is an optimisation to keep the lookup size small. The prologue/epilogue optimisation was also discovered after the initial version of this post.]

Each x86 instruction is translated to one or more ARM instructions once within the ahead-of-time binary (with the exception of NOPs, which are ignored). When an indirect jump or call sets the instruction pointer to an arbitrary offset in the text segment, the runtime will look up the corresponding translated instruction, and branch there.

This uses an x86 to ARM lookup table that contains all function starts, and other basic blocks that are otherwise not referenced. If it misses this, for example while handling a switch-statement, it can fall back to the JIT.

To allow for precise exception handling, sampling profiling, and attaching debuggers, Rosetta 2 maintains a mapping from translated ARM instructions to their original x86 address, and guarantees that the state will be canonical between each instruction.

(The two lookups (one from x86 to ARM and the other from ARM to x86) are found via the fragment list found in LC_AOT_METADATA. Branch target results are cached in a hash-map. Various structures can be used for these, but in one binary the performance-critical x86 to ARM mapping used a two-level binary search, and the much larger, less-performance-critical ARM to x86 mapping used a top-level binary search, followed by a linear scan through bit-packed data.)

Rosetta 2 takes advantage of this by rewriting x86 CALL and RET instructions to ARM BL and RET instructions (as well as the architectural loads/stores and stack-pointer adjustments). This also requires some extra book-keeping, saving the expected x86 return-address and the corresponding translated jump target on a special stack when calling, and validating them when returning, but it allows for correct return prediction.

A lot of overhead comes from small differences in behaviour between x86 and ARM, like the semantics of flags. Rosetta 2 uses the ARM flag-manipulation extensions (FEAT_FlagM and FEAT_FlagM2) to handle these differences efficiently.

x86 shift instructions also require complicated flag handling, as it shifts bits into the carry flag. The RMIF instruction (rotate-mask-insert-flags) is used within rosetta to move an arbitrary bit from a register into an arbitrary flag, which makes emulating fixed-shifts (among other things) relatively efficient. Variable shifts remain relatively inefficient if flags escape, as the flags must not be modified when shifting by zero, requiring a conditional branch.

One non-standard ARM extension available on the Apple M1 that has been widely publicised is hardware support for TSO (total-store-ordering), which, when enabled, gives regular ARM load-and-store instructions the same ordering guarantees that loads and stores have on an x86 system.

There are only a handful of different instructions that account for 90% of all operations executed, and, near the top of that list are addition and subtraction. On ARM these can optionally set the four-bit NZCV register, whereas on x86 these always set six flag bits: CF, ZF, SF and OF (which correspond well-enough to NZCV), as well as PF (the parity flag) and AF (the adjust flag).

I believe there is room for performance improvement in Rosetta 2, by performing more inter-instruction optimisations. However, this would come at the cost of significantly increased complexity (especially for debugging and exception handling), and increased translation times.

After reading some comments I realised this was a significant omission from the original post. Rosetta 2 provides full emulation for the SSE2 SIMD instruction set. These instructions have been enabled in compilers by default for many years, so this would have been required for compatibility. However, all common operations are translated to a reasonably-optimised sequence of NEON operations. This is critical to the performance of software that has been optimised to use these instructions.

3a8082e126