@CamGreezy If the subnet is at the same site then as long as routing is working then you can image. It uses the same tools. There is an issue with WOL (wake on lan) if you have different subnets you need to allow directed broadcasts on your network. But from an imaging stanpoint as long if the fog server can reach it, it should work.

Now if your remote site is connected over a low speed link (like mpls) then you might want to think about installing a fog storage node at the remote location to help with the imaging process.

@nitelife There is still something going on here that is not clear. Are these 10 systems of the same manufacturer and model?

If you change the target computer’s bios to not pxe boot but to boot from the local hard drive do they get an IP address?

If the fog server and one of these 10 pxe booting clients are on the same subnet then I think we need to see a pcap of what the hey is going on with the dhcp process.

This tutorial will walk you through setting up the fog server to capture the dhcp process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Hi Tom

Apologies for the first post. I meant to edit the post and add more info in and got caught up researching what happened. I found the answer below and wanted to post it here for future reference or anyone else that might run into this issue.

I’m on FOG 1.4.4 and Ubuntu 16.04 LTS w/ latest updates.

On Chrome the Hosts tab would just provide and error that it could not load.

I found in the Apache logs at /var/log/apache2/error.log that php was using too much memory since I have so many hosts.

I then went to /etc/php/7.1/apache2/php.ini and edited the Resources to increase Memory Limit to 512M.

After increasing the memory limit I was able to load the hosts page fine.

@Tom-Elliott @george1421 Moving those folders and running the installer again has resolved the issues. Thank you again!

@george1421 It is a physical machine with 1 onboard NIC and (now) one TP-Link networkcard.
Works fine now.

Thanx for the help!

@Dark000 1.4.4 includes the aforementioned fixes already.

Please create a new thread detailing this problem.

@UCJared Excellent, I’m glad you have it worked out. ipxe.kpxe “should” work for all hardware nics, you may run into an odd-ball one where undionly.kpxe works better. The advantage of undionly.kpxe is that is smaller and quicker to load and usually a better chance of compatibility (except for those darn realtek chips).

I’m confused. FOG wouldn’t capture an inconsistent system in the first place. So how is this error appearing at deployment rather than capture?

Typically when you see “Object reference not set to an instance of an object” errors from the fog client, this most typically means tge encryption needs reset for that host.

the reset can be done from the web gui, on the host’s general page. It’s a big button towards the top.

If this fails to fix the issue, try reinstalling the client on that box. Make sure there are reboots between Uninstall and reinstall.

If several hosts have the issue, this points to an image problem - perhaps reboots were not done (two at least) prior to capture after all software has been installed.

@Tom-Elliott said in Windows 7 Activation issues:

So MAK has a limit, typically, of 25 or 50 keys to the server it’s activating against. Is the activation limit possibly met?

Depends on the site. My last job asked Microsoft to raise our limit from 10,000 to 20,000 activations. They gave it to us, no questions asked.

Nothing else seemed to work so redid the system and now it works

I know I’m gravedigging an old topic, but since this is all the Google could find for me on this topic I thought I’d post a solution for future reference.

For my setup (FOG 1.3.5), the following allowed me to get my Dell Latitude M4800 and E7470 laptops to exit iPXE and continue booting the hard disk properly without the dreaded flashing cursor:

FOG Configuration -> iPXE Boot Menu -> Exit to Hard Drive Type = GRUB_FIRST_HDD (default is SANBOOT, which was giving me trouble)

Hope this helps someone.

Jon

while i was digging in my log files looking for the error you suggested i found that one of my nodes was down. on a hunch that that was causing some issues. i went and turned it back on and things seem to be back to normal. replication seems to be back online. i must have had something trying to replicate to the offline node and was holding it up. but that you so much for the response!

now im just stuck with the red ! saying no such device or address for all my hosts. any ideas?tasks perform normally so it doesnt appear to be a big deal, but id like to fix it if possible.

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