hashicorp/packer · error

post-processor type not found: %s

Error message

post-processor type not found: %s

What it means

Thrown by Core.Build at packer/core.go:559 as a defensive fallback: PostProcessors.Start returned no error but a nil postProcessor, meaning the type was listed but no actual plugin factory could be produced for it. This indicates an inconsistent PluginConfig (registered name with no runnable implementation).

Source

Thrown at packer/core.go:559

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

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

				return nil, err
			}

			// Get the post-processor
			postProcessor, err := c.components.PluginConfig.PostProcessors.Start(rawP.Type)
			if err != nil {
				return nil, fmt.Errorf(
					"error initializing post-processor '%s': %s",
					rawP.Type, err)
			}
			if postProcessor == nil {
				return nil, fmt.Errorf(
					"post-processor type not found: %s", rawP.Type)
			}

			current = append(current, CoreBuildPostProcessor{
				PostProcessor:     postProcessor,
				PType:             rawP.Type,
				PName:             rawP.Name,
				config:            rawP.Config,
				KeepInputArtifact: rawP.KeepInputArtifact,
			})
		}

		// If we have no post-processors in this chain, just continue.
		if len(current) == 0 {
			continue
		}

		postProcessors = append(postProcessors, current)

View on GitHub (pinned to eb36e3c3e4)

Solutions

1. Check which component types the plugin actually ships (`packer plugins installed` / plugin docs) and use the correct component name
2. Reinstall or upgrade the plugin binary
3. If assembling PluginConfig programmatically, register the post-processor with a non-nil start function instead of only listing its name

Example fix

// before: registered name without implementation
cfg.PostProcessors = plugin.PostProcessorSet{names: ["foo"]}
// after: register the start function too
cfg.PostProcessors.Register("foo", func() packer.PostProcessor { return &FooPP{} })

// before building, ensure the registered plugin exposes a post-processor factory
if known := cfg.PostProcessors.Has(ppType); !known {
    return fmt.Errorf("post-processor %q not registered", ppType)
}

When it happens

Trigger: Core.Build reaches the `if postProcessor == nil` branch after Start succeeded — the plugin list contains the type but Start yields nil, e.g. a registry entry pointing at a plugin that exposes no post-processor factory.

Common situations: A plugin binary provides the name in its list but not a post-processor implementation (e.g. it only offers builders); a hand-crafted or corrupted PluginConfig; custom PluginConfig assembled in Go tests embedding a type that was never registered with a start function.

Related errors

• The post-processor %s is unknown by Packer, and is likely pa
• error initializing post-processor '%s': %s
• Post-processor failed: %s
• provisioner failed to be started and did not error: %s
• builder type not found: %s

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