@Redbob What I’m seeing here:

It asks for the file size over and over again, on a 5 second timeout, then eventually it asks for the file. This should be a two packet process. 1. Ask for the file size and 2. Download the file. There is something abnormal going on here.

@Redbob said in Pxe-E32: TFTP open timeout - FOG 1.5.10 - DHCP Windows Server 2019:

server is in default subnet (172.24.0.0/22) and the workstation 172.24.12.35 is in WLAN 12 (172.24.12.0/23)

Specifically I’m asking if they are on the same site or different sites? I have seen the tftp download fail (which is what it looks like in the pcap) if the mtu of the link between the subnets are smaller than the default tftp packet size of 1456. I have seen WAN links sometimes have smaller than 1500 mtu.

Also is there a screening firewall between the subnets that might be blocking tftp traffic?

@Redbob Without being able to see the original pcap it makes this a little hard to debug on the boot file side to see if your dhcp server profiles are correct.

But on the surface if you are pxe booting a bios based computer everything looks right between the dhcp server configuration and the pcap. It should be working…

So I have to ask you this, is the pxe booting computer on the same subnet as the fog server? Is it local or across some WAN link?

@Jim-Holcomb

Just a few questions:

1. How did you delete your images?
2. Did you go into the image definition and pick delete, or did you delete the images from the image list?

If you deleted them from the image list then the files still persist on the fog server this is by design. If you went into the image definition then picked delete, it gives you the option to purge the files from the disk.

If you have deleted the image definitions already, you can manually go into the fog server console and purge the files. You will need to sudo to root then navigate to /images directory on the fog server. Your images will be under that directory. You can use the command rm -rf <image_directory_name> and it will purge what ever directory you give it. Be mindful with that command because if you remove a directory this way its gone. The -rf flag is recursively delete the files and force the delete. With great power comes great responsibility.

@elchapulin You created the pcap perfectly.

I can see the pxe booting computer is in bios mode.

Looking at the dhcp OFFER packet, I see in the header the next-server is 192.168.1.22 and the boot file is undionly.kpxe. What is strange is in the dhcp options there is only dhcp option 66 which again points to 192.168.1.22. The issue is there is no dhcp option 67. All 4 fields need to be filled out. Its strange that pfsense is doing this…

Lets try this, in your screen shot the tftp server field is filled out, but that is in a different section than netbooting. Lets remove the tftp server value under the tftp section, but lets leave the next-server field set correctly under network booting. I think the tftp section is overriding the netbooting section.

@elchapulin Ok follow the instructions to get the pcap. That will tell us what the target computer is being asked to do. With a bios computer it should just work.

@skyborne98 Just for confirmation 10.23.3.17 is your fog server’s IP address?

