What causes "failed to start scanner: %s" in hashicorp/packer?

Inspect the wrapped communicator error to distinguish connection loss from shell spawn failure.

failed to start scanner: %s

Error message

failed to start scanner: %s

What it means

Returned by runScanner (provisioner/hcp-sbom/provisioner.go:738) when comm.Start fails to launch the rendered scanner command on the remote host. This is a transport/session-level failure — the command never ran, so no exit status exists. It wraps the underlying communicator error describing why Start failed.

Source

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

		elevatedCmd, err := guestexec.GenerateElevatedRunner(cmdStr, p)
		if err != nil {
			return "", fmt.Errorf("failed to generate elevated runner: %s", err)
		}
		cmdStr = elevatedCmd
	}

	log.Printf("Executing: %s", cmdStr)

	// Execute scanner
	var stdout, stderr bytes.Buffer
	cmd := &packersdk.RemoteCmd{
		Command: cmdStr,
		Stdout:  &stdout,
		Stderr:  &stderr,
	}

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

	cmd.Wait()

	// Log output
	if stdout.Len() > 0 {
		ui.Say(fmt.Sprintf("Scanner stdout: %s", stdout.String()))
	}
	if stderr.Len() > 0 {
		ui.Say(fmt.Sprintf("Scanner stderr: %s", stderr.String()))
	}

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

	return outputPath, nil
}

View on GitHub (pinned to eb36e3c3e4)

Solutions

Inspect the wrapped communicator error to distinguish connection loss from shell spawn failure.
Re-run the build; transient SSH drops are the most common cause and often succeed on retry.
Check guest sshd/WinRM limits (MaxSessions, MaxStartups; WinRM MaxShellsPerUser) and raise if you run many provisioners concurrently.
Verify communicator settings (host, port, user, key/password, use_sftp vs scp) and network/firewall stability between Packer host and guest.
Run with PACKER_LOG=1 to see the exact communicator-level failure before Start.

Example fix

// before: flaky SSH drops mid-build
ssh_handshake_attempts = 10
// after: keep the session alive and allow more handshake time
ssh_handshake_attempts = 30
ssh_keep_alive_interval = "5s"

Defensive patterns

Strategy: retry

Validate before calling

// Pre-flight: confirm the guest accepts a command session before the build step
// e.g. ssh -o BatchMode=yes user@host 'echo ok' must succeed

Try / catch

if err := comm.Start(ctx, cmd); err != nil {
    // transient session loss is common: retry once after backoff
    return "", fmt.Errorf("failed to start scanner: %w", err)
}

Prevention

Raise ssh_handshake_attempts and set ssh_keep_alive_interval.
Check guest sshd MaxSessions/MaxStartups and WinRM MaxShellsPerUser.
Stabilize network/firewall rules between Packer host and guest.
Retry the whole build once on transient communicator failures.

When it happens

Trigger: Calling `packer build` when the SSH/WinRM session cannot spawn the command: connection dropped before Start, SSH channel could not be opened, the guest rejected the session, or the shell specified by the communicator is unavailable.

Common situations: SSH keepalive/timeouts killing the session mid-build (long downloads before this step); WinRM session limits on concurrent shells; guest sshd restarted or MaxSessions exhausted; communicator misconfiguration (wrong port/user) surfacing only at this command.

Related errors

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