packer init 报“plugin was not found”是因为 Packer 1.7+ 默认不内置插件，需在 packer.hcl 中声明 required_plugins 并确保插件目录干净或手动下载解压至 ~/.packer.d/plugins/。

packer init 为什么报错 “plugin was not found”

刚下载完 Packer，运行 packer init 就失败，常见原因是插件目录未初始化或版本不匹配。Packer 1.7+ 默认启用插件系统，不再内置 builders（如 amazon-ebs、virtualbox-iso），必须显式声明并下载。

• 确保当前目录下有 packer.hcl 或 template.pkr.hcl，且其中包含 required_plugins 块，例如：

  required_plugins {
    qemu = {
      source  = "github.com/hashicorp/qemu"
      version = "~> 1.0"
    }
  }

• 首次运行前删掉旧的 .packer.d/ 目录（尤其从老版本升级后），避免缓存冲突
• 国内用户常因网络问题卡在插件下载，可手动下载对应平台的插件二进制（如 packer-plugin-qemu_v1.0.11_linux_amd64.zip），解压后放入 ~/.packer.d/plugins/，再运行 packer init

build 时卡在 “Waiting for SSH to become available”

这是最典型的启动阶段阻塞，本质是 Packer 启动的虚拟机（QEMU/VirtualBox）没成功暴露 SSH 端口，或 cloud-init / 安装脚本没完成初始化。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

• 检查 ssh_username 和 ssh_password（或 ssh_key_path）是否与镜像中预设一致；CentOS Stream 9 默认禁用 root 密码登录，需改用 cloud_init 注入用户
• 在 boot_command 中确认是否触发了安装流程（比如 CentOS 需要 <wait><tab> inst.ks=http://...</tab></wait>），漏掉会导致系统停留在安装界面而非进入 SSH 可用状态
• 加 ssh_timeout = "20m" 避免默认 5 分钟超时误判；同时用 ssh_handshake_attempts = 10 提高容错
• 调试时启用 qemuargs = [ ["-display", "sdl"] ]（仅限本地开发），直接看到虚拟机控制台输出

如何让生成的镜像自动包含 Docker 和 systemd 服务

不能只靠 shell provisioner 装包，关键在于确保服务在镜像启动后真正生效——很多镜像构建完重启就丢失状态，是因为没有持久化 enable 操作或未清理 cloud-init。

• 在 provisioner "shell" 中执行：

  systemctl enable docker<br>systemctl set-default multi-user.target

  ，避免图形目标干扰
• 务必运行 cloud-init clean --logs（如果 base 镜像含 cloud-init），否则首次启动时会重置网络、SSH 密钥等，导致后续连接失败
• 若用 qemu builder，注意 shutdown_command 必须是 echo 'packer' | sudo -S shutdown -h now 类似真实关机命令，不能用 poweroff 或直接 kill 进程，否则 systemd 不会保存 unit 状态
• 验证方式：用 qemu-img convert 导出 qcow2 为 raw，挂载后检查 /etc/systemd/system/multi-user.target.wants/docker.service 是否存在符号链接

output_directory 输出的镜像怎么导入到 Proxmox 或 OpenStack

Packer 默认输出的是“原始磁盘镜像”，但不同平台对格式、分区、引导方式要求差异极大，直接上传大概率启动失败。

• Proxmox 要求 QCOW2 格式 + BIOS/UEFI 兼容，用 qemu-img convert -f raw -O qcow2 input.raw output.qcow2 转换，并在创建 VM 时勾选 “Use SATA controller”（避免 virtio-blk 启动无驱动）
• OpenStack 推荐使用 qcow2 + hw_qemu_guest_agent=yes，上传前需设置镜像属性：

  openstack image set --property os_distro=ubuntu --property hw_disk_bus=virtio <image-id>

• 所有平台都要求镜像内核支持对应虚拟硬件：Proxmox 用 virtio_net、virtio_blk；OpenStack 通常还需 cloud-init 支持，否则无法注入密钥和 hostname
• 别忽略 grub 配置：某些精简镜像会把 initrd 打包进内核，导致 update-grub 失效，应确保 /boot/grub/grub.cfg 中 linux 行含 console=ttyS0，否则串口日志看不到启动错误

事情说清了就结束。真正麻烦的不是写 HCL，而是每换一个 base ISO、换一个云平台、甚至换一个 Packer 小版本，boot_command 的等待时机、ssh_host_port_min/max 的范围、guest_additions_mode 的取值，都可能得重调一遍。