Hey @Tom-Elliott I was able to get our FOG instance working by following the upgrade path to upgrade fully to 1.5.10.1673. I guess I should have tried that first :-/.

Thanks for your help.

@AngryITGuy The iPXE file likely needs the boot shim or whatever to allow things to work correctly and with upgrades this isnt’ really feasible as every newly built ipxe file (snp.efi, snponly.efi, etc…) would need that shim configured and installed in place.

It’s possible there was a step in the original installer from your collegue that may have moved the ipxe files from a backup where these were shimmed appropriately?

I don’t know exactly just spitballing.

Ultimately, yes, I’m glad you got this working by disabling secure boot.

Technically, it’s possible to do this with secure boot, but not in an easily scalable way that we can include as part of the install script. Nor, in reality, do I think we want to do such a thing. While it’d be nice to do it as an installer, I am hoping we can get a document that more clearly details what steps to do. This is mainly due to the constantly changing nature of fog, so if we have an easily repeatable knowledgebase on what steps to do in a well documented sort of way, it’d be a lot better than trying to have us maintain some installer that could easily have some issue on a new iteration and continually have to maintain yet more blocks of potentially os dependent code.

I didn’t try updating the kernel (as when @Tom-Elliott replied I had already started the linux upgrade) however updating the linux to Ubuntu 24.04.3 LTS, and downloading and installing latest FOG built (as after the upgrade it wasn’t working anymore) fixed the issue.

Thanks @Tom-Elliott

This is the kernel version with the updated linux

Linux version 6.8.0-79-generic (buildd@lcy02-amd64-049) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #79-Ubuntu SMP PREEMPT_DYNAMIC Tue Aug 12 14:42:46 UTC 2025

@chunter2 Ah, yes that would do it.
That just becomes the default value when creating new hosts.
If you set it via a group, it will update those values on all hosts in a given group, but it doesn’t do that dynamically/perpetually.

@shieldsj

By “10.149.50.21:/images” I was referring to the “images” directory in the filesystem on the storage node at the IP address 10.148.50.21

So to check the actual contents of the “/images” directory, you’ll need to either:

1 - have a display and keyboard directly connected to that storage node (PC) to log into it and view the filesystem with whatever File Explorer type app its GUI desktop supplies OR

2 - open a terminal / command line on that storage node PC, either at a display/keyboard connected to the storage PC or across the network with SSH.

In any case, the contents of the storage node’s /images directory should be (mostly) subdirectories that are named exactly the same as your saved/captured images.

Example:

If you intended to capture an image called “Teacher_Pc”, the storage node’s /images directory should contain a subdirectory named “Teacher_Pc”

In my case, I have captured an image I named “20250319-7010-adult-builder”. Here is a truncated directory listing on one of my storage nodes:

root@node25-0:/images# ll total 140 drwxrwxr-x 32 fogproject fogproject 4096 Aug 12 11:19 ./ drwxr-xr-x 25 root root 4096 Aug 12 09:33 ../ drwxrwxr-x 2 fogproject fogproject 4096 Jul 31 10:05 20250319-7010-adult-builder/ drwxrwxr-x 2 fogproject fogproject 4096 Jul 31 10:06 20250327-7010-deploy-test/

If somehow you have managed to get the image name (directory name) to be “, Image name Teacher_Pc” then I’ll not be surprised if parsing (text handling) errors happen within FOG when you try to use that image name. In that case, the directory can be renamed to “Teacher_Pc”, BUT that directory name must match in one field recorded in the fog database on the FOG server.

Let’s see what you’ve got in the “/images” directory first.

@JJ-Fullmer Dear Fullmer, thanks in advance for your intervention.

