Skip to content

FillDefault enables containerd.user for macOS guests on aarch64 — nerdctl unnecessarily downloaded #5037

@trodemaster

Description

@trodemaster

When starting a macOS guest VM (os: Darwin) on an aarch64 host, limactl downloads the nerdctl archive (~250 MiB) even though nerdctl is a Linux container runtime and has no use in a macOS guest.

Root cause

pkg/limayaml/defaults.goFillDefault() defaults containerd.user = true for x86_64 and aarch64 architectures with no check on the guest OS:

if y.Containerd.User == nil {
    switch *y.Arch {
    case limatype.X8664, limatype.AARCH64:
        y.Containerd.User = ptr.Of(true)
    default:
        y.Containerd.User = ptr.Of(false)
    }
}

macOS guests should default to false for both containerd.system and containerd.user.

Why it surfaced now

This code path existed before, but nerdctl 2.2.2 was cached locally from prior Linux VM use so the download was skipped silently. PR #5024 bumped nerdctl to 2.3.1 — the new archive is not in cache, so the 250 MiB download now appears on every limactl start of a macOS guest.

Suggested fix

In FillDefault, gate the true default on the guest OS being Linux:

if y.Containerd.User == nil {
    switch *y.Arch {
    case limatype.X8664, limatype.AARCH64:
        if *y.OS == limatype.OSLinux {
            y.Containerd.User = ptr.Of(true)
        } else {
            y.Containerd.User = ptr.Of(false)
        }
    default:
        y.Containerd.User = ptr.Of(false)
    }
}

Or more simply: default both containerd.system and containerd.user to false whenever os != Linux.

Workaround

Explicitly set in the macOS guest YAML:

containerd:
  system: false
  user: false

Environment

  • Lima: 2.1.0-dev.20260525 (master @ 939f413)
  • Host: macOS 26.5 (25F71), aarch64
  • Guest: macOS 26.5, os: Darwin, vmType: vz

Assisted-by: Commercial LLM tooling

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions