All issues have been resolved by the latest kernel . Best regards, this thread can now be closed. Solved. 😉

@rodluz Updating the kernel to the latest version helped; the computers are finally being restored at full and consistent speeds, for both unicast and multicast deployments. Thank you for your help.

Well, I have to admit, I opened this issue a while ago, and then didn’t really have time to play with it. I only have a handful of these machines, and while it’s a pain when I have to reimage one, I didn’t have time to spend a lot of time trying to figure this out. Well, today I had to reimage another one of them, and so just out of curiosity checked this thread again, and wouldn’t you know it, it seemed like the issue might be resolved…I updated the kernel, started imaging, and it is going in 5 minutes again!

Thanks so much for an amazing product and community!

Q

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

@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

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

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

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

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

Fix is here:
https://github.com/FOGProject/fogproject/issues/740

I’m having the exact same behavior.
Was working on the 27, 28 and 29.

Stopped working start of this week (2 september)
Added 3 storage nodes in between.
1a07ba58-be68-4007-a60c-5532e6c42e41-image.png

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

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.

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