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

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

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!

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

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.

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

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