@Tom-Elliott
The upgrade to stable version completed successfully.
I’m now on fog 1.5.10.1673
Thanks again

@Tom-Elliott
That was it, Tom. Thank you so much for helping me with this. I was starting to lose some hair!

@pilipp_edv That should be enough I imagine, thanks for being thorough. I’ll take a look at the kernel config when I get a chance.

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

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.

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

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

@eoli3n Versions are impossible to give because they keep changing, so we do try to have the version that are supported between masters/dev-branch/etc… for the os’s at that point in time (and backward)

Debian Based (Mint, Ubuntu, Debian), Redhat Based (Redhat, Rocky, Alma, Fedora).

The versions, dev-branch is more likely going to be in line with latest/greatest. Some what of a delay of course, but there’s no list that clearly spells out what version of specific OS is supported.

In my opinion, Redhat based OS’s are the best as we don’t have to continually update the installer code to support future versions. Most will just work right out of the box.

Migration process? No, if you’re moving one machine to another that’s one thing of a migration and there is a process for that, but if you’re meaning “I’m on bookworm and without moving anything, I’m going to do an in place upgrade?” I don’t believe there will be problems but what I would suggest is re-installing FOG once the upgrade is complete as any services or config files that got changed would need to be rebuilt for the new OS. It’s not hard and I don’t think there will be any issues. If there are, please let us know.

@Tom-Elliott that seems to have solved it. Thanks yet again for speedy service! Cheers

@gaptoothgonni Well darn, have you tried booting with snponly.efi instead of ipxe.efi? It wouldn’t make a ton of sense if that worked but something else to try.
If it’s booting to the wim though, it should just be getting the drivers from the wim unless ipxe somehow changes how they’re presented, which I don’t think it does but that’s also the only difference between where it’s working. Might be worth looking at https://github.com/ipxe/ipxe/discussions and seeing if anyone has had similar issues. Since you’re just using FOG to create the ipxe boot menu, it’s not likely anything within FOG that’s causing this. You could try ipxe’s pre-built boot files, though they won’t have the embedded fog stuff https://boot.ipxe.org/ but maybe will make a difference. There’s other ipxe efi files you can try too, or try an older one ( I think we still include some legacy ones in /tftpboot)

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

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

I completly reinstalled the dev_branch software in an new Debian 12 guest and now it seems to work fine.
Thank you

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

@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

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.

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

@Petrushka hello!!

In our firewalld rules we have

services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

@rurap Not sure what that patch would have been, but our last kernel release includes the Realtek R8168 driver. This kernel has fixed that same issue for other users.