Wipe and Image from PXE
-
@Wayne-Workman I found this: https://forums.fogproject.org/topic/6696/fog-and-tasks/3 but the solution wasn’t conclusive in my mind. Were you thinking of another thread?
-
Just so I’m clear on this, you want in one action to wipe the system and then quick image it?
You can do this in two steps by loading a dban iso into FOG and then create an iPXE menu item to call dban once dban is done then you would reboot into the iPXE menu and you could then select quick image.
Beyond that if you wanted it in one action you would need to integrate dban into the FOS Engine’s (the OS that moves data between the fog computer and target computer) virtual hard drive (init.xz). While adding stuff to the inits are not hard one must do it with some care.
-
@MattPayerle Found it.
https://forums.fogproject.org/topic/7407/dban-booting-into-adThere is another thread somewhere around here where a person used the FOG Plugin
tasktypeeditto add FOG Wipe as a regular deploy-able task. I have been looking for that one but I can’t find it, but I remember the person was successful. -
Why do you need to do a wipe before imaging anyways? It’s not necessary at all, unless you’re reselling computers that had sensitive stuff on them prior.
-
@Wayne-Workman Thanks, really great stuff, and I appreciate your dedication to this project!
I prefer to do a wipe of the drive before deployment, perhaps it is just what I have done or what I am comfortable with. The company I work for uses a paid, enterprise level product that has pre-installation task that take care of things such as this. Even if it is just a quick wipe of the drive, and reconfigure the partition table, I feel slightly better about this. It would be neat if we could daisy chain some of these tasks together, because I really like the boot option to wipe, which I just created and am testing, and then will deploy again to the same box, maybe something to look forward to in a future release
Until then, I think this option will work.
On a side note, it looks like I can somewhat schedule some tasks, but only when the host has been registered with the server. That said, when scheduling a task, the first option is “Schedule Shutdown on completion” Anyway to add another option that is “Schedule reboot”? This would allow me to schedule items one after another, with the auto reboots in the middle and it would be somewhat automated. I am testing this currently so I’m hoping that if I schedule a normal wipe, say at 10pm, and then a deploy image task at 10:05pm, even though the wipe might take longer, it will still do the task, but again, I’m testing and not sure what the intended thought is here.
Thanks again for answering and your support towards a really awesome project. Keep up the hard work!
-
@MattPayerle said in Wipe and Image from PXE:
That said, when scheduling a task, the first option is “Schedule Shutdown on completion” Anyway to add another option that is “Schedule reboot”? This would allow me to schedule items one after another, with the auto reboots in the middle and it would be somewhat automated.
I don’t think I’m following what you’re getting at. Image deployment tasks reboot afterwards by default. Shutdown and reboot are options for snapins already.
-
@Wayne-Workman Ok, so then it is just a learning curve then. It didn’t specify that a reboot was built in. So I can stack tasks against a host (once registered) to do a Normal wipe, and then deploy image. The image below shows the checkbox to shutdown, so I wouldn’t need this, I could leave that unchecked because it would reboot automatically as you say, which is awesome.
Also, there might be an issue with Normal wipe. If I use this basic task (under advanced tasks for each host) OR I create an iPXE menu option as you outline here: https://forums.fogproject.org/topic/7407/dban-booting-into-ad
It halts at this:
This works just fine for a full wipe and fast wipe, I can see it do the work as it does 4 passes, or a quick wipe. But for some reason, normal does this. Thanks again, I appreciate it.
-
@MattPayerle In the picture you posted, it appears normal. It takes a really long time to write zeros across a big drive. If anything, it would indicate an issue with full-wipe, because full-wipe should take x4 longer than normal wipe. @Tom-Elliott.
-
@Wayne-Workman Ok, I let that process sit overnight on a normal wipe and it never did anything. When I did the Full wipe, the process started right away and moved through the blocks, 4 times. It’s on a VM with a fair amount of RAM and CPU and a small drive, so it didn’t take a long time for the full wipe, but the normal wipe never seemed to start at all. Thanks for any insight.
-
@MattPayerle Ok then, you’re right there is a problem. What version of FOG are you on?
-
@Wayne-Workman 1.3.0 RC 5. I tried doing the update to RC 7 but it isn’t pulling properly from git. Do the git pull and installfog.sh and it does the installation, and completes, but the version doesn’t change. Running on Centos 7.
-
@MattPayerle Wherever your repo is that your working with (the fog repo), just delete it and re-clone the whole project.
-
@Wayne-Workman Ok, great tip on that. I am now up to RC-8.
I went ahead and imaged a machine, and then kicked off the normal wipe. It sat at the same screenshot I sent earlier for about 30 minutes, and then shutdown, but I didn’t see any messages, or might have missed them that it was wiped. Regardless, it does wipe the drive because it doesn’t allow it to boot to the hard drive. Perhaps verbosity could be turned on for this? I can use quick wipes for most other things, but it also seems like the full (4 pass) wipe took about 15 minutes long, so I figured this would take about 1/4th the amount of time, but it took nearly twice. So one or the other must be fouled up somewhere. No major rush for me for a fix, but wanted to illuminate a possible bug. Let me know if there is anything else you can think of or need me to test with it, happy to help out where possible.
-
@MattPayerle Can you make a new thread about the output and normal wipe? We are willing to help but this is way off topic of the thread title.
-
@Wayne-Workman Agreed, I figured I should file it as a bug anyway. Thanks for the help here. I’ll post shortly regarding this.
