Cant pxe boot to fog.
-
@blindcat420 How did you configure the Hyper V network for your VMs? I am not much into Hyper V but for VirtualBox/XenServer and so on you always have different options, one of them usually being named something like network bridge or bridged mode. Possibly called different in Hyper V speech. If you want “external” clients like the laptop to be able to PXE boot you definitely need properly setup the network. Here you find a hint on that: https://wiki.fogproject.org/wiki/index.php?title=Installation#Hyper-V
@Wayne-Workman is the one to talk to about this I reckon.
-
Here is a picture. I have created a virtual switch with one of the network adapters. The switch is setup to provide external addresses. I dont know what happens during pxe. But I do know when vm’s boot into windows they obtain an 192.168.1.x ip address.
-
@blindcat420 Ok so you have a home lab setup here. That is fine, it just helps us set the scope on things.
Since you have a home lab and are using virtualization, what hypervisor are you using VMWare or Virtualbox? First thing you need to ensure your fog server is bridged to your physical network and not connected via nat. Also once you install your fog server it’s IP address must not change. There are hard coded bits of fog that use static ip address when fog was installed.
Also since you were not getting any real error message it sounds like the dnsmasq pxe boot stuff is not getting through. Make sure on your FOG server that you have selinux set to permissive and the linux firewall disabled.
Also there was a recent thread where someone was using virtual box for both the target and fog server. For what ever reason he could not get that setup to pxe boot. All of the signals where there bit the client kept coming up with unable to locate the boot file. He was using the isc-dhcp server and not dnsmasq so you may have better luck.
I know in my soho setup I have a home router setup and then a fog server running on a raspberry pi3 running dnsmasq. I can pxe boot clients running under virtual box (on linux mint) just fine. So you should be able to get it to work in your soho environment too.
Edit: Well dang I should have refreshed my page before answering. I see you and Sebastian have been working on it too.
-
I would suggest a packet capture on the fog server to see whats going on.
@blindcat420 do you know if you’re VM is setup to network boot via Legacy or UEFI? Do you know what version of dnsmasq you’re using? -
@blindcat420 said in Cant pxe boot to fog.:
When I try to pxe boot from a laptop with legacy booting it fails and gives me pxe-e53 no boot filename received.
@Wayne-Workman You are right the next steps is to grab a pcap of the external laptop pxe booting. That pxe-e53 error is telling. The soho routers will typically post themselves as the next server with no boot file.
@blindcat420 Follow the instructions here and post the results in this thread: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
-
I installed tcpdump and have created the output.pcap file. I dont have much experience with linux hence why I’m messing with it.
How can I move that file to one of my windows file shares? So i can upload it here?
Answers to earlier questions.
I have a few vm’s 1 uses legacy, 1 uses uefi, i have a laptop that is currently set to legacy but i can change it to uefi.
I just installed dnsmasq the other day so it would be whatever the latest version is.
-
-
So I got a update. Seems I’m getting more action after disabling the firewall on fog.
vm 1 with legacy boot gives me this now.
vm 2 with uefi boot gives me this.
the laptop gives me the same error as the first picture.
-
@blindcat420 Just a quick question. Did you disable selinux? Check with
sestatus
or withgetenforce
. This is in the CentOS 7 instructions. -
@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.
- Putty (remote ssh termial)
- 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.
-
@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
andnetstat -antup|grep 69
, and post the full output here. -
@Wayne-Workman said in Cant pxe boot to fog.:
sestatus
i disabled firewalld i assume that is different than selinux?
-
-
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 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 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.
-
So i started xinetd.
Iooks like i get the same error as before. so seems something is wrong with tftp
-
@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
-
I followed the guide to install tftp and this is what i get.
-
@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.