UEFI boot on vmware

[george1421]

@dejv Ok so I take it this is the first time for uefi on your campus. That is OK, it tells us where not to look.

The first thing is that you need to make sure your policy in the dhcp server is activated. Its been so long since I set it up I don’t remember, but when others have issues with the policies in windows dhcp server its because they forgot to activate the policy.

Now second bit is to try to uefi pxe boot with a real computer. This will help us eliminate vmware from the truth table.

Lastly if the fog server is on the same subnet as the pxe booting computer and the dhcp server we can use tcpdump to capture what the dhcp server is telling the pxe booting computer. That will help us spot the root of the problem. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Upload the pcap to a file share site, share it as public and then either DM me on FOG forum or post the link here and I’ll take a look at it. Once the pcap has been reviewed you can remove it from the file share site.

I’ve ordered these from the easy to less easy so start at the top first.

[dejv]

@george1421 first of all thanks for your help :):):)

-The policy on the dhcp is enabled on the dhcp of the pcs

-Booting UEFI with a real computer
I have a dell laptop and after changing from raidon to ahci I managed to boot into the fog menu, registered the machine.

The fog server and the laptops are on a different subnet. However the fog server and the vmware I have issues booting from network are on same subnet

[george1421]

@dejv said in UEFI boot on vmware:

The fog server and the laptops are on a different subnet. However the fog server and the vmware I have issues booting from network are on same subnet

OK, pxe booting to a physical machine works, but they are on a different subnet. So the problem could still be with dhcp and the local subnet. Lets have you use the fog server and tcpdump to capture a pcap (packet capture) of the pxe booting process on the vm’s subnet. You can either use tcpdump as in the article or use wireshark on a witness computer connected to the same subnet as the fog server and VM. If you use wireshark then use the capture filter of this port 67 or port 68

You can either upload the pcap or review it with wireshark. If you want to self review, look at the OFFERs packets coming back from the dhcp server. There is typical only one OFFER packet, but if you have multiple OFFERS then you might have multiple dhcp servers on this subnet. But anyway, in the DHCP OFFER, look at the ethernet header. There should be a {boot-file} field. That needs to be ipxe.efi. Also look down in the dhcp options, there should be a dhcp option 67 value. That needs to be set to ipxe.efi.

[dejv]

@george1421 Basically I went into the server room and connected the laptop to the server switch (which gives ip on the same network as the fog server and the vm)

However it is not booting into the fog menu, it is booting into the dell diagnostics
I think the issue is that it is opening the file undionly.kpxe instead of ipxe.efi?

[george1421]

@dejv said in UEFI boot on vmware:

However it is not booting into the fog menu, it is booting into the dell diagnostics
I think the issue is that it is opening the file undionly.kpxe instead of ipxe.efi?

Good debugging step. This is kind of where the truth table was taking me. Just because it works on subnet X, doesn’t mean it will work on subnet Y. It does work on subnet X so we can rule out the fog server as culprit.

You need to ensure your policies are being applied to the subnet where the VM is running. It sounds like there is no policy so its applying the default values for dhcp option 67.

[dejv]

@george1421 I am on leave and will be back on wed to try it out.

[dejv]

@george1421 Managed to get it fixed.

I followed these insturctions and found out that I had the 066 was not selected
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

thanks a lot for the help and keep up the good work.

Wishing a great Christmas and New year to all the team, and to your families and loves ones!

[dejv]

@george1421 I changed the option back from ahci to raid on exactly after image has been deployed.

However I laptop is not booting. Is there any easy way to do this without taking too much time or maybe someone to automate it?

[george1421]

@dejv said in UEFI boot on vmware:

I changed the option back from ahci to raid on exactly after image has been deployed

I guess the simple question is why would you do this? Do you need raid capabilities? There is no performance gain/loss by leaving it in ahci mode.

In theory this should work (switching between ahci mode and raid-on) before the first boot of windows as long as you have the needed intel drivers onboard the target image before you capture it. Switching between the two modes actually turning on/off different hardware. That hardware presents itself as a physically different disk controller depending on the mode. AHCI mode drivers are built directly into windows, depending on the model of hardware the raid drivers may not be.

[dejv]

@george1421 mainly I wanted to select raid on so that if a laptop hass issues and looses bios settings it will still work

Example I have a couple of HP laptops that for some reason if left not being used for a couple of days they loose bios settings even if they have battery life :S