@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!

@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?

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.

@Tom-Elliott sounds good!

Hi @rodluz

Just wanted to confirm that this update has worked. Now deploying my images in <5mins.

Thank you for your help.

@george1421 Thank you so much! I enabled portfast on the switch port, and it works on physical PCs.

Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0) Kernel Offset: disabled ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0)

But sometimes this error appears even if I haven’t changed anything in the configuration and files. Even if I update or roll back the init.xz or bzImage file to a previous version, it doesn’t help. The only thing that seems to work is setting up a completely new FOG server, but after some time, the problem can come back. How I can find right version or how I can solve this problem? Most time it error on PCs with UEFI

@uzee FOG doesn’t change or really step into the target system during deployment. You CAN do this if you write a post install script that will get called once the target image is deployed to the target computer. In the case of a linux computer you could potentially set the target computer’s name here by updating the /etc/hostname file or anything else you can do with a bash script. The FOG Client can also be configured to make changes to the target computer or install applications based on instructions from the fog server. Its really identifying what you want to do and how much automation you want to script. Its all possible with FOG and a little creativity on your end. Since you already know Ubuntu (linux) bending FOG to what you want will be easier than coming strictly from a MS Windows background.

version is 1.5.10

I was not able to figure out capturing the image from a VM, I decided to use an actual desktop as the master/golden image. It made more sense as it would include the right hardware type, drivers, etc. I have captured the image finally. Now on to deployment