@hvaransky This error has nothing to do with debug mode I reckon. Did you set a kernel name in that client’s host settings?? Or maybe you changed the general FOG configuration in the web UI?!

@alex84 reading the post I see no issues with what @Wayne-Workman has asked.

If indeed capture takes forever but deploy is fast as your post suggests, what is the compression set too? What is the RAM (size/speed)? What is the disk?(ssd/spinner) is the disk good?

@wayne-workman
Thank you workman, I will read the Wiki page.
Thanks again.

@george1421 I might just try that, just for troubleshooting purposes.

Re: firmware - There is a BIOS update for the machines, and a firmware update for the NVM Samsung drive. Sadly, trying these was my first troubleshooting step (not listed here, because it was before I suspected components of FOG). I sure was holding my breath that it was the drive firmware though!

So that gave me the answer I needed. It’s not a problem with fog. These aren’t the machines they were supposed to be they sent us the 64gb emmc version instead of the 128gb m.2 thanks for your help.

@cs_pccs Please start a new thread since your conditions are likely different than the OP, unless you just upgraded from 0.32 version of FOG.

Please include any images you feel are relevant in your post. HINT: A clear picture of the error provides us with an idea of the context of the error as well as the exact error message.

You need to use the kernel and inits shipped with FOG 1.5.4 (almost) or you will have an unsuccessful deployment. FOG kernel 4.17.0 is shipped with FOG 1.5.4. There is something wrong with that kernel version, it takes minutes to create partition tables on target computers. This is not a FOG issue per se, but a linux kernel issue. But to the point roll your FOG kernel back to 4.15.2 via the FOG Settings -> FOG Kernel menu. Also note that the inits are tied to the kernel version, so you need to put the FOG 1.5.4 inits back in place or you will get an error message. Once you provide the info in your own thread, we can start to dive into your issue.

@quazz @george1421 well, disabling secure boot seemed to do it. Thank you sooo much for the help. I will continue on with the process and hopefully all goes well.

@Wayne-Workman No they are not

@nt_tech

I’ll reply to myself! 🙂

I dumped the database as a backup and used PHPMyAdmin to delete the first 1000 entries in the imaginglog table.
It all works now! There was obviously a bad record somewhere in there that was breaking the report.

As a side note, the imaging log issue was arrarently fixed. When I change the definition on a host is DOES NOT change the record of what was previously imaged…as it should be.

Glad I upgraded.

Brian

Found the problem, needed to disable TPM 2.0 security in the Bios prior to deployment.

Tom

@Tom-Elliott Tried running the script w/ psexec w/ all files in appropriate locations and it ran w/o an issue doing everything it was supposed to. Unfortunately FOG still doesn’t seem to want to copy those 2 files. GroupPolicy is a hidden folder, could that be causing an issue?

@tom-elliott said in Replicated image not showing up under "List All Images":

If your other node is a server in its own right, then this is to be expected. Images aren’t automatically populated in the database, each one requires a definition to be available. So replicating an image from one server to another is fine, but it doesn’t automatically populate the receiving server with the definition.

oh, ok thanks.

@george1421 This has resolved the issue. Many thanks for your help.

Forget it, sorry to waste anyone’s time. Redoing it has worked on all machines. I am guessing applying just the snapin via group wiped the key fields for each host.

Never mind. It was an OS issue. Solved.

@carlesgm You see that sda5 your linux system partition is resized/shrunk but the following swap partition (sda6) is not moved forward. We usually don’t move partitions as it can cause really bad issue (unbootable system).

Not sure what to advise in this situation. Could you remove the swap partition before capturing the image and then re-create it (and fix your entry in /etc/fstab) after deploy?

Hello guys, here again returning for feedback.

The multicast worked fine!! very good. Thanks for all devs and people who help us. Thanks!

Now, as said in the first topic, i´m very happy with this and thinking of doing my course completion work(TCC in portuguese) of University graduate about the use of FOGServer in computers lab.

@sebastian-roth shoot I should have tried that, no I kinda give up. And used fedora 26.

This error is very much like other when FOG admins change the linux user (service account) fog’s password. Understand this is not the webui default admin called fog this is the linux user called fog. That account should only be managed by the fog install script.

@vanlue-it-guy Leave that at 0 for disabled. It’s for those people who are using the 224.0.0.1 and want to use a different multicast address, (say for example 234.0.0.1)