@errbravosix said in FOG server Withou dhcp services:
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15
In your LTSP.conf Update this section to:
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15,172.16.1.15
Lets see if that gives you a successful pxe boot.
@errbravosix said in FOG server Withou dhcp services:
enable the true dhcp on my pfsense, everthing works fine
This is because pfsense is filling out both the bootp and dhcp parts for pxe booting.
dhcp just work on legacy no problem
This can be explained because the legacy bios firmware is probably only looking at the bootp fields and not only looking at dhcp fields for pxe boot info.
The issue “I think” is specifically with dnsmasq and its configuration. There is something missing to tell it to also send dhcp fields and not just boot fields. I’ve just not used dnsmasq this way before I don’t know off the top of my head the answer.
@errbravosix OK I see the problem but not sure right away how to fix.
In the ethernet header we are seeing both the next-server [172.16.1.15] and boot-file [ipxe.efi] fields populated. But there are no dhcp options of 66 and 67. The PXE roms in computers can either look at the header or at the dhcp options or both to find the boot server. Its up to the rom manufacturer where to look.
What dnsmasq is doing at the moment is only filling out the ethernet header fields, this is BOOTP method. and not filling out the DHCP method fields. In your ltsp.conf file the field match is happening because its picking ipxe.efi for the boot file. Whats missing is the sending the dhcp options too. So its 80% working, we just need the remaining 20% to have a functional solution.
@errbravosix From the DISCOVER packet I see this is an EFI system.
What I need to see is in the OFFER, the ethernet header section is there a value for next-server and boot-file? And then in the dhcp options section is there a value for dhcp option 66 and 67? Your screen shot doesn’t show that. We really don’t need the other two packets for seeing what is going wrong.
@errbravosix Your config file looks OK, typically that configuration is used for proxydhcp where dnsmasq only gives the pxe boot information and not dhcp.
But I can tell you that wireshark will be your friend here to see what the client is doing and what its being told. Take wireshark and load it on a witness computer (third computer not part of pxe booting). Set a capture filter of port 67 or port 68 to capture the dhcp info. When you pxe boot you should see the DORA process.
Discover: client
Offer: DHCP server
Request: client
Ack: dhcp server.
In the discover packet the client will tell what it is in dhcp option 93 or 94. .The dhcp server will Offer in next-server and boot-file as well as dhcp option 66 and 67 the boot info.
@Roger-Saffle Using a web browser navigate to http:<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that is the text behind the ipxe menu. There must be something wrong with the menu or short name for the custom menu.
@Enigma I asked a few questions in chat, but I’ll reask them here.
@Enigma Would you install wireshark on a witness computer connected to the same subnet (ideally same network switch) as the pxe booting computer? If yes set a capture filter of port 67 or port 68
Start wireshark, then pxe boot the target computer to the error and stop wireshark capture. There should be ~4 dhcp packets captured.
DISCOVER: This is from the client asking to configure me
OFFER: there should be one or more responders. These are the dhcp servers. These are the packets we are interested in. How many offers do you see? Do they have dhcp options 66 and 67 set as well as in the ethernet header next-server and boot-file?
REQUEST: This is the client asking for the full details from the selected dhcp server
ACK: The dhcp server saying that IP address is now yours.
If you can’t figure out the pcap upload it to a file share site and either post the link here or use FOG DM chat to send me the url and I will look at it. The answer has to be “on the wire”.
@Sebastian-Roth I think I was able to solve this with the current buildroot build by just updating what buildroot package it would download to get the new e2fsk code. But I know you are right that we should update to the latest version since FOG is using kernel 6.2 now.
@ArtemZ I would check to make sure your dhcp server has the fog server’s IP address in dhcp option 66. The error message is kind of telling me that.
@Roger-Saffle Add in shutdown=1 into your custom menu parameters. The system will power off after wiping the drive.
@professorb24 said in Can't get pxe boot on my VM (FOG):
me to give out “fake” IP addresses
I think we have a language conflict here.
To use fog, the target computers (the devices where you will deploy your image), must use dhcp to get the pxe boot information. If you don’t have dhcp available for the client computers you will have a difficult time booting over the network. With that said, we do have a method to boot the computes into FOG via a usb boot stick. In this case you will need to take the usb boot drive around to the computers to start the imaging process.
The second issue you have is WDS. Right now FOG and WDS can not both occupy the same IP subnet since they will fight each other for network booting.
@professorb24 said in Can't get pxe boot on my VM (FOG):
and it only boots into WDS
This right here is problem #1. WDS has a net boot service that overrides dhcp settings for pxe booting.
I’m only allowed to use static IP and not can’t use DHCP
Please explain this, do you mean you can’t use dhcp for the fog server ip address assignment or you can’t modify dhcp which is a primary requirement to pxe boot for the target computers?
@Enigma It appears that the isc-dhcp server (the one that FOG uses for sending dhcp info to the pxe booting clients) is not loaded. So that would explain why your clients are seeing that message, there is nothing to configure them.
You can install the isc-dhcp server after the fact too. Its easier to do when you install FOG, but can be done after fog has been installed too.
@Enigma ok lets run these commands:
netstat -an | grep :69
That should return something that looks like this 0:0:0:0:69
ps aux | grep isc
It should respond with something M says isc-dhcp
Make sure the the firewall isn’t turned on the fog host server.
@Enigma Sorry, that really didn’t answer my question. So let me ask it another way. Do you have the FOG server configured as a dhcp server? This would have been one of the questions it asked as you installed the FOG software.
@af-pw I’ve reread your OP several times and its not clicking in my head to what the problem is.
I can tell you that its possible to have 2 standalone fog servers and have the images from server A replicated to server B using the fog UI. All of the images from server A can be replicated to server B and then server B can add its own images to its own server only. But there is a caveat with this solution and its not supported by the Developers. Let me explain.
For a fog “image” there are two components. The first is the raw data files stored in /images. The second is the data base record (meta data).
You can do this by on server A going into the storage nodes and add server B as a slave storage node. Then add server B to the storage group for storage A. This will start to replicate the images from FOG server A to FOG server B. If there are images you don’t want replicated to server B, on server A go into the image definition and disable replication for that image.
Now for the caveat. The process above will replicate the raw data to server B. What it will not do is copy over the meta data. You will have to do that manually. on FOG server A go into the image definitions and export them as csv. Edit the csv with your favorite editor removing image definitions you don’t want to appear on server B. Then on server B’s web ui import the image definitions from server A. This step really only needs to be done if/when you add new images to server A that you want to see on server B.
@Enigma What device is your dhcp server for this isolated network?
@rodluz If you have an idea, I’m interested since I can’t seem to get the FOS kernel to boot on this hardware, and without having the hardware in hand its difficult to debug the issue too.
The FOS Linux original kernel configuration to start with is here: https://github.com/FOGProject/fos/blob/master/configs/kernelx64.config
@sopinv FOG doesn’t have controls to limit the number of devices that can register or the number of systems that can deploy.
This type of control is not a typical request of a FOG Administrator. What is your use case/purpose/problem you are trying to solve?