Just one limitation, if you use a qnap device as a storage node AND have all of your data on the qnap device, FOG will not replicate these image files to other storage nodes. Only a full FOG server can become a master node in the storage group.
@itachi_19 There is something going on here because both conditions can’t happen tcpdump sees nothing but dhcpd responds to a client request.
Are you running tcpdump as root or sudoing to it? If you don’t have elevated rights I can understand why tcpdump would not see (because tcpdump can’t connect to the raw socket).
Yes, both are VMs on a Virtualbox, and their network is set to NAT.
Well that would keep the witness computer from seeing this communication. With NAT enabled that still doesn’t explain where the tftp://10.0.2.4/Windows@2010.pxe “Windows 10.pxe” file name is coming from. As they say, the culprit has to be in the house (virtualbox).
Add the Persistent group plugin
Manually create a new host with a unique name that signifies it is a template host.
Associate all of the snapins and what not that you want consistent for every host added to the group.
Create a new Group that is exactly the same name as the template host.
Now add hosts to this group (you can do this when you are registering the new computer with FOG too).
The settings will be copied over from the template host to the new host.
The workaround is just a patch file that needs to be replace on the FOG server. Replace this file BEFORE you install the plugin. If the plugin is installed before you add the patch file, uninstall the plugin then add it back.
We had a bad factory BIOS setup and didn’t think about looking into more detail … our fault!
Thanks a lot for your help, from the outside the problem is often more quickly identifiable;)
Thinking long-term sustainment, are there user methods for getting additional firmware (or drivers) built in? I found the wiki instructions for building custom kernels but those don’t cover additional firmware blobs.
I’ll give you the hints here in the forum and will add this to the wiki soon:
Follow the steps in the wiki article up where it says you should run make menuconfig or make oldconfig.
Now either edit that file manually, search for CONFIG_EXTRA_FIRMWARE, simply add the relative path of the firmware blob you want to that line (separated by spaces) and run make oldconfig or run make menuconfig, navigate to Device Drivers -> Generic Driver Options -> Firmware loader and edit the second option starting with (bnx2x/... (a list of files)
Save config and build the kernel
We are also working towards updating all the documentation (wiki) and move it to readthedocs. You are very welcome to help if you like.
With apologies for the necropost, I’m looking at exactly this question at the moment. My thinking is you could possibly pair FOG with Relax-and-Recover or SystemImager for a complete backup/image/bare metal restore solution.
Looks like you would be able to add a Relax-and-Recover (ReaR) menu item to FOG’s menu for a full network-based restore, in the event of disaster. Since FOG can be used as a scheduler and general-purpose task executer, it is entirely possible to run one of these open source “live backup” solutions alongside FOG - i.e. on the same server.
I also note that ReaR can deal with UEFI/MD RAID situations, which seems to be a rare gift.
@george1421 Thanks for the information on this. Also, what is the process for updating the kernel? I know it is on the GUI side of FOG but not sure if the is a specific process to avoid any unexpected errors. I have 2 storage servers and not sure if this would affect the connection or settings.
Another thing is that I have already set up Windows 10 on this Dell 3410 laptop using the RAID settings on the BIOS. So how can I fix Windows 10 since when changing to AHCI I get a blue screen?
Any tips or suggestions would be greatly appreciated.