@Tom-Elliott said:

now there is a bug plaguing fog and I’m failing to fix it at every angle. Help, a little help here now?

SVN revision 4168 is solid lol.

However, the latest is fine in my environment with 500ish hosts using the legacy client. So I say solid because I feel like it’s pretty solid.

Tom, I’m trying to boost your confidence man! 😉

@Pascal-Gazaille http://askubuntu.com/questions/493460/how-to-install-add-apt-repository-using-the-terminal

I created this script from various install files:

https://github.com/AdmissionRegret/utils/blob/master/fog-resetpermissions.sh

wget https://raw.githubusercontent.com/AdmissionRegret/utils/master/fog-resetpermissions.sh chmod +x fog-resetpermissions.sh

Thanks guys!

all ok now!

@Uncle-Frank yup

Marking this solved. Feel free to ask again here if you still have issues.

@AeonLucid Awesome debugging information!!! Lots of thumbs up for you. I am a bit late now but I did see the post just now. Funny that but I had the exact same thing happening with my home router when trying to debug some other iPXE stuff at home. It seams like there are DSL routers out there which send ‘next-server’ in their DHCP OFFER/ACK without handing a filename to the client. I am not sure why they do (and I guess most don’t). So your client asks for PXE boot. Gets next-server from the router DHCP and your proxy. It seams to be fine in the first run where Intel PXE ROM boots up but as iPXE comes up it uses the next-server send by your router instead of the proxy one. Run wireshark on your FOG server and you should see it in the DHCP packets broadcasted by your router (original firmware).

Instead of flashing the router you could have also build your own iPXE binary with a customized script - I talked to Tom and we might add that at some point anyway, now that we know more people see this.

Let me know if you want to know more about custom iPXE…

So, after uninstalling the Legacy Client, and not rebooting but just immediately re-trying the new client, it works, it installed without error.

Working on this in a new thread: https://forums.fogproject.org/topic/6020/fog-svn-5020-and-above-cpu-hammered-thread

Thank you Uncle Frank that was the answer. instead of being /fog/ there was nothing there.

Solved.
Reason: windows 2012 dhcp failover error. (Two dhcp server with load balancing. Synhronization was’nt perfect, fog settings exist just one of them.) Sorry my english.

Bumping this, just so everyone now knows it’s a source forge project. 🙂

@george1421 I send the host name with the load out labeled as hostname and the primary Mac of the host as mac.

All versions of fog currently put only one storage node’s config into /etc/exports, normally, this is just /images

so the first thing is to check the exports file: /etc/exports. If an entry for your eternal drive isn’t there, just copy/paste the two existing lines and change the paths to point to the external drive.

Note that inside the external drive’s “images” directory, you need a “dev” directory.

/images/dev

also, in both /images and in /images/dev, you need a hidden file, named .mntcheck

you can create this file using the touch command, like this: touch .mntcheck

For future readers, the select statement that @ch3i posted can be converted into a delete statement like so:

DELETE hostName FROM hosts WHERE hostID NOT IN ( SELECT hmHostID FROM hostMAC );

Ok that tells me you only have /Data exported from your FOG server, I understand why the client can’t connect to the /images folder.

For full disclosure this is what I get when I run the following commands.

showmount -e localhost

Export list for localhost: /images/dev * /images *

cat /etc/exports

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

I’m going to recommend that you add the above two lines to your /etc/exports file.

Then run:

exportfs -r

Then run the showmount -e localhost command. This should then show you the exported /images directory.

yeah so i figured it out …
had a problem with the way i registered the machine … thanks for the help.

@george1421 said:

I assume that the FOG Project has some kind of feature requests system to request this function.

There is a feature request area in the forums.

@baboun said:

I understood that FOG should be the master node in the case of Multicast but with not enough space, how it works when I want to upload?

You can setup the storage nodes however you like.

The master node of a storage group does not have to be the fog server. It can be what you define it to be.

All uploads go to the master node of a storage group first, then are replicated to other storage nodes in the storage group - so keep that in mind.

For multicast to work, the interface name must be correct. It also has to be running Linux, so that the FOGMulticastManager can run and do the job. The interface name must be correct for multicast to work for that storage node.

So, you have options for the master node, it just takes configuration. While 1.2.0 is not as flexible with this, I’m sure it can be done.

I would also say its the physical disk based on what you have posted. I have experienced a bad sector on a hard drive cause ghost and clonezilla to fail. I have not yet experienced this with FOG (just because with the other I’ve deployed units in the 1000s).

I would ask 2 questions here.

What is the hardware you are deploying to (ie Lenovo M93, Optiplex 9010, etc) Have you physically replaced the hard drive in this system. (I noted that you mentioned hard drives . Do you have more than one in this system?