@User_wds First let me say I have no experience with windows 11, but it should be similar in disk structure to windows 10.

So I would have to ask did you prepare the system for cloning?
Did you sysprep the image before capture?
Did you properly shut down the OS for cloning?
Is this the first computer you are cloning?

@tadziuuu Are you referring to booting bios based computers? If yes then use memdisk to load the cd iso image into memory. The one caveat here is that the iso disk must be less than 2GB in size since memdisk is a 32 bit application and there needs to be room in ram for the OS to boot from the iso image. In the same tutorial you found the parameters in your first post, search for memdisk to see what parameters you need.

@Alan-Lim Lets run through this tutorial and compare it to your settings: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@anwoke8204 Lets start by taking the space out of the OU name for “Fog Access”, on the linux side that may require you to escape that space (more complicated then necessary). If your user account NT style naming for users have a space in the name get rid of that too. Looking at users and groups too, just get rid of spaces to eliminate that issue.

@joseheitor I can think of 2 possible conditions to cause this.

1. The reboot process leaves the hardware in a strange state where iPXE can’t get an IP address on a warm start.
2. Your network switch and spanning tree (if standard spanning tree) is enabled would cause this. Explanation Default Spanning tree takes 27 seconds to start forwarding network data after a network wink (as if the computer is rebooting). A warm start boots faster than a cold start so by the time iPXE gives up STP has not started forwarding data yet. Where at cold start the computer tests memory and checks hardware that isn’t needed on a warm start. But again this is only a guess as to the reason.

One quick check for spanning tree is to put a dumb (cheap) un managed network switch between the building switch and pxe booting computer, see if that resolves the post imaging reboot. If it does then look into your network switch settings to enable fast-stp, port-fast, or RSTP (whatever your switch vendor calls it).

@tlehrian said in PXE boot failing at DHCP:

I supposed that upgrade also updated the iPXE file?

Yes that is correct, but it will only upgrade it to the version that was in place when 1.5.10 was packaged for deployment. You can run through the upgrade tutorial at any time to build the very latest version of iPXE if you get new hardware that gives you the same problems as before. The FOG new version release cycle is much longer than iPXEs.

@tlehrian OK Lets have you run through this tutorial to update iPXE. Because this is iPXE failing to access the network interface.

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

If that gives you no joy, then switch your ipxe boot loader to snponly.efi instead of ipxe.efi. The snp driver should be built into your uefi firmware.

@joseheitor Yes the easiest way is to schedule a debug deployment. Before you hit the schedule task button, tick the debug checkbox. PXE boot the target computer, after a few screens of text you need to clear with the enter key you will be dropped to the FOS Linux command shell. Kye in fog to start the deployment process in single step mode.

What I would do first is edit the fog.powerdownload script and put an echo statement like “script is running” then enter a debugPause after. When you see the script is running text and the pause afterwards you can hit a ctrl-c to drop out to a command shell. Your context will be as the script is running so you will have access to the fog variables. you can see them using the set | more command.

Once you have your post deployment script figured out you can restart the deployment process by just rerunning the fog command. You don’t need to reboot the target computer as long as you don’t let the script run past the post install script spot.

@joseheitor The short answer is you are correct a post install script is what you need. We don’t have a tutorial on this for a linux target computer, but we do for a windows target computer. The concepts are the same between the two platforms. I have to admit it a bit easier for linux since the FOG deployment engine is based on linux already.

This tutorial gives you the framework you need: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

The fog.custominstall script checks to see if its a windows platform by the $osid variable then loops through the disk partitions looking for the fs type of ntfs, if found it tries to detect the windows folder. If you know the partition number already you can just do the direct mount of the directory onto the mount directory you create. From there is just piping the variables you need into a text file on the target computer.

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