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

Also I have this rEFInd hangup screen… there are a solution? hw Is a hp all-in-one the temporary solution Is to Press f9 at boot to start via pxe so if hard disk Is the First start option in BIOS list Windows starts up normally, but Is Crazy pressing f9 Every time when you have to do a multicast session of 20-30 PC…

@itcchs-bob There are a couple of things going on here then. (good you found the root of the issue)

Starting with Win10 20H2 microsoft changed the disk structure where they placed the recovery partition at the end of the disk and marked it as non-movable. In the FOG dev branch FOG version 1.5.9.110 and later has a fix for this locked partition.

There are some disk layouts that also are problematic to shrink. Think about it a 512GB hard drive could potentially have a partition starting location beyond the last block on a 256GB disk. So its always problematic haveing a source disk larger than a destination disk. Can FOG deploy larger to smaller disk? Yes as long as all of the conditions are right.

If I’m doing a one to many image deployment, I always create my golden image on a VM with the disk set to the smallest disk I will every deploy to. So for Win10 I create a 70GB disk, and Windows Server a 120GB disk. This way when deployed the disk always grows to the final size.

@george1421

No bitlocker enabled, so I’m not sure why it’s not resizing that partition. I’m in the middle of another image capture attempt, and though it captured the OS partition quickly(and then took 15 ish minutes to move on to the next one after the ‘Cloned Sucessfully’ message) it’s back to the thing where it’s stalled for no apparent reason and dropped back down to miserable speeds.

I am entirely mystified about what is going on. It doesn’t seem to be consistent in what it’s doing. sigh Is there something else I can grab to help identify what’s going on?

@ljh said in High DB utilization:

So it looks like that fixed my issue

FWIW: Which “that” is the fix? Switching over to innodb engine or the reboot?

Hi,

Sorry to revive an old thread but it is still happening.

For example with ThinkPad T450, T460, T470 it goes very fast (6-8GB/min). With ThinkPad E14 G2 it only goes around 600MB/min.

Thank you

@george1421 , thanks, i will see that.