Yes I tried it with a new Icubes desktop and that worked ok. So far only this Lenovo laptop has caused the problem. As it’s a laptop, I’ve been using the wired connection rather than wi-fi. The laptop used the same network connection as the Icubes machine. It’ll be a while before I can try any more tests as I had to rebuild the Fog server due to a problem I possibly caused when replacing the drive that hold the images.

Once it’s up and running again, I might try it out on a private network to see what happens.

Many thanks,

Paul.

Dear All,

I’ve tried making an image of a Lenovo B590 laptop. When it is booted from the network (this has to be selected from a menu via F12 as the boot order can’t be set to try the NIC first), it successfully gets an address from DHCP but then TFTP fails after a long delay. The screen reads:

PXE-E32: TFTP open timeout
TFTP…

There is quite a delay before TFTP gives up so I don’t know if adjusting the timeout (if possible) will work. Is there anything I need to change? The NIC is a realtek of sorts.

As it doesn’t go further than this, I can’t auto-register the laptop. I’ve tried creating the client manually using the MAC address hoping to be able to wake it up remotely but this doesn’t work either. I reckon I’ve set the BIOS up accordingly.

Many thanks,

Paul.

Jaymes/Lethal Kebab,

Being new to this system but based on your responses, am i right in saying that this uses a broadcast system, i.e. all nodes on the network receive the data rather than just the target PCs? I guess that would account for such a slow down. Currently our network infrastructure is about to be revamped. We have some managed switches coming into being as part of this with the idea that we can improve access to key servers etc.

As an experiment, I plugged the two test target PCs and the fog server into a small switch. We’re using our existing DHCP server rather than running this on the fog server so I started the multicast task then re-booted the PCs. Once they’d been issued with an address, I unplugged the switch from the school’s network and the multicast ran much faster. It was still slower than a unicast but certainly acceptable and miles faster than the rate I was getting beforehand. To that end quite possibly it could be a rogue device on the network causing the problems as you suggest.

One thing I noticed was the bandwidth usage seen on the fog server’s home page. With the multicast when connected on the school’s network, this hit the ceiling constantly rather than going up and down. When I looked more closely, I noticed that this ceiling was only 1MB/minute (?) where as during the unicast or multicast on what was effectively a private network, the ceiling was much higher.

Thanks,

Paul.

Kevin,

I forgot to mention the client was installed on the machine I took the image from so should be available when the target machine restarts.

Thanks,

Paul.

Kevin,

Thanks for the info.

Yes the hostname changer is enabled and also is in the main Fog settings (I saw the bit saying one would override the other). Presumably the target PC should take on the hostname used when it was registered? Where is the ini file by the way?

Ta,

Paul.

Having recently tried out 0.32 to the extent of taking an image of one PC and deploying it to another identical machine, I then tried multicasting the image to those same two machines.

Once started, the multicast process crawled along and estimated 5 to 6 hours for completion where as 15 minutes was about the time it took when I test deployed it to the single PC.

I had suspected our network as one machine was in the room next door. The Fog server and first PC were on net the same switch as each other but the second machine (next door) was connected via two switches. The subnet was the same for both locations.

I stopped the process and deployed the image via unicast to the first PC. This ran quickly, so I stopped the task and did the same for the second machine which (still connected via the extra two switches). This too ran quickly which I didn’t expect.

Any idea what I am doing wrong?

Many thanks,

Paul.

I recently installed Fog 0.32 and have made it upload an image and deploy it to another (identical) machine. What I can’t find out is how to set Fog to change the hostname of the target PC. The target PC has been registered on the Fog database ok but the hostanem always ends up as the same as the PC the image was taken from. Does host re-naming only work with Multicasting?

Many thanks,

Paul.

I’ll have to experiment a bit more. I’ve had the machine start up several times remotely or started up + memtest but it won’t automatically start as part of an imaging task.

Rocco,

Just had this problem myself and found the answer when searching for something else.

There is nothing to see when creating the file, i.e. no feedback is given. It’s also a hidden file anyway and I couldn’t see how to display hidden files using ls in a terminal window so I went back to the gui. Once I’d set it to view hidden files as well, .mntcheck was visible. I tried creating another image and this time it mounted /images/dev without problems and the image was created quite quickly.

Ta,

Paul.

Ok, so I found the answer to this while searching for something else so I thought I’d post it just in case. Somehow /images/dev didn’t have a .mntcheck file. Having sorted that out, I made images without any problems although there’s still the issue with starting the PC remotely and the task status still shows up as queued even when it has finished. That’s not exactly a problem though…

Ta,

Paul.