Wiping Drive via PXE menu
-
@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.
-
@vanfifty1 Expermental release is built and ready for testing:
seen here:
https://github.com/FOGProject/fos/releases/tag/EXP_20260716-114430 -
@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?
-
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?
-
@Tom-Elliott said in Wiping Drive via PXE menu:
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) … FailedAn 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? -
@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) … FailedAn 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 erasedThe 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.
-
@vanfifty1 Performing another build as required. Will come back when it’s ready.
-
@vanfifty1 Latest experimental is available here:
https://github.com/FOGProject/fos/releases/tag/EXP_20260716-155505 -
@Tom-Elliott said in Wiping Drive via PXE menu:
@vanfifty1 Latest experimental is available here:
https://github.com/FOGProject/fos/releases/tag/EXP_20260716-155505Tested 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.” -
@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!
-
@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?
