@entr0py OK lets see what you find. iperf3 will help you with bandwidth checking.
Yep on the sever thing for imaging if you have a fast path from disk to network that is all you need. The only thing that will put a heavy load is if you have computers running the fog client software. Depending on your check in interval that can put a heavy load on the fog server and make it a bit slow to respond in the web ui. But that’s different than imaging.
@anwoke8204 What device is your dhcp server? Your solution to booting both is with that device.
If your dhcp server is a fog server then it automatically supports both bios and uefi pxe booting. If you have a windows 2016 or later dhcp server then the steps are here to create your profiles. Look in the windows section
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
If your dhcp server is a router, then we should look towards a utility called dnsmasq to configure dynamic pxe booting.
@entr0py You didn’t happen to mention if the FOG server is now virtualized or physical.
In doing some benchmark testing back in the day, I was able to saturate a 1GbE link with 3 simultaneous unicast imaging. While you talk about 10 and 40 GbE, this point may not be relevant, but 3 is when things start falling down in your environment. Its not the solution but just one data point.
During imaging the FOG server doesn’t require much CPU. Its only function is to monitor the imaging process and move files from the storage subsystem to the network adapter. All of the heavy lifting during imaging is happening at the target computer. Heck I can run FOG on a raspberry pi 3 and image at almost a normal speed (one unicast image only). So I’m just saying, having a FOG server with gobs of RAM and 128 processors won’t really speed up the imaging process. It will help with multiple concurrent unicast imaging but it won’t make the process faster.
So there are two areas I would look into
I have this article from a long time ago that will give you commands to test your FOG server. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast?_=1691688342623
If you put one of the target computers into debug mode you can startup the iperf3 (built into FOS Linux) as a server iper3 -s and then from the fog server run the performance tests lets see how fast your fog server can go.
@dsutton2001 That line in question was copied from here: https://github.com/FOGProject/fos/blob/45ba692315f6e5857c12d933ae2c9c4dd5c35778/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L8
Its possible that the curl command or the php page is not working as it should. That php page is only used when you usb boot into fog to pick up the imaging bits.
If you want to debug this I can give you some places to look.
@dsutton2001 said in Manual Register then straight to imaging:
curl -Lks -o /tmp/hinfo.txt --data “sysuuid=${sysuuid}&mac=$mac”“${web}service/hostinfo.php” -A ‘’
Along with what Tom mention the above line on the surface looks suspicious. The back to back double quotes look out of place.
@ITCC I’m trying to remember back, but I think the 7010 or the X010 series was the first to support pxe booting in uefi mode. If this computer was in uefi mode it would the iPXE boot loader would not get past initializing devices. For a successful pxe boot you need to make sure that the disk mode is ahci mode (not raid-on), and secure boot is disabled.
Your #2 issue is more of a windows thing than a fog thing.
While I don’t ave personal experience imaging windows 11 with FOG, but functionally the current release of windows 11 and windows 10 are the same from the perspective of imaging. Its true that the fog code does not specifically call out windows 11, but that is because imaging wise there are no differences. Now if Microsoft changes windows 11’s disk structure or such, then that will force the developers to add a specific menu for windows 11 to adapt the imaging process with the windows 11 specific code.
@filisdiez It looks like you are using https on the fog server, but iPXE was not compiled with the same ssl certificate used to set the fog server to https. How did you change the fog server from http to https ? Did you interact with apache directly to do this?
@anwoke8204 In this article https://www.cherryservers.com/blog/how-to-configure-ubuntu-firewall-with-ufw There is a section about logging. It kind of indicates that the default deny policy logs blocked packets in /var/log/ufw* files. Lets see if there is something there regarding to what nfsv3 is trying to do. I don’t have ufw enabled on my fog servers so I have not run into this issue before.
It looks like you have all of the rules/ports enabled.
@dvorak Its not e2fsck in your fog server host OS, its in the FOS Linux OS that gets copied to the target computer during pxe booting. That needs to be updated.
@anwoke8204 The only one I don’t see is ftp.
Fog uses ssh, nfs, ftp. tftp, bootp/dhcp, http, https, rpc port mapper Make sure that stuff is enable. The rest looks good.
@anwoke8204 said in No route to host when trying to capture with fog 1.15.10 new install:
I uninstalled ufw/iptables because I prefer firewalld.
I as you have moved on from Centos/RHEL. I was in the RHEL camp starting in 1999. With them closing down Centos as we knew it, I made the switch to Debian about 2 years ago. To me Centos is dead to me.
I can only comment on firewalld and masking Debian because you are comfortable with the way RHEL worked. Eventually you will need to become familiar with the way Debian and to a lesser extend Ubuntu does things. IMO just bit the bullet and use ufw that way you can find support. The concepts are pretty much the same between firewalld and ufw because iptables runs under the hood for both. Now that you understand the concepts the rest is just syntax. You have to do what’s right for you and your business, don’t simply listen to some dude on the internet.
@anwoke8204 How did we get from debian which uses ufw for the firewall, to firewalld which is typically used on centos? But that also explains why ping works but nfs does not.
First I would stop firewalld to see if that is the root of the problem. You can get nfs v3 to work with the firewall enabled there is just a few more ports that are needed than just ports 2049.
Here is a document that covers firewall requirements for FOG. https://forums.fogproject.org/topic/6162/firewall-configuration
@anwoke8204 OK I want you to schedule a new capture/deploy but tick the debug checkbox then schedule the task.
Now pxe boot the target computer. After a few screens of instructions that you need to clear with the enter key you will be dropped to the FOS Linux command prompt. From there see if you can ping the fog server.
The get target computer’s IP address with this command ip a s make sure the subnet mask and ip address is what you expect.
On your debian server make sure that the firewall is not installed. On debian the firewall is ufw.
@anwoke8204 Is the pxe booting computer on the same subnet as the FOG server? The error kind of indicate a network (dhcp) or routing issue, not specifically related to fog.
@asawtell Sorry for the late viewing, is this still an issue.
@tomynocker FOG 1.5.9 and fog 1.5.10 should function the same in this regards. But with tat said, 1.5.10 has a newer FOS Linux kernel being used. Its possible that the linux kernel behaves differently.
Fist between your 1.5.9 and 1.5.10 systems make sure your global kernel settings are the same between the two systems. This is viewed via fog web ui configuration->fog settings and hit the expand all button. Then search for kernel you should find the global kernel settings. Make sure they are the same between the two servers. Then look into the host settings for this specific computer. Make sure the host kernel settings are the same. If they are lets go to the next step.
On the 1.5.10 fog server schedule a capture task for this computer. Before you press the schedule task button tick the debug check box. Now pxe boot the target computer. After a few screens of text on the target computer you will be dropped to the FOS Linux command prompt. At the FOS Linux command prompt key in the following commands.
lsblk
cat /proc/cmdline
take a clear picture of the output with a mobile phone and post the results here
@knight4sue I’m not sure I understand your problem because the windows 8 key is stored in the firmware so if you are putting an OEM image back onto the computer it should activate itself using the built in key.
Now, I’ve done something similar to you to put the computers back to the default OS as we purchased them. Typically before we even boot the new computer into the as purchased OS we will use FOG to capture an unactivated version of windows from that new computer. If you did not do this originally you can still do what you want to do.
Take one of these computers and an OEM version of the OS that was delivered with the computer. Install windows from the DVD or usb media. But this part is important. The windows installed will install the base OS and then reboot. Power off the computer when it starts to reboot. Its important you stop it in this exact spot. So what is on the hard drive is the OS files before windows boots for the first time and windows setup begins. NOW capture this disk image with FOG. Leave the original computer untouched, but deploy what you just captured to a new target computer. The first time that computer boots winsetup and oobe will start. They OS will not know it was cloned to a second computer and it should activate on its own with the OEM windows key.
@brakcounty the issue is with the ipxe menu. reguardless how you get to the fog ipxe menu its will point to the interface marked as for imaging.
With a web browser make a call to http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 this will display the text behind the ipxe menu. At the top it defined a variable that includes the IP address of the imaging interface.
Just to help you get started, dig into the iso image and collect these file. The wimboot file is a download from the internet. The rest are on the iso and put them in the http path /var/log/www directory
set http-path http://${fog-ip}/mdtboot
kernel ${http-path}/wimboot
imgfetch --name BCD ${http-path}/BCD BCD
imgfetch --name boot.sdi ${http-path}/boot.sdi boot.sdi
imgfetch --name boot.wim ${http-path}/LT_PE_x64.wim boot.wim
boot || goto MENU