@Wayne-Workman a couple minor corrections. the last official release to capture using partimage was 0.32, i think. images have always been gzip compressed. between 1.2 and 1.3 the program for decompressing was switched to pigz. pigz is a parallel (multi-threading) implementation of gzip compression, which sped it up a bit.

@Wayne-Workman let me save you the trouble of testing:

    case $imgFormat in
        6)
            # ZSTD Split files compressed.
            zstdmt --ultra $PIGZ_COMP < $fifo | split -a 3 -d -b 200m - ${file}. &
            ;;
        5)
            # ZSTD compressed.
            zstdmt --ultra $PIGZ_COMP < $fifo > ${file}.000 &
            ;;
        4)
            # Split files uncompressed.
            cat $fifo | split -a 3 -d -b 200m - ${file}. &
            ;;
        3)
            # Uncompressed.
            cat $fifo > ${file}.000 &
            ;;
        2)
            # GZip/piGZ Split file compressed.
            pigz $PIGZ_COMP < $fifo | split -a 3 -d -b 200m - ${file}. &
            ;;
        *)
            # GZip/piGZ Compressed.
            pigz $PIGZ_COMP < $fifo > ${file}.000 &
        ;;
esac

this is the code that the image format setting gets used for on uploads. the default partclone image format is “1” partimage is “0”
as you can see, literally the same thing is done on an upload with either of those two settings set with regard to how the image is captured.

@scgsg since we no longer support capturing with partimage, a capture image set to partimage is captured using partclone with literally the exact same code as if it had been properly set to partclone to begin with. I suspect external factors are at play causing any difference in speed you are seeing.

@scgsg if you want to optimize for speed, i suggest switching to zstd compression. it works better with modern multi-core multi-thread processors than the previously used types. as for whether partimage or partclone is faster by themselves, i consider it a moot point since partimage has not been under active development in 7 years. partclone might be slower due to it’s built in checksums.

@x23piracy yeah, if he wants to clone to the drives in the way he originally describes clonezilla is probably the best choice.

@jaoyer whatever is serving out options 66/67 dhcp options is providing the next-server address.

@jaoyer those worked. any luck with default.ipxe?

@jaoyer

Your client does not have permission to get URL /v8XwHa7EvGmlAc-9NqToHtVtsfdfcbDoKR-Q-y0feAsv0D-ahsZHipQqqP77P5y2BJ1WeycTgJyMFs4SpaqKDG64f-YfxHhxPAY6=w1920-h941-rw from this server.(Client IP address: <retracted>)

Forbidden That’s all we know. 

first thing i’m going to recommend is that you upgrade to fog version 1.4.0. so many many things have been fixed or improved.

have you migrated your images and database info from the old server to the new? if you get the new server working, will you need the old one at all?

quick and dumb solution for a lot of your issues: put a copy of the default.ipxe file from the new server in the /tftpboot folder of your FOG 0.32 server so that it can always be found and loaded. that file just loads the next file from http. it doesn’t technically need to be on the new server.

oh, and btw, your images didn’t load

@Wayne-Workman fixed
of course, this is super slow compared to our current imaging speed. i image in almost half that time now.

@Wayne-Workman i’ve created a demo video in the past for a conference i spoke at
https://youtu.be/gHNPTmlrccM
i just don’t have the time to edit the video for a new one

i have to recommend that you give FOG a shot as it is supposed to be configured. with as fast as FOG images systems, you’ll have them all imaged in the time it would take you to remove all their hard drives for your original intended method. does anyone have a demo video from after we added zstd compression?

@george1421 that sounds the easiest to me too. since it sounds like he’s not registering them and managing them in fog anyway. the only tasks it would affect are captures and deploys.

@vkenny said in Mounting /images/dev Permission Denied:

Attempting to work my way through the creation of a backup solution…

I just want to address this from your first post. Fog is NOT a backup solution. It is a deployment solution. I do not recommend you try to use it for backups.

@***Redbob in the file /tftpboot/default.ipxe
edit it with a text editor like nano or vi

i did this once.
here’s what i had to do for the kernel arguments of the custom task

&& imgfree && initrd http://${fog-ip}/<path>/Win7PE_x64.ISO && chain memdisk iso raw ||

the default kernel name and arguments get passed by fog, then this says “when you’re done loading that kernel and init into memory, drop that kernel and init from memory, then load this ISO file into memory and boot from it”

@george1421 said in New to Fog:

If you have someone that knows linux, they can create new fog server in under an hour from bare metal to a working fog server.

and if you don’t have anyone that knows linux, you can probably still fumble your way through getting a new fog server up and running in a day

@Tom-Elliott true, forgot about that. we only deploy traditional hard drives in special cases now. we find it’s more effective for us to put in an SSD than a faster processor for our users.

point being, if someone had relatively small image storage requirements they could probably get as fast of results as i do by putting an SSD in their server.

@george1421 i don’t think my setup is really that special. it’s a gigabit network with dell clients and a used Poweredge R510 we picked up cheap for the server (perc H700 raid controller with a 24 drive array, which is probably why i have the nice speed, tbh)

@george1421 said in FOG Server CPU Requirements:

I would expect a single unicast image to deploy about 6GB/m on a typical solid network.

is a typical network really that slow?