@symrex On the windows side you need to drop the firewall because tftp works much like ftp in that there is a command channel from the remote to the server and then a data channel from the server back to the remote. Both links are needed to get the file.

There is not quite enough info in your OP.

1. Is the computer a bios or uefi based?
2. Is your dhcp server configured for static or dynamic boot file names?
3. What is your dhcp server? (mfg and model)
4. Is it only this specific computer that has booting issues or do you have others that have similar failures?
5. It would be really handy to know what it flashed on the screen after it gave up with ipv4. Possibly video it with a mobile phone in slow video mode?
6. Is the firmware (bios) up to date on that target computer?

@symrex said in TFTP port is closed is it normal?:

Next-Server: xxx.xxx.xxx.xxx
Bootfile: undionly.kpxe
Option 66: yyy.yyy.yyy.yyy
Option 67: boot\x86\wdsnbp.com

It looks like someone setup a Windows Deployment server/SCCM server.

Just for clarity the next server and dhcp option need to be the same (exactly) the same goes for boot file and option 67.

The first part is in the ethernet header, that is for bootp the dhcp options are for dhcp. Some clients use bootp some use dhcp so they both need to be set correctly.

@berndttoast23 In the fog installer directory there should be a log directory ./fogproject/bin/error_logs. There will be a fog_error-xxxxx.log Where xxxxx will match the version of FOG you are installing. That should give us a bit more detail on what is wrong.

I don’t have an answer for you directly, but I can tell you how FOG work and how to reverse engineer a few things.

When a computer pxe boots it downloads the iPXE boot loader that has been customized by the FOG Developers. This will be ipxe.efi or undionly.kpxe (typically). Inside that boot loader the FOG Developers placed an initial iPXE script. That script calls a script on the FOG server called default.ipxe. That script then chains into FOG via the boot.php code. If you were to write your own code for the default.ipxe file (its just a text file) that displayed some background image and that had a count down timer. If no key is pressed then it would just boot from the hard drive. If a key was pressed then you could chain to the default FOG iPXE menu by calling the boot.php file directly.

So you will want to review the file /tftpboot/default.ipxe just know when you update fog it will overwrite this file so keep a backup if you alter it.

The next bit of hackery is seeing the text behind the FOG iPXE menu (I would use this as the framework for your own custom default.ipxe file). If you go to a web browser and key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that will display the text behind the FOG iPXE menu. In there its really a program that runs based on the iPXE programming language. You will see how menu entries work as well as the default menu selection as well as how the backgound image is called (hint you don’t have to use the fog background image for your custom boot menu).

Quick fix is to update the FOS Linux kernel to 5.6.8 or later under the FOG Settings->Kernel menu in the web ui.

@smoooo If you are going to use two network adapters (recommended) before you install fog, know the linux name of the nic that will be your imaging network interface. Make sure you have static IP address mapping done on the imaging network interface. When you install FOG it will ask you which interface do you want to use. Make sure you name it correctly. Also FOG gets angry if you change the IP address of the imaging network interface after FOG is installed. So have your network configuration complete before you install FOG.

@Carbonnier-Alexandre But putting together just what I see in the screen shots, I think the target computer is a bios based one and you are sending ipxe.efi to it. Again the pcap will tell us exactly what is going on, but the error screen you showed us looks like a bios pxe boot screen but in dhcp option 67 you have ipxe.efi listed. A uefi boot screen should say something about NBF (network boot file) and not the message about PXE-M0F. At least that is what I think.

If the newer versions of refind > 0.11.0 don’t work, roll back to 0.11.0. This version of refind shipped with FOG for many years. I’m not saying this version works better, but if you upgraded 1.5.4 (which was probably shipped 0.11.0) that may indicate the change.

I’m suspecting the latest version of refind is having an issue initalizing the updated firmware. The FOG Project is at the mercy of the rEFInd project to solve this issue.

@jvenus I’m still looking into this, but looking at the pcap I can see what its doing.

