1 person found this helpful
Spoke with Engineering and this is actually by design. If you have Secure Boot enabled, %firstboot is not supported. The reason for this is Secure Boot mandates only known tardisks can hold executable scripts, and a kickstart script is an unknown source so it can not run when Secure Boot is enabled. If you wish to continue to use %firstboot, the only option is to disable Secure Boot an then enable it after the installation. An alternative option is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (preferred method) and this way you can still customize your ESXi host after the initial installations. I have filed an internal documentation bug to add a note regarding Secure Boot and %firstboot
Just ran into the same issue.
Oh boy. Those UEFI specs are really a mess. So let me get that right: in order to be UEFI secure boot compliant as the system operator at first boot you are not allowed to execute a script? But bundling stuff in a custom *.vib and packaging that on the ISO and having it execute on first boot would be fine? How would that be any more "secure"?
Why on earth did we ever let that UEFI crap happen.
BTW: the main purpose of the ks.cfg %firstboot script is bootstrapping. This means: in most cases to do just enough so the server is available from vSphere in first place. Using the vSphere API probably is not an option for most people who are serious with %firstboot.
/EDIT: I was just able to verify that disabling Secure Boot will fix the issue. I also verified that once installed it's possible to shut down the ESXi host and turn Secure Boot back on. The ESXi will boot up just fine.
Can VMWare team help with the example or point to the right direction for the following approach? We are currently configuring host DNS/network settings post installation using kickstart firstboot section. Wanted to achieve the same behavior during secureboot where %firstboot is not supported.
An alternative option is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (preferred method) and this way you can still customize your ESXi host after the initial installations.