@Obi-Jon the error is most likely completely unrelated to the compression level. if you can capture more information, we’ll see if we can find the cause.

@Obi-Jon you may want to use zstd -19 compression. that takes about 3x longer on upload for me, but it shaves another ~5% off the size of my images. it takes about the same time when deploying to a single machine, but that could make a big difference in the volume of network traffic with multiple unicasts

@Junkhacker no SSD on the server, it’s running in a vm with a raid for storage

@Obi-Jon it’s important to note that gzip (the default) only has legitimate values of 0-9. zstd has legitimate values of 0-19 (normal) 20-22 (ultra). i don’t have a computer that can use ultra settings without running out of ram and crashing, and i don’t think the extra gains from those settings would be worth it if i did.

@george1421 by using zstd compression 11 i have managed to make my images ~26% smaller and deploy ~36% faster. of course, that’s with a normal image. one full of video may not do so well. mine starts at about 18-20GB/min, but that settles down to the speed in the picture after it gets about 5% done.

since we’re sharing…

i5 SSD client
zstd -11 compression

@watson if you’re running 0.32, i kind of assume you’re also running an old server OS too. you’ll need to update that too.

@watson first off, you’re really going to want to update to the latest version of fog. the number of improvements, enhancements and optimizations are huge.
you’re going to have a hard time finding help with 0.32. it’s old, and frankly i’ve never used it (ok, i used it for a day, then started testing the development build, then 0.33b)
also, the lastest version of fog is faster than 0.32. like, way way faster.
i can assure you that the latest version of fog will work with the Optiplex 380 as well.

of course make a backup before you try upgrading

@watson fog version, client version if you’re using it, windows version, image type (resizable, not resizable, etc) ?
btw, my dedicated fog test machine is an Optiplex 3020, i can assure you that there are no issues with this model and fog, so whatever the issue is, we can help you figure it out.

@Tom-Elliott it looks like he tried to include a link to a picture in his post, but i can’t get it to load

@lmorel12 did you try the same things that solved the problem for OP?
for future reference, it’s best to create a new thread for issues unless you’re absolutely certain the issue is the same and it is still unsolved. new posts in a “solved” thread can get ignored very easily.

something i’ve done is to just leave windows running on a vm, getting windows updates automatically, and having a scheduled upload task that runs every week. you’ll want to not install the vm tools for the machine, since they can seem to cause some odd behavior when the image gets deployed back to real hardware

you’re going to have to be a bit more specific

also, if you just need the original to compare against, to find your mistake, you can find it here:
https://github.com/FOGProject/fogproject/tree/master/src/buildroot/package/fog/scripts/bin

@Lebowski simple answer: no.
complicated answer: it’s probably technically possible, but it would be less work to just create the image the way you want it to be deployed.

could you tell us more about how the partitions are laid out? which ones are restore/recovery/system/efi partitions?

@Foglalt said in Documented host drive killing:
in the postdownloadscript stage of my method, you could have the killdisk program generate the certificate and upload it to the fog server

i don’t think anyone has mentioned this so far, so i feel i should: FOG is not designed to be a backup solution. It is a systems deployment/management solution. Generally speaking, images are not expected to contain sensitive data (it’s usually just Operating System, and some programs, tweaked the way you want it).

@MarkusK I recommend you simply wait until there are no active imaging tasks before you create the snapin task, also you may have some luck with using a scheduled task for this

how about this:

1. you make an image and called it, for example “!KilldiskTask!”
   this image is just an empty formated drived that you’ve uploaded for the image. it exists only so that this is a valid imaging task
2. you create a postdownloadscript that checks if the image being deployed is “!KilldiskTask!” and, if so, retreives the killdisk linux terminal application from the server (you could put it in the service/ipxe directory on the server, so it could be downloaded just like the kernel and init files) and run it with the appropriate command line parameters (i have not tested that this program will work within FOS)

have your people

1. quick register
2. on reboot, task with a quick deploy of “!KilldiskTask!”

doing it this way, you have a hardware inventory of each computer, and a log of them getting the “!KilldiskTask!” deployment