Re-enable Rosetta

[knarewski-livelink]

Rosetta was disabled in podman-machine-os due to incompatibility with newer kernel versions, however the issue appears to be fixed in MacOS 26.

I confirmed that Rosetta works on my MacOS 26 by manually running steps from rosetta_activation.sh.

I'm not sure how much grace period you want to leave for people to update their OS, but this issue should help with visibility, especially with podman-desktop not mentioning, that Rosetta doesn't work at the moment.

Podman Desktop UI suggests, that Rosetta will be enabled

---

Loosely related note: once I enabled Rosetta, I started seeing buildx errors caused by another issue, which is fixed in master, but not yet released as stable. I managed to fix it in two ways: either using moby/buildkit:master or applying the "disable SELinux" workaround.

[baude]

We have not re-enabled Rosetta by default because Sequoia is unfortunately the dominate OS being used by people especially in enterprise environments.

[Luap99]

I am not sure I want to enable it again by default. It is clear that Apple did not care about this bug for 6+ months leaving us in a really bad spot. And when they finally fixed it in in macos 26 they refused to backport said fixes to the older (still by them supported) OS versions.

As such I don't want to have that turned on just to break again. Second there is the point of podman 6 which will default to using libkrun which cannot use rosetta.

As such I think defaulting to qemu makes more sense. Yes some things work better with rosetta and are even faster there but the same goes into the other direction of some things working with qemu but not rosetta.

I guess the only advice I can give people is do not rely on these emulation layers at all if you can avoid it.

[benoitf]

could we enable rosetta if we detect OS's version is >=26. podman cli has access to the version of the env so when initializing the VM it could say 'enable rosetta by default as it'll work'
if OS version < 26, do not initialize it with rosetta enabled

[Luap99]

Well it means adding ugly version checks which I hate because they become stale quickly. And it ultimately doesn't address my concern of this breaking again.

I think it is better to be left as opt in though I agree the way we disabled it was not optimal as it ignores the containers.conf setting. So maybe the better thing is make sure containers.conf has it off by default and when turned on by a user or PD then we enable it in the VM so podman doesn't need to be in the business of version checks.

[baude]

depending on how this is done, we would also need to verify the provider is applehv; and we would need to work out the behavior of what we do if it's set in conf but we're using something like libkrun . the easy answer is to ignore but i can see a user wondering why they have it in conf but its not being honored.

[baude]

@Luap99 do you want me to capture this as a piece of work to do ?

[Luap99]

@baude sure, I think for libkrun we always ignored that setting anyway. The code in podman should also still be there. I think the only thing missing would be to make the default in containers.conf false and then update the unit file here gain to not require the additional rosetta-enabled marker file work around I used.

[tomkel]

For now, I created a minimal ansible file:

- name: Enable rosetta
  hosts: localhost
  become: true
  tasks:
    - name: Create empty file /etc/containers/enable-rosetta
      ansible.builtin.file:
        path: /etc/containers/enable-rosetta
        state: touch

    # trick to reboot control plane
    - name: reboot
      ansible.builtin.command: /usr/bin/systemctl reboot
      async: 1
      poll: 0
      ignore_errors: true

And I init podman machine with:

> podman machine init --rootful --playbook ~/.config/containers/rosetta.yml --now

I checked the journal logs and I don't think the reboot interrupts anything important first-boot related. playbook.service seems to run almost last, After=ready.service but before network up and time sync.

[baude]

For now, I created a minimal ansible file:

• name: Enable rosetta
  hosts: localhost
  become: true
  tasks:

  • name: Create empty file /etc/containers/enable-rosetta
    ansible.builtin.file:
    path: /etc/containers/enable-rosetta
    state: touch

  trick to reboot control plane

  • name: reboot
    ansible.builtin.command: /usr/bin/systemctl reboot
    async: 1
    poll: 0
    ignore_errors: true
    And I init podman machine with:

podman machine init --rootful --playbook ~/.config/containers/rosetta.yml --now
I checked the journal logs and I don't think the reboot interrupts anything important first-boot related. playbook.service seems to run almost last, After=ready.service but before network up and time sync.

if that works, that's a nice idea. thanks for sharing.

[tnk4on]

Regarding re-enabling Rosetta — I think it would be better to keep it disabled. Since libkrun is expected to become the default backend, Rosetta support will not be available there due to technical and legal constraints. I wrote a report explaining why:

https://tnk4on.github.io/libkrun-rosetta/

I've also posted a summary in the Podman discussions: containers/podman#28297

[tomkel]

I discovered rosetta-activation.service, here's a simpler ansible file

- name: Enable rosetta
  hosts: localhost
  become: true
  tasks:
    - name: Create empty file /etc/containers/enable-rosetta
      ansible.builtin.file:
        path: /etc/containers/enable-rosetta
        state: touch

    # rosetta-activation.service runs /usr/local/bin/rosetta-activation.sh
    # has ConditionPathExists=/etc/containers/enable-rosetta
    - name: Restart rosetta-activation.service
      ansible.builtin.systemd_service:
        name: rosetta-activation.service
        state: restarted

    # to verify, podman machine ssh "cat /proc/sys/fs/binfmt_misc/rosetta"

[paschun]

Regarding re-enabling Rosetta — I think it would be better to keep it disabled. Since libkrun is expected to become the default backend, Rosetta support will not be available there due to technical and legal constraints. I wrote a report explaining why:

https://tnk4on.github.io/libkrun-rosetta/

I've also posted a summary in the Podman discussions: containers/podman#28297

Your report claims that activating rosetta is a DMCA violation? Using rosetta as it was intended via its external API is not "circumventing TPM". I don't think you should be using AI to generate reports like this. It works by creating a bunch of plausible-sounding claims, that doesn't mean it's correct. LLMs are also sycophantic. If you ask it to generate a report finding legal issues, it will happily make stuff up. If you ask it to generate a report finding there are not legal issues, it will do that just the same.

[tnk4on]

@paschun

Your report claims that activating rosetta is a DMCA violation?

The report is about libkrun, not about AppleHV/vfkit. It specifically explains that Rosetta works normally through Apple's Virtualization.framework (which is what vfkit uses) — but libkrun does not use Virtualization.framework. It uses its own hypervisor implementation via Hypervisor.framework.

To make Rosetta work under libkrun, you must reverse-engineer and replicate Rosetta's proprietary verification protocol — a handshake that Apple has not documented or made available as a public API. I know this because I'm the author of containers/podman#21670, the original PR that integrated Rosetta into Podman. As the author, I have complete code-level understanding of how Rosetta integrates with Podman — from the Virtualization.framework shared directory setup, through binfmt_misc registration, to the guest-side activation flow. Building on that, I implemented a fully working Rosetta integration for libkrun in a private repository. That implementation required reverse-engineering undocumented Apple code, which is precisely why it cannot be published.

The report does not say "activating Rosetta is a DMCA violation." It says that replicating Apple's proprietary verification mechanism in a non-Apple VMM raises legal concerns. These are fundamentally different statements. Section 7 of the report explicitly documents how other projects (vfkit, Docker Desktop, UTM) use Rosetta legally through Virtualization.framework.

I don't think you should be using AI to generate reports like this.

The technical findings in the report are based on my own reverse-engineering work and hands-on implementation. If you have specific factual objections, I'm happy to address them. However, I'd recommend reading the report beyond the section titles before making assumptions about its content or authorship.