We have ended up rebuilding our image and it is now working OK. It mustn’t have liked something in our old image.

Thanks for your help and suggestions!

@george1421 Ok, sorry about not getting back to this sooner, but work has been a bit busy. So anyway, I made the changes to the config file. (basically I created the ltsp.conf because it did not exist in the dnsmasq.d directory) there was only a README file. I was able to do a TCP dump and cap the information. But I have a feeling it will not be much help,

0_1532033995049_pcap.fog.JPG

I did see that I am running 2.75 version of dnsmasq, but I can reload the VM to just before I installed DNSMASQ and make sure the 2.76 version is installed. *will update if there are any changes from that versioning.

Thanks for the help!

Can you confirm

The FOG webgui is reachable On the switch where the target computer is: Ensure that spanning tree is configured for fast-STP or RSTP or place an unmanged switch between the target computer and the building switch.

@tom-elliott
It turns out that the crappy HP procurve 1900 switch that my xenserver was connected to has a feature called “auto DOS” that was blocking the NFS packets. I installed a couple of physical Linux systems to test with and found that I could mount the NFS shares when I was plugged into a different switch.

All works as it should after turning off “auto Dos” under security settings on the switch. The crazy thing is that I had a working fog server for years on this same switch/xenserver. Time to upgrade that switch. Anyway, thanks for all your help. Much appreciated!

@tom-elliott Wow, you’re awesome! We’re actually getting a new network because of E-Rate within the next month. I am logging your explanation/suggestions and will run this by the guys installing the switches. Thanks.

@wayne-workman Thanks. I changed it to 15 minutes. I’ll see how that does.

@Mike-Fahey As George said, the ACPI messages should be ok to ignore for now. About the CPU stall, find some posts from other users in the forums:
https://forums.fogproject.org/topic/8918/fog-boot-to-fos-rcu_sched-self-detected-stall-on-cpu

Not sure if this is the same issue. Please read through the whole post start to end and see if it helps.

@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.