@Dee Updating to the latest version is a good idea in general but as you seem to not have much experience with FOG and possibly Linux yet I am wondering if we better try to fix your issue before diving into a full upgrade.

I’m hoping that updating it will fix the issue of it not capturing images.

Please explain in more detail what’s happening. Error messages? Please take pictures and post here.

@mckayj @Quazz Great this has turned out to fix the issues on those CPUs. Thanks heaps!!

Will add x2apic to the official FOG kernel build. Let’s hope this is not going to cause any trouble for other devices. 😉

Edit: Added the option, will be in the official binaries soon: https://github.com/FOGProject/fos/commit/34967bf3f42fe56d835e1e179cdea78213ab3b6b

@MarkG said in Image files and Snapin files not deleted:

Bug in 1.5.0?

Possibly. 1.5.0 is long away and I don’t have all the changes in the back of my mind… 😉

So updating to the latest will fix the issue, that’s good!

@Jim-Holcomb Yes, you’re on working-1.6 and I’ll be helping with that here shortly.

@Sebastian-Roth I wish this was the case, but unfortunately, it isn’t. I just booted up a machine to give it a try, because I’m willing to try anything and it did not work. I typed my password in the username box to see how it was coming out and it was correct. I was wondering if there was some permission we need to set up for a user to be able to use this. I even tried using the defaulted fog user that is listed and that password, but again it didn’t work.

However, I just tried using the account we set up in Linux and it worked, although I was sure I tried it last week and it didn’t work, but maybe our system admin rebooted the server while I was out to make the changes take effect. It is now working.

Thank you for your response. I am enjoying FOG so far, it is much faster than the KACE 2000 client we were using before. In today’s IT world speed is necessary.

@BenR Don’t know from the top of my head right now as I have not coded the fog client. Could be registry setting. Probably easiest way is to purge and re-install the FOG client on that machine. Sorry but that’s the quick solution.

i have finally figured out how to get vm workstation working with no problems. My computer is plugged into real network at the time. I have to plug into the isolated network. When it pulls an IP address I then go and disable the adapter and enable it again. it then gets the ip address again. I then run ipconfig /flushdns.

After i do that and only then will i start VM workstation. i will go to the vm and go back to my snapshot. before i open it i always make sure the settings are showing bridged. I then power on the vm to the saved stated and run a ipconfig to make sure the computer and vm have actual same IPs in the subnet. Then run a flushdns on the vm. Then i sysprep and then boot to firmware on the vm. Then i pick network boot.

This has worked 7 times with no issues. I am sure i could cut out some steps but it is real easy for me to do all of it real quick. I only check to make sure it is bridged mode once.

Once i started to do this vm workstation work everytime and even on VM reboots.

I hope this helps someone else out.

Oh and i disable wireless first if you are using that.

@leonj said:

The repos that we have internally …

This would have been a very valuable information right from the start. 🙂

Good to hear you got it solved.

Oh yes, I forgot about it. You recommended it to me the last time too. This time I’m going to save it on my deployment server desktop, to have it there for debugging.

I remembered something about FOGMulticastManager. Here is were I red about it.
Thanks again.

I’ll be back with feedback after my next deploy.

@jahilton2002 said in Issues importing /images since new fog server build:

But it hasn’t worked, same error

Which error do you mean? I can’t believe you are seeing the same “Attempting tp expand/fill partitions…awk:…” error.

After talking to my tech team here, we’ve decided to “take the hit”.

Probably a good idea!

That works, thanks!

I’ve found the issue and the resolution:
https://bugzilla.redhat.com/show_bug.cgi?id=1582672
support for TCP wrappers isn’t compiled in vsftp binaries found in SLES and Redhat.

The installer must be modified to not output tcp_wrappers into the vsftpd.conf
This has resolved this issue in SLES.
I’m guessing ntcp_wrappers=$tcpwrappers\n$seccompsand is configured to output disabled if certain versions redhat? but that didn’t trigger for SLES

Thanks very much for your help @Sebastian-Roth

@Quazz Thanks again for your work on this! I’ll add this soon but have one more question about it, see on github.

What are your thoughts on https://forums.fogproject.org/topic/12428/win7x64-golden-image-partitions-problems-again/29 as an alternative system, by the way?

Good you reminded me on this! I moved the issue from repo fogproject to fos#18 where it belongs now that we have those things separated a while ago. Please let’s try to collect information and ideas there.

@Jonathan-Cool Nice you got it working! We’ll add Quazz pull request anyway for the time being. Should be in there in the next couple of days. I’ll mark this solved now.

@george1421 ok, that makes everything alot clearer, thank you for your help!

You could also disable the nodes you want to delay replication for via Storage Management.

@pdehombreux Sorry for leaving you alone for such a long time on your very first post. It’s been a very busy time and I just couldn’t get my head around your post when I first read it and so kept on putting off to look into this.

I think we need to get into the logs to see what’s actually happening when you try to update the AD information. First check the apache error and php-fpm logs right after (or while) you update the client’s AD information. See my signature on where to find those.

If that does not shed a light (I suppose it won’t) then I may ask you to enable mysql query logs. For that it’s probably best to turn off as many components as possible first. Shut down clients that have the FOG client installed and make sure you are the only person on the FOG web UI for that moment. Just trying to keep the logs to a minimum.

See here on how to enable mysql query logging: https://www.pontikis.net/blog/how-and-when-to-enable-mysql-logs

Before you enable it, get the web interface ready. Navigate to the right host, select AD settings and change OU and username for example. Then turn on logging, restart mysql, update the client settings and switch off mysql logging again. Upload the full log here (make sure it does not contain any sensitive data …)

@p4cm4n said in install fails - adding repository... failed:

when it gets to adding distro it fails.

I guess you meant “adding repository” here, right?

For Mint and Ubuntu we add ondrej repos (commands add-apt-repository ppa:ondrej/php and add-apt-repository ppa:ondrej/apache2).

Debian is different, here we only add a repo for Debian 7 which shouldn’t be used anymore anyway.

In the same directory where you have the FOG installer script there is a subdirectory called “error_logs”. There you find log files with specific error messages. Please take a look and post here if you can’t figure it out on your own.

The way both iPXE and FOS work is it will stop searching when it finds an ‘up’ interface. So if you want it to pxe boot place the pxe boot network in the first interface position and then use the second or what ever else for the network where you have no control.

@vincityhn1 said:

When we try send a image stored in node A, the Fog Server search this image in both nodes A and B.

What exactly do you mean by “try send a image”? Send where? Pushing the image to the client? And what do you mean by “Fog Server search this image…”? Can you be more specific on this. Maybe take a picture of what you see on screen and post here.