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

@fogofwar said in "Operation not supported" tftpboot failing - please help:

Only one problem now that we got past that I am getting this error about “No configuration method succeeded” but only on a VM. I will have to look at that next.

This is only on reboot I am fairly sure! Shut down the VM completely, bring it up again and PXE boot will work nicely. This is a known bug in virtualbox.

@jherron The information is split in two different tables. Host information and MAC information. So you need to commands to clean that host’s information from the database:

mysql> DELETE FROM hostMAC WHERE hmHostID = 1272; ... mysql> DELETE FROM hosts WHERE hostID = 1272; ...

But I still wonder why we only see one entry while FOG seems to find duplicates. Would you be keen enough to add some more error output to the PHP code so we see which MAC it sees as duplicated? If yes, I should be able to help you with the code. Let me know.

@kwilson7392 said in FOG Capture Task keeps rebooting:

This is my first capture task…

So my guess is you might still be thinking in different concepts. Ghost for example did some modification to the boot loader on disk and joined into the task when rebooted from disk. But FOG is different. It’s based on PXE booting the client. If a job is scheduled then the PXE loader will bring up the FOS system to do that task on your machine and if there is no task it will chainload from disk to boot the OS.

Have you setup your machine to PXE boot?

I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”

I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.