@RAThomas If the value is empty it shoudl think it’s false, and since it seemed to be random that’s where I got confused. But I’m glad this is working for you.

Thank you!

@george1421

thank you for your great answer. You are completely right, it is a 17-x104ng, not a fg. It was an error of me 🙂

The needed hardware id is VEN_10EC&DEV_8136

Hope that helps

Thx,
mchristo

@Selanty
I have the same problem, fresh installed Fog on Debain 12, PHP 8.2.29, Fog 1.5.10.1667.
Fog-Server is running on the same switch as the 2 Clients in one VLAN 2765. For that VLAN ip igmp is enabled.
“sh ip igmp” on that aruba switch shows:
-IGMP version : 2
-Querier Address : 10.73.65.21 (vlan-address of a second switch witch plays as querier)
-the querier ist running igmp v2

“service FOGMulticastManager status” result is:
PHP Fatal error: Uncaught Error: Non-static method FOGService::outall() cannot be called statically in /opt/fog/service/FOGMulticastManager/FOG>

unicast to that 2 clients is running.

I have done this before on a Cisco switch but it’s been a while. Thought I share my notes on what commands are needed

# Vlan131 (fog server vlan) ip helper-address 192.168.158.255 # Vlan158 (fog client on a different vlan) ip directed-broadcast 101 # ip access-list extended 101 access-list 101 permit udp host 192.168.131.149 any eq 9 * NOTE in the ACL above 192.168.131.149 is the fog server ip address # forward udp ip forward protocol udp 9 (it might say discard) # On the switch the two vlans look something like this interface Vlan131 description fog server vlan ip address 192.168.131.1 255.255.255.0 ip helper-address 192.168.131.3 (my dhcp & dns server) ip helper-address 192.168.158.255 (fog client subnet broadcast address) end interface Vlan158 description fog client vlan ip address 192.168.158.1 255.255.255.0 ip directed-broadcast 101 (extended ACL) end

Hope it helps

@vincent33 Hello, thanks for the response! I was able to change my HW so this was no longer an issue.

Hi there
If someone else reads this and they aren’t using autoexec.ipxe (just the default.ipxe like me) and still has this error I’ve got the solution that worked for me:

I had to downgrade the GRUB version from 2.12 to 2.06 in my Linux images (mostly Kali Linux).
Version 2.12 has a bug (bug #67078) which is mentioned here: https://savannah.gnu.org/bugs/?67078

The downgrade works as follows:
Create a pin file: sudo vim /etc/apt/preferences.d/grub-pin
Content of the file:

Package: grub* grub2* Pin: version 2.06* Pin-Priority: 1001

sudo apt update
Downgrade grub packages: sudo apt full-upgrade
sudo grub-install
sudo update-grub
verify the installed version: dpkg -l | grep grub-common

You can now capture and deploy the the image.

Edit: of course I am and was using the latest FOG 1.5.10.1667 with newest Kernel and Initrd versions.

@Clebboii These warnings are safe to ignore. While the REQUEST_METHOD issue you’re seeing has already been fixed in dev-branch, the dashboard page issue you’re seeing is just because sometimes the values are set, sometimes they’re not. Unfortunately there’s no real way to validate cleanly. (at least right away or easily at this point in time. But it’s not causing issues.)

I’m not seeing there being issues with the files syncing? It seems, to me, the location it’s sending the file to (192.168.140.39) isn’t accepting ftp?

@george1421 Resolved: A 3rd party package in my router was intercepting my outbound FTP connections.

Tom
I still get this error when I try to Create a New Image:
This page isn’t working
10.149.50.21 is currently unable to handle this request.
HTTP ERROR 500

Web searches says this is a server provider issue. Is there something in Fog Project that can be checked for me?

Thanks @george1421,
I haven’t setup Fog yet so was looking for a step by step guide to getting it installed and configured.

I’ve gotten a very similar set up to what you want and have tried working.

You’ll need to either rebuild the FOG version of iPXE with the shim command enabled or use a stock version of iPXE with the default.ipxe script replaced with an autoexec.ipxe script (I haven’t tested this so you mileage may vary). Once you’ve done that you can just sign your iPXE binary with your sec boot key, and save it as grubx64.efi (or see this Shim Issue or this part of the foguefi install script if you use Dell PCs.)

Finally now when you netboot, provided you also have mokmanager (mmx64.efi) in the same folder, you’ll be prompted to install your secboot key and on next boot you’ll be able to boot. iPXE with secure boot on. You will also need to sign you bzImage etc and then modify your default.ipxe script to load the shim with the shim command, and then you’ll be able to boot into fog fully!

If anyone wants I can put together a more coherent guide and I’m happy to answer any questions you have on this.

Hi @Tom-Elliott,

Currently both nodes are in the same storage group as I want to replicate images and snapins from the Master to the Normal storage Node. I read through some documentation and it seems this should still happen if they are in different storage groups. Is this true?

If so, I believe this second issue should be fixed.

@Fog_Newb probaly just typoed it and i went with it too lol.

@marcolefo Sounds like the package ‘build-essential’ should be an install target of the FOG install script? It doesn’t seem to be.

However I think my distro installs of Debian 12 and Mint 22.1 both installed that package by default.

@Tom-Elliott sounds good!