@gaptoothgonni So while this can be done, FOG is designed to capture an image from where windows is already installed and sysprep’d, not to boot to a wim. Of course it can be done, but I just wanted to make sure that’s clarified.

All that said, doing it that way may or may not get past your problem, because it may just be a client pc bios setting.
If you manually boot to that iso on a usb on that pc, does it see the disks?
That message generally means it’s missing the storage driver.
Does the host you’re trying to deploy to have VMD/RAID enabled in the bios settings?
It is possible, and not even that hard if you’re already customizing the iso, to add the storage driver to the wim. I’ve never used NTLite, but in powershell you can mount the wim of the image with Mount-WindowsImage and use Add-WindowsDriver to add the inf you need to that image. You probably need to mount the boot.wim and setup.wim images and add it there too as you’re booting to the boot.wim and using winpe. This page might also be helpful https://learn.microsoft.com/en-us/windows/deployment/update/media-dynamic-update#update-windows-installation-media

I would also say, if you’re going this route, to consider making a autounattend.xml if NTLite doesn’t do that, as it can automate the install of windows and then have it kick things off into provisioning. We customize an iso like this and use it to create and capture our base image in FOG.

I got a little off topic there, TL;DR
Make sure the disks are seen if you boot to the iso manually, if they are not, then adjust the bios/uefi settings to use AHCI mode for disks as it works universally. If the disks are seen when manually booting, then something else is causing it not to see the local hardware.

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.

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.

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

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?

@Sebastian-Roth Sorry for missing your reply. Just shows that fog has been running great for a while.

I like the thought of adding better debugging log messages so I think this would be helpful.

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

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

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.

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