@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.

@george1421

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

@WhyAydan memdisk is a bios only boot loader. Its possible to pxe boot lite touch image but you need the wim files. Looks like I need to take a few minutes and update the documentations. Give me a few hours to get this written. But its possible to do to allow both uefi and bios to load the lite touch image.

@tcso Surely run this by your network admins but if you use my configuration there is low risk to your network infrastructure. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1690230679683

dnsmasq is a swiss army knife of services and if misconfigured will cause problems in your network. But using it in a proxydhcp configuration it will only provide pxe boot information only for your network. When the fog server is powered off then no pxe boot information, which you can’t pxe boot without fog anyway. So no harm no foul here. FWIW, proxydhcp is what windows wds uses to configure the target computers for pxe booting. A ProxyDHCP announcement will override anything configured in dhcp options 66 and 67.

@Jump_Ace Issues related to not getting FOS Linux (bzImage and init.xz) sent completely to the target computer is related to iPXE and or the target computer not FOG itself per se.

1. First make sure the firmware is up to date on the target computer.
2. Secondly build the latest version of iPXE and see if that fixes the networking issues with your target computer. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
3. If you are using the boot image ipxe.efi see if snponly.efi works any differently.

@wildcat2083 You need to ensure that there isn’t a dhcp server already running on your fog server.

ensure that dnsmasq is not
systemctl stop dnsmasq

now check to see if something is bound to the dhcp port
netstat -an | grep :67

If you see a response like 0.0.0.0:67 then there is still a dhcp server on the fog server.

You can also run this command to see if the isc-dhcp server is in memory. ps aux | grep dhcp If it returns isc-dhcp and a process ID then its still running.

My bet if you look at the log file in /var/log/syslog (or /var/log/messages) it will say that dnsmasq can’t bind to the port :67

@brakcounty On the server can you serve tftp on two interfaces. The tftp server is interface agnostic. The problem you will have is the FOG code running on the FOG server only knows about 1 network interface. So event if you pxe boot into the FOG iPXE on either interface, the ipxe menu will only point to the interface FOG considers the its imaging interface.

@tcso I think I can shed a little bit of info on you and you will be up to speed pretty quickly. That doesn’t mean it will solve your problem, you will just know why you have a problem.

Just be aware that if you want to boot a bios based computer you will need a bios based operating system. Bios and uefi are interfaces to the hardware. These are two different environment and are not directly related. So you can’t boot a bios based operating system on a uefi based computer the same way you can’t boot a uefi based os on a bios based hardware. This works the same for windows, linux, or embedded OS. Once the OS bootloader starts then the OS can be a bit more generic.

FOG as well as other network boot based imaging tools, use a bootloader that gets sent to the target computer over tftp protocol. The target computer knows what bootloader to request because of DHCP option 66 and 67. To boot a bios based computer with FOG dhcp needs to send in option 67 typically undionly.kpxe. If you want to pxe boot a uefi based computer, dhcp option 67 needs to be ipxe.efi or snponly.efi.

The problem with normal dhcp is that this dhcp option 67 is a static value. So you can only pxe boot bios or uefi based computers. Luckily both linux and windows dhcp server’s support something called target profiles. Using target profiles the dhcp server will detect the pxe booting target computer and send the proper pxe boot file name to the target computer. https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#using-proxydhcp-dnsmasq look into the section that talks about windows 2012 servers and later on instructions to set this up.

If you have an unchangeable dhcp server and your target computers are on the same IP subnet as your FOG server you can install dnsmasq on your fog server to override dhcp options 66 and 67 with the proper values. If your target computers are on a different ip subnet and you have control of your network switches you can integrate dnsmasq pxe info to other subnets.

@engineerfranko I would start by updating iPXE. You didn’t mention the version of FOG you are using, but its still a good idea to update it if you have really new hardware.

https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1689971549331

@ERockZab Is secure boot enabled on the target computer? If yes turn it off and try again.

@spchristy said in HP 705 G4 - rEFInd Initializing....:

Last night I went the ./buildipxe.sh route assuming that it would install the most recent version (0.14.0.2).

OK you have a conflict here. The buildipxe rebuilds the iPXE boot loader (not a bad thing to do to stay current). But that has noting to do with refind. Refind is its own critter. Refind is only installed from the fog installer, and its never made current. Its only what version is release when new version of fog is created.

Just to test, see if it works, change your UEFI exit mode from refind to EXIT. EXIT is a built in function of iPXE. Where refind.efi gets called (chained) from iPXE then iPXE leaves memory.