@msaglioc99 To test, open a linux command prompt on your FOG server. Key in ping <host_name> to test.

The dns server settings are in /etc/resolv.conf file. If you are using the Network Manager application to manage network profiles then you would edit it there.

But in my case this is what my resolv.conf file might look like.

domain mydomain.com search mydomain.com subdomain.mydomain.com otherdomain.com nameserver 192.168.100.6 nameserver 192.168.100.8

@Avaryan said in Powershell Snapin:

unpin the apps for all users or just the

Currently logged in user. If there’s a way to set it up for all users that’s what I would prefer.

It sounds like someone has mucked about with the linux user account called fog. We have seen some people use the linux fog account for system maintenance and other activities. This is an internal account and should be used by the FOG system only.

It sounds like you have started checking the spots for this user account. I would look in this order.

Review the /opt/fog/.fogsettings file for the password. Ensure you can log into the FOG server from a windows ftp program using uid= fog and passwd= <password listed in .fogsettings>. If that works move on to step 3 In the web gui, look at the storage node configuration for the master server. At the bottom there should be a user ID and password. Make sure that password is the same that is found in the .fogsettings file. Look at FOG Configuration->FOG Settings, in the tftp section there is also a user ID and password that needs to be consistent with the .fogsettings file.

If all of the test pass then post back here (either way) and we can dig a bit deeper into the error message, but I believe either the linux user fog’s password has been changed or one of the checks above will point to the problem.

I might also suggest (once you get the password issue worked out), that you upgrade to fog 1.4.4, because 1.4.0 had several issues with the single disk resizeable option, that was addressed in 1.4.1 and again in 1.4.4. It is in your best interest to upgrade once the password issue has been fixed.

@Tom-Elliott said in Recapture Image:

During capture, the original image will remain u

Thank You!

ok. i finally figured it out 😄

Problem is whit my Mainboard.

Cloud test my fog with other computers and they worked just fine.

I’ve tested and it still doesn’t copy the drivers when they are there?

Thanks @Tom-Elliott, I have successfully captured and deployed Debian 9 clients both in virtual space and to real hardware. So, it looks like your fix works. I did notice some slower booting as you mentioned but that seemed to be minimized after I went through a full capture-deploy-capture sequence. Perhaps there was residual file system ambiguities that was affecting the boot times. In any event, the boot times smoothed out over time. The only slightly odd thing I did notice is sometimes the client would boot twice before the capture would actually start. I cannot reproduce this all the time. Just thought I would mention it if it makes you think of anything.

Thanks again; will this fix make it into 1.4.5?

Two other things to check are the bios versions identical, and is secure boot on or off.

@BedCruncher Maybe DNS handling in FOS is better than how it’s being handled when the OS is opened?

@Tom-Elliott
That did the trick, thanks!

@misaina said in Problem bootPXE Fog : Please enter tftp server:

Please enter tftp server

This usually means you don’t have your dhcp server setup correctly. What precisely do you have setup for dhcp option 66 {next-server} and dhcp option 67 {boot-file} ?

At this prompt “Please enter tftp server” if you key in the IP address of your FOG server you should see the FOG iPXE menu. This is not a solution just a test to prove you have something setup not right with dhcp.

@george1421
Hi George,
Thanks for your reply.
I had no infos in the apache logs, so i think you right there was a redirection.
So, i just uninstalled manually fog (mv /var/www/fog to fog.bak & /opt/fog to opt.bak), uninstall mysql with apt-get purge mysql-* and reinstall completly fog from the git dir.
Now it works.
Arnaud

@tyler2017 Thanks for responding as I don’t know what mac is what, I just took a guess and it was wrong. Thanks for trying the other and glad it helped.

@Quazz The standard stuff. The page could not be reached. I also was wondering if I need to uninstall and reinstall FOG anyways, because we have DHCP servers setup on our network, and I skipped all of that through the initial config. Do you think this is maybe why I’m having issues now? I tried to setup the startup script in the CentOS 7 manual, but it seemed not to work. Thanks for any input.

@Quazz said in Deployement failed on smaller drive (message "Target partition size smaller"):

I’ve made it a habit to just start over every time.

We also find the same thing and create new every time.
FWIW: We use MDT to build the reference image, that way we have a consistent way to “start over every time”.

@Tom-Elliott

Thanks alot for pointing out on the nic cannot get an ip. we have did some digging on fog wiki and found out it is network switch issue.

Thanks alot again.

So I was able to do a “Full disk Repair” and then use command line to shut down the system which seemed to fix the error I was having and am now doing a successful capture! Thank You!

@mtanigawa lol, what would you suggest to make it infiltrate better? I can change the article if you can come up with something better.

@george1421 I have removed the the global parameters and still exhibiting the same behavior. It is weird that this happened right after I made that change. I think something might have gotten corrupted, but I am not sure what to do at this point.

@SquidgyHobo RHEL 5.3 isn’t supported by FOG.

RHEL 5.3 also it went EOL from Redhat Jan 2011. I would not even use that in my environment since it is susceptible to a handful of nasty and well publicized vulnerabilities.

RHEL / Centos 6.5+ and 7.x are currently supported, as well as the Debian variants.