VMware Cloud Community
AdamFJS
Contributor
Contributor
Jump to solution

ESXi automated KS install with EFI Secure Boot - skipping execution of 001.firstboot_001

I am preforming an Automated install of ESXi 6.5 on a server which has EFI Secure Boot enable.  The /efi/boot/boot.cfg and using the extra flags on mkisofs/genisoimage created the customer esxi ISO.

The ISO boots and uses the KS file is located on a NFS share, but after the installation completed none of the customer configuration has been applied.

Checking the kickstart.log file it shows

     INFO UEFI Secure Boot Enabled, skipping execution of /var/lib/vmware/firstboot/001.firstboot_001

The file is present in /var/lib/vmware/firstboot/ and contains a copy of the %firstboot section of the KS.

I have not found any KB or blogs that show this issue.

Is there something extra that needs to be added to the Kickstart file to allow the firstboot script to run when using secure boot?

Reply
0 Kudos
1 Solution

Accepted Solutions
lamw
Community Manager
Community Manager
Jump to solution

Hi,

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

View solution in original post

6 Replies
lamw
Community Manager
Community Manager
Jump to solution

Hi,

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

rszymczak
Hot Shot
Hot Shot
Jump to solution

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.

coreboot.jpg

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.

Reply
0 Kudos
VjBhatt
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
harezzebra1
Contributor
Contributor
Jump to solution

VMware documentation team updated kickstart documentation for EFI Secure boot.

About the Default ks.cfg Installation Script

/s/Harshvardhan Gupta
Reply
0 Kudos
dwchan
Enthusiast
Enthusiast
Jump to solution

Sorry but just ran across the same situation, will validate this with my BIOS setting to confirm.  So if I understood correctionly, and post configuration one normally perform with ks.cfg (e.g. enable ssh, ntp, etc) are longer supported to be kick off as part of your ks.cfg if you are using UEFI Secure boot?

Reply
0 Kudos
zero_shane
Contributor
Contributor
Jump to solution

Here at RackN - we worked with VMware to develop a signed VIB that enables advanced ESXi install configuration, even during UEFI Secure Boot mode being enabled.   The product is Digital Rebar Platform (DRP).  We are an ecosystem partner.

https://partnerlocator.vmware.com/PartnerView?id=0013400001XiXvXAAV&companyname=rackn&lang=en

Reply
0 Kudos