@klkwarrior why not do full registration?

@alouis here’s what i use

:MENU
menu
item --gap -- ---------------- iPXE boot menu ----------------
item clonezilla_backup Clonezilla backup
item clonezilla_restore Clonezilla restore
item return return to previous menu
choose --default return target && goto ${target}

:clonezilla_backup
login
kernel http://${fog-ip}/ipxe/clonezilla/live/vmlinuz initrd=http://${fog-ip}/ipxe/clonezilla/live/initrd.img ocs_live_run="ocs-live-general" boot=live live-config noswap nolocales keyboard-layouts=NONE edd=on nomodeset ocs_daemonon="ssh" ocs_lang="en_US.UTF-8" vga=788 nosplash fetch=http://${fog-ip}/ipxe/clonezilla/live/filesystem.squashfs ocs_prerun="mount.cifs -o user=${username},dom=<domain>,pass=${password},vers=2.1,rsize=32768,wsize=32768,rw, //server/share/clonezilla/${username} /home/partimag "
initrd http://${fog-ip}/ipxe/clonezilla/live/initrd.img
boot ||
goto MENU
:clonezilla_restore
login
kernel http://${fog-ip}/ipxe/clonezilla/live/vmlinuz initrd=http://${fog-ip}/ipxe/clonezilla/live/initrd.img ocs_live_run="ocs-live-general" boot=live live-config noswap nolocales keyboard-layouts=NONE edd=on nomodeset ocs_daemonon="ssh" ocs_lang="en_US.UTF-8" vga=788 nosplash fetch=http://${fog-ip}/ipxe/clonezilla/live/filesystem.squashfs ocs_prerun="mount.cifs -o user=${username},dom=<domain>,pass=${password},vers=2.1,rsize=32768,ro, //server/share/clonezilla/restore /home/partimag "
initrd http://${fog-ip}/ipxe/clonezilla/live/initrd.img
boot ||
goto MENU

i this uses a mapped smb location using user supplied credentials to save into a folder that shares the user’s name.
to restore images, move the image to the “restore” directory.
i did it this way to reduce clutter by multiple people saving images, and adding a small amount of security, since most of this is done by student workers.

just reporting in problems i encountered testing 1.6
registered new host, created new image, tried to upload image of host to the newly created image:
image uploaded, but repeatedly failed to update database that it had finished.
while looking at the error, i realized that invalid parameters were sent to the computer, as well
the newly created image had a compression value set to 0 and the compression type was not assigned. i could not update these values on the image’s profile page. nor could i import a image list with corrected values.

I don’t have time to troubleshoot further right now, but I am interested if anyone can reproduce similar problems (or i just messed up my setup somehow).

@candidom i think one FOG server configured that way should be able to handle it. you might want to consider trying it with 1 before buying the other 2. i was doing 30+ at a time with traditional drives in a raid 5 at speeds that i found quite adequate.

@vascomorais here’s how the advanced menu is used https://wiki.fogproject.org/wiki/index.php?title=Advanced_Boot_Menu_Configuration_options

@vascomorais fog configuration > ipxe general configuration > advanced menu settings
there should be a text box at the “Advanced menu command” line

if you’d like my advice, here’s what it would be. just buy 1 server with SSDs in a raid 10 or raid 5. use zstd compression on your images set to a compression level of 11.

i honestly think you’ll get better performance out of a single fog server with a solid storage subsystem then 3 lower speced servers (not to mention you won’t be wasting the storage on redundant copies, allowing better cost benefit per GB)

@hvaransky if you’re wanting high compression, you’ll want to switch to zstd. it’s faster and compresses better. don’t bother with maxing it out though, you’ll triple the time it takes to compress and only save a few % in size. comparing gzip -6 to zstd -11 ( our recommended settings ) my testing showed zstd was 10% faster at capture, 26% smaller in final file size, and 36% faster on deployment

@compman while that’s true, in practice zstd at a higher compression level will return a faster overall process when the bottleneck is the network.