4 Replies Latest reply on May 17, 2019 10:14 PM by PBensonNet

    Different Installers Not Working w/PXE Boot of UEFI Hosts

    PBensonNet Novice

      Hoping that someone can help me determine what is incorrect with my environment. I can currently install ESXi 6.7 u2 via a PXE boot solution using TFTP. The problem that I am facing is that I cannot choose different installers using folders named after the hosts MAC addresses as described in step 8 of the VMware documentation.


      Here is what I have done so far using the 8 steps in the documentation as my guide:


      1) DHCP configured with TFTP option for PXE boot.
      2) This step was not applied, because it does not apply to UEFI hosts.
      3) Copied bootx54.efi to root of the TFTP server and named it mboot.efi.

      4) Created a folder for the ESXi image in the root of the TFTP server.
      5) Copied the contents of the ESXi image to the folder created in step 4.
      6) Modified the boot.cfg file as directed to by step 6.
      7) This step was not applied, because I want to solve this issue and add scripted kickstart configs based on the MAC of the host.
      8) Everything works for a default install, but this is the step where suddenly things just don't seem to jive. I created the folders named after the MAC addresses of the hosts using the correct naming convention. I added a boot.cfg file to these folders. Each boot.cfg file has a custom title, including the default boot.cfg, so I know which boot.cfg is being applied to the PXE boot. I've have left the boot.cfg in the root of the TFP server and that booted the default option. I removed the boot.cfg file from the root TFTP server, but the PXE install fails when it cannot find the file even though I have the MAC address folders with their own customer boot.cfg files.


      I'm going to try updating the image with the latest ESXi patches. I've already updated the firmware for every device used in the process (the hosts, DHCP server & TFTP server). Security permissions for the MAC folders is the same as the root TFTP directory.


      Any other ideas as to what I should double check? Looking forward to hearing what others think the problem might be.

        • 1. Re: Different Installers Not Working w/PXE Boot of UEFI Hosts
          jburen Hot Shot

          Some TFTP servers only serve the root directory to clients and not the sub folders. I had that issue with Windows WDS that was used as the TFTP server. What TFTP server do you use?

          • 2. Re: Different Installers Not Working w/PXE Boot of UEFI Hosts
            PBensonNet Novice

            Thanks jburen for the suggestion! I can't rule out anything at this point, so I'm trying to figure out a way to test the TFTP server. Here are the reasons why I don't think it is the TFTP server:


            1) Files are being retrieved from the ESXi subdirectory with the build image for a default install.
            2) A tftp command to retrieve a copy of the boot.cfg file from one of the MAC subdirectories is successful.


            Were you able to do these types of requests with the TFTP server setup that you mentioned? The way I understand how the PXE for UEFI works is that when the ESXi host boots it will first boot using the contents of the root TFTP folder, and then search for a folder with a name matching the MAC address within the root TFTP server. If that is the case, then being able to do a successful get with TFTP like I can should rule out the TFTP server.


            That being said, I am going to build a second TFTP server and point the DHCP server to it. This is my home lab, so currently I am using a QNAP NAS appliance which includes a TFTP server. I'll build a TFTP server on a Linux distro, point DHCP at it, and see if that solves the issue.

            • 3. Re: Different Installers Not Working w/PXE Boot of UEFI Hosts
              jburen Hot Shot

              I did some research and found this article: https://rudimartinsen.com/2018/06/09/customizing-esxi-installation-with-kickstart-files-and-pxe-boot/


              Try the MAC address folder with a prefix of 01- (zero one hyphen)

              • 4. Re: Different Installers Not Working w/PXE Boot of UEFI Hosts
                PBensonNet Novice

                jburen - You sir, are a genius!


                I first went down the route of trying another TFTP server. This actually was a good exercise to do. I was using the QNAP for both TFTP and DHCP, and that was due to the convenience of the solution but my intention was to always move those onto a Raspberry Pi eventually and have the QNAP be dedicated to just iSCSI storage needs. I just moved that project ahead of schedule, and now have the TFTP and DHCP services running off of the RPi with no problems.


                Except I still could not load a different installer based upon the MAC address of the ESXi host. I was about to call it quits for the day, and logged onto here to post an update that it was still not working with a completely different TFTP server. Then I saw your post and gave it a shot. Adding the "01-" prefix is exactly what was missing. I edited the directory names, and now everything works as expected.


                This is stated in the VMware documentation that I used:


                "Create a subdirectory of /tftpboot named after the MAC address of the target host machine (01-mac_address_of_target_ESXi_host), for example, 01-23-45-67-89-0a-bc."


                I just completely missed this step. I am going to suggest to the VMware staff that a change be made to the documentation though. I'd like to see the instruction changed to the following:


                "Create a subdirectory of /tftpboot named "01-" followed by the MAC address of the target host machine (01-mac_address_of_target_ESXi_host), for example, 01-23-45-67-89-0a-bc"


                Hopefully that will prevent others from making the same mistake that I did. Serves me right for working on the home lab well past a reasonable hour! I'm glad I turned to others for a second set of fresh eyes to take a look at the problem. Now I'm back on track for fully automating my home lab being built from scratch whenever I need to.