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
- Check that the provisioner type is not shadowed by a misregistered custom plugin with the same name.
- Reinstall/rebuild the plugin binary providing that provisioner type.
- File a bug with plugin maintainers if a stock provisioner reproduces this (it indicates a Start() returning nil,nil defect).
- 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
- Use official plugin releases instead of locally patched builds.
- Reinstall plugins if you override builtins with custom binaries.
- Report nil-factory regressions to the plugin maintainers.
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
- builder type not found: %s
- Did you mean to use %q?
- error initializing provisioner '%s': %s
- post-processor type not found: %s
- failed to wrap script contents: %w
AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05).
Data as JSON: /api/errors/4b08e29687ceed1d.
Report an issue: GitHub.