# Dell Latitude 3400 hangs at boot after a FOG deploy: investigation, workaround and notes

**Period:** September–October 2026
**System:** FOG 1.6.0-beta upgraded to 1.6.0-RC-2, Ubuntu 26.04 LTS
**Hardware:** Dell Latitude 3400 (BIOS 1.39.0, latest available)
**Image:** Windows 11 Enterprise 25H2, captured from a Hyper-V Gen 2 VM (vTPM, Secure Boot off)
**Status:** worked around, in production, automated and tested on several consecutive deploys. **The root cause of the firmware hang was not identified**: the workaround avoids Partclone for this model.

> **TL;DR**
> - Windows 11 images captured in a Hyper-V VM and restored with FOG/Partclone made some Latitude 3400s hang intermittently in firmware (Dell logo, F2/F12 unresponsive). 16 hypotheses were tested and ruled out; the root cause was not found.
> - The same image applied with diskpart + `DISM /Apply-Image` (the SCCM way) never hangs. Latitude 3400s are therefore deployed through a custom FOG plugin that boots a WinPE via wimboot instead of FOS. All other models still use FOS/Partclone.
> - Side findings that may help others: a WinPE deploy never closes the FOG task (clients loop on reboots, fixed by calling `Post_Stage3.php`), the PKI tree problems hit while upgrading to RC-2 (partly self-inflicted), Secure Boot/MOK details, and a `vsftpd` home-directory pitfall that makes snapin downloads fail with a bogus hash.

---

## PART 1: The investigation

### 1.1 Original symptom

After deploying the Windows 11 image with FOG, the Latitude 3400 hangs **intermittently** during boot:

- The Dell logo appears and stays on screen indefinitely. It is not a full system hang: the keyboard responds (for example the Caps Lock LED toggles normally), but there is no video or boot progress.
- **F2** (BIOS Setup) and **F12** (boot menu) hang the same way, at "Preparing to enter BIOS Setup". So the hang is at the **firmware level**, during disk scanning/enumeration, **before** Windows or any bootloader gets involved.
- It is **reproducible on 3 identical Latitude 3400 units** and with **2 different NVMe SSD brands** (SSSTC and Toshiba).
- **With the NVMe disk removed**, the PC behaves normally (BIOS reachable, no hang).
- It is **intermittent**: the very same disk with the very same content sometimes boots and sometimes hangs, with a failure rate between roughly 50% and 80% in our tests.

### 1.2 Reference checks

- The **exact same pipeline** (Hyper-V VM → sysprep /generalize /oobe /shutdown → FOG capture → FOG deploy) with **Windows 10 23H2** never shows the problem, on any machine tested.
- The same Windows 11 image works **perfectly** on an HP ProOne 440 G9 AiO.
- Deploying the same image with **SCCM** (task sequence: native diskpart partitioning + `DISM /Apply-Image`) on the same hardware **never hangs**.
- So the problem is specific to the combination **Windows 11 + Latitude 3400 firmware + restore via Partclone/FOG**, regardless of the physical disk used.

### 1.3 Hypotheses tested and RULED OUT (16)

