hashicorp/packer

[Proxmox-iso] Bad boot order prevents post installer steps

Asharas opened this issue · 10 comments

Asharas commented

Overview of the Issue

When packer creates the VM the boot order is (no bootdisk), any CD-ROM, any net.
Once the installation is complete and the machine reboots, this boot order makes it load the iso again thus preventing further steps.
This problem is quite recent as I didn't experience it few months ago. Probably due to a Proxmox update since I updated packer when trying to troubleshoot this.

Reproduction Steps

Run the build

Packer version

Packer v1.6.5

Simplified Packer Buildfile

https://gist.github.com/Asharas/e1959e39995a9d5d43bfccb5e6a5045b

Operating system and Environment details

Machine running packer: Debian Buster x64
Proxmox hypervisor: PVE 6.2-15

Log Fragments and crash.log files

https://gist.github.com/Asharas/3dd1e199eab599b855cd895bb2bd02b5

RemiDesgrange commented

Same here with 1.6.3. Im currently downgrading pve in order to see if it's a new version of pve could break stuff.

EDIT: That was quick 😄 I downgraded qemu-server=6.2.14, pve-manager=6.2-4 and pve-qemu-kvm=5.1.0-2.

No idea if it's packer (or more likely https://github.com/Telmate/proxmox-api-go ) which sends malformed infos or not.

  • 👍1
RemiDesgrange commented

I can't see (but not a go dev) how to debug network calls made by proxmox-api-go in packer. In terraform-prrovider-proxmox, which use the same lib, TF_LOG=DEBUG output the HTTP calls made, don't know if it's possible with packer

Asharas commented

Thanks for the packages version numbers, works like a charm now.

Packer only seem to have the env var PACKER_LOG but it doesn't display the requests content.
I tried to find them on the hypervisor but with no avail

loloolllool commented

The issue seems to me that the "cdn" hardcoded boot order set by the packer proxmox builder is no longer compatible with Proxmox new way to set boot orders. A workaround could be passing the boot field to allow the end user to set it in the packer file, like this loloolllool@2bdfd53
Said workaround also allow the user to not specify the boot field at all, which will tell Proxmox to use it's get_default_bootorder behavior, meaning this workaround could be a non breaking change for the packer proxmox builder.

Asharas commented

Would it be possible to have packer get the disk type from the disks object? (but maybe it should be an issue for proxmox-api-go
Say the user specifies order=disk0 it'd get the value from disks[0]type (sorry if this is badly explained, not a dev).
This could also be the default if option is absent.

resmo commented

same issue with 1.6.5, tested nightly 1.6.6. with

 "boot": "order=scsi0;ide2",

solves the issue.

  • 👍1
  • 🎉2
resmo commented

just a side note:

even though with unmount_iso: true set, the iso seems to get unmounted at the finish but IMHO should be unmounted on the first reboot. that would IMHO, also fix the issue.

  • 👍2
Deleted user commented

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.