Probably, you need configure the time zone on the fog website.
“FOG Configuration” (above, wrench icon)
“FOG Settings” (left column)
“General Settings”->“TZ Info”

After many try&error runs, I managed to sign the files and to boot into the FOG menu with secure boot enabled. And I can deploy an image, register the host and do all the other things except boot from hard disk. Whenever I choose this option in the FOG menu he just goes back into the menu.
When I boot directly from the hard disk it works and also if I disable the secure boot option the FOG menu can boot from hard disk.

What could be the problem here? Oh and while I was troubeshooting I updated Ubuntu from 20.04 to 22.04 and FOG to 1.5.10

@Tom-Elliott That did not have an impact. still seeing ${serial} on the host list. If it helps I am also seeing at the bottom of my host management page

${pingstatus} ${host_name} ${deployed} ${image_name} ${serial}

Sorry to resurrect an old thread. I ran into this issue today and have found a resolution (at least in my case).

I had an image that was quite old that I wanted to update. The client I wanted to image was from a completely different system (a VM). I cloned over top the existing image with the VM. I got the same exact 504 error and it would eventually fail to update the database.

I created a new image in fog and assigned the new host that new image. Went through flawlessly.

It’s weird because I’ve done this in the past on multiple occasions and never had an issue. It was more than likely I created the older image (that I was just trying to clone over) on v1.5.9. I did update to v1.5.10 a couple months ago.

So if you have this same problem, try creating a new image if overwriting an old image fails with the 504 error.

@helian

Hi,

Which Distribution do you use?
there is many solutions for this Problem.

Example:
1- you have to edit your dhcp-range

I do not use the fog server as DHCP-Server. But i can help u if u have Debian Distribution 😉

nano /etc/dhcp/dhcpd.conf

find the line like this:

subnet 192.168.14.0 netmask 255.255.255.0 { range 192.168.14.10 192.168.14.100; option routers 192.168.14.1; option domain-name-servers 8.8.8.8, 8.8.4.4; default-lease-time 600; max-lease-time 7200; }

you can setup the range of DHCP-Server as u want. I will prefer from 150-230. be careful just edit the last octet do not change the your whol network.

Restart ur DHCP Server

systemctl restart isc-dhcp-server

Now you can reserve the IP-Adresses in the file DHCP-Leases. In this file you will find every Host in this network. You can use Every IP-Address under 192.168.14.150. do not use the IP-Address of the FogServer or any IP-Address which is already in used.

Nano /var/lib/dhcpd/dhcpd.leases systemctl restart isc-dhcp-server

I hope that i could help 🙂

I was able to resolve this by recreating the Storage Management Node on the master server. My master node does not host any images but it was required to have a node present for the Create New Image page to be displayed.

@tlehrian Ok so you get a BSOD with windows and under linux you get a kernel panic (same but different). So that points to a hardware issue with this computer.

I would swap memory with a known good computer, even if the mem test comes back OK. By moving parts hopefully the problem will move with the hardware.

Move other pcie attached devices like GPUs (if external) or other add in riser cards.

Now that you updated the bios, go in and reset the firmware settings back to factory defaults. In case there was a firmware setting change with the new firmware that corrects a known issue.

Sorry I can only give random ideas, but since this seems to be a hardware issues I can only make logical guesses here.

@george1421 Thanks a lot, it works !
Have a nice day and thank you again !

@kamburta I am not sure this is the right topic to be trying to bring back from the dead. There has been quite a lot (almost entirely) that’s changed about FOG since 2014.

Registering nodes ot the master is, now, automated during the installation process of a new storage node.

@mashina hd isn’t a “true” kernel argument, and as such isn’t built as an environment variable at load up. As the OS loads, the getHardDisk function will get called and make its best guess to what drive to use.

If you want the specific disk of a host to be /dev/nvme1n1, then you should set it on the host under kernel device (or if it’s always global, set fdrive=/dev/nvme1n1 on the extra args instead of hd=/dev/nvme1n1)

@professorb24 Here is a wiki page on the fog client install and setup: https://docs.fogproject.org/en/latest/installation/client/install-fog-client/

The unattend.xml file is a windows thing. There are many resources on the internet that discusses its setup: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/update-windows-settings-and-scripts-create-your-own-answer-file-sxs?view=windows-11

The unattend.xml file is an auto answer file used by the windows setup program to preanswer all of the questions that the installer might ask during installation. There are even answer file generators on the internet that you can answer a few simple questions and it will create the answer file in the proper format like this one: https://www.windowsafg.com/win10x86_x64_uefi.html (I would be careful entering your actual license key on a internet web page, just edit the answer file when you get it by hand to include your key).

I also have some tutorials on fog post install scripts. This one has code snippets at the bottom of the post that discuss the unattend.xml file and how to potentially update the file with the script. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script The way the forum works read the first post and then scroll to the end to read the second and third posts in the series.

Thanks for clarifying it.
The default bzImage kernel already had the network drivers needed for my setup (onboard Realtek NIC). I checked the WoL status of the ethernet adapter with ethtool. It showed:

Supports Wake-on: pumbg Wake-on: d

So WoL was supported, but disabled.
Then I followed this guide to enable WoL on boot: https://wiki.archlinux.org/title/Wake-on-LAN
I created the /etc/udev/rules.d/81-wol.rules file in init.xz and init_32.xz, and added this rule:

ACTION=="add", SUBSYSTEM=="net", ATTR{address}!="00:00:00:00:00:00", RUN+="/usr/sbin/ethtool -s $name wol g"

I use ATTR{address} instead of NAME, so this rule would apply to any network interface (except loopback), regardless of the interface name.
With this rule in place I can wake up computers after a shutdown task (deploy with shutdown or capture with shutdown).

TLDR; I only needed to add an udev rule to the pre-built init.xz and init_32.xz (https://github.com/FOGProject/fos/releases/latest) to enable WoL.

@atlas When it comes to opensource, the only wrong answer is one that doesn’t work. Well done!

Another hackish way would be to instead of changing the programming, you could enter a fake/but valid entry in the /etc/hosts table to point the dns entry to your internal server. This way you can use fog native code when version next comes out. But again if it worked for you it was the right answer.

Never mind, I renamed the file /opt/fog/.fogsettings and runned the installer again with ssl enabled. It’s working just fine.
Probem solved, this topic can be closed. 👍