@Tom-Elliott I’ve done that. I’ll try swapping the drive but I am fairly confident that’s not the issue.

@iljared98 There is a way. The CSV will contain more information than just the Motherboard Product Name, but that is easy to clean.
On FOG, go to the Reports tab and select Inventory Report from the left side menu. Don’t change anything there, just click on Search. Download the CSV from the page using the excel sheet icon. When you open the CSV, column R should be mbproductname which is what you are looking for.

@youzersef It looks like that is for HDD I am using an SSD. I followed the steps anyway and it has changed the error but its freezing up in the same spot still. New Error

@george1421 That did the trick. Now I need to dig into why its failing to capture an image. I’ll make a different post for that though if I need to.

I had to make a correction. I meant to say pre-1Gbit internet not 10Gbit internet. We have 10G backbones (intranet) but not to the internet.

@mikael1909

Hello,
try this.

https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#example-1

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.