https://www.reddit.com/r/sysadmin/comments/a727a8/fog_appreciation_post/

@Jbob said:

Tom is just … Tom.

that’s like saying: Superman is just … Superman.

trunk 7609? is there a reason you upgraded to a release that’s almost 2 months old? i think this has been fixed already.

@wanderson fog 0.32 was released in 2011. i’m afraid none of us know how to support it. it may be time to upgrade or migrate to a new install of fog. there have been far more than enough improvements to be worth it. your existing images will be compatible with the latest version of fog (as legacy images. if you migrate to a new server instead of upgrading a few setting will need to be set to recognize them properly, but they will work)

don’t forget to get the proper licensing. you can’t capture an OEM image and redeploy it to other computers and be in compliance with Microsoft’s licensing. you’ll need a volume license.
once you have an imaging server, you’ll find yourself using it a lot more than you think. user has a virus? a few hours to repair, or a few minutes to reimage, etc.

@VincentJ default compression level is 6. testing found that it had the best compression/performance ratio for us. i don’t think many people change it.

@Junkhacker to clarify, your new “default” menu item would contain something like this:

iseq ${serial} <labSerial1> &&  goto chainboot ||
iseq ${serial} <labSerial2> &&  goto chainboot ||
goto fog.local

:chainboot
set net0/next-server <otherPXEbootServerIP> && set filename <whateverFile> && chain 
tftp://<otherPXEbootServerIP>/<whateverFile> ||
exit

@dwagner sounds like you need to recreate the /images/dev/postinitscripts directory, and it’s contents, a single file named “fog.postinit” with the contents

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>

permissions 777
also, you’ll need to create an empty file named “.mntcheck” in /images/dev too, if you haven’t

@george1421 this one? https://forums.fogproject.org/topic/9396/stopping-web-service-failed/8?page=1

ok, here are my pseudo scientific results:

pigz vs pzstd (parallel implementation of zstandard, experimental)
tests were performed using a windows 7 image
(larger of 2 partitions only)
uncompressed image file size:34650439624

(de)compression tests were performed as closely as i could to emulate fog’s operation methods (without doing too much work :P). files were cat-ed from a mounted nfs share and piped into the programs, with results saved to an SSD. test machine was running Lubuntu instead of a custom FOS init, because i’m lazy.

pigz -6 compression
duration: 6:06
file size: 17548659028

pigz -6 decompression
duration: 6:00

pzstd default (3?) compression
duration: 5:16
file size: 16967988207

pzstd decompression default compression file
duration: 3:17

pzstd -6 compression
duration: 6:11
file size: 16247155611

pzstd decompression -6 compression file
duration: 3:16

pzstd -9 compression
duration: 10:00
file size: 16084180231

pzstd decompression -9 compression file
duration: 3:21

Edited to add zst compression level 6

@george1421 i meant to reply to this a long time ago, but here goes.

testing on deduping of those images has been done. they dedup quite well. the dedup changes affect zstd and pigz compressed images. pigz compressed images actually dedup better, but the the compression and performance are worse. it’s a tradeoff to be evaluated by the individual.

dedup is only possible with the newer version of partclone due to a rolling checksum integraed into the image format on earlier versions. the newer version lets us choose no checksum.

the compressed binary file is dedupable thanks to the --rsyncable flag on compression that is supported by both pigz and zstd.

like george said, any deduping would be the responsibility of the underlying filesystem or storage, not built into fog itself.

@fog_newb “FTP IMAGE SIZE” on the settings page

on the subject of “not using nfsv3” i have an idea on how to reimplement torrent-casting. clients receiving images wouldn’t need file level access at all (though uploads would still need nfs).

would there be any interest?

for virtualbox, i recall having better luck if i set up the vm OS version as being “windows 7”

since you’re able to get the furthest with that, maybe give that a try

@init32 what are you running for DHCP?

@Tom-Elliott i think we should default to Y/n instead of y/N

most people don’t care one way or the other and will just click through, let the people who care chose not to send it

@Wayne-Workman how about “install survey”

@Wayne-Workman shall we make the stats public, because “why not” and to be transparent about what we collect?

@THEMCV to be honest, i’m not sure. i haven’t been involved much between the new kernel size being experimental to it being in production. i just recognized the problem.

@THEMCV You need to update a FOG Configuration->Fog Settings parameter->TFTP Server->KERNEL RAMDISK SIZE set it to 275000 from the original value of 127000