Posts made by jfath

Thanks Tom.

Not a huge problem for me as I can just change the host names manually on a dozen or so machines. I’ll be happy to test any changes you make.

Jerry

It occurs to me that I’m logging in to the machines running client using a user account that does not have admin rights. Any chance that is keeping the hostname check/set from happening correctly? I’m not on site right now, so I can’t do the simple test of logging in as an admin.

Jerry

http://10.0.0.4/fog/service/ipxe/boot.php?mac0=A8:A7:95:93:72:87 -> Host is NOT registered

http://10.0.0.4/fog/service/ipxe/boot.php?mac0=A8:A7:95:93:72:87&mac1=AA:A7:95:93:72:87&mac2=DC:FE:07:06:58:38 -> Host is registered as EBGC-001

http://10.0.0.4/fog/service/ipxe/boot.php?mac0=00:00:00:00:00:00:00:E0 -> Host is NOT registered

The hostname listed for DC:FE… does match what I set when I registered the host and what I see in the FOG host list, but locally that machine still displays the original hostname from the captured image.

Thanks again.

Jerry

Only the DC:FE… address is an actual host. It was the source machine for the log file and does appear in my list of hosts. I also checked the MAC address of the FOG server and it does not match the other addresses from the log.

The local host names do not match the FOG interface. All of the machines show the same Windows generated host name from the machine that was used to capture the image. In the FOG interface I have registered the hosts as ebgc-001, ebgc-002, …

Thanks for the reply. Anything else I might check?

Jerry

I’m running server 6751 on Lubuntu 14.04 32 bit and client 0.9.11 on Windows 10 x64 machines in a simple workgroup.

After image deployment all hosts retained the name of the host stored in the image, not the host name shown in FOG server. The client log shows:

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 3/20/2016 9:49 AM Client-Info Version: 0.9.11
 3/20/2016 9:49 AM HostnameChanger Running...
 3/20/2016 9:49 AM Middleware::Communication URL: http://fog-server/fog/service/servicemodule-active.php?moduleid=hostnamechanger&mac=A8:A7:95:93:72:87|AA:A7:95:93:72:87|DC:FE:07:06:58:38||00:00:00:00:00:00:00:E0&newService=1
 3/20/2016 9:49 AM Middleware::Communication Response: Success
 3/20/2016 9:49 AM Middleware::Communication URL: http://fog-server/fog/service/hostname.php?moduleid=hostnamechanger&mac=A8:A7:95:93:72:87|AA:A7:95:93:72:87|DC:FE:07:06:58:38||00:00:00:00:00:00:00:E0&newService=1
 3/20/2016 9:49 AM Middleware::Communication Response: Success
 3/20/2016 9:49 AM HostnameChanger Checking Hostname
 3/20/2016 9:49 AM HostnameChanger Hostname is correct
------------------------------------------------------------------------------

I’m new to FOG, so I suspect operator error, but I’ve not been able to figure out what I’m missing.

Any help is appreciated.

Jerry

Unicast deploy completed succesfully when I isolated the hosts on a known good switch, so likely network problems.

Thanks again for the help.

Thanks for the reply.

It’s a consumer, unmanaged switch. That was kind of my guess too. Current deploy is at 80% and still running.

Jerry

I’m running 6751 on Lubuntu 14.04 32 bit. I imaged a Windows 10 machine with 4 partitions, then deployed that image back to two machines - first using unicast, then using multicast. All went well, so I attempted to deploy at my target location, a small non-profit with 10 workstations, using the same server and image.

First, I tried multicast and the process hung within a couple of minutes. All machines stuck on a slightly different block with ‘time remaining’ counting up. I had read of problems with various switches, etc using multicast, so I set up a group deploy task using unicast and left the workstations to image over night. On my return 12 hours later the workstations were once again all stuck on a slightly different block with ‘time remaining’ counting up.

I didn’t know whether it might be possible to recover from the problem and continue from that point in the deploy. Not knowing any better, I rebooted the fog server and restarted one of the hosts. It appeared to start at the biginning of the large partition where the hang happened previously. When I rebooted a second host, however, it gave a repeating error of ‘no slots left’.

I have removed half of the machines from the network, put them on the small switch I used for my successful home tests, and started a new unicast deploy on those machines. They are currently running the deploy task.

So, my questions are:

Any guesses on what might have caused my hangs? I was surprised that all hosts hung during a unicast deploy.
Any tips on where to look for further debugging information?
In the case of a hang such as this, might I be able to restart one or more services in hopes of getting the deploy to continue?

Any help is appreciated.

Jerry