Wiping Drive via PXE menu
-
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 HostsI 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.xzWith :
kernel http://${fog-ip}/fog/service/ipxe/bzImage
initrd http://${fog-ip}/fog/service/ipxe/init.xzAlso 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 ?
-
@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?