@asawtell said in Hand-off to FOS kernel fails on certain Gen4 Xeon (Sapphire Rapids) based systems - Dell R760, Supermicro X13, etc:

I’ll also see if we can safely update iPXE without breaking anything in our environment and report back if it changes anything.

Upgrade iPXE will only impact pxe booting if something goes really bad. You can fix it by just recloning the installer files and reinstalling fog.

So this means that if you used the usb fos boot and its still failing to start up linux there is something fundamentally wrong with the FOS kernel. I would think that xscale processors are x64 compatible, so they should boot the fos linux kernel.

@asawtell OK lets see if we can usb boot into FOS Linux. It looks like there might be a problem with iPXE not handing off to the OS cleanly.

But first, lets see if its ipxe causing this problem. Lets update to the latest version of iPXE using this process. This is all done on the fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1692123396261

If that process fails we will use this tutorial to create a usb flash drive to direct boot into FOS linux. Look over this tutorial completely to understand the caveats with this route. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image Look at the FOG Forum chat for some additional tips.

The idea of usb booting into FOS Linux will be to boot into debug mode so we can try to find out what hardware is missing from the kernel build. The default kernel build is targeted to workstation class computers not servers, we may need to make a customer (one off) kernel that has raid drivers or specialty network drivers.

@asawtell You are on the latest kernel at the moment. But I was referring to FOG Configuration->Kernel update menu to get the latest version if you need it.

@dashwell Are you using the “usb boot easy way” to get into the iPXE menu? iPXE should support multiple network adapters out of the box. It should support 2 or maybe 3 external adapters and will try them in order.

There is a different way to usb boot directly into FOS Linux (the engine that moves data on the client). The tutorial is covered here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image read the entire article top to bottom. Also check the FOG Form chat for a few more hints.

@asawtell well one way to give a bit more information if you go into FOG Configuration->FOG Settings and hit the expand all button. Then search for log set the log level to 7.

Also upgrade to the latest version of kernel 6.x. There has to be a bit more info here on why its failing. I know for the servers we may need to create a custom kernel to have drivers for the raid controllers. But if its not booting into FOS then we haven’t got to the drivers yet.

@astrugatch said in Configuring LDAP Authentication:

Both Search Base DN and Group Base DN should be OU’s not CN’s.

Good catch! The search bases should be a path not an entity. So in other words stop the path at the users OU.

The log file still says its using ldaps. Yet your configuration in your first post is using ldap.

If your groups and users are in the users OU then your search scope of base only is OK. If you have sub OUs below users then you will need to change the search scope.

@anwoke8204 Are you still getting the unable to ldap bind message but with the ldap and port 389? I do remember seeing post recently about people having issues with php8 and ldap binding. But I don’t know the solution.

@anwoke8204 I believe the code for ldaps is outdated. As a test use ldap and the ldap standard port to test. If your company requires ldaps then its going to be complicated to setup.

@anwoke8204 If your computer is uefi based, lets try the easy method first. https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

By using the easy method above, you can retain all of the features of the FOG preboot environment. If that method doesn’t work we can build FOS Linux on a usb flash drive and boot that way. Its a little more complicated to setup but I have an image already created you can use. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image the previous link is the instructions to build it yourself. Make sure you read through the caveats if you go this route.

@entr0py said in Odd performance issue:

We were hitting 7-8 Gbit last night with 8-9 devices imaging.

I would say this is fairly into the acceptable range on a well managed 10GbE network. Good job!!

@anwoke8204 said in issues with deploying on UEFI computers:

Any idea on how to get the USB Network cards to boot?

For these usb nic cards they need to be supported by either bios or uefi firmware or they won’t pxe boot. Its not a fog or dhcp issue, its a potential conflict between the hardware and uefi.

With that said we do have a method to usb boot into fog imaging. There are some drawbacks to this method, but if all you need to do is clone computers it should work.

@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

1. Disk subsystem
2. Network performance.

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.