Topics created by need2

@Uncle-Frank You’re amazing! What you posted is very similar to what I came up with in a thread, but I haven’t gotten around to testing it.

If you get dnsmasq to work with co-existence then you’re like… everyone’s hero… for real. Because if we can get a rock-solid dnsmasq config for all types of booting - then for 95% of fog setups out there, we’ve eliminated the need to change DHCP. Fog can then come with dnsmasq setup by default and it JUST WORK without further setup.

In my opinion, Linux DHCP is far superior to Windows DHCP… but dnsmasq would be the ultimate solution if we could just get it to work.

Excellent, thanks for your quick work on this. I’ll update to that branch tomorrow and give it a shot.

The NFS that works is on a Windows server, and the one I haven’t gotten working yet is on the FOG server. And I do have it in the exports file, but come to think of it I should take another look at the settings it has.

That’s cleaner than what I had done, so I will take a gander at that later this week. Thanks for the info.

Perhaps I miscommunicated a bit. Typically an MSI is deployed through a domain rather than an EXE. This allows the domain to control what is done with the installer a bit more, including the use of an MST. The MST is a transform file that feeds the MSI commands and/or fills in options that the MSI usually contains. By default all domain managed MSI installs are silent, so in addition to not wanting to rely on the end user to know what buttons to push on an installer, an MST is necessary for anything other than a completely default install. I COULD replace the .ini files, but I would have to do this with another script, and I don’t know of a way to do this that is smart enough to run once per install, but also run again later if the install is marked as damaged or is somehow removed.

I’ve dug into the MSI a bit, and I have found a section under _Validation where I can modify a Table AppID with Column RemoteServerName. I will do some testing and report back.

Alright, that answers that. I appreciate the consideration.

Maybe in the near future I can get it so when you change the storage node to another storage group that updates the graphs appropriately but my knowledge’s wrath like it’s displayed four of the maximum number of clients is always the first one is fine

I’m working on trying to figure out what and when to do things. iPXE itself has a method to know whether something is UEFI or PXE booting, but I have to get more details before I can just add it all in.

Excellent. I am now testing this against other systems I had failing to boot the previous kernel or register.

I will give it a shot once I can take that system down again. No screenshots since this is on baremetal, but I will take a photo and transcribe.