Multicast “SHOULD” be the FOG Master Node. Unless your NAS Box can install web and run UDP, it MUST be done with a different box.

That said, NAS’s have a lot of their own problems with FOG Beyond multicast. 1.2.0 just isn’t very friendly with them. I’ve made some strides with the issue’s most NAS’s tend to cause in FOG Trunk, but what you’re wanting to do (Multicast from a NAS) is still not something I would try.

First, as I stated earlier, the NAS would need to be it’s own node completely for it to work best. While many NAS box’s have a form of linux running them, I don’t think they have the utilities available to install UDP-Cast which would be needed.
Your best option would be to mount the NAS’s storage to a more appropriate system that has a FOG Server installed.

Second, if you go with the option to mount the NAS’s storage, the work is, most times, mounted from the network. Multicast just wouldn’t work very well because of how UDP works. UDP spams its packets out without caring who or what see’s them. This, typically, floods a network. As the NAS is network connected, it would also be spammed by these Packets. Essentially, this could cause a complete disconnect of the NAS’s shared filesystem, ultimately affecting the imaging you’re doing.

If you must use a NAS for storage I would highly staying away from Multicast.

I guess I should clarify. We use MDT to create our reference image on a VM with a 40GB disk. During the MDT deploy task we apply all of the windows updates. If we are making a fat image then we install the additional software at that time (using a fat image task sequence in MDT). When we have the image the way we want it, then we sysprep it and capture the image. At this capture point we still only have a 40GB disk. So we deploy that 40GB disk to the target computer and then once on the target computer we extend the disk with diskpart.

We do it this way because we rebuild the golden image each quarter. If you have everything setup to create your reference image automatically, the actual hands on time is very small. What takes the most time from start to finish is windows updates. So far with the WIndows 7 updates it takes overnight to apply them all (~14 hrs).

While I got a bit off point, the key is to deploy a smaller image to your client computers than their smallest disk size then extend their logical disk to the physical size during the cleanup process.

@Drevonovic You are welcome! Do you want to stick with pxelinux or try to get the normal way with default.ipxe up? See my other post and feel free to ask if you need further assistence.

I’ve readded the code that supposedly fixed this earlier. I’m hoping it can be put to bed, but my track record or something.

This issue as well as a few others have been pushed. Thanks for reporting.

I have used this configuration and it works! Link from Wayne Workman! Kudos to you my brother! Thanks!

Example 1

Here’s a complete configuration example where TFTP and DNS is on the same Server. No router is defined in this configuration but can easily be added by changing X.X.X.X and un-commenting the line.

option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; # RFC4578 use-host-decl-names on; ddns-update-style interim; ignore client-updates; next-server 192.168.1.1; authoritative; subnet 192.168.1.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.1.10 192.168.1.254; default-lease-time 21600; max-lease-time 43200; option domain-name-servers 192.168.1.1; #option routers x.x.x.x; class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/ipxe.efi"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "ipxe.efi"; } class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "undionly.kkpxe"; } }

@mjcrane Great! Got it right this time 😄 You are welcome!

Take a look at this script: http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/src/ipxe/src/ipxescript

This is compiled into the iPXE binary Tom is building for all of you (the original undionly.kpxe you had in /tftpboot sitting). The last line is chainloading default.ipxe from the FOG server. In your case the variable ${next-server} is being set to your ISPs router IP. So I just compiled a new binary and exchanged the varibable with a “hardcoded” 192.168.0.111 - pretty ugly but still working…
If you want to play with this without installing all the building tools you can go to https://rom-o-matic.eu/ (But be warned, getting all the settings right is kind of tricky!)
Just give it a try. There is a lot you can learn about PXE booting by trying out these things.

As I already said there might be a fix in the script that we could add which hopefully should work for others too. @Tom-Elliott What do you think? See in one of my earlier posts. Either that or we just overwrite next-server without checking it being set or not in case proxydhcp is set?!

#!ipxe ... isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ...

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