Well this will get a little complicated to explain, but lets try. Traditional pxe booting requires dhcp options 66 and 67 to be set with the proper information namely the next-server and boot-file settings. In a normal environment that is all that is needed to pxe boot a device. Now enter a network function called ProxyDHCP. A proxy dhcp server can be configured to override what is set in dhcp options 66 and 67. FOG can use a ProxyDHCP server in cases where the main dhcp server can’t be modified such as in a managed service. For the FOG/linux world you would install DNSMASQ which can be configured as a proxy dhcp server. ProxyDHCP servers work over broadcast messages. So if you have a ProxyDHCP server on one subnet it will not hear or respond to pxe boot requests on a different subnet unless you have the ProxyDHCP server configured in the dhcp-helper/dhcp-relay service on your subnet router. SCCM / WDS has a built in ProxyDHCP server. So that is why your dhcp options are being over written with the SCCM boot loader. If you want to block / stop this there is a netboot service on your SCCM server that you need to stop. If you want proof this is happening you can use wireshark on a computer on the same subnet as the pxe booting computer that connects to sccm instead of fog. If you use the capture string of port 67 or port 68 or port 4011 then capture the pxe booting process. When you look in wireshark you will see Discover sent by the client. (2) Offers one from your dhcp server and one from sccm Request from the client ACK from the dhcp server You probably won’t see this unless you run wireshark on your sccm server, but he client will talk to the proxydhcp server over udp port 4011 to get the pxe boot information.

@im-pearce said in Muticast: My network supports routing across networks. Just be aware that multicast routing is different than tcpip routing. Most tcpip routers block multicast messages from crossing the subnets. Fog has two modes of imaging, unicast (point to point one stream) and multicast (point to many one stream). Unicasting will work in any routed network. Multicasting needs the infrastructure setup to support the multicast stream. But for the point of discovery, can you put at least 2 of these computers on the same vlan as the fog server and test. What I want to rule out is the fog server not multicasting right. If they image correctly then we can rule out the fog server at fault.

It should be possible to do, I’ve knitted together an idea that might work. Note: there may be a smarter way to go about this, but this might get you going until I can get my hands on a fog server console. Go in and create a new FOG iPXE menu item and have it displayed for all hosts. Menu Item: fog.fastwipe Description: FOG’s Fast Disk Wipe Parameters: kernel bzImage initrd init.xz imgargs loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=${fog-ip}/fog consoleblank=0 loglevel=4 capone=1 mode=wipe wipemode=fast mac=00:00:00:00:00:00 boot || goto MENU

I’m on fire today guys… I apologize for all of these mis-posts… The reason why my FOG hosts aren’t getting jobs is because my old server is still online… I was running an old image that had my previous server IP on it for the client… Boy oh boy! Glad it was that simple. I believe that is the end of it. Please mark this as solved.

@Sebastian-Roth I thought I tried doing that but I think I am getting lost on how to do that.

Nevermind!!! My browser must have been being an issue… Disregard this thread. SMH… Ha!

@Fernando-Gietz @Sebastian-Roth Fernando’s fix takes it! That worked! The first statement didn’t produce any results. But the second one did and after I restarted Multicasting, things are working again! Woo Whoo! Thanks guys! I owe you both a beer! Cheers! For the record, if anyone else has this issue… This was the fix… ALTER TABLE multicastSessions ADD COLUMN msAnon4 VARCHAR(250) AFTER msAnon3;

@george1421 the next time I need to change something in the golden image I will test these scripts. Thank you.

@blainey Replication needs FTP (random ports for the data channel) and HTTP.

Here is the Error Log

@Sebastian-Roth said in Connecting FOG to Virtual Machine: What host OS do you have VirtualBox installed on? Windows 10 @Quazz said in Connecting FOG to Virtual Machine: the PIIX3 one works fine though. I changed my chipset to PIIX3 and it works! Thank you guys for the long headache relief!

@Quazz My setup is now updated from 1.5.5 to 1.5.6. It’s very strange, once created, some are now belonging to fogproject:root and other to root:root. And no matter whom they belong to, a delete through the webui does not remove them from the drive. Any Idea?

I would be interested in seeing a pcap (network capture) from this device as its booting to make sure our wiki still contains accurate info: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@Quazz Partitions are written twice…? d1.fixed_size_partitions.txt

I created a new disk. I have to change the repertory of the picture. It is on wich file ? Only /opt/fog/.fogsettings ?

After a few days of testing on a local network just using the onboard ethernet port going to a router this is already a heck of a lot easier than the previous imaging solution that I banged my head against for a month. Bare metal is definitely the way to be and I greatly appreciate the insight. I would have torn what remains of my hair out trying to figure out making that work with Virtualbox. Going from here, trying to get the final set up the way I described in my original post, it sounds like I need to look into the DHCP configuration to move the imaging to the two additional ethernet ports and off eno1, is that correct? Right now I have eno1, enp2s0f0, and enp2s0f1. eno1 will be supplying internet and I presume the other two will be on different gateways reaching out to the switch where the target PC’s will be connected to. Would this be something I can achieve using the built in tools?

THANK YOU @Sebastian-Roth just got a pallet of 67 of these and would hate to go back to pre-fog days…:)

@george1421 I ran a full chkdsk on that machine, and I still received the same error. To see if the issue was isolated to that machine I grabbed another one, inventoried it, and ran a capture task without issue. I think we can safely call this issue solved at this point. To all interested, Following the below guide solved my initial NFS issue with my QNAP: https://forums.fogproject.org/topic/10973/add-a-nas-qnap-ts-231-as-a-storage-node-fog-v1-4 Thanks to everyone for their help with this project!

@george1421 Just wanted to let you know that I updated to the latest kernel as suggested and it worked! Not sure if anyone else has the same issue, but now we can image about 630 PCs! You guys rock!

I create a new topic : https://forums.fogproject.org/topic/13366/tftp-error-on-server/2