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

@celsoares said in ACPI BiOS Error:

Sorted out! Thank you so much for the availability…

Just for clarity for the next person who finds this thread: Did you install the 4.15.2 kernel and it worked correctly?

If yes, you can create a fog settings group for those 100 HP computers to apply that kernel name to all devices with out having to hand edit each host record.

Related article: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@nono The values in fogsettings should remain as the installer created them. As I said the fogstorage account is for external access to the master fog node from storage nodes. That account only has edit rights to the database, it can’t create or delete tables or schemas, that is the function of the fogmaster account. If you change it to fogstorage your next fog upgrade will fail because it doesn’t have the right access level to update tables in the fog database.

@willingmost7 said in not entering fog menu after nbp completed:

it is on the same subnet.

OK good. Lets follow this tutorial to capture a pcap of the pxe booting process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Upload that to a file share site and either post the link here or DM me the link in FOG chat and I’ll take a look at it. There is something unexpected going on here. The pcap will tell us.