Sorry my Portuguese is not good so I’ll answer in english. If you have windows 2012 server you can configure it to support dynamic dhcp option 67. For windows 2008 you have no joy. For 2008 you can only pick bios or uefi booting. You can still make FOG work in your environment. You will need to install DNSMASQ on your FOG server and let DNSMASQ send out the pxe boot information. If you have Windows 2012 or later server you can follow these instructions for dynamic booting of bios/uefi: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy To instal DNSMASQ on your fog server: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server One doubt with DNSMASQ is if your client computers are on a different subnet than your fog server you will need to make a change to the dhcp-relay service on your router. You will need to add the FOG server’s IP as the last dhcp server in the dhcp-relay service list. Mod Note: Translation via Google Good morning, I have a doubt about dhcp, I am using fog as the right image server !, and using the dhcp server in Windows server 2008, I am having difficulties in options 67 where I put which file to use at boot, this is working all in how much, my doubt and the following is there any way that I can leave the boot options in the dhcp UEFI and LEGACY together, or every time I will have to change within the scope of DHCP? Thanks in advance!

I’ve updated to 1.5.9-RC1 after a bit of work, I think I’ve gotten everything working now. I have my Public signed wildcard cert working. I’ve got ipxe configured to Trust the godaddy root cert. This was important as our content filter was again blocking what I think to be the validation attempts. This time it was not showing up as OCSP, but simple “web-browsing”. edited /tftpboot/default.ipxe to use hostname, and added parameter to change screen resolution. Some of our newest machines have 4k monitors that make the menu tiny. And lastly, Replication services, Image and Snapin, both are working. It final magic seems that the Replication services use “Fog Configuration -> Fog Settings -> Web Server -> Web Host” and cross reference it to the StorageNode names. It then takes the IP address and Interface configuration from there to determine if the nic is “UP”. It seems DNS resolution is not done on the IP address field here. I had the names and not the actual IP addresses. After setting “Web Host” to the FQDN, and adjusting the StorageNode name to match, and setting the StorageNode IP to the ip, and finally restarting the replication services, things started to all work. Sorry, that one was wordy. @Sebastian-Roth Thanks for your help. I’ll post new topics if I find anything 1.5.9-RC1 related.

We’ll need a bit better picture of how your network is constructed. Is the 192.168.9.x subnet just a dedicated imaging network, or is it a general business network with printer and an internet connection? Is the 192.168.10.x subnet your general business network? Does it have a connection to the internet? Where is your upstream router? From that upstream router can you get to the internet? Sebastian is right about configuring the fog server as a router to forward packets between the interfaces. Its not the best solution since all of the data between the nas and the target computers will flow through the FOG server. Its totally possible to do, I just want to make sure there isn’t a better way to go about this. Is your FOG server a physical box or is it a VM?

@j00k4 I suppose you use FOG 1.5.8, right? When we released this version Ubuntu 20.04 wasn’t out yet and while I have tried to get it right, Ubuntu decided to switch to a different PHP version just a few weeks before the final 20.04 release. So please download the latest release candidate version of FOG and give that a try: https://github.com/FOGProject/fogproject/archive/1.5.9-RC1.zip

@Sebastian-Roth Yes it was on the iPXE side. During testing we booted FOS Linux off a usb flash drive and it imaged fine. Well with some clarity, it imaged fine once we added nvme_core.default_ps_max_latency_us=0 to the usb/grub boot parameters. SO that kind of points to ipxe/hardware/uefi firmware that had a conflict with this specific nvme disk.

I’m so confused. I see 2 posts now with: 1923168.1.10...... One @Sebastian-Roth brought up, and the post directly after that also has the same typo. Is this a typo, or is this literally what’s being displayed on the Host machine?

@fogusnew We are working towards a next stable FOG version by pushing out release candidates (RCs). FOG 1.5.9-RC1 is out since a few days and you might want to update to that to see if the issue mentioned is really fixed. If it’s not we can still look into it before the final release comes out!

@j00k4 As I said, the fog-client can run so called snapins to do certain jobs for you automatically, like install software.

It is not happening anymore. The VM is only 18GB. It takes less than 10 minutes to capture and less than 10 minutes to update FOG. Or visa versa. The only weird thing I have since noticed is during the install process, when are asked to go to fog/management and hit update database, that page no longer shows up. It just displays the fog login screen. So I just go back to the installer and hit ENTER. It seems to work fine.

@Jeff-Findley said in kernel interface not working: Just an FYI - according to Netgear none of their unmanaged switches do any sort of STP. But who knows. Yeah you never know. But beside STP we have seen a few cases where ethernet energy efficiency (EEE) stuff kicked in and caused such things. While it is possible to be EEE I still suspect George is right with STP…

Thank you guys. I have now got the latest RC 1.3 and found a problem. I made another thread about it.

@Greg-Plamondon another suggestion. We had enough issues with pxe boot compatibility acorss different devices that we embed a custom bootloader that has an option for booting directly to a local copy of the ipxe.efi file. We use grub2win and just have its installation as part of our provisioning scripts that are started by sysprep firstlogon. Found this to work better than trying to get custom nvram type settings, this way you get it individuallized per hardware but also using a universal config file.

@JYost Yeah, truly a bug. Fixed in latest dev-branch. Change will be in the next release.

I don’t have the ignore mac on client/imaging Setting built in to those functions, but you can take a peek at the code to see whrte you are setting the primary property there is also a property for ignoring mac on client. I’m on my phone at the moment so can’t go test and get for sure answers. But it’s either a part of thr maclist array of a host or a different property. Point is you can for sure set that. If you give me a bit more detail I will gladly try to give you further examples on how to do it with the powershell module

@beardedfool said: Need to check how to do reinstall (can I just ./installfog.sh -A over the existing installation as per new build Yes you should be able to do just that!

Agreed, won’t be my main method but will be useful for other people and, to be fair, the odd quick install to test something over the network rather than breaking out usb sticks is always welcome Thanks, that’s good, suspected that it would be in sql and I should be able to follow those changes. Even for me I can see a useful script like “redeploy.sh hostname” which creates the deploy task from outside of the fog gui, reboots the machine then performs tasks afterwards (though I also need to look at the snapins). I’ve just noticed the API so suspect there may be something there and appreciate I’ve verging off topic with that one. Lots for me to follow up on so will leave you in peace for now but thanks for coming back to me so quickly.

@JYost What you see when you first click hosts is the search view. Typing in the menu bar search field you should see results below. To change this you go to FOG Configuration -> FOG Settings -> FOG View Settings and change setting VIEW DEFAULT SCREEN from SEARCH to LIST. Don’t forget to click Update to save the change.

@lewisreid01 Thanks for the update and good to hear that you were able to fix it this way. I was hoping we could figure out what happened to your install and try to fix it “a less invasive way”. But possibly this is the quickest way to solve this issue anyway. Well done. For anyone reading this: The installer option -C should be used with great caution! It will reset all the pinning you have made when installing the fog-client on your hosts. So as described by @lewisreid01 the second step is to re-install fog-client on all hosts!

@Norm said in Help with Mac imaging: When I upgraded to Fog 1.5.8 it broke. Can you please give us some more details on where it breaks. Please take a picture of the screen and post here.