Hard Disk not found after Deployment
-
@vanopy If you only define to you need efi-64 and efi-bc to cover all of your x64 bases.
-
@george1421 So I’m looking into this again…
I’ve adjusted everything on the DHCP as I believe it should be.
I also found an article saying that I should use vmxnet3 as the network adapter instead of the E1000, which could have difficulties with PXE Booting.I’m now getting a different error message when I’m trying the UEFI PXE Boot, I’m getting the following:
succeed to download nbp file unsuccessfulAny idea what else could be going wrong for me?
Thanks again.
-
@vanopy said in Hard Disk not found after Deployment:
succeed to download nbp file unsuccessful
Well this tells me the file name asked for was not delivered to the uefi firmware (NBP would indicate uefi firmware). If tftp is logging to syslog or its own log file (in /var/log directory) you might be able to see what file name is being requested. If not you can setup tcpdump to capture the entire dhcp/pxe booting process that will give us an idea what is going wrong. I have a tutorial for that: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
But now you know that the pxe booting client is at least getting the information needed to pxe boot. It might not be getting the right information, but at least its getting something.
-
This post is deleted! -
@vanopy You were too quick to request, I just posted a link to it in the previous post
-
@george1421 Already removed it when I saw it, thank you!
I will give it a try and get back to you. -
@george1421 Ok, I think this may have been helpful, George.
What I’m seeing is the following:
But shouldn’t it be referring to ipxe.efi instead of undionly.kpxe?
-
@vanopy said in Hard Disk not found after Deployment:
@george1421 Ok, I think this may have been helpful, George.
What I’m seeing is the following:But shouldn’t it be referring to ipxe.efi instead of undionly.kpxe?
Maybe this isn’t making any sense what I’m saying…
Anyway, this is the output I get when I perform tcpdump -i any port 67 or port 68 or port 69 or port 4011
When I enter the command which is in your tutorial, I’m getting the following error:
NFLOG link-layer type filtering not implemented. -
@vanopy Well, we can see from the tftp log that the target computer is asking for undionly.kpxe. The issue is from the NBP message you posted before, the target system is uefi based. You can not load a bios based boot loader on a uefi based system.
The quick fix would be to change dhcp option 67 to send
ipxe.efi(uefi boot loader) to the target system and then try to pxe boot it.Now I have to say 2 things.
- Did you specifically configure the vm for uefi mode? The default when a new VM is created (at least for VMWare Workstation and ESXi is BIOS mode).
- If you need to support both bios and uefi based systems in your environment and have either a linux or windows 2012 or later dhcp server there is a configuration you can use to make dynamic support for both systems functional.
Finally
“NFLOG link-layer type filtering not implemented”
What linux distribution is running on your FOG server? -
@george1421 1. Yes, I’m sure it is specifically configured for Uefi mode.
2. I have a w2012 dhcp server and thought I had it configured for dynamic support. I’ll go through all the settings again to make sure. The thing is, I can PXE boot in UEFI just fine when it’s a physical machine, it’s just the VM which is giving me trouble, but I’ll make sure to check all the settings on my DHCP server.My FOG server is running on CentOS.
-
@vanopy For reference here is the guidance on setting up a 2012 server for dynamic support for both bios and uefi systems: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy
I would make sure you have filters for both type 0007 and 0009 uefi systems (bc and x64) because both are common in environments.
The tftp logs of course show that a bios file was requested, so that may be why the vm failed to pxe boot.
