I’d also recommend not upgrading your OS to 14 or 16, it will not go well with fog. Sit aside the old server (or swap out HDDs or something) and build a new one from scratch, if you are going to build a new server, I’d recommend going with Ubuntu 16 only because it’s the latest and will be supported the longest.

@zingaro That’s not NFS, in the command it says cifs. without heavy init modification, fog will not work with cifs. Also, you shouldn’t setup an NFS share this way, either. The share does not get mounted to the server at all, because if it were, imaging would not work. The Linux kernel will not allow you to re-export an already exported directory. You don’t even need to touch the CLI of the main server to do this. Just the NAS and the web interface of FOG.

On the NAS, create an NFS share with full read/write permissions for everyone. Create an FTP user called fog and grant it full rights to the share. In the share, make a file called .mntcheck and a folder called dev and inside of dev make another file called .mntcheck Then plug in the IP address and share name and the fog user along with it’s password, and ftp path into FOG’s web interface.

@goempie There is a posting on the FOG wiki that discusses this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

As for the differences between undionly.kpxe and ipxe.kpxe. The difference is that undionly,kpxe is smaller and is only has a shim between the iPXE kernel and the network adapter. It relies on some firmware on the network adapter to provide basis undi network services. As long as the network card firmware is well behaved then everything works great in this model. The ipxe.kpxe contains the majority of known or common network drivers right in the kernel. This iPXE kernel is bigger for sure but also include very well behaved network drivers.

Just a comparison between the two kernels.
undionly.kpxe is about 93KB in size
ipxe.kpxe is about 343KB in size.

These days with multi GB workstations this is really a trivial matter, but smaller kernels make faster boots. But in reality find the iPXE kernel that works best for your environment and stick with it.

Do you have an image assigned to the host? Are you using the location plugin? What storage group is the image assigned to? Would you mind updating to RC11 please?

Goes hand-in-hand with

https://forums.fogproject.org/topic/8638/full-registration-causing-rogue-snapins-to-apply/

@zln1996 Sure no problem. Here is the article, the 2012 section is below the linux section. https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@Wayne-Workman I have successfully installed Microsoft office snapin to other systems. of course I increased the data amount I can upload based upon the steps outlined hereI made the size 10GB. I created a msp and placed it in the updates folder then zipped the package, uploaded to fog server and was able to deploy via the .exe Template.

@davidedpg10 https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

@Tom-Elliott all OK.
i have moved all image in another folder.
now work fine !

/var/www/fog/images is redirect to /var/www/fog/images
Case Closed!

@Wayne-Workman Thank you so much!

@Wayne-Workman
Thank you Wayne and Tom for your replies.
I guess i didnt understand the idea of snapins, anyway, now I do.
Eventually, I solved the problem with creating a new path to the sanpins.

Regardless of this problem, I have another one now.
I just noticed that since updating to 1.3.0-RC-10, I cant capture any machine.
The progress is stuck on the client, like this:
0_1474521399902_fog-stuck-on-mountingfilesystem.JPG

im trying to capture an image i already captured, just for testing, I left it all night and it didnt continued…
Im sure about the settings i set for the new image, since its the same as the image settings that already deployed to the machine.

Should I post a new topic about this or wait here for help?

Niv.

The switch did not support any faster methods of STP, or they did not work. Disabling STP altogether is a calculated risk that we took, and it has fixed the problem.

This issue is solved.

@Quazz

Permissions solved the issue. Fog had access to the folder, but when I pasted this new image in it, it needed the permissions for it.

Thanks for the help!

Problem seems to be resolved.
I deleted the storage node that was showing up in apache error log. Not sure why FOG reverted to a storage node that was not listed as master, but it did.
After deleting, I have uploaded an image.
Words of wisdom from an idiot…When SVN up-ing, Make sure that you don’t delete your images, evidently there is a setting to delete images and I missed it. It is a bad thing to delete them. Worse than that…I did not have a backup of the images.
Happy Fogging.

@Wayne-Workman @Quazz Thanks for your support you guys are great to have around.

@Wayne-Workman
No problem with Fog, just old machine with unstable WOL.

@Tom-Elliott the backup was my fault. To gain access to the internet I have to swap cables. When I did the “real” dhcp server gave that server a different ip. The database had the old info.

Crosslinking similar threads:
https://forums.fogproject.org/topic/8601/ipxe-boot-php-hanging-on-capture

Appears to be working, will let you know once the image is uploaded if it still boots 🙂

@Wayne-Workman I was able to get it rolled back. It is looking like the snapins are back now. thanks for the help

@adukes40 Ok. That means your DB connection from nodes to main is good. I think it’s just a bug on the version you’re on, you’ll have to wait for tom to look at it - sorry.