Solved Cant pxe boot to fog.

[blindcat420]

So I created a fog server the other day on my test lab following the guide located here.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

Fog is up and running and I can navigate to the fog web portal.

I also setup ProxyDHCP with dnsmasq following this guide.
https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

I assume this guide was setup for both legacy and uefi booting - i could be wrong.

When I try to pxe boot from a gen 1 vm it fails and gives me boot failure. reboot and select a proper boot device…
When I try to pxe boot from a gen 2 vm it fails and doesnt boot into fog and continues booting to windows 10. - dont see a error.
When I try to pxe boot from a laptop with legacy booting it fails and gives me pxe-e53 no boot filename received.

On all 3 machines secure boot is disabled.

I have to assume dnsmasq isnt passing the file. Is there something i’m missing maybe?

The config file is pretty much the same as in step 4 on the article.

#Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<192.168.1.3>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<192.168.1.3>
dhcp-boot=net:UEFI,ipxe.efi,,<192.168.1.3>
dhcp-boot=net:UEFI64,ipxe.efi,,<192.168.1.3>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<192.168.1.3>,proxy

Is there something I may be missing? Any help is appreciated.

[Wayne Workman]

@blindcat420 said in Cant pxe boot to fog.:

I went ahead and reran the fog installer.
That seems to have fixed it.

Sometimes it’s the simplest things… I need to remember to suggest rerunning the installer when there is strange things happening.

[blindcat420]

@Sebastian-Roth @Tom-Elliott @Wayne-Workman @george1421

I want to thank you guys for all the assistance.

[blindcat420]

@Sebastian-Roth

I went ahead and reran the fog installer.

That seems to have fixed it. I would have to say it most likely didnt finish last time. But since im a noob i dont really know what to look for. lol.

both legacy and uefi boot to pxe now.

[Sebastian Roth]

@blindcat420 said in Cant pxe boot to fog.:

When you say rerun the installer are you talking about fog?

Yes, simply do as if you’d do your FOG install normally. Answer the questions as you did last time and let it run through. I am fairly sure the installer didn’t finish last time as it would have created /tftpboot and copied the iPXE binaries to it - and many more things.

[blindcat420]

@Sebastian-Roth

I will give that a try. I dont really remember. As far as I know the install should have completed. When I try to run this command from that tftp troubleshooting page. I get this.

Doesn’t look like i have a folder called tftpboot.

When you say rerun the installer are you talking about fog?

[Sebastian Roth]

@Sebastian-Roth said in Cant pxe boot to fog.:

/etc/xinetd.d/tftp…

Here we go. Your config hasn’t been modified by the installer. Maybe the installer didn’t run all the way to the end? When it asked you to access the web interface, did it proceed further after you hit ENTER there? You can simply fix the path in the config (should be server_args = -s /tftpboot and disable = no) and restart xinetd but you might run into other issues if the installer hasn’t finished last time. The food thing is you can simply re-run the installer to do it’s thing again. It will detect that all packages are already installed and do all the config stuff for you again.

[blindcat420]

@Sebastian-Roth

[Sebastian Roth]

@blindcat420 In the xinetd status picture I see ... removing tftp and so I guess something went wrong with the configuration file. Please check /etc/xinetd.d/tftp and post the full content here. The FOG installer does manipulate that file but I have not seen something going wrong here in the last couple of months or even years.

[blindcat420]

@Tom-Elliott

I followed the guide to install tftp and this is what i get.

[Tom Elliott]

@blindcat420 can you run a simple tftp transfer test? First can you double check rpcbind is running? Usually, I see tftp in a call port created when requested rather than a constant seeing of port 69 being open. This is usually handled by rpcbind utility. Xinetd May play a role as well but I don’t know if it running alone will prove anything.

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Testing_TFTP

[blindcat420]

@Sebastian-Roth

So i started xinetd.

Iooks like i get the same error as before. so seems something is wrong with tftp

[Sebastian Roth]

@blindcat420 Ok then, TFTP is not running. Usually FOG sets it up properly when running the installer. As you are running CentOS tftp is provided by xinetd. So please run the following commands:

systemctl start xinetd
systemctl status xinetd

@Wayne-Workman SELinux is disabled already, see posts further down.

[Wayne Workman]

@blindcat420 said in Cant pxe boot to fog.:

i disabled firewalld i assume that is different than selinux?

You need to set SELinux either to permissive or disabled, instructions for that are in the CentOS 7 tutorial.

[blindcat420]

@Sebastian-Roth

@george1421

192.168.1.3 is the fog server.

for output.pcap i did run that from the fog server and it was before i disabled firewalld.

output2.pcap is after disabling firewalld.

this is what i get with those two commands.

[blindcat420]

@george1421

here is the updated pcap file.

0_1543078114945_output2.pcap

[blindcat420]

@Wayne-Workman said in Cant pxe boot to fog.:

sestatus

i disabled firewalld i assume that is different than selinux?

[Sebastian Roth]

@george1421 Very strange I think. The pcap was captured on the FOG server I suppose. Why don’t we see any packets from dnsmasq??

@blindcat420 Ok let’s check if your TFTP server is running properly. Run ps aux|grep tftp and netstat -antup|grep 69, and post the full output here.

[george1421]

@blindcat420 Ok those screen shots are very helpful in telling where its going sideways. Can you grab another pcap now that you have the linux server firewall disabled. In the previous pcap I only see dhcp “Offers” from your firewall/router and not dnsmasq.

I also suggest that you load wireshark onto a windows computer so you can review the pcap file.

Remember a dhcp/pxe boot process always follows this flow.
Client ->Discover
DHCP Server->Offer
(if you have proxyDHCP) DHCP Proxy ->Offer
Client ->Request
DHCP Server ->ACK
(end of normal dhcp)
(start of pxe booting)
Client ->DHCP Proxy
Client ->DHCP Proxy
Client ->tftp server (request file size)
Client ->tftp server (request file)

Also if you want to interact with FOG server from windows land you will need 2 applications in your tool box.

1. Putty (remote ssh termial)
2. WinSCP (remote file copy explorer)

From your picture, just for clarity 192.168.1.3 is your FOG server?

From the pictures it appears that dnsmask is working but maybe the tftp server is sending the file. The pcap will tell us a bit more where to look.

[Wayne Workman]

@blindcat420 Just a quick question. Did you disable selinux? Check with sestatus or with getenforce. This is in the CentOS 7 instructions.