@DBCountMan First let me say this is a new one, that I’ve never seen before. So the rest of this is a lot of pure guessing.

If we reference the ipxe documentation https://ipxe.org/cmd/certstat for certstat something jumps out at me. The definition of permanent:

[PERMANENT] 	The certificate was embedded into iPXE at build time. 

This is a certificate that was added when ipxe was compiled. For the one that no work, it has a permenent id of 5e…c9 for the CA certificate. In the one that works the permanent one is 81…0c (which is also what your browser is reporting.

So if we build a truth table on this, it points that you might have 2 ipxe boot loaders at play here (because we are seeing two different certificates). So the question is how can we tell?

ideas from the ipxe console:

1. Seeing if you have multiple dhcp servers responding here? There should be a way to see dhcp option 66 and 67
2. Seeing if there is a way to find the boot loader name or version number or build number to see if a second ipxe boot loader is in play
3. The one working vs not working is the platform different uefi vs bios?

@DBCountMan And does the files in /tftpboot have todays date too? I was kind of hoping to catch things in a broken state to understand the the symptom vs cure.

@DBCountMan said in ipxe chain boot.php permission denied on pxe but not autoboot:

SSLCertificateFile /var/www/fog//management/other/ssl/srvpublic.crt
SSLCertificateKeyFile /opt/fog/snapins/ssl//.srvprivate.key
SSLCACertificateFile /var/www/fog//management/other/ca.cert.pem

Lets start by inspecting these keys, has the file date changed?

If you use ssl and these are self signed certificates, the web browser should show a red mark in the address line to that there is something wrong with the ssl key. You should be able to inspect that ssl key from the browser, lets make sure the expiry date has not been reached. A certificate expiring would also cause this issue.
EDIT: This site shows how to check a certificate expiry date from the fog server linux console https://computingforgeeks.com/how-to-check-ssl-certificate-expiration-with-openssl/

If everything looks good on the certificate side, then lets go and rebuild ipxe that should recreate ipxe with the properly installed certificate.

@seppim First let me say this is a windows imaging issue not specifically a FOG issue. FOG will clone almost any disk feed to it.

Your step ‘A’ and ‘B’ will work and is typical. If you go this route then you would typically put the windows box in ‘audit mode’ as you first install this golden/mother image. This step isn’t absolutely needed, but a good idea.

Now to answer the question before ‘C’, you typically will use the windows sysprep process in coordination with an unattend.xml answer file, to answer the Windows OOBE questions that are presented during the Windows Setup process. If setup properly here you have created the Windows Lite Touch deployment method. Make sure you use sysprep and the command line option to power off the computer after sysprep is done. Now the computer is ready for step ‘C’ in your outline.

With that (above) your outline will work.

A few additional comments (tips) with this process.

1. Create your golden/mother image on a VM so that you can use the VM snapshot tools in case you make a mistake, so you can revert the image to the last snapshot. If you don’t and make a mistake you will have to wipe the mother image and start over. I did this route until I got tired of rebuilding the mother image each time I messed something up.
2. The bold text words above are key words to search for in regards to windows imaging. They should lead you to the answer you seek.
3. A good reference site is DeploymentResearch https://www.deploymentresearch.com/ It helped me out many years ago when I was first developing a golden image and trying to make windows do something I wanted.

@DBCountMan I’m going to repeat what I’ve previously said a bit differently.

This error is typically because the certificate in iPXE (if it exists) is different than the certificate on the server. This has to do with the https protocol.

The booting process is such.
PXE ROM: DHCP to collect pxe boot info over udp port 67
PXE ROM: TFTP download of iPXE boot loader udp port 69
iPXE: DHCP to collect pxe boot info so iPXE knows where to find the FOG server udp port 67
iPXE: TFTP Download of default.ipxe udp port 69
iPXE: default.ipxe script chain loads https://...boot.php over port 443. This is the first interaction of iPXE and the Apache web server.

So the question is, did the certificate in Apache change the day before yesterday for some reason, or did possibly ipxe.efi/snp.efi change two days ago? Something has changed in your environment.

@Almeida I haven’t used the tarball method in about 6 years, it still should contain the scripts needed to create an updated image. Go into where you extracted the tar archive and then follow the path in the tutorial to rebuild ipxe. You may need to manually move the compiled files to the /tftpboot directory.

@DBCountMan I’m going to guess that you enabled https on your server not using the fog installer. The permission denied message usually comes from the ipxe client not having the certificate that matches what apache server has so it fails to boot. When you use the FOG installer to create the https confiugration it should recompile the ipxe programs with the certificate.

@User_wds So I have to question if sysprep is working correctly because it should prepare the system for cloning and resetting of SSID.

This is the command I use to sysprep my image.
c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xml

The unattend.xml file must be in the Panther directory and it should contain all of the settings you need to lite touch your image during automated imaging process.

Understand your issue is not a FOG imaging issue but a windows imaging preparation issue.

@Almeida If you want to stay on version 1.5.9 then this is the process to update iPXE: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1692712872527

If you upgrade to 1.5.10 that will update iPXE, but maybe not to the very latest version. The above is still the process to get the newest version of iPXE.

@hancocza Its a bit complicated, but the short answer is that the inits will need to be updated to support NFSv4 then its needs to be paired with the current kernel. You will have this issue with usb booting or booting via PXE. The default inits don’t support nfsv4. The answer is they can be fixed.

@Developers can we enable the inits to be compiled with NFSv4 support but not update the scripts to include NFSv4 support. This way the FOG Admin can just unpack, add the settings and repack the inits because everything would be already compiled in. Or simply include my hack below to enable a kernel variable to enable nfsv4 and only have one master inits package.

@OutlastTrace The easiest way is via a dedicated disk. As Sebastian mentioned that iSCSI disk will be a block device to the FOG server so it can be shared. Resharing an NFS share is akin to mounting a remote share on a windows server as the w: drive then trying to share that to a third computer.

You can try to configure your truenas device as a fog storage node. We’ve done that with other nas device such as readynas and synology. The truenas device needs to support NFS and tfp services.

Synology nas as fog storage node:
https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Make windows 2012 as a fog storage node (proof of concept only) https://forums.fogproject.org/topic/10097/setting-up-a-windows-2012-server-as-a-fog-storage-node

The thing you have to remember about FOG is that the FOS Linux OS (engine that clone’s hard drive) uses the “root” user account to copy files. So if your nfs share has squashroot attribute then the “FOS Linux root user” won’t be able to mount the nfs share on truenas. Look over both tutorials then you should have enough info to configure truenas as a FOG storage node if you want to go down that path.

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