For PXE part that is 100% good and the tftp is OK. iPXE starts up just fine then issues a dhcp. Now if you look at the pcap you see this cycle of discover offer discover offer and so on. What is going on here the discover asks for certain fields from the dhcp server and the fields returned from dhcp are not sufficient so iPXE queries again and the cycle repeats. What’s missing I don’t know yet. I’m getting a side by side setup.

@jvenus https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

The simple answer is that value is ONLY set when the image is updated by the FOS Linux engine. If you copied over the images from the old FOG server and the then recreated the image definitions that field will be zero. Its a display value and not used in any way related to imaging.

@JRA said in Can't WOL PCs:
It would help if you quoted the questions but we can work with that.

Understand I’m looking at this from a truth table perspective and not judging your responses.

Old one was 1.2.0, new one is 1.5.7

OK that is fine. AFIK the code for WOL has not changed since the 1.2.0 days. If you were running something from the early days (0.29 etc) it probably has.

Have tried those yes, no joy.

Ok if you have tried a different product and still no WOL, then we might rule out FOG as being faulty. I’m not saying it isn’t at fault but you have software from different vendors acting the same way.

Most if not all aren’t on the same subnet/vlan no.

OK WOL uses a directed broadcast. So your network infrastructure can control the WOL ability to work properly. I would suggest that you put a test computer on the same subnet as the FOG server and test to see if WOL works here from a cold boot of the target computer.

Didn’t know that in fact! Tried pulling the power out for a test but still no, nothing will WOL.

OK so windows probably isn’t stepping on WOL in your case.

The key to solving this is to find out where the problem isn’t so you can narrow in on where the problem might be. Its possible in your core router’s ip helper service you have an access list hard coded to the old FOG server’s IP address in an access list, firewall rule, or something. That is why the directed broadcasts of WOL are failing.

Also understand there are at least 2 standards on how WOL works. The utility I mentioned before supports both methods.

From the FOG server you can capture the WOL packets if you install the tcpdump program and run this command. Understand you will need to change the network interface name to match what your fog server’s interface name is (can be found with ip a s command and then pick the right interface). Replace eth0 in this command with your interface name.

sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)' -x | tee wol.log

Run the above command and then generate a WOL packet either from FOG or the WakeOnLAN program. To see if its actually generating the WOL magic packet. The output will be saved in the wol.log.

Here is a wiki page on WOL forwarding that may help: https://wiki.fogproject.org/wiki/index.php/WOL_Forwarding

@JRA said in Can't WOL PCs:

(on eth0 as the output of the first command gave me)

As I said you need to change eth0 to match what is installed in your fog server for its network adapter.

If you use the command I provided ip a s you will see an output that looks like this.

In my case ens192 is the right answer. That needs to replace eth0 in the command I gave you.

@JRA How old is this host OS? What OS is this fog server using? That hasn’t been a standard for years.

@JRA OK I just tested in my network, same subnet as fog server the system WOL correctly from a G3 state.

So you now test same subnet can FOG WOL a system that is configured in the firmware to wake up via the network?

@JRA Ok then in the network driver setting (same neighborhood) How about these settings.

Turn off allow computer to disable this device to save power
Turn on allow to wake leave the second one off or only magic packet method will wake it. At this point I don’t know what is the right answer. I don’t use WOL in my environment, and if I do its only for imaging computers in our dev lab.

@DJslimD1k Well its because you changed the permissions on that file. You should have edited it with root user or sudo edited the file. Change the mode back to 755 sudo chmod 755 /etc/my.cnf.d/mysql-server.cnf Then restart mysql server.

MOD Note: merged posts into this tread

@Pyrol said in FOG Kernel update: "Preparing to move to tftp server":

I’ve a problem with pxe boot not finding an interface.

Well this issue may show up in two different places. If you get to the FOG iPXE menu then you are on the right track by upgrading the FOS Linux kernel to 5.6.18 or later.

On point of your issue, if the FOG server doesn’t have create permissions on the fog web site (/var/www/html/fog) this issue might appear. Please do the following on the FOG server and post the results.

cd /var/www/html/fog/service/ipxe
ls -la

Lets see what permissions are set on those files.

Also did you set selinux to permissive? What is the results of this command?

getenforce