@wt_101 When I say heavy lifting is done by the client computer, I mean all of the work and the actual performance of fog imaging is directly impacted by the target computer’s capabilities and components. While I understand this is technically impossible, but if you have 2 computers that are exactly matched, except for one has DDR3 1600 and the other has DDR4 2133 RAM, the second computer with the faster ram will deploy the image faster because the transferred image is decompressed in ram on the target computer (more on that in Q2).

Q1 To be honest I never paid attention to what the web ui says for size vs what is on the disk. Off the top of my head having a 3:1 compression ratio seems a bit high in my estimation. Is it possible, yes. What really is a metric is what is the size of actual data on the target computer vs the size of the image files. Its possible that the web ui is recording something different that raw source disk vs compressed image file. There is a compression slider in the image definition. This tells the compressor what compression metric to use (not the right words) during compression. The higher the number the more compression methods it uses to compress the data. i think the slider is set for a default of 4 or 6 for gzip that value is a good balance between compression size and speed. For zstd the Goldilocks number is 11. Where the gzip compressor has a range of 0 to 9, zstd has a range of 0 to 22. I don’t think anyone has done any testing to find the actual Goldilocks number in a quantitative way though. I suspect they found a number that worked well for them and called it good.

Q2 Option A is correct. The image is compressed/decompressed on the client so only a compress image is ever communicated with the client. This saves on storage image size on the storage node as well as transfer bandwidth. From a metric standpoint I know that a 25GB target image can be transferred in about 4 minutes. The only way that’s possible on a 1 GbE network is to transfer a compressed image.

Q3 See that is where the magic of FOG is. The developers created a custom version of linux. That version of linux is called FOS (FOG Operating System). That OS has all of the tools built in that FOG uses to image a target computer. Yes FOS has zstd and gzip compressors built in. When you pxe boot a computer during image, first the iPXE boot loader is transferred to the target computer. iPXE is responsible for the FOG iPXE menu. Once you make a menu selection (like registration) you will see two files transferred to the target computer if you have a fast eye. You will see bzImage (the kernel) and init.xz (virtual hard drive) send to the target computer, that IS FOS linux being sent over. The OS is very small and very fast.

For Point 4, that is more of a question for the developers. I don’t look under the hood for statistics settings. I just know that on the Partclone screen what that speed number means. I don’t know if the FOG program as a way to record that speed or not. As for taskelasped time I think that means something else. As I mentioned above, on a 1 GbE network a 25GB image should take about 4 minutes of transfer time. 16 seconds seems a bit quick.

For Point 6, The fog client is used for more than just renaming the client and connecting the target computer to AD. Its also used for application deployment and some rudimentary system management. You do not need to run the FOG Client if you don’t want to manage the target computer after image deployment.

Q1 yes there is a way. On my campus, which is mostly MS Windows based, I don’t use the fog client at all, yet I still have a touchless deployment. I leverage a feature in FOG called a Post Install Script to make changes to MS Windows unattend.xml file just after the image is pushed to the target computer. For a linux client it is just as easy most of the things that configure linux is just in text file, and FOS Linux is… wait for it… linux, so the possibilities are endless. The concept of a post install script is that you would create a bash script on the fog server that is executed by FOS Linux. That bash script would mount the target computer’s hard drive (post image deployment) and make the necessary adjustments to the hostname and any other deployment specific settings. The post install script can have access to fog host definition variable so you can leverage some of the extra fields in the host definition for specific uses (like other1 and other2 fields).

@lerne-nie-aus if i give static ip, than i can ping 8.8.8.8 and surf in internet.

