hashicorp/packer · error

provisioner failed to be started and did not error: %s

Error message

provisioner failed to be started and did not error: %s

What it means

After starting the provisioner plugin, Packer got a nil provisioner back with no error — a state the code comments as 'seems unlikely'. Because Packer cannot proceed with a nil provisioner, it raises this defensive error naming the provisioner type.

Source

Thrown at packer/core.go:262

			strings.Split(rawP.Type, "-")[0],
		)

		if sugg := didyoumean.NameSuggestion(rawP.Type, c.components.PluginConfig.Provisioners.List()); sugg != "" {
			err = fmt.Errorf("Did you mean to use %q?", sugg)
		}

		return cbp, err
	}

	provisioner, err := c.components.PluginConfig.Provisioners.Start(rawP.Type)
	if err != nil {
		return cbp, fmt.Errorf(
			"error initializing provisioner '%s': %s",
			rawP.Type, err)
	}
	// Seems unlikely that a provisioner doesn't start successfully without error
	if provisioner == nil {
		return cbp, fmt.Errorf(
			"provisioner failed to be started and did not error: %s", rawP.Type)
	}

	return c.generateCoreBuildProvisionerWithProvisioner(rawP, rawName, provisioner)
}

func (c *Core) generateCoreBuildProvisionerWithProvisioner(rawP *template.Provisioner, rawName string, provisioner packersdk.Provisioner) (CoreBuildProvisioner, error) {
	cbp := CoreBuildProvisioner{}

	// Get the configuration
	config := make([]interface{}, 1, 2)
	config[0] = rawP.Config
	if rawP.Override != nil {
		if override, ok := rawP.Override[rawName]; ok {
			config = append(config, override)
		}
	}
	// If we're pausing, we wrap the provisioner in a special pauser.

View on GitHub (pinned to eb36e3c3e4)

Solutions

  1. Check that the provisioner type is not shadowed by a misregistered custom plugin with the same name.
  2. Reinstall/rebuild the plugin binary providing that provisioner type.
  3. File a bug with plugin maintainers if a stock provisioner reproduces this (it indicates a Start() returning nil,nil defect).
  4. As a workaround, verify plugin discovery with `packer plugins installed` and use an alternate provisioner type if available.
Defensive patterns

Strategy: try-catch

Try / catch

if _, err := core.Build(name); err != nil {
    if strings.Contains(err.Error(), "failed to be started and did not error") {
        // indicates plugin registry defect; report/log the provisioner type
        return fmt.Errorf("broken plugin install for %s: reinstall", pType)
    }
    return err
}

Prevention

When it happens

Trigger: PluginConfig.Provisioners.Start(rawP.Type) returns (nil, nil). This indicates a plugin registry/builtins misconfiguration where the Start call silently yields no provisioner implementation. Raised from generateCoreBuildProvisioner during Core.Build.

Common situations: Custom or vendored plugin builds where a builtin is registered but its factory returns nil; internal plugin-wiring bugs rather than user template mistakes; broken plugin builds distributed with empty implementations.

Related errors


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