@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!

Thank you!

With the experimental init.xz when it said the following in my case: “Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)” does this mean the following command was run?: nvme sanitize /dev/nvme0n1 -a 2

Does this mean the bug is patched? Should I use the experimental init.xz file on the production FOG server? What ramifications will this have? Is it better to wait until this is released in an official version down the road?

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Latest experimental is available here:
https://github.com/FOGProject/fos/releases/tag/EXP_20260716-155505

Tested and wipe was successful. It is faster, about six seconds vs ten seconds with the non experimental init.xz file.

Also previously it was less verbose stating:
“Starting disk wipe of /dev/nvme0n1 using nvme format …
Success formatting namespace:1
Wiping complete.”

With the experimental init.xz file it states:
“Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)
Sanitize cannot be canceled once started; it will resume after a power cycle.
Sanitizing /dev/nvme0n1 … 100%
Wiping complete.”

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1

I think it depends, bu tif it’s working then you’re fine.

Ultmately are you saying the wipe succeeded and worked?

Did it take longer or was it still pretty fast and unexpected?

The wipe succeeded using the original init.xz file that was part of FOG 1.5.10.1826
In terms of speed it was very fast but as I am new to FOG I have no previous history to compare against. My expectation was a long erase time similar to killdisk which takes hours rather than about 10 seconds with FOG (just timed it). Though you clarified in your previous post about this and how writing zeros/random writes is only needed with older non SSD drives…

I just cloned the FOG server to a different system and copied the experimental init.xz file to /var/www/fog/service/ipxe
Selecting the custom wipe option that I added to the menu resulted in the wipe failing:

"
Erasing /dev/nvme01 with NVMe sanitize block erase (sanact 2)
…
…
Sanitize failed; falling back to a format user data erase
Erasing /dev/nvme0n1 (nvme format --ses=1, user data erase) … Failed

An error has been detected!

Init version: 20260716
The wipe of /dev/nvme0n1 did NOT complete. (/bin/fog.wipe)
Mode: Full
This disk still holds its data; do not treat it as erased.
"
It seemed to be fine with the previous init.xz file that was part of FOG 1.5.10.1826. What was the bug that you found?

@Tom-Elliott said in Wiping Drive via PXE menu:

As for the RAMDISK size within the gui, 256000 (256~ MB) should be plenty big enough to house the initrd file, but 512000 is fine as well. We have a default set of 275000 for some time now, so if you upgraded from a very old version of fog that might explain this particular issue or are you saying this needs even more room now?

I am using a recent version of FOG installed in May or June 2026. It looks like even more room is required now as I needed to change rhe argument ramdisk_size=256000 to something larger (I used 512000).

The original suggested PXE menu entry suggestion included “imgfetch init.xz”. I left it out and it still started the wipe fine. I am assuming this line is not required?

Re: Wiping HD

It was mentioned in an earlier post:

@george1421 said in Wiping HD:

@lostitguy We you will need to make up your own fog ipxe menu to specifically call the wipe function.

I am not 100% sure I have the stanza right but it should look like this

Menu Item: fog.wipeit
Description: FOG builtin Disk Eraser Tool
Parameters:
kernel tftp://${fog-ip}/bzImage
initrd tftp://${fog-ip}/init.xz
imagargs bzImage initrd=init.xz root=/dev/ram0 rw ramdisk_size=256000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 mode=wipe wipemode=full
imgfetch init.xz
boot ||
goto MENU
Menu Show with: All Hosts

I was trying this today. As things likely changed since this was posted I found that I needed to change:

kernel tftp://${fog-ip}/bzImage
initrd tftp://${fog-ip}/init.xz

With :

kernel http://${fog-ip}/fog/service/ipxe/bzImage
initrd http://${fog-ip}/fog/service/ipxe/init.xz

Also there was a ram error so needed to increase size of the ramdisk to something larger such as 512000

I also omitted imgfetch init.xz and it still worked to my understandimg. Can someone please confirm that this line is redundant?

I get a database failed to update after the wipe. I am assuming this is because the wipe was initiated without being tasked?

Also I was surprised that the full wipe on the nvme SSD took less than a minute. Shouldn’t it take much long to write zeros or does FOG wipe perform some other type of erasure? If so what kind of erase method does FOG use for wipemode=full ?

@Tom-Elliott When searching for a solution I recall seeing a related post on GitHub but that was not me. Today I created a new VM that was 70GB with 2GB EFI partition and after sysprep and it yielded the similar resize error during capture.