| # | Hypothesis | How it was checked | Result |
|---|---|---|---|
| 1 | Malformed GPT / partition table | `gdisk -l`, `sgdisk -v`, `sfdisk -d` on a working and a failing disk | Identical structure, GUIDs, attributes and order; no anomaly |
| 2 | Missing/corrupt bootloader | Checked `bootmgfw.efi` in `/EFI/Microsoft/Boot/` | Present and valid |
| 3 | Leftover RAID/mdadm metadata | `mdadm --examine` before and after a full wipe | No superblock found in any case |
| 4 | Intel IMSM/RST metadata | Raw search for the "Intel Raid ISM Cfg Sig." signature in the last sectors | No signature found |
| 5 | BIOS storage mode (RAID vs AHCI) | Checked directly in the BIOS | Already AHCI |
| 6 | Sector size mismatch (VM 512B vs physical disk) | `blockdev --getss`, logical/physical size | 512/512 on every disk tested, no mismatch |
| 7 | SSD firmware (APST/low-power bug known for SSSTC CL1-3D256-Q11) | Model and firmware version identified | Ruled out: it reproduces identically on a different brand (Toshiba) |
| 8 | Hardware fault (RAM, CMOS, motherboard) | Reseated RAM, replaced the CMOS battery, cleared TPM, tested with an external monitor, diagnostic LEDs | No hardware fault found; the PC works perfectly without the NVMe disk |
| 9 | BitLocker / hardware encryption (eDrive/OPAL) | `manage-bde -status` | Always "None / protection off" |
| 10 | VBS / HVCI | Disabled the master switch in the registry (`EnableVirtualizationBasedSecurity`), checked `Get-CimInstance Win32_DeviceGuard` | No measurable improvement in the failure rate |
| 11 | Firmware bug "power-on password + black screen" | Removed Admin/System passwords from the BIOS | No improvement; the intermittent hang is identical without passwords |
| 12 | Protective MBR (LBA0): x86 bootstrap code, Size field, EndCHS field | Byte-by-byte hex comparison between a disk partitioned by FOG/sgdisk and one partitioned natively with diskpart; then isolated tests and a **full byte-for-byte replica of the diskpart pattern** on a fresh deploy | **Ruled out definitively**: even an exact replica of the diskpart pattern does not fix the hang |
| 13 | Code Integrity policy files (WDAC/HVCI) on the ESP, specific to Windows 11 | Removed `.cip`/`.CIP` files from `EFI\Microsoft\Boot\CIPolicies\Active\` | No improvement |
| 14 | NVMe controller APST (Autonomous Power State Transition) | `nvme get-feature /dev/nvme0n1 -f 0x0c` in a Debug session | Value already `0x00000000`; not applicable here |
| 15 | Volume Boot Record (VBR) of the NTFS Windows partition (BIOS Parameter Block) | Raw read of the VBR at the Basic Data partition offset | Standard values, no anomaly |
| 16 | FAT32 boot sector of the ESP (kept from the Hyper-V disk by Partclone vs natively formatted) | Reformatted only the ESP with `diskpart`, copied the EFI files back, regenerated the BCD | No improvement; same hang as before |

### 1.4 A confirmed technical finding (not the cause)

A FOG forum moderator helped identify exactly how FOG writes the Protective MBR during capture/deploy (`saveGRUB()`/`restoreGRUB()` in `funcs.sh`). It is an **intentional and necessary** mechanism, to preserve GRUB's `boot.img` on Linux disks. However, changing those fields **did not fix the hang**. The correlation first observed was a coincidence related to how the disk gets initialized, not the cause.

### 1.5 Conclusion of the investigation

None of the 16 hypotheses about the **content or structure of the data on disk** isolated a direct cause. The comparison with SCCM (stable) does show that the problem is tied to the **restore method** (Partclone) and not to the content itself. That is why the adopted solution (Part 2) bypasses Partclone entirely for this model instead of continuing to hunt for the single responsible byte.

---

## PART 2: The workaround: native WinPE deploy (diskpart + DISM)

### 2.1 Principle

Since SCCM (native diskpart + `DISM /Apply-Image`) never hangs, the workaround **reproduces the same approach** inside the existing FOG infrastructure, for Dell Latitude 3400 hosts only:

1. A **custom FOG plugin** (`winpe3400`) intercepts the generation of the iPXE boot menu. If it recognizes (via SMBIOS/Inventory) that the host is a Latitude 3400, it replaces FOG's standard kernel/initrd with **wimboot**, sending the boot to a **custom WinPE** instead of the normal FOS (Linux).
2. Inside WinPE, an automatic script (`startnet.cmd` → `Apply-Image-Latitude3400.cmd`) does native partitioning with `diskpart`, applies the image with `DISM /Apply-Image` (from a `.wim` file, not Partclone), and generates the BCD with `bcdboot`.
3. All **other models** keep using FOG/Partclone normally, with no change in behavior.

### 2.2 Components

| Component | Location (survives FOG updates) | Function |
|---|---|---|
| PHP plugin `winpe3400` | `/opt/fog/plugins/winpe3400/` (FOG creates the symlink in `lib/plugins/` automatically) | Hook on `IPXE_EDIT`: detects the model through Inventory (`sysproduct` contains "Latitude 3400") and rewrites the `kernel`/`imgfetch` lines in the already-built iPXE array |
| wimboot files | `/opt/fog/winpe_3400/` (`wimboot`, `BCD`, `boot.sdi`, `boot.wim`) | Served over HTTP through a dedicated Apache `Alias` plus an exception in FOG's rewrite rule |
| `startnet.cmd` | Embedded in `boot.wim` (`Windows/System32/startnet.cmd`) | WinPE start-up script: checks network stability, maps the FOG share, launches the apply, handles the final reboot |
| `Apply-Image-Latitude3400.cmd` | Embedded in `boot.wim` (`Windows/System32/`) | diskpart partitioning (ESP 260MB, MSR 16MB, Windows, Recovery 990MB), `DISM /Apply-Image`, copies Winre.wim if present, `bcdboot`, `bcdedit` to force the next boot from disk |
| `install.wim` | `/opt/fog/FOG_Share/Deployment/Images/Latitude3400/install.wim` | Windows 11 image captured with `DISM /Capture-Image` from the master VM (not Partclone) |

### 2.3 Key technical details

**Model detection (plugin):** the plugin reads the `sysproduct` field of FOG's Inventory table and compares it (case-insensitive, as a substring) with "Latitude 3400". The host must have completed a hardware inventory at least once.

**Intercepting kernel/initrd (the trickiest part):** simply overriding `$this->_kernel`/`$this->_initrd` in the `IpxeBootMenu` class is **not enough**, because some code paths interpolate these values into strings **before** the `IPXE_EDIT` hook runs. The working approach rewrites the text lines already present in the `$Send` array (the `'ipxe'` parameter passed by reference to the hook), looking for patterns such as `kernel bzImage` and `imgfetch init.xz` and replacing them with the wimboot sequence.

**Task automation (no menu or manual login):** scheduling a **Deploy task** for the host from the FOG web UI (Host Management → Basic Tasks → Deploy) makes the PXE boot skip login and image selection and go straight to the deploy. The plugin still intercepts correctly.

**Auto-confirmation in the script:** `Apply-Image-Latitude3400.cmd` skips its "Y/N" confirmation **only** when called with all 3 parameters already given (the automatic flow). Run by hand without parameters (emergency use), the confirmation stays on as a safety net.

**Automatic reboot from disk (not from the network):**
- `startnet.cmd` must call `Apply-Image-Latitude3400.cmd` with the **`call`** keyword. Without it, in Windows batch the control never returns to the caller after the invoked script ends, and the PC stays at the prompt instead of rebooting.
- Right after `bcdboot`, the apply script runs `bcdedit /set {fwbootmgr} bootsequence {bootmgr}`, which forces the **next single boot** to the local disk, bypassing the firmware order (which on FOG-managed machines usually has network/PXE before the disk).

**WinRE (recovery environment):** `Winre.wim` is never inside `C:\Windows\System32\Recovery\` when WinRE is enabled (Windows moves it to the dedicated Recovery partition), so an image captured with `DISM /Capture-Image /CaptureDir:C:\` never includes it, by construction. Despite this theoretical limit, in practice WinRE was present and working on the deployed PCs (checked with `reagentc /boottore`: full recovery menu, Command Prompt, System Restore and Reset this PC all working). The exact mechanism by which the file ends up there was not pinned down, but the result is stable and reproducible over several consecutive deploys.

**Network stability in WinPE:** mapping the FOG share (`net use`) turned out to be intermittent in the first seconds after WinPE boots (not a physical link problem, confirmed by stable pings). What works in production is a light preliminary check that the share is reachable (`dir \\server\share`) before the real mapping, with up to 30 retries.

### 2.4 Scripting pitfalls solved along the way

- `timeout` and `choice.exe` are **not available** in base WinPE. Replaced with `ping -n X 127.0.0.1 >nul` and `set /p`.
- Script files must have **CRLF** line endings, not LF. A file with Unix endings can behave unpredictably in multi-line `if(...)`/`goto` blocks.
- `net use Z: ...` should always be preceded by `net use Z: /delete /y` to avoid "device name already in use" on repeated attempts.
- A WIM can be updated **directly from Linux** with `wimlib-imagex update` (`delete`/`add` commands via stdin), without redoing the whole mount/edit/commit cycle on the Windows ADK.

---

## PART 3: FOG update to RC-2 and PKI problems

### 3.1 Context

While upgrading from FOG 1.6.0-beta.5388 to **1.6.0-RC-2**, the FOG Client failed to authenticate on **all** hosts (both those deployed with normal Partclone and those deployed with the custom Latitude 3400 method):

```
Data::RSA ERROR: Certificate validation failed
Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Thumbprints did not match.
Middleware::Authentication ERROR: Certificate is not from FOG CA
```

### 3.2 Diagnosis: an inconsistent PKI tree

`openssl verify`, `namei -l` and a comparison of the RSA moduli showed the following state after the RC-2 upgrade. Note that `/opt/fog/pki` is itself a symlink to `/etc/fog/pki`, so the same file has two paths.

**Pre-existing state (not caused by us):**
- `/opt/fog/snapins/ssl/CA/.fogCA.pem` was a symlink to `/opt/fog/pki/web/ca/.fogWebCA.pem`, i.e. to the **Web CA** certificate rather than the root certificate. The real root key (`/etc/fog/pki/root/ca/.fogCA.key`, dated 2020) did not match that certificate, and the root certificate no longer existed as a file. This is where `CA certificate and CA private key do not match` came from on the first `installfog.sh -K`.
- `/etc/fog/pki/root/ca/` held only the key and two symlinks (`.fogCA.pem` and `.fogCA.pem.webca-backup`) pointing to that path under `/opt/fog/snapins/ssl/CA/`. The link dates (August 24 and September 21) suggest earlier installer runs during upgrades between beta builds, but the exact origin was not established.

**Two mistakes of ours while trying to repair it (worth avoiding):**
1. The root certificate was rebuilt from the key (`openssl req -new -x509 -key ...`, legitimate: same key) and then copied with `cp` onto `/etc/fog/pki/root/ca/.fogCA.pem`. Because that path was a chain of symlinks, `cp` wrote **through the links** and overwrote the Web CA certificate (same size, 1870 bytes, and same timestamp as the command). That created the "mismatch" between `.fogWebCA.pem` and `.fogWebCA.key` that broke the next step ("Creating SSL Certificate"). So it was not an old Web CA error, as we first concluded.
2. Recreating the `.fogCA.pem` link by hand pointing at the path under `/etc/fog/pki/root/ca/` closed a **loop between two symlinks** (`namei` → "exceeded limit of symlinks"), because the other end already pointed back.

**Lesson:** on a PKI tree with symlinks, check where a path really points (`namei -l`, `readlink -f`) before writing to it: `cp` and `>` follow links.

### 3.3 Solution

Since each targeted fix revealed another problem, we went for a radical procedure, inspired by the installer's own message (which, to change the CA constraints, suggests removing the CA directory and re-running):

```bash
sudo rm -rf /etc/fog/pki
sudo rm -rf /opt/fog/snapins/ssl
cd /root/fogproject
sudo ./bin/installfog.sh -K
```

This regenerates the **whole certificate chain from scratch**, internally consistent. Inevitable and expected consequence: **every existing FOG Client** (even those not showing the error) stopped authenticating, because the root CA changed and the certificate each client had pinned locally was no longer valid.

### 3.4 Why simply reinstalling the client was not enough

**Observed:** reinstalling the client with `msiexec` left the certificate error unchanged. Deleting the `C:\Program Files (x86)\FOG` folder first (and the leftover service with `sc delete FogService`) made authentication succeed.

**Mechanism:** not isolated. The MSI log of a clean install shows that the MSI itself runs the `InstallCert` and `InstallFOGCA` actions (described as "Pinning FOG Project", with `CAFile=C:\Program Files (x86)\FOG\fog.ca.cer`), so the certificate is handled by the installer. One possible explanation, **not verified**, is that an uninstall leaves files from the previous installation in the folder (for example the old certificate) that are then reused.

### 3.5 Bulk reinstall automation

For the PCs already deployed (fewer than 10), a PowerShell script (`Reinstall-FOGClient-Silent.ps1`) was built that:

1. Reads the host list **straight from the FOG database** (`mysql fog -N -e "SELECT hostName FROM hosts;"`, exported to a text file reachable through the existing FOG_Share).
2. For each host: checks reachability (ping + `Test-WSMan`), stops the service, removes the leftover folder and service, reinstalls with `msiexec` using the parameters already in use in production (`USETRAY`, `HTTPS`, `WEBADDRESS`, `WEBROOT`, `ROOTLOG`), and checks that the service starts.
3. Produces a summary **CSV report** with the result of each phase for each host.

It runs completely silently for the end user (no visible window, only a brief stop/restart of the FOG service in the background).

### 3.6 Surviving future FOG updates

Both the `winpe3400` plugin and the wimboot files were moved **outside** the web tree managed by FOG (`/var/www/fog/`, which an update overwrites entirely):

- Plugin: moved to `/opt/fog/plugins/winpe3400/`. FOG itself creates a symlink from `lib/plugins/winpe3400` to this external location.
- wimboot files: moved to `/opt/fog/winpe_3400/`, served through a dedicated Apache `Alias` in `001-fog.conf`, with an explicit exception in FOG's `RewriteCond` rule so the application router does not intercept requests to this path.

**Note for future updates:** the Apache configuration (`001-fog.conf`) **is still overwritten** on every update. The added `Alias`/`RewriteCond` lines must be restored by hand after each FOG update, using the backup kept in `/opt/fog/backup-latitude3400-<date>/001-fog.conf` as a reference, or a simple `diff` to see quickly what is missing.

---

## PART 4: Final state and maintenance

### 4.1 Checklist after every future FOG update

1. `ls -la /var/www/fog/lib/plugins/ | grep winpe3400` should show the symlink to `/opt/fog/plugins/winpe3400`.
2. `sudo grep -n "winpe_3400" /etc/apache2/sites-enabled/001-fog.conf` should show the Alias/RewriteCond lines (if missing, restore from the backup).
3. `curl -sI http://<server>/fog/winpe_3400/wimboot` should answer `200 OK`.
4. Check in the web UI that the `winpe3400` plugin is still Activated/Installed.
5. Run a test deploy on a Latitude 3400 before considering the update complete.
6. Check that `/usr/local/sbin/fog-winpe-signals.sh`, `/etc/cron.d/fog-winpe-signals` and the folder `/opt/fog/FOG_Share/Deployment/Signals` (mode 777) still exist.
7. Check that `/home/fogproject` still exists (needed by vsftpd, see 4.3).