I dont know why:(

@george1421 said in User defaults to root on image capture:

The root of the issue is that when FOS Linux (which runs on the target computer) clones an image it runs as root (to have full control of the target computer during imaging), that is why they are being created on the FOG server as the root user.

That’s correct, though not the whole truth. FTP is used within the FOG server internally to move the fully captured image files from /images/dev/… to it’s final destination /images/IMAGENAME/. It’s been a long time since I looked at that part last time but I think it was actually meant to do a chown operation alongside those FTP move and rename operation. But I can’t remember why this wasn’t actually working from the top of my head. It’s probably still the case because it works in pretty much all cases since then.

I guess it can be changed to chown fogproject user If you can explain why it causes issues on deploy in your case. What’s special about your setup? Modifications?

@sebastian-roth May have just fixed it - had to set the server I restored from snapshot to the correct location in “Location Management” on the master server. Will update thread once I get an opportunity to test.

Sorry, I only noticed after posting that I accidentally removed a single ’ character when I edited my tokens for the post.

@lerne-nie-aus said in Deployment without Register and credentials:

Or where i can find some batch file or unattendend.xml to check for zero touch deploying?

This is a MS Windows thing and not really anything that FOG cares about. The unattend.xml and sysprep there are many examples of how to do that part on the internet. How I do this is I use MDT to build the golden image then sysprep and power off the golden image VM. Then reboot the golden image VM and capture with FOG. So FOG only moves the disk image from local hard drive to and from the FOG server. Once the image is copied over to the target computer and the target computer is rebooted then FOG does not touch it any more.

My Question was, if i dont need to select this image and if i can set it up somewhere else as default.

Just so I’m clear here, You want to PXE boot into iPXE and then have a single image deployed to a computer without anyone touching it? Like PXE boot then image is deployed? If you think about its like a deep freeze system restore? I’m just trying to understand your use case. Can it be done with FOG? yes. Should you do this? I can’t answer that.

Thank you both for your help! George and I were messaging back and forth and my DHCP policies and scopes were pretty messed up. Looking back I have no idea how it worked before. After completely changing them the machines are booting into FOG again just fine. Appreciate the quick responses!

@sebastian-roth Thanks!! We will double your pay! I love the FOG project and I really appreciate the FOG community! thanks again!

@lerne-nie-aus Well you have 1 big issue and a few small issues.

The big issue is that the OS that clone’s the disks is linux based so it can’t directly interact with the target windows OS.

With that said, the proxy settings for Windows are typically deployed via Windows GPO policy.

The proxy settings are user specific, so the values are stored in HKCU (current user) and not in a system location (HKLM).

@jaceituno Do you still see all the images listed? What about groups, maybe snapins, printers and older tasks? What is still there and what is missing? Any obvious error messages in the FOG web UI?

@blueberry By default the iPXE binaries go into /tftpboot/ in your FOG server.

@sebastian-roth Thanks, i did it with rename.

I am not expert so i wanted give the options by instalation. Thats why i just renamed the .fogsettings file.

@sebastian-roth Perfect. The original install was through a Group Policy .msi push, so I added the newer agent to replace the old one. Appreciate the quick info!

@doc Having backups would have saved you some pain, but you can rebuild it.

Understand this memory is vague, but I seem to recall if the fog client is installed on your target computers, when the fog client checks in, the registration will be created, but in a pending state, where you need to authorize the client in the FOG Web ui. If it still works that way, this may be a way to rebuild the registrations without much pain. The other options may be to add the hosts via a csv file into the host table, there may be a web ui option to import hosts too. You will at least need hostname and mac address.

@poizzon Same here. I tried replacing in S: partition to the latest rEFInd but still getting stuck at “initializing”.

Finally got a chance to run the upgrade again and figured out my issue.

For some reason safari wasn’t happy with the upgrade. I can open fog fine from a private window or if I cleared history. It doesn’t open in Chrome, which was my other test because chrome doesn’t trust the ssl cert and no longer gives an option to bypass by default.

@george1421 That’s probably why its not working, I have my root account username is fog. Thank you, I will change it

@Pinki This sounds like a layer 7 firewall is in between FOG server and the client/host. Sometimes alles the transfer of init.xz but more often blocks it.

The later error is due to the firewall not allowing connections on random network ports which are used by NFS.

Either way you need to talk to your network/security team and see if they can help.