Unfortunatly in the machine that run my fog container there is another mysql database listen on port 3306.
This is not a problem, i just semi-resolved creating a non-privileged/shared network host mysql container with no exposed port -> place fog container and this database container in a same network (they can ping each other with fqdn) and i’ve just modified the /opt/fog/.fogsettings with your suggestion in the past, but the solution doesnt work:
The installation goes fine, but the result is a blank http page that it say: database error. (something like that).
I think (but is only supposition, im not absolutly a developer) that there is written php scripts that must to be point to a localhost database (something in /var/www/html/fog/*).

This problem is born because the fog container must be in privileged mode, with the same network namespace as the host, and in this host there is another database already.

Thanks for confirm me the inevitable death of the container version of fog. it really hard to containerize this application without setting privileged mode and/or share the host network. and the huge problem of systemd processes make this containerizzation very difficulty to maintain.

Thanks for the patience

@Tom-Elliott Hi Tom, Thanks… I updated to 1.5.10.1692 and was able to deploy a 2 day old image to the PC. I updated some things on the PC, mostly with Steam and display settings then went to capture an image from it again and ran into the same problem mention in the OP. Only this time, I was able to take a pic.

I ran chkdsk prior to capturing and it came up clean

alt text

UPDATE: So I tried everything for the ntfsresize error … turns out, I had to shrink the partition in windows a bit then expand it. After that, I could capture.

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

Thank you for your detailed reply, @george1421

I have decided to run both servers on the same network. With DHCP switched off on AikenWorkbench, I’m able to boot intoFOG menu.

Your entries aren’t quite right, or I’m doing something wrong. If I use it as is, I’m getting something like "Could not boot: Not found (https://ipxe.org2d12618e)

I have decided to exclude some of the commands and narrowed it down to:

chain -ar tftp://192.168.2.1/grub/bootx64.efi boot || goto MENU

And I’m trying to run it on EFI EFI-capable machine, but I’m only getting to the grub console and no further.

I understand my best bet is to learn how iPXE works and study its documentation.

There is more config from Aken if this helps:

cat /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/awbcboot" TFTP_ADDRESS="192.168.2.1:69" TFTP_OPTIONS="--secure" ls /awbcboot bios biso boot grub ls /awbcboot/grub biso boot bootx32.efi bootx64.efi grub.cfg grub.cfg.bak snap unicode.pf2

And grub.cfg

cat grub.cfg set default="0" set timeout=0 menuentry 'Aiken Workbench V2 UEFI ...' --class gnu-linux --class gnu --class os { linux (pxe)/boot/vmlinuz-awc root=/dev/nfs nfsroot=${pxe_default_server}:/awbclient ip=dhcp rw libata.allow_tpm=1 -- initrd (pxe)/boot/initrd.img-awc

And here is the whole dhcp.conf but we don’t use Apple class as they dropped PXE support.

ddns-update-style none; authoritative; allow booting; allow bootp; option domain-name-servers 208.67.222.222; option arch code 93 = unsigned integer 16; class "AppleNBI-i386" { match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386"; option dhcp-parameter-request-list 1,3,17,43,60; if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; option vendor-encapsulated-options 08:04:81:00:00:67; } if (option dhcp-message-type = 8) { option vendor-class-identifier "AAPLBSDPC"; if (substring (option vendor-encapsulated-options, 0, 6) = 01:01:01:02:02:01) { option dhcp-parameter-request-list 60, 43; option vendor-encapsulated-options 01:01:01:03:04:C0:A8:02:01:04:02:80:00:07:04:81:00:00:89:09:2A:81:00:00:89:09:44:6f:45:2d:49:6d:61:67:65; } } if (substring (option vendor-class-identifier, 15, 7) = "iMac4,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 7) = "iMac4,2") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 7) = "iMac5,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 7) = "iMac5,2") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 7) = "iMac6,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 10) = "MacBook1,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 10) = "MacBook2,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 13) = "MacBookPro1,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 13) = "MacBookPro1,2") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 13) = "MacBookPro2,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 13) = "MacBookPro2,2") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 13) = "MacBookAir1,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 10) = "Macmini1,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 9) = "MacPro1,1") { filename "grub/bootx32.efi"; }elsif (substring (option vendor-class-identifier, 15, 9) = "Xserve1,1") { filename "grub/bootx32.efi"; }else { filename "grub/bootx64.efi"; } } class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; next-server 192.168.2.1; if (option arch = 00:00) { filename "bios/pxelinux.0"; }elsif (option arch = 00:06) { filename "grub/bootx32.efi"; }elsif (option arch = 00:07) { filename "grub/bootx64.efi"; } } subnet 192.168.2.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.2.10 192.168.2.254; next-server 192.168.2.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.2.255; option routers 192.168.2.1; default-lease-time 600; max-lease-time 3600; }

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

Dear Tom,

Thanks, and this is what I figured. At least I can pxe boot it and capture the image now, if I switch it to “AHCI/NVMe” mode, and switch back to “RAID” mode to boot the single NVMe drive.

I made this known so we can reach out to Dell and possibly have this changed as it actually doesn’t need this “RAID” mode.

Also we still have to disable secure boot on any computer either HP or Dell to get the pxe boot to work.

We did manage to use FOG to capture a RAID from an HPE DL380 Proliant Gen10 RAID controller and use that to load Windows Server 2022 now, so it does seem the kernel is the issue here on this intel motherboard RAID.

Regards,

Matt

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 Thanks for your help.

I solve the problem with this AutoUnatted.xml

<?xml version=“1.0” encoding=“utf-8”?>
<unattend xmlns=“urn:schemas-microsoft-com:unattend”>
<!-- Bypass OOBE -->
<settings pass=“oobeSystem”>
<component name=“Microsoft-Windows-Shell-Setup” processorArchitecture=“amd64” publicKeyToken=“31bf3856ad364e35” language=“neutral” versionScope=“nonSxS” xmlns:wcm=“http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<ProtectYourPC>3</ProtectYourPC>
<SkipUserOOBE>true</SkipUserOOBE>
<SkipMachineOOBE>true</SkipMachineOOBE>
<UnattendEnableRetailDemo>false</UnattendEnableRetailDemo>
<NetworkLocation>Other</NetworkLocation>
</OOBE>
</component>
<component name=“Microsoft-Windows-International-Core” processorArchitecture=“amd64” publicKeyToken=“31bf3856ad364e35” language=“neutral” versionScope=“nonSxS” xmlns:wcm=“http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
<SystemLocale>pt-PT</SystemLocale>
<UILanguage>pt-PT</UILanguage>
<UserLocale>pt-PT</UserLocale>
<InputLocale>0816:00000816</InputLocale>
</component>
</settings>

<!-- Run SetupComplete.cmd via PostOOBE --> <settings pass="specialize"> <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <RunSynchronous> <RunSynchronousCommand wcm:action="add"> <Order>1</Order> <Path>reg add "HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\PostOobe" /v "00" /t REG_SZ /d "cmd /c C:\Windows\Setup\Scripts\SetupComplete.cmd &amp; exit /b 0" /f</Path> </RunSynchronousCommand> </RunSynchronous> </component> </settings>

</unattend>

The AutoUnatted.xml will call the the script C:\Windows\Setup\Scripts\SetupComplete.cmd

I make the sysprep with AutoUnatted.xml

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

@george1421 So removing my key from the unattend file fixed the SetupComplete.cmd running issue. I forgot to tell it to join the domain after deploy and made a snap in for that which worked to test it out (I could tell the service was running because it rebooted to change its name as well but wanted to verify with the snap in). Windows must have activated based on something in the hardware because the machine is activated as well, so the key didn’t really need to be there I guess(?)

Also thanks for all your help, several years ago under another username you helped me a lot with random issues on another fog set up. The whole FOG project team is amazing!