### 4.2 Files to keep

- `/opt/fog/plugins/winpe3400/`: the plugin code
- `/opt/fog/winpe_3400/`: `wimboot`, `BCD`, `boot.sdi`, `boot.wim` (the latter embeds `startnet.cmd` and `Apply-Image-Latitude3400.cmd`)
- `/opt/fog/FOG_Share/Deployment/Images/Latitude3400/install.wim`: the Windows 11 image for the custom deploy
- PowerShell script `Reinstall-FOGClient-Silent.ps1`: bulk client reinstall
- `/usr/local/sbin/fog-winpe-signals.sh`, `/etc/cron.d/fog-winpe-signals`: closes the Deploy task for the WinPE flow (see 5.1)
- `Signal-FOG.cmd`: inside `boot.wim`, together with the updated `Apply-Image-Latitude3400.cmd`

### 4.3 Lesson learned: `/home/fogproject` is NOT a harmless folder

During the post-upgrade cleanup, `/home/fogproject` was removed because it only contained `.bashrc`, `.config` and a generic script, apparently unimportant leftovers. In fact it is the **home directory** of the `fogproject` system user, which `vsftpd` needs for the FTP transfer of snapins between the web tier and the storage (even on a "Normal" server without a separate Storage Node, the transfer still goes through an FTP session to itself).

