Hi, seems it was failing to update the DB at the end of the imaging,

We reset the DB creds and now its working perfectly 🙂

@pbelzile If you are running FOG 1.5.9 then M$ changed the disk structure starting Win10 20H2. They marked the recovery partition as non-movable. That causes resizing the disk a bit complicated when going from larger to smaller. FOG 1.5.9.115 (i.e. dev branch) has a fix for it so if you switch to the dev branch then you might work around it.

Or removed that recovery partition because it has little value because in my opinion you can just reimage with fog faster than trying to save the OS by using windows recovery. Now there are times where based on your installed applications you need to save the OS for some reason, then boot from a usb recovery disk to try to revive the system.

Now in your case, when you capture the image. On the largest partition watch to see if partclone is in raw mode. This is a block clone method that records all blocks on the disk. In this case you will get about the same size on disk in the captured image. Depending on the target OS, it might say ntfs or ext4 then that is file based capture. That capture value should be the size of the actual data on the disk.

@sebastian-roth Ok - thank you - that works! ( I actually did see mention of this but did not quite follow through on testing it)

ipxe boot issues with https enabled (I enabled https on the old server and it all went wrong).

Ran into this issue again with new server this morning – looked at the system time of the pc, date was way off – corrected and booted fine…I gather system time + UEFI + https ipxe is crucial?

Regardless, I appreciate the quick replies!

@ouédraogo Please update your FOS Linux kernel to version 5.15.x series for both x64 and x32. FOG UI -> FOG Configuration -> Kernel update.

That should address this issue.

@trev-lchs it appears this was a one off and subsequent installs have not had this issue. So this one can be written off as solved. Seems the resize NTFS partition failed to work one time.

@geekyjm said in PXE client not seeing new Fogserver:

How do I tell if the PXE server is running on the Fog server?

If you want to get literal, there is no such thing as a PXE server. PXE is a protocol not a thing.

DHCP tells the client where to look for the boot file. Then the client downloads what its told from a tftp server. That is the pxe process in 20 words or less.

The pcap is important to ensure the client computer is being told to load the right file from the proper computer. If you look in the OFFER packet (that comes from the dhcp server). In the header there will be a {next-server} field. That should be the IP address of the fog server. There should also be a {boot-file} field, that should be ipxe.efi or a uefi system and undionly.kpxe for bios system. That should match dhcp options 66 and 67 respectivly.

@george1421 Thanks George, i will leave well alone, I am a great believer in “if it isn’t broke don’t fix it”. Thanks for all your help with this.

@george1421

Thanks for the hint! Turns out a field in the Web Server section had the old IP address. All is well now.

@trev-lchs that was the Ticket George, I just thought the config would go across to the fail over DHCP Server, live and learn eh. Thanks very much for your help

@jacob-woolbright said in Fog management website throws 500 error:

Would it be best to just revert to 20.04?

Yes or debian 11 if you want to switch to FOG’s dev branch a.k.a.1.5.9.115 or later. When its released it will become FOG 1.5.10. The newest version of PHP in 22.04 needs a little clean up on the FOG side before its ready for release with FOG 1.5.11.

@steharv https://fogproject.org/kernels/old/

@george1421 , thank you for all your time. I will try it.

@george1421

Hello,

Any luck with incorporating the 0.3.20 into FOG? Also, is there something I can check or turn on the debug/partclone logs? Nothing ever shows up in /var/logs

Thanks

Has anyone had similar experiences and can indicate whether settings in the network or on the clients should be made?

@rude26 if you have the FOG client installed on the image, then I think by default there should be a “FOG.log” on the C drive of the computer. That log should hopefully have a section in it about computer name and domain joining which generally has info in it about what is going on. Just bare in mind that it appends to the log, so it could have that section of info in the log multiple times, so make sure you are checking the latest info in the log. Sometimes I clear the log and then reboot and check the log again to make sure I’m looking at the latest info.

Did you set it as a “Single Disk - Resizable” image type? If so, were you creating a Windows 10/11 image?

We’ve had trouble with that lately and it turns out that Windows was putting a little partition after the main C partition on the disk. I think FOG tries to resize the last partition by default, so it ends up only resizing that small partition, thus it won’t end up fitting on any smaller disks.

To fix it we just removed that last little partition before capturing the image. I think it was just a recovery partition or something that we didn’t really care about.

Hope this helps!

@george1421 removing the t/ from web gui fixed the problem. Thanks a lot!

@george1421

The compression ratio was set to 6 changed it to 11 and everything is working great. Thanks again for your help, we would still be struggling without it.