@george1421

The problem was the IGMP Snooping as you suspected. Thank you for your help.

At this point, I would stop modifying the image files by hand and do one clean test from scratch.

• Fresh Windows install
• Verify BitLocker / Device Encryption is Fully Decrypted
• Leave the default Windows partitions alone for this test
• Do not edit BCD / boot entries
• Disable the FOG client before capture if it is installed
• Sysprep and shut down
• Create a new image definition in FOG
• Capture it again as Single Disk - Resizable
• Deploy that new image without modifying any files in the image directory

Right now, the modified image is not a clean test anymore. The latest error shows Partclone is attempting to deploy p3 and then failing, which also explains why the restored partition shows as RAW.

This is how I have captured and deployed images on various HP models.

@Tom-Elliott

This is fixed, too, and can be marked as solved. The reason was stale WOL power action. I deleted those manually from the DB, and the CPU went back to normal.

I’m not sure about the SSH and replication issues, but I deleted my physical storage node, and I’m not seeing those anymore.

@Tom-Elliott

Here is a clearer forum version:

What I meant is this:

If a group is created but no hosts are added to that group, opening/clicking that empty group in the FOG dashboard throws an error in the browser.

I tested this on two separate FOG instances and got the same result on both.

Example: If the group sysprep-test-5002 is clicked in the screenshot below.

The browser shows this SQL error:

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version
for the right syntax to use near ')' at line 8

Expected result:

FOG should open the empty group normally and show that it has no members, instead of generating a SQL syntax error.

@devle @Tom-Elliott This problem occurs when there are no hosts associated with the group (the group is empty). This can be closed, but I believe it should be moved to the BUG reports.

@lucamathuse No, I would not move the files manually yet.

If the capture reports “Cloned successfully” but the task remains In-Progress, then the capture itself may have finished, but the post-capture process is not completing correctly. Under normal conditions, the host should finish the task and then reboot or shut down automatically based on your settings.

So, before moving anything by hand, I would want to know whether the host is actually stuck there indefinitely or whether it is still finishing something in the background. If it never updates the task status, that could also explain why your image set ends up incomplete or inconsistent.

At this point, I would stop modifying the image files by hand and do one clean test from scratch.

• Fresh Windows install
• Verify BitLocker / Device Encryption is Fully Decrypted
• Leave the default Windows partitions alone for this test
• Do not edit BCD / boot entries
• Disable the FOG client before capture if it is installed
• Sysprep and shut down
• Create a new image definition in FOG
• Capture it again as Single Disk - Resizable
• Deploy that new image without modifying any files in the image directory

Right now, the modified image is not a clean test anymore. The latest error shows Partclone is attempting to deploy p3 and then failing, which also explains why the restored partition shows as RAW.

This is how I have captured and deployed images on various HP models.

@lucamathuse From the metadata you posted, I do not see evidence that Partclone skipped the Windows partition.

d1.partitions shows p3 as the large Microsoft basic data partition, d1.original.fstypes shows p3 as ntfs, and d1p3.img.000 exists. That indicates the Windows partition was captured. That, by itself, does not prove that the deployed content is valid, but it does not support the claim that C:\ was simply left out.

So I think it is important to distinguish between these two cases:

1. The Windows partition was not restored at all
2. The Windows partition was restored, but the system is not bootable

Based on what you posted, this looks closer to the second case.

The reported behaviour also points more toward a Windows boot configuration issue than a Partclone omission. In particular, the manual changes you described on the Windows side — disabling WinRE, deleting/extending partitions, and editing BCD-related settings before capture — are much more likely to produce a recovery-only boot state than Partclone “skipping C:”.

If you want to prove that C is actually not being deployed, the correct test would be a debug deploy or checking the failed target from recovery/WinPE:

• confirm partition 3 exists
• confirm it is NTFS
• confirm C:\Windows is present

If those are present, then the problem is not that Partclone omitted C:, but that Windows cannot boot from the restored layout.

@kratkale said in Windows 11 | 65x HP Z2 Tower G1i:

Can I specify in FOG which hard drive to clone to? For example, using the serial number? That could be stored in the host entry

Hi, this is a known issue when using NVMe, as you’ve probably already discovered. I’m not sure whether FOG 1.5 supports using serial numbers to target disks, but someone from the team may be able to confirm that. FOG 1.6, however, does support targeting disks by serial number.

I ran into the same situation. As a workaround, I customized my init.xz to use the PCI path instead, since those appear to be more persistent.

@lucamathuse Hi. I have faced similar situation on HP. I think your computers are going into recovery because the BIOS hasn’t updated its boot entries. So it still thinks it should load the old OS.

From the steps, I saw you fiddling with the Boot entries. I’m not familiar with that method, but at least on my computers, I don’t need to change anything. Just a sysprep -> Shutdown and capture.

Have you actually tried investigating whether the data has been copied to your disk? Do you see the boot directory? You should be able to drop into the CMD from that recovery or advanced option and investigate that.

I have deployed Windows 11 while the image type was Windows 10, and never needed to change anything.

@Tom-Elliott Hi, has there been any development with this?

I’m facing a situation that’s not quite identical but very similar in my 1.6.0-beta.2297.

