The POST Section

The first POST section is small, and all it does is copy the call-script.sh that we created in the PRE section (which has our ESXID in it) and our main esx-post-script.sh (which we'll come to a bit later), into the real soon-to-be-running filesystem.

ks.cfg POST 1
# This is the POST section
%post --interpreter=bash --nochroot 
cp /call-script.sh /mnt/sysimage/call-script.sh 
chmod a+x /mnt/sysimage/call-script.sh 
 
cp /mnt/usbdisk/esx-post-script.sh /mnt/sysimage/esx-post-script.sh 
chmod a+x /mnt/sysimage/esx-post-script.sh 
   

The main bit of cleverness here is that in line 2, where we start the section, we're telling the installer not to run the script as if it's on the live system, but to stay in the installer environment.  That gives us access to both the installer config files (in /mnt/usbdrive) and also the production filesystem (in /mnt/systemdrive).  That means we can copy stuff to the production system!

The second, normal, POST section will be executed by the installer in a chrooted environment, so it'll think it's actually running on the real production operating system.  The key thing here though is that we don't actually have a running ESX server, so none of the esx commands will work.  So all we do is run the call-script.sh file, which uses the esx-post-script.sh file to create a script that can be run after the reboot once all the services are running.

ks.cfg POST 2
# This is the POST section
/call-script.sh 
   

What this final step does is

1. call esx-post-script.sh with the ESXID passed as a parameter
2. esx-post-script then creates a final, customised, configuration scipt called esxfg.sh
3. Backs up the current rc.local configuration script
   
4. Adds a call to esxcfg.sh to the rc.init script (which runs after reboot)