Boot delay for Debian images

[BDelacour]

Code of Conduct

• I have read and agree to the project's Code of Conduct.

Project Version

develop

VMware vSphere

7.0.3

HashiCorp Packer

1.10.0

HashiCorp Packer Plugin for VMware vSphere

1.2.3

Guest Operating System

Debian 12.4

Environment Details

No response

Description

When I create a VM using Debian example, the VMWare screen is stuck for some seconds at each boot whereas it is not for with the Ubuntu example.
First of all, I though it was a VMX problem (see hashicorp/packer-plugin-vsphere#360) because deleting them resolves the problem, but Ubuntu has those options and no problem.

Expected Behavior

Boot time should be instant

Actual Behavior

It takes tenth of seconds to boot, like if the bootOrder was hdd,network,debian (but hdd is already the disk holding debian...)
I entered the UEFI setup and boot order is fine on this side.

Steps to Reproduce

Deploy a VM using Debian 12 template and try to boot it

Log Fragments and Files

https://gist.github.com/BDelacour/64c14d783d02b67e2b338a3636f32106

Screenshots

Additional Context

My project is inspired from those examples but I made it more simple (for my own usage). Here are my files : https://gist.github.com/BDelacour/9393e6614bc3b1400333e53b93fff934

[slekkus75]

Facing the same issue with debian 12.4. Once pxe boot times out, a hit on the escape key in the console loads grub.
Is there a solution to this?

[tenthirtyam]

I'll address it when I'm able to provide it some attention along with another Debian related item. This will be prioritized after the current pull requests.

[tenthirtyam]

Please retest on the latest in the develop branch.

[BDelacour]

I'm not using Ansible this way, but I saw your commit 5bc79f6 and wrote it by myself.
Unfortunately, this does not fix the boot delay. vSphere successfully shows Other 5.x or later Linux (64-bit) as Guest OS but delay's still here

I did some research and I see a main difference between Ubuntu's and Debian's EFI Grub implementation :

• Ubuntu has a /boot/efi/EFI/boot option and a /boot/efi/EFI/ubuntu one
• Debian only has a /boot/efi/EFI/debian option

I'm currently working on this hypothesis

[tenthirtyam]

Did you set:

boot_wait = var.vm_boot_wait

e.g.:

boot_wait = "2s"

[BDelacour]

Yes, I tried with, without.. and same for boot_order :(

[BDelacour]

Oh god, I think I found a solution (and may be "the solution", I'll let you decide).

I searched a lot on Ubuntu's side to understand what was changing. Ubuntu is more permissive with the UEFI configuration. It keeps a legacy /boot/efi/EFI/BOOT alongside the new /boot/efi/EFI/ubuntu option, and it allows booting directly from the disk without using the ubuntu boot option.
Debian on its side only has a /boot/efi/EFI/debian option, it means that overriding the bootOrder in the .vmx forces the firmware to boot on the disk without respecting the grub configuration.

If we set

boot_order = "-"

as the Cleanup function does (see govmomi codebase), the firmware handles it dynamically and nicely

I told myself (believe me, I'm sane)
"So, why doesn't it work when we remove boot_order to let the plugin handle it temporarily ?"

Well, the cleanup function is called after the VM is converted to a template. When we don't set convert_to_template = true,bios.bootOrder is not present in the .vmx file and the boot is instant. But if we have a template, the .vmtx file keeps the temporary bios.bootOrder and we have the delay.

And anyway, forcing it to - disables the temporary bootOrder and it shortens the build by ~30s-1min because the post-install reboot is instant instead of being buggy.

[alb-dev]

@BDelacour I tested your workaround but without any success. boot_order = "-" still ends in the stuck pxe boot. Did you disable to boot_wait also?

[BDelacour]

@alb-dev No, I didn't need to. Did you check your vmx file, bios.bootOrder and bios.hddOrder should not be present

[alb-dev]

@alb-dev No, I didn't need to. Did you check your vmx file, bios.bootOrder and bios.hddOrder should not be present

Looks like that worked. The 30s PXE-Boot wait seems still to be present. Is it possible that this whole problem is a combination from vsphere 7 and debian 12?

[BDelacour]

@alb-dev No, I didn't need to. Did you check your vmx file, bios.bootOrder and bios.hddOrder should not be present

Looks like that worked. The 30s PXE-Boot wait seems still to be present. Is it possible that this whole problem is a combination from vsphere 7 and debian 12?

I don't know, I dig some time to find this UEFI problem but I can't be sure that you have exactly the same problem

[tenthirtyam]

Is it possible that this whole problem is a combination from vsphere 7 and debian 12?

Quite likely.

[alb-dev]

After some digging i found the "problem". Vmware UEFI implements quick boot by feature. This seems to create problem in regard of the uefi boot process with debian 11/12

Following is the articel from the debian forum.
https://forums.debian.net//viewtopic.php?t=153326

After setting efi.quickBoot.enable = "FALSE". Debian boots as aspected.
Later helps during rollout with ansible/terraform. Haven´t checked how to set these variables with packer.

Don't know if patching grub directly is the better solution. At this point i found no problem by disabling uefi.quickBoot.

[tenthirtyam]

You might try:

  configuration_parameters = {
    "efi.quickBoot.enable" = "FALSE"
  }

[tenthirtyam]

You might try:

  configuration_parameters = {
    "efi.quickBoot.enable" = "FALSE"
  }

A quick test with the above results in:

sata0:0.present = "TRUE"
efi.quickBoot.enable = "FALSE"
bios.hddOrder = "scsi0:0"
bios.bootOrder = "hdd,cdrom"

However, it did not resolve the issue. I'll investigate a fix for the next update.

[tenthirtyam]

If we set

boot_order = "-"

I can confirm that the above setting does resolve the issue.

@BDelacour - since you discovered the fix, please feel free to contribute the fix following the contributing guidelines.

Ryan Johnson
Distinguished Engineer, VMware by Broadcom

[BDelacour]

If we set

boot_order = "-"

I can confirm that the above setting does resolve the issue.

@BDelacour - since you discovered the fix, please feel free to contribute the fix following the contributing guidelines.

Ryan Johnson Distinguished Engineer, VMware by Broadcom

Sorry, I didn’t see your comment before, but thank you for having fixed this ! 🔥

[github-actions]

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.