The deployment path looks strange 10.23.3.17:/**vol/lab.fog.image.std.1/**images is not the default FOG path. How did you get this path?

What is the output of showmount -e 127.0.0.1?

The web url look strange too, but that’s not the issue here.

@sgilbe said in Client hangs at EFI stub::

Platinum 8480

OK I’ll look into the kernel configurations tonight. From what I see commercial linux can run on this hardware, there must be something missing from FOS linux. Understand that FOS Linux is a very light and fast version of linux dedicated to imaging. So it supports almost all hardware, servers them selves give us a problem since the hardware is more specific than generic.

@totoro Ok this can give me something to work with.

00:1d.1 Ethernet controller [0200]: Intel Corporation Device [8086:4ba0] (rev 11)

This is the ethernet controller. first available in linux kernels 5.7–5.19, 6.0–6.5. I don’t see a fail to load firmware for this one. Run the lspci command again lspci -Knn | more you will need to look for device 00:1d.1. I need to see that entire section.

EDIT: I just looked at the build settings for FOS Linux 6.x and it does compile the driver in the 6.x released of FOS Linux https://github.com/FOGProject/fos/blob/45ba692315f6e5857c12d933ae2c9c4dd5c35778/configs/kernelx64.config#L1720 lines 1720-1724

Bus 001 Device 011: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

OK that answers why I was seeing a failing to load for the realtek nic

@sgilbe OK so this is telling us that the linux kernel is not booting on this hardware. Can you go to this URL https://github.com/FOGProject/fos/releases and download the 5.15.x bzImage and copy that to the usb drive to see if 5.15 will boot on this hardware? If not working, then try the 5.10.x, if that fails then try the 4.19.x series.

As for the type of system it is an Intel 4th Gen Xeon system (D50DNP)
What exact processor is installed in this computer? I might have to search this issue based on the processor. You were able to live boot ubuntu 22.04 so a linux kernel should boot on this system. There might be something missing from the FOS linux kernel.

@totoro Do you have access to the FOS linux console or is the output from some other linux distro?

If you have access to the fos linux console key in the following commands and post the output here.

uname -a
lspci -nn | grep -i net
grep -i firm /var/log/syslog

1. The first command tells me the linux kernel version
2. The second command lists all network adapters in the computer. The important value missing from your printout is the device id [8086:xxxx] that will tell me if linux has a driver for it.
3. The third command should list any possible firmware the network adapter is missing that we need to include in the kernel.

@totoro Do you have the option to usb boot this device for imaging?

For completeness, you say you are able to image using 2 network cards. One allows pxe booting. What model network adapter is this? The first one is not seen by FOS linux but the second one is seen by FOS. What model number is that? Is it an added in network adapter like usb a or usb c network adapter? The transfer of 26% of bzImage is suspicious why it works for capture but fails on deploy. I have to be missing something here. I realize this hardware is not a typical PC, but if its x86 based it should work.

@sgilbe ok, please pick the debug option, I think its item #6. That menu has a log level of 7.

But it does look like the linux kernel is not booting on this hardware, hopefully the additional logging level will give us some help. Also now that you have a usb drive, we can try the 5.15.x linux kernels too. It might be something in the 6.x kernel.

@skyborne98 Will you provide a clear screen shot taking with a mobile phone of the actual error so we can see the context round the error message.

One other debugging step we can do is to schedule a capture/deploy (desn’t matter) but before you hit the schedule task button, tick the debug checkbox. Now pxe boot the target computer and it will begin imaging in debug mode. So it will drop you to the fos linux command prompt on the target computer. Key in fog to start the imaging process. The imaging process will single step through imaging. You will be required to press enter at each breakpoint to continue. When you get the error press ctrl-C and then take a screen shot of the error. From there we can begin trying to debug what is going wrong.

One thing that also reminds me, did you update the database schema? It would have been a step in the installation process to go to the web gui and update the schema.

@iljared98 The problem here is raid-on + uefi + linux. There is no known driver for raid-on mode with uefi and linux. You need raid-on mode for the intel raid controller to work for the fake raid.

For full disclosure I have not tested the intel hardware accelerated raid with the 6.x linux kernel yet.

Now if you change one of the settings you will be able to image. Something you can try. I know this works, but I have not tried it recently or with your hardware. If you have a uefi image, you can capture and deploy that image using a bios based computer, as long as the first boot is in uefi mode of the target system. So the idea here is to pxe boot the computer from the Dell boot manager in bios mode (CSM mode needs to be enabled in the bios). Deploy your image to the raid disks in bios mode and see what that gives you. Now I’m suggesting that you leave the computer in uefi mode with raid-on just from the boot manager pxe boot in bios mode (hopefully that is still an option). Upon a reboot after imaging the computer will remain in uefi mode and for the OS first boot it will be in uefi mode.

@sgilbe said in Client hangs at EFI stub::

I will go through the forum chat to see if there is anything there about the issue

Hint: little speech bubble along the fog menu bar on the right next to your avatar picture.

@skyborne98 There as been many, many changes since 1.2.x series. One notable change is that the service account fog has changed to fogproject, but that would only come into play during a capture.

The permission denied message during a deploy is suspicious since FOS linux (at this point in a deployment) is running as root. It should have access to the nfs share.

Also for reference, the .fogsettings file is only referenced during an install.

Lets have you run through this tutorial. Remember the service account for FOG is now called fogproject since there were bad instructions on the internet for people to use the fog account to install fog, which reset its passwod. https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password?_=1694461880173 Lets make sure your fog service account is all synchronized before we dig deeper.

@sgilbe I can say I have not tested this process with Rocky Linux (any version). I did create the image for the tutorial using ubuntu/debian version. This issue may be related to a newer version of grub. You might want to try to add the --force switch to the command.

Did you look at the forum chat at the top of the page for additional hints?

@elchapulin This should work for pxe booting except the 32 bit field is bad. It should be i386/ipxe.efi but that probably isn’t your problem since 32 bit uefi systems are rare.

So when you say the pxe client can’t boot, what errors do you see?
Is the fog server, dhcp server and pxe booting client on the same subnet? If yes then we should grab a pcap of the pxe booting process from the fog server using: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1694459465428 You can look at the output with wireshark.

In the DISCOVER statement in dhcp options 93 or 94 the pxe booting computer will tell its arch. The dhcp server will take that statement and then (should) seen the proper boot file info in dhcp options 67 as well as the boot-file field in the ethernet header of the OFFER statement. The OFFER statement comes from the dhcp server. If you have only pfsense as your dhcp server then you should have only one OFFER statement, if you see more than one you have multiple dhcp servers on your network.

If you can’t figure it out with wireshark, upload the pcap to a file share site and post the link here or DM me the link with FOG forum chat. I’ll take a look at it.

Also one additional comment, if you have uefi system make sure secure boot is turned off or the firmware will reject ipxe from loading.

@elchapulin Yes it does. (saying these instructions from memory) in the dhcp server there is a section under advanced for netbooting (its not called pxe booting). There was 4 or 5 fields. One for bios, that takes the value of: undionly.kpxe, one for 64 bit uefi: ipxe.efi, and one for 32 bit efi: i386/ipxe.efi and maybe one for ARM processors. There should be a field for next server or boot server IP. That will be the IP address of your fog server.

I seem to recall a section on tftp, that section is not used for net booting.