hashicorp/packer · error

OS detection command exited with status %d

Error message

OS detection command exited with status %d

What it means

detectRemoteOS runs an OS-detection command over the communicator (`uname -s -m` for SSH, `echo %PROCESSOR_ARCHITECTURE%` for WinRM) on the build machine. After the command finishes, it checks RemoteCmd.ExitStatus(); any non-zero exit status means the remote shell could not execute the command, so the provisioner aborts SBOM generation with this error. It is thrown by the hcp-sbom provisioner itself, not by the communicator.

Source

Thrown at provisioner/hcp-sbom/provisioner.go:390

			Command: "echo %PROCESSOR_ARCHITECTURE%",
		}
	} else {
		cmd = &packersdk.RemoteCmd{
			Command: "uname -s -m",
		}
	}

	var stdout bytes.Buffer
	cmd.Stdout = &stdout

	if err := comm.Start(ctx, cmd); err != nil {
		return "", "", fmt.Errorf("failed to run OS detection command: %s", err)
	}

	cmd.Wait()

	if cmd.ExitStatus() != 0 {
		return "", "", fmt.Errorf("OS detection command exited with status %d", cmd.ExitStatus())
	}

	output := strings.TrimSpace(stdout.String())
	log.Printf("OS detection output: %s", output)

	// Parse output
	var osType, osArch string
	if connType == "winrm" {
		osType = "Windows"
		osArch = strings.ToLower(output) // AMD64, ARM64, etc.
	} else {
		parts := strings.Fields(output)
		if len(parts) >= 2 {
			osType = parts[0] // Linux, Darwin, FreeBSD, etc.
			osArch = parts[1] // x86_64, aarch64, etc.
		} else if len(parts) == 1 {
			// Some systems might only return one value
			osType = parts[0]

View on GitHub (pinned to eb36e3c3e4)

Solutions

  1. Verify the build machine's shell can run `uname -s -m` (or `echo %PROCESSOR_ARCHITECTURE%` for winrm) by logging in with the same credentials and running it manually.
  2. If building Windows guests over SSH, switch the communicator to winrm so the Windows-specific detection command is used.
  3. Check the guest's login shell init files (.profile, .bashrc, /etc/profile) for commands that exit non-zero, or fix the account's shell to a valid POSIX shell.
  4. Ensure the target image includes uname (install coreutils/util-linux) or pre-populate OSType/OSArch in generated_data so detection is skipped.
  5. Inspect the Packer log for the exact exit status and any stderr from the remote command to pinpoint the failing shell.

Example fix

// before (packer template using ssh for a Windows guest)
communicator = "ssh"
ssh_username = "Administrator"

// after: use winrm so the correct detection command runs
communicator = "winrm"
winrm_username = "Administrator"
winrm_use_ssl = true
Defensive patterns

Strategy: try-catch

Validate before calling

// Packer templates can't run code before, but you can validate the guest:
// SSH into the machine with the same creds and run:
//   ssh user@host 'uname -s -m' ; echo $?   # expect e.g. 'Linux x86_64' and status 0
// For winrm targets confirm: winrs -r:host 'echo %PROCESSOR_ARCHITECTURE%'

Try / catch

// In Go code embedding the provisioner:
osType, osArch, err := p.detectRemoteOS(ctx, ui, comm, generatedData)
if err != nil {
    if strings.Contains(err.Error(), "exited with status") {
        ui.Error("OS detection command failed on remote host; check shell/uname availability")
    }
    return err // or fall back to a default OS/arch
}

Prevention

When it happens

Trigger: The remote OS-detection command returns a non-zero exit status: the target machine's default shell cannot execute `uname` (e.g. Windows SSH via cmd.exe/powershell where uname does not exist), the shell is restricted or not found, `set -e`-style profiles fail during login, or the WinRM command fails with %PROCESSOR_ARCHITECTURE% unset.

Common situations: Using an SSH communicator against a Windows guest without an OpenSSH bash/POSIX shell; a hardened/minimal image (distroless, busybox without coreutils full set) lacking `uname`; a broken login shell (bad .profile/.bashrc returning non-zero); restricted SSH accounts with forced commands or rbash blocking uname.

Related errors


AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05). Data as JSON: /api/errors/685e15a84b36cb24. Report an issue: GitHub.