**Symptom:** every snapin failed with a "wrong" SHA-512 hash that was **identical on every attempt**. The file was not corrupt. `Snapins::stream()` (see `src/Agent/Snapins.php`) writes the **PHP error message** (`"cannot connect to the storage node"` or the underlying FTP error) **into the very file** the client downloads, instead of returning a clean HTTP error. The real FTP error, visible only in `journalctl -u vsftpd`, was:

```
500 OOPS: cannot change directory:/home/fogproject
```

(vsftpd authenticates the user but fails the `chdir` to the missing home right after login, aborting the session.)

**Fix:**
```bash
sudo mkdir -p /home/fogproject
sudo chown fogproject:fogproject /home/fogproject
sudo chmod 755 /home/fogproject
```

**Going forward:** before deleting any folder under `/home/`, check whether it is the home of an active system user (`id <username>` or `grep <username> /etc/passwd`), however harmless or empty its content looks.

### 4.4 Result

After all the fixes, an automated Latitude 3400 deploy (from scheduling the task to a PC that is ready to use, including a working WinRE and the automatic reboot) **needs no manual intervention**, with a result verified as stable over several consecutive tests from a completely clean disk.

---

## PART 5: Additions of October 5, 2026

### 5.1 The Deploy task stayed queued, so the PC was never renamed

