Here is the end of the log file for a newly imaged machine this morning which is still working on downloading a snapin. The 10.24.25.165 IP is our main Fog server. The building where the machine resides local nose is at 10.40.25.165. The image itself deployed correctly from the local node.

----------------------------------------- ------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 6/20/2017 10:29 AM Client-Info Version: 0.11.11 6/20/2017 10:29 AM Client-Info OS: Windows 6/20/2017 10:29 AM Middleware::Authentication Waiting for authentication timeout to pass 6/20/2017 10:29 AM Middleware::Communication Download: http://10.24.25.165/fog/management/other/ssl/srvpublic.crt 6/20/2017 10:29 AM Data::RSA FOG Server CA cert found 6/20/2017 10:29 AM Middleware::Authentication Cert OK 6/20/2017 10:29 AM Middleware::Communication POST URL: http://10.24.25.165/fog/management/index.php?sub=requestClientInfo&authorize&newService 6/20/2017 10:29 AM Middleware::Response Success 6/20/2017 10:29 AM Middleware::Authentication Authenticated 6/20/2017 10:29 AM Bus Registering ParseBus in channel Power 6/20/2017 10:29 AM Middleware::Communication URL: http://10.24.25.165/fog/management/index.php?sub=requestClientInfo&configure&newService&json 6/20/2017 10:29 AM Middleware::Response Success 6/20/2017 10:29 AM Middleware::Communication Download: http://10.24.25.165/fog/management/other/SMALL.png 6/20/2017 10:29 AM Middleware::Communication URL: http://10.24.25.165/fog/management/index.php?sub=requestClientInfo&mac=98:90:96:BF:CB:76||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json 6/20/2017 10:29 AM Middleware::Response Success 6/20/2017 10:29 AM Middleware::Communication URL: http://10.24.25.165/fog/service/getversion.php?clientver&newService&json 6/20/2017 10:29 AM Middleware::Communication URL: http://10.24.25.165/fog/service/getversion.php?newService&json 6/20/2017 10:29 AM Service Creating user agent cache 6/20/2017 10:29 AM Middleware::Response Invalid time 6/20/2017 10:29 AM Middleware::Response No Printers 6/20/2017 10:29 AM Middleware::Response Module is disabled globally on the FOG server 6/20/2017 10:29 AM Service Initializing modules ------------------------------------------------------------------------------ ---------------------------------ClientUpdater-------------------------------- ------------------------------------------------------------------------------ 6/20/2017 10:29 AM Client-Info Client Version: 0.11.11 6/20/2017 10:29 AM Client-Info Client OS: Windows 6/20/2017 10:29 AM Client-Info Server Version: 1.3.5 6/20/2017 10:29 AM Middleware::Response Success ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ ----------------------------------TaskReboot---------------------------------- ------------------------------------------------------------------------------ 6/20/2017 10:29 AM Client-Info Client Version: 0.11.11 6/20/2017 10:29 AM Client-Info Client OS: Windows 6/20/2017 10:29 AM Client-Info Server Version: 1.3.5 6/20/2017 10:29 AM Middleware::Response Success ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 6/20/2017 10:29 AM Client-Info Client Version: 0.11.11 6/20/2017 10:29 AM Client-Info Client OS: Windows 6/20/2017 10:29 AM Client-Info Server Version: 1.3.5 6/20/2017 10:29 AM Middleware::Response Success 6/20/2017 10:29 AM HostnameChanger Checking Hostname 6/20/2017 10:29 AM HostnameChanger Hostname is correct 6/20/2017 10:29 AM HostnameChanger Attempting to join domain 6/20/2017 10:29 AM HostnameChanger Host is already joined to target domain ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ ---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 6/20/2017 10:29 AM Client-Info Client Version: 0.11.11 6/20/2017 10:29 AM Client-Info Client OS: Windows 6/20/2017 10:29 AM Client-Info Server Version: 1.3.5 6/20/2017 10:29 AM Middleware::Response Success 6/20/2017 10:29 AM SnapinClient Snapin Found: 6/20/2017 10:29 AM SnapinClient ID: 86642 6/20/2017 10:29 AM SnapinClient Name: MS Office 2013 6/20/2017 10:29 AM SnapinClient Created: 2017-06-20 09:34:39 6/20/2017 10:29 AM SnapinClient Action: 6/20/2017 10:29 AM SnapinClient Pack: False 6/20/2017 10:29 AM SnapinClient Hide: False 6/20/2017 10:29 AM SnapinClient Server: 6/20/2017 10:29 AM SnapinClient TimeOut: 0 6/20/2017 10:29 AM SnapinClient RunWith: cmd.exe 6/20/2017 10:29 AM SnapinClient RunWithArgs: /c 6/20/2017 10:29 AM SnapinClient Args: 6/20/2017 10:29 AM SnapinClient File: Office2013-32.exe 6/20/2017 10:29 AM Middleware::Communication Download: http://10.24.25.165/fog/service/snapins.file.php?mac=98:90:96:BF:CB:76||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&taskid=86642