I then tried Windows 11 25H2 June 2026 Build 26200.8655 with 60GB VM and it generated the resize error. 25H2 with 60GB VM and 2GB EFI also generated the resize error after sysprep during capture.

The AI suggested defrag C : /X

I ran the defrag before sysprep and capture was succesful.

The pre optimization total fragmentation was 22% and post defragmentation it was also 22%

To my understanding the /X flag consolidates free space. How was this the solution to my issue?

Per the FOG Project wiki I found that defrag is recommended before sysprep:

"…
Before Running Sysprep
Other steps to consider are:

Run Chkdsk /f /p prior to imaging
Defrag the drive
Make sure 2gb of disk space is free or the NTFSresize will fail
Make sure the FOG service is installed and properly configured
Update your hostnamechange.dll file
…
"
https://wiki.fogproject.org/wiki/index.php/Client_Setup

Working in a VM (QEMU/KVM/Libvert) I found that attempting to capture (single disk resizable) a fresh ISO (June 2026 Windows 11 Enterprise) install where I enter audit Mode and then sysprep, the capture fails to resize during the FOG capture process:

“An error has been detected! … Resize test failed! … Device name: /dev/sda3 … Space in use: 10535MB (16.6%) … Needed relocations: 1610313 (6596MB) … ERROR(28): Could not update runlist for attribute 0x80 in node 156294: No space left on device (shrink partition) Args Passed: /dev/sda /images…”

Previously I had no issue capturing an install using Windows 11 Build 28000.1836 via FOG. The older build allowed for smaller VM disk size such as 40GB if I recall. The newer June 2026 ISO Build requires around 50GB for Windows 11Enterprise to install (else there is an error) so I allocated 60GB to the current VM (where I am getting the capture error).

I found that on the June 2026 Build (28000.2269) if I set the EFI partition size to 2GB (still using 60GB VM disk size) during the installation using diskpart, complete the install, enter audit mode, sysprep, and then attempt the capture I am successful and there is no resize failure. Why does setting the EFI partition to a larger size allow the capture process to succeed? (I found this by accident as I was increasing the EFI partition for another reason discussed in the side note here.

Working in a VM (QEMU/KVM/Libvert) I found that attempting to capture (single disk resizable) a fresh ISO (June 2026 Windows 11 Enterprise) install where I enter audit Mode and then sysprep, the capture fails to resize during the FOG capture process:

“An error has been detected! … Resize test failed! … Device name: /dev/sda3 … Space in use: 10535MB (16.6%) … Needed relocations: 1610313 (6596MB) … ERROR(28): Could not update runlist for attribute 0x80 in inode 156294: No space left on device (shrink partition) Args Passed: /dev/sda /images…”

Previously I had no issue capturing an install using Windows 11 Build 28000.1836 via FOG. The older build allowed for smaller VM disk size such as 40GB if I recall. The newer June 2026 ISO Build requires around 50GB for Windows 11Enterprise to install (else there is an error) so I allocated 60GB to the current VM (where I am getting the capture error).

I found that on the June 2026 Build (28000.2269) if I set the EFI partition size to 2GB (still using 60GB VM disk size) during the installation using diskpart, complete the install, enter audit mode, sysprep, and then attempt the capture I am successful and there is no resize failure. Why does setting the EFI partition to a larger size allow the capture process to succeed? (I found this by accident as I was increasing the EFI partition for another reason discussed in the side note here)

I originally posted here and hoping for more feedback.

I am imaging a Dell laptop (Windows 11) using FOG. The laptop has two identical hard drives identified by FOG as /dev/nvme0n1 and /dev/nvme1n1

I imaged one of the drives a couple times, first using GParted to delete any existing partitions on any of the drives (not formatting). I recall one time after imaging Windows logged in after OOBE (the image was syspreped) and after restarting I got a Windows Inaccessible Boot Device Error. I had options to go into Windows recovery modes. I recall subsequent imaging and restart went ok.

At one point I decided to try imaging the other drive (again deleting any existing partitions first). After FOG finished its imaging and Windows started its setup, the computer started up Dell Diagnostics automatically (which happens on this laptop when both drives have their partitions erased). Subsequent imaging resulted in the imaging completing and Windows logging in as before though after restarting the Inaccessible Boot Device Error occured. I tried deleting the Windows Boot Manager entry in the firmware between reimaging however this did not resolve the issue.

I don’t see any option in the firmware to disable a drive. I physically removed the second drive and it imaged fine, about 4-5 reimages, and restarting Windows caused no issues.

Is this a UEFI/NVRAM issue or something else? Would there be anything I could try instead of having to remove one of the drives?