**Symptom.** After a WinPE-flow deploy, the FOG Client log showed `TaskReboot Restarting computer for task`, followed by `HostnameChanger A power operation is pending, aborting module` and the same message for Snapin and PrinterManager. The PC rebooted repeatedly and was never renamed or joined to the domain.

**Cause.** The WinPE flow (diskpart + DISM) does not go through FOS, so nobody told FOG that the deploy was over. The Deploy task stayed in state `Queued`, and at every check-in the client scheduled a reboot that blocked the other modules. It shows in the DB as `tasks.taskStateID = 1` for the Deploy task.

**Solution.** After a successful deploy, WinPE signals completion to FOG with the same call FOS makes (`Post_Stage3.php`, which clears the host's keys, records the deploy date and moves the task to Complete). WinPE cannot make an HTTP request (see 5.2), so the signal goes through the SMB share:

1. `Signal-FOG.cmd` (inside `boot.wim`, in `Windows/System32`) reads the MAC addresses from `ipconfig /all`, writes a file with the MACs to `Z:\Deployment\Signals` and waits for an `.ok` or `.err` file.
2. On the server, `/usr/local/sbin/fog-winpe-signals.sh` (started every minute by `/etc/cron.d/fog-winpe-signals`, polling every 5 seconds) reads the file, accepts only valid MAC lists, calls `Post_Stage3.php?mac=...&type=down` and leaves the result in `<file>.ok` or `<file>.err`. The log is `/var/log/fog-winpe-signals.log`.
3. `Apply-Image-Latitude3400.cmd` calls `Signal-FOG.cmd` as step 6, after `bcdboot` and `bcdedit`, and ends with an explicit `exit /b 0`. Otherwise a leftover errorlevel from a non-fatal step would stop `startnet.cmd` before the reboot.

Everything lives outside the trees a FOG update rewrites (`/usr/local/sbin`, `/etc/cron.d`, `/opt/fog/FOG_Share`).

**Verification.** The task being closed through the whole chain was seen in the DB (tasks 452 and 453 in state 4 at the time of the call, with a matching line in the server log). After a deploy with this flow the PC renamed itself and the snapin started, with nothing cancelled by hand.

**Known minor issue, not solved.** On a real deploy the Latitude showed `ATTENZIONE: nessuna conferma dal server entro il tempo previsto` ("no confirmation from the server in time"; the script messages are in Italian), even though the server had already closed the task. WinPE did not see the `.ok` file that was on the share. The cause was not established; an unverified guess is the SMB client cache in WinPE. Practical effect: about 70 seconds more at the end of the deploy. If the warning appears, check the FOG web UI first: the task is almost always already Complete.

### 5.2 Tools missing from this WinPE

`certutil.exe` and `findstr.exe` are missing, besides the already known `timeout`, `choice` and `reagentc`. `find`, `ipconfig`, `ping`, `echo`, `type`, `net use` and the usual cmd expansions work. Any script for this WinPE has to be written with those only.

### 5.3 Secure Boot enabled with FOG

- **Observed:** with Secure Boot on and the DHCP configuration we started with, the Latitude beeped and opened the Dell diagnostics instead of showing the FOG menu. After setting DHCP option 067 to `secureboot/snponly-shimx64.efi` the FOG menu appeared. (The previous boot file was not signed, so that is the most likely cause, but it was not proven separately.)
- If FOG reports that the host does not trust the kernel, enrollment is needed, once per PC: from the PXE menu choose **"Enroll Secure Boot Key (MOK attended setup)"**; in MokManager choose **"Enroll key from disk"**, then the **iPXE** device and the **MOK.der** file. The "hash from disk" option fails with `Hash failed ... Unsupported`, because MOK.der is a certificate, not a binary.

### 5.4 Image management: name vs path

Changing an image's "Path" field in the FOG web UI also renames the physical folder under `/opt/images`. The "Name" field is just the display name. Before deleting an image from the web UI, check under `/opt/images` whether the files are removed: orphaned folders of several GB can remain.

### 5.5 Practical notes

- Task times in the database are two hours behind the server clock: always compare with that offset in mind.
- A heredoc pasted with leading spaces never terminates: use `printf '%s\n' ... > file` to create command files from a terminal.
- The FOG version in use is 1.6.0-RC-2. The RC-3 release notes list fixes for fog-agent, wildcard certificates and multiple master nodes, none of which applies to this setup (classic client, a single server, internal CA).

---

## PART 6: References

- FOG forum thread: "Windows 11 image captured from VM hangs indefinitely at Dell logo on Latitude 3400" (General section)
- Related historical cases (unresolved, same family of symptoms): forums.fogproject.org/topic/14191 (Latitude 3400), forums.fogproject.org/topic/14147 (Latitude 3500)