Builds may fail when using iso_url and other iso_* variables remain defined
#343
Comments
|
Hello, PabloRapidScale! 馃枑 Thank you for your submitting an issue for the project. We will respond soon. If you want to contribute to this project, please review the contributing guidelines. |
tenthirtyam
added
status/awaitng-response
tenthirtyam
changed the title
tenthirtyam
changed the title
|
Please note that I have properly formatted the Markdown for the variable and log content of the issue description. |
tenthirtyam
changed the title
iso_url and other iso_* variables remain defined
|
Try the following and let me know the results: Debian Example: // Removable Media Settings
iso_url = "http://cdimage.debian.org/cdimage/release/11.5.0/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso"
iso_path = ""
iso_file = ""
iso_checksum_type = "sha512"
iso_checksum_value = "6a6607a05d57b7c62558e9c462fe5c6c04b9cfad2ce160c3e9140aa4617ab73aff7f5f745dfe51bbbe7b33c9b0e219a022ad682d6c327de0e53e40f079abf66a"However, it will likely still attach a CD-ROM to a datastore with no attached media. |
|
To work around this issue, the project will likely need to incorporate some logic in the HCL config to support one or the other methods, or remove support for |
This worked, it just makes it fall into scenario 3 I mentioned in my original post. As you noted It still mounts an additional CD with no attached media. I imagine this would still fail with Windows as it will still throw the drive letters out of order causing the autounattend.xml to not be accurate anymore. |
|
I've placed this on the backlog and will review this option at a later time to see if there is a more elegant method to toggle this feature. For now, the projects defaults works as intended. If you think of a method, contributions are welcome following the CONTRIBUTING.md. |
tenthirtyam
added
priority/low
tenthirtyam
removed
type/refactor
|
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. |
Code of Conduct
Community Note
Project Version
main
VMware vSphere
7.0.3d
HashiCorp Packer
1.8.4
HashiCorp Packer Plugin for VMware vSphere
1.1.0
Guest Operating System
Debian 11.5, Windows 2022, Windows 2019, Windows 10
Environment Details
No response
Description
Builds may fail if using
iso_urlwhile leaving theiso_pathandiso_fileoptions filled in.Expected Behavior
Per Readme "The
iso_urlvariable takes presedence over any otheriso_*variables." i.e. when adding a URL location it should ignore the rest of theiso_*entries. However, if you add a value to theiso_urlvariable it will do what it normally would do like download the iso, put it in the cache, upload it, etc. but it will also mount theiso_fileas an additional disk object causing different OS versions to have to account for an additional unexpected disc.Actual Behavior
You will end up with an extra disc device and an iso attached to the specified
iso_pathandiso_filelocation regardless if the actual iso file or path exists. Depending on the OS you're deploying they may act differently in each of the scenarios below.iso_urlis not null, OS is Windows based, doesn't seem to matter ifiso_pathandiso_fileexist or notiso_fileautounnatend.xmlfails to launchF:\windows-vmtools.ps1andF:\windows-init.ps1(Server 2022)iso_urlis not null,iso_pathandiso_fileexist, OS is linux basediso_urlis not null,iso_pathandiso_filedon't exist, OS is linux basediso_pathandiso_filebut should succeed as the second boot simply finds that the device is not a valid boot target and should boot from the disk.Steps to Reproduce
Windows 2019
Windows 2022
Debian 11.5
Log Fragments and Files
Screenshots
Additional Context
No response
The text was updated successfully, but these errors were encountered: