@janez3k said in Fog iPXE Menu no input:

https://pastebin.com/xWhJkDX1

Thank you for this, I have copied and pasted what you have. The only part i noticed (though I left it for now) is the missing building of ncm--ecm-axge

I don’t know that this file is particularly in use so I think it’s safe to keep out but If I’m wrong I’m sure we’ll learn about it quickly enough.

I have pushed this version of the IPXE building script to both working-1.6 and dev-branch.

This won’t become part of the release until the 15th of September (at this point), but is available for testing on the bleeding-edge/beta channels.

@ProfessorFow There is the ability to replicate images across groups. You can set which “groups” images need to replate to by associating images to multiple storage groups. You can even define which storage group is the primary.

@diogo-seabra As for the picture, I think we need to clearly define your network.

dnsmasq works by using broadcast messages. So that means dnsmasq will only work on the local subnet. If your pxe booting computers are on a different subnet then you will need to add the fog server’s IP address to the list in the dhcp relay service on your router.

Also if you have dhcp snooping enabled on your network switches, that may also cause dnsmasq to not respond properly.

Hi, just wondering if you were able to find a fix for this. Right now I’m experiencing a similiar issue when in the ipxe menu for Fog. No keyboard input works.

@rodluz
Thanks for the feedback. I swapped the RAM module and NUC was able to re-image. Case closed.

@george1421 No luck, could you please have a remote session at your convenient time?

@BrightPipe said in FOG not saving images in the directory:

EDIT---- Running the installer again seems to have fixed the issue. Thanks.

Good deal because that was going to me my next request. I’m glad you have it sorted out.

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

You might start by verifying the actual stored image name on the storage node at 10.149.50.21:/images

Next you might use some SQL tool (I use phpMyAdmin) to check the ‘fog’ database on your FOG server, table ‘images’ and verify that the values for ‘imageName’ and ‘imagePath’ both look correct.

‘imageName’ could be different from ‘imagePath’, but only if someone has renamed the image in the FOG server web GUI. ‘imagePath’ should be the same as the desired image directory in your storage node(s) /images directory.

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