I already posted to the Forum with the details I thought were relevant, but noticed my FOG status is showing the same messages that are posted here.

Hello,

Recently, I noticed that I cannot run any snapins that were associated with the host. I also noticed the FOGScheduler was not working. After investigating, I found several issues.

FOG Version:
Upgraded from 1.15.10 → <several 1.6-beta in between> → currently running 1.6.0-beta.2297

Setup:

• FOG Server: 172.28.1.80
• Storage Node: 172.28.1.89

---

1) Replicator: falsely reports image files as missing at first, then immediately syncs.

[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.fixed_size_partitions(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.mbr(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.minimum.partitions(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.original.fstypes(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.original.swapuuids(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.partitions(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1.shrunken.partitions(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1p1.img(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1p2.img(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1p3.img(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist d1p4.img(storage 1)
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.fixed_size_partitions on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.fixed_size_partitions file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.mbr on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.mbr file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.minimum.partitions on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.minimum.partitions file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.original.fstypes on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.original.fstypes file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.original.swapuuids on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.original.swapuuids file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.partitions on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.partitions file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1.shrunken.partitions on storage 1
[04-07-26 9:28:10 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1.shrunken.partitions file to storage 1
[04-07-26 9:28:10 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1p1.img on storage 1
[04-07-26 9:28:11 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1p1.img file to storage 1
[04-07-26 9:28:11 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1p2.img on storage 1
[04-07-26 9:28:11 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1p2.img file to storage 1
[04-07-26 9:28:11 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1p3.img on storage 1
[04-07-26 9:28:11 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1p3.img file to storage 1
[04-07-26 9:28:11 am]   # peruswin-audit-1.2: File does not exist on master node, deleting /images/peruswin-audit-1.2/d1p4.img on storage 1
[04-07-26 9:28:11 am]  | peruswin-audit-1.2: No need to sync /images/peruswin-audit-1.2/d1p4.img file to storage 1
[04-07-26 9:28:11 am]  | CMD: lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogreplicator.peruswin-audit-1.2.transfer.storage 1.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; mirror -c --parallel=20 -R --ignore-time -vvv --exclude ".srvprivate" "/images/peruswin-audit-1.2" "/images/peruswin-audit-1.2";exit' -u fogproject,[redacted] 172.28.1.89
[04-07-26 9:28:11 am]  * Started sync for Image peruswin-audit-1.2 - Resource id #1583
[04-07-26 9:28:11 am]  | Sync finished - Resource id #602

Observed:

• Files exist on both server and storage under /images/<image>
• Verified with find and lftp
• Image deploys successfully to clients

---

2) SSH spam between nodes

Apr 07 09:42:13 fog sshd[2483177]: error: kex_exchange_identification: Connection closed by remote host
Apr 07 09:42:13 fog sshd[2483177]: Connection closed by 172.28.1.89 port 55330
Apr 07 09:42:13 fog sshd[2483178]: error: kex_exchange_identification: Connection closed by remote host
Apr 07 09:42:13 fog sshd[2483178]: Connection closed by 172.28.1.89 port 55336
Apr 07 09:42:14 fog sshd[2483179]: error: kex_exchange_identification: Connection closed by remote host
Apr 07 09:42:14 fog sshd[2483179]: Connection closed by 172.28.1.80 port 34766
Apr 07 09:42:14 fog sshd[2483180]: error: kex_exchange_identification: Connection closed by remote host
Apr 07 09:42:14 fog sshd[2483180]: Connection closed by 172.28.1.80 port 34768

Observed:

• Happens multiple times per second
• Seen on both server and storage

Fix / Isolation:

• Stopping FOGMulticastManager stops the SSH spam
• Starting it again reproduces the issue

---

3) FOGMulticastManager creates broken PHP session files (storage node)

session_start(): open(... Permission denied)

Observed:

• /var/lib/php/sessions directory is correct:

  drwx-wx-wt root:www-data
  

• Session files are created as:

  -rw------- 1 root root ...
  

• Apache/PHP-FPM runs as www-data → cannot access them

Isolation:

• Stop:

  systemctl stop FOGScheduler FOGMulticastManager
  

• Delete sessions:

  find /var/lib/php/sessions -type f -name 'sess_*' -delete
  

• Errors stop

• Start only:

  systemctl start FOGMulticastManager
  

• Errors immediately return

---

4) Power Management warnings

Undefined array key "pmAction"

Observed:

• Many hosts have no row in powerManagement table

Fix:

• Disabling Power Management in FOG settings stops the warnings

---

5) Scheduler tasks do not run

Observed:

• Scheduled tasks do not execute unless FOGScheduler is restarted
• After restart, tasks run, but later scheduler stalls again
• New tasks are not picked up

---

6) Snapins do not execute

Observed:

• Snapins can be assigned
• Execution on a single host associated with the snapins fails
• Snapin runs on a group

---

7) High CPU usage (PHP)

php (root) ~100% CPU

Observed:

• High CPU usage on both server and storage
• Drops when stopping FOGScheduler

---

Additional notes

• Manual SSH from server → storage using fogproject works
• FTP (lftp) can list image files correctly
• Installer has been re-run on both nodes after update