Wiping Drive via PXE menu

vanfifty1

It was mentioned in an earlier post:

@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

@vanfifty1 Yes, the information was likely psuedo code and your method:

kernel {{schema}}://${fog-ip}/fog/service/ipxe/{{kernel}}
initrd {{schema}}://${fog-ip}/fog/service/ipxe/{{initrd}}

Would be the more correct method, unless you were hosting directly off tftp and you put the kernel/initrd in the tftpboot folder (where your tftpd daemon is housing the files.)

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?

Database failed after the update, yes this is true. The code that fires tries to complete a task, but it seems there was no task actually created in the database so there’s nothing to fire against (especially on machines that are not registered.)

NVME has a special path mainly because:

SSD is very very fast. However, because it’s a super fast “flash” you should never use the spinner type wipe style on SSDs. Writing 0’s or random digits to disk is only necessary on Spinners in the slow style you’re thinking.

That said, I’m taking a look and there does seem to be a potential bug in how wipe is functioning that I wasn’t aware of until now, so having a look at that.

I might ask you to download the experimental initrd when that completes to see if it is working as you would expect (maybe slower, maybe no major noticable change, I don’t know yet.) This takes time to build of course.

Tom Elliott

@vanfifty1 Expermental release is built and ready for testing:

seen here:
https://github.com/FOGProject/fos/releases/tag/EXP_20260716-114430

vanfifty1

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

Tom Elliott

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

vanfifty1

@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

@vanfifty1 said in Wiping Drive via PXE menu:

"
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

The bug was that it didn’t check on any failure and would just alwasy presume success which is not correct. This at least shows the SES (Secure Erase) for the nvme types and is returning the correct errors.

Unsure why it’s failing but working what I can.

Running checks at this point. I need the info to fix the problem and you’re helping whether you know it or not.

Tom Elliott

@vanfifty1 Performing another build as required. Will come back when it’s ready.

Tom Elliott

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

vanfifty1

@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

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

Wiping Drive via PXE menu

86

12.7k

17.6k

156.8k