lima-vm/lima · critical

failed to get hostname: %w

Error message

failed to get hostname: %w

What it means

Lima needs a stable machine identity for an instance and first tries the OS machine ID. When that fails it falls back to os.Hostname(); this panic wraps an error from that hostname lookup itself. It is thrown because a Go program can proceed with an empty/unknown hostname only at the risk of colliding identities, so the library aborts loudly.

Source

Thrown at pkg/osutil/machineid.go:32

	"os/exec"
	"runtime"
	"strings"
	"sync"

	"github.com/sirupsen/logrus"

	"github.com/lima-vm/lima/v2/pkg/plist"
)

var MachineID = sync.OnceValue(func() string {
	x, err := machineID(context.Background())
	if err == nil && x != "" {
		return x
	}
	logrus.WithError(err).Debug("failed to get machine ID, falling back to use hostname instead")
	hostname, err := os.Hostname()
	if err != nil {
		panic(fmt.Errorf("failed to get hostname: %w", err))
	}
	return hostname
})

func machineID(ctx context.Context) (string, error) {
	if runtime.GOOS == "darwin" {
		ioPlatformExpertDeviceCmd := exec.CommandContext(ctx, "/usr/sbin/ioreg", "-a", "-d2", "-c", "IOPlatformExpertDevice")
		ioPlatformExpertDevice, err := ioPlatformExpertDeviceCmd.CombinedOutput()
		if err != nil {
			return "", err
		}
		return parseIOPlatformUUIDFromIOPlatformExpertDevice(bytes.NewReader(ioPlatformExpertDevice))
	}

	candidates := []string{
		"/etc/machine-id",
		"/var/lib/dbus/machine-id",
		// We don't use "/sys/class/dmi/id/product_uuid"

View on GitHub (pinned to dd909d0973)

Solutions

1. Ensure a valid machine ID exists (e.g. write a UUID to /etc/machine-id on Linux) so the hostname fallback is never reached.
2. Verify the container/VM has a proper UTS namespace and a set hostname (run `hostname` in the same environment).
3. If running in a restricted container, allow the uname/sethostname syscalls or run with a normal namespace (e.g. docker run without a custom seccomp profile).
4. As a last resort set a hostname explicitly in the environment before starting lima.

Example fix

// before: container started with --security-opt seccomp=unconfined but no uts namespace
// after: ensure machine-id exists so hostname fallback is not needed
$ uuidgen > /etc/machine-id
$ hostname myhost

// Linux: ensure a machine ID exists so the hostname fallback (and its panic) is never hit
if _, err := os.Stat("/etc/machine-id"); err != nil {
    id, _ := uuid.NewRandom()
    os.WriteFile("/etc/machine-id", []byte(strings.ReplaceAll(id.String(), "-", "")), 0o444)
}

// error 860 is a panic, so use recover
func safeMachineID() (id string, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("machine id panic: %v", r)
        }
    }()
    return osutil.MachineID(context.Background())
}

When it happens

Trigger: os.Hostname() returns a non-nil error during the fallback path of the lazy machineID resolution — i.e. the machine ID file was unreadable/empty AND the kernel hostname lookup failed.

Common situations: Running in a stripped-down container or chroot with no /etc/machine-id (or /etc/sysidcfg etc.) and a broken/unset UTS namespace; extremely restricted seccomp profiles blocking uname; corrupted /proc/sys/kernel/hostname on Linux.

Related errors

• no machine-id found, tried %v
• --condition=boot is only supported on macOS
• failed to register instance %#q to start at login: %w
• failed to disable the autostart entry for instance %#q: %w
• failed to start the instance %#q via systemctl: %w

AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01). Data as JSON: /api/errors/0ebbd303a1c443da. Report an issue: GitHub.