@Tom-Elliott
Hi,
It’s ok but just a detail in fog.log we no longer see the list of shutdown/reboot which are programmed.
Have a good day.

@Avaryan Thanks Avaryan. There was nothing in the target computer. Not sure what happened.

Thank you !

Just test and the host are now created

PS : How can I make solved ?

Checking the CentOS repo just now I saw a new package being available since 13th of June - search for rpcbind here. Anyone keen to test? @neodawg

@JJ-Fullmer Don’t worry about this duplicate post. It was just a lucky guess of mine that this could be connected. As well it’s good that you brought up this issue again as I would have forgotten about it. Checking the CentOS repo now I see a new package being available since 13th of June - search for rpcbind here.

@jaoyer said in Image Capture FTP Failure - Could Not Create File:

Yes. Taking the “/” out of the name fixed my issue.

I think we should reconsider, maybe we should filter out the /'s in the image name, but allow them in the image path. If they were in the image name I can see bad things happening. (I haven’t confirmed if they are allowed in the image name or not, I’m only suggesting based on this discussion)

@cjesso said in Unable to register machines to FOG:

I used an older “dumb” switch and i was able to successfully register a host.

If an older / unmanaged switch solved your issue, then have your network engineers look at your switch configuration. Make sure one of the fast spanning tree protocols are enabled (RSTP, Fast-STP, or what ever your switch mfg calls it). This will allow your switch port to start forwarding data right away instead of waiting for the obligatory 27 second timeout of start spanning tree protocol.

@rwakc well, it would be technically possible to set up a method where you could be automatically imaging any device pxe booted from the network, and set up multiple dhcp scopes on different network ports, serving out different pxe boot files with embedded scripts. that way, you’d be able to choose what image the system gets imaged with by choosing what network you plug the device into.

That is correct. I have tried both Chrome and IE. Same result with each.

I’m confused how init.gz was even a thing? Were you building custom init’s (or reworking the original init’s) and re-zipped as .gz?

In case anyone is running into this same iPXE error again. Please read this thread. Old initrd files (init.gz from October 2014 instead of current init.xz) were in place and caused the problem.

Not sure if this was the case here to but I doubt that ubuntu server was the problem!!

@chris.dees If it works for you, then it was the right fix. Run with it.

@Quazz I am using the Ubuntu VM as my FOG server. I don’t want to use the whole server with ESXi for storage also, just for the server portion. That is why the old Xserve is getting Ubuntu installed and set up as the NAS. I can then use it as a storage node as well as storage for files for things like computer backup and storage for files from our art department. Since the Xserve is just going to be a NAS the IPXE thing shouldn’t matter.

@george1421
The image transfer is complete!

I had to touch the .mntcheck file to the /images and /images/dev directory. But other than that, I’m up and rolling again! Woo Whooo!

I can’t wait to start fresh with Debian and clean up my server a bit. That’ll be next month’s project!!

Thanks everyone who’s contributed!! I appreciate all the advice! 😄

Cheers,

Joe Gill
Townsend K-12 Schools

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