@george1421 In fact i never had to purge the fog directory after removing the legacy client but i’ll try that too. I just remove it and install the new fog service… It works everytime except here. I’m not backing up this image for archive, the idea is to migrate from the 1.2 to the latest version of fog and, by the way, to recapture theses old images (with new fog client, update, etc…) and get better compression of images.

For this PC, the image in the old fog was corrupted. All i can do its taking it from a PC allready in the park. Or remake it…
When i redeploy an old image, update client, and register the host i have no problem.

Last thing, i’ve no idea how the image was created the first time i didn’t worked here at this time. But i see a recovery partition so i think it was an pre-installed windows 7 pro x86

I think you are fixing a problem the wrong way. The pxelinux.0 is an old boot kernel that should never be used now. If you do use it you WILL get the error you mentioned.

For FOG 1.3.x and beyond you should either use undionly.kpxe for legacy (bios) mode and ipxe.efi for uefi mode. For your setup you need to modify your dhcp server and change dhcp option 67 {boot-file} to undionly.kpxe. While what you did will work its a non-standard setup that may break on the next update to FOG.

I had exactly the same problem with some old pc/laptops (i.e. hp probook 4411s) but not on recent pc

fog 1.3.0rc8 on debian the dhcp server was handled by a juniper switch ex3300 junos 12.3R10.2 made some test with a pfsense vm v2.3.2 acting as a dhcp server

When I captured packets on the server, I noticed that the client was requesting a files that did not exist so I decided to mirror the port and capture the complete process as I was expecting something with the dhcp

the main difference seems to be that the juniper dhcp includes the filename in the option 67 (in addition of being also in the "boot file name¨ ) and pfsense doesn’t, and some legacy computer seems to not handle that properly and adds some caracters at the end of the filename which make the tftp request wrong which makes the tftp server to not understand what file is requested

here’s my notes from the captures

differences in dhcp offer (dhcp answer to the client) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ server hostname 10.0.5.90 "not given" dhcp option 67 undionly.kpxe "not set" differences in TFTP read request (client asks the file to the pxe-tftp server) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ source file undionly\377 undionly.kpxe in details undionly\357\277\275 undionly.kpxe hexa before "octetsize" ff00 00 differences in TFTP server answer (from pxe-tftp server to client) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ answer error code (5) file not found option acknowledgement

I hope the can be helpfull to you !

Said it couldn’t resolve the URL’s. We recently dropped our DC it was pointing to. So I edited the interfaces file to an updatde DNS IP. So basically, it was DNS, mixed with a DUH moment on my side. Thanks for pointing to the log file to shine my stupidity 🙂 (－‸ლ)

Thanks, will do!

@george1421 said in full host registration Error:

/fog/

Thank you very much. It’s working.

@x23piracy Mark as solved is only available for moderators and developers and such, to prevent people from solving too early and what not.

@Avaryan No.

But I might suggesting upping in 128 increments (128, 256, 384, 512, etc…)

@thebrennan47 said in Fog freezes on boot at kernel_thread_helper:

We want to avoid upsetting our production environment if at all possible

I can understand your concern about not wanting to destabilize your environment.

But realize that the Windows 10 train is heading towards your environment very soon, so you WILL have to upgrade sooner or later. Also the 7040 is the last of the sky lake models the next generation are on kaby lake. Microsoft has intentionally crippled windows 7 to not run on kaby lake hardware (even though it ran fine earlier this year). So moving forward you will have to install win10 if you purchase new hardware. That day is coming. I’m only telling you what is coming down the road so you can plan for it.

As for ubuntu 12.04 that reached end of support in April of this year. So you will not receive any security updates for it if any are detected. That is also a pressure for you to upgrade.

The kernels that Tom posted about may work on the newer hardware, surely FOG 1.4.2’s kernels will run on that hardware. It might not integrate with FOG 0.3x very well, but it should run on the 7040 ok (I’m doing that today).

@FlareImp It looks like the TVNE-Fog server didn’t have the whole image. The pic on the left is larger (at least the d1p2.img is) than the one on the right.

@george1421 said in Remote node on different DHCP and subnet:

Not being able to alter the remote dhcp server is a problem but you can fix if you install dnsmasq on your storage node. Dnsmasq will then supply the pxe boot options you need.

It wouldn’t be a problem if the DHCP server didn’t have any 066/067 options. In this case it does. I think it’ll be hit or miss for proxy-dhcp working in this case. And if it works, it might intermittently work.

@UWPVIOLATOR said in Snapin Hash Issue:

But if we use any snapin from out master FOG the hash fails. In the temp folder it downloads 1KB

If the file on the server is whole, but not being downloaded to clients - this has to be some sort of network or security problem. It could be a content filter, a firewall, antivirus, anti-malware. You know your environment better than us - spend time thinking about what could possibly block the download.

@george1421 I have left work for the day, but will do so tomorrow morning. Thank you.

I forgot to mark my changes permanent across reboots. It’s chugging right along now. Thanks!

With FOG 1.3.x and newer there is a change in the process that is required for sysprep. You can install the fog client into your golden image before sysprep. But you must set the service to disabled. And then add to your golden image a setupcomplete.cmd batch file that enables the service. What happens is that the fog client doesn’t know that OOBE is still running so it starts doing its job too early in the imaging process causing OOBE to fail because the fog client reboots the system at an unexpected step in OOBE.

ref: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Also you should consider upgrading to FOG 1.4.2 if you are still running on FOG 1.3.X

@sanman Well done. Thanks for letting us know. Might be helpful for other users as well. Marking this solved.

Yeah, the 1.3 RCs had lots and lots of bugs. Please update to the latest stable release.

@george1421 said in Replication Timing?:

First the generic recommendation. Please update FOG you are several versions behind and on an RC release that has a known bug with image resizing.

More than a generic one, this is a very strongly recommended and needed. We could end up wasting days on an issue in an RC that’s already fixed in the next stable release. Imagine asking Microsoft to help you fix something on a Windows 7 Beta copy.

@Wayne-Workman

Thanks!!

@ECRTechZ said in Copy images from dead 1.2.0 server to new 1.4.0 server:

The problem with those articles is that they assume the old server is accessible.

The guide only requires that ssh is accessible. The web interface can be nonfunctional. If you don’t have ssh, then yeah the only thing to do is mount the disk on another box as you’ve done and just copy the needed things from it.