@Brad39413 The FOG service should be started from your setupcomplete.cmd batch file. That way it doesn’t start doing its part before oobe is complete. Just update your software or delay the startup of the fog service until you are ready for it to do its thing.

@2000gtacoma FOG doesn’t have a concept of OUs built in. You could use one of the “extra” fields to define the unique part of the OU and then have a FOG post install script update the unattend.xml file with the right/proper OU path.

First we don’t use the fog client on the target computes on my campus. We use a custom post install script to determine what image was deployed as well as the current IP address of the target computer, from there we calculate what OU the computer belongs in. We update the unattend.xml file with the proper OU path and then let the unattend.xml file connect the computer to AD as well as define the right OU path.

At other times we had to deploy the computer to a specific container that didn’t have any GPOs defined. These GPOs broke deployment so we had to deploy the target computers to this clean OU, then we had a vbs script that would move the computer to the right OU after deployment. This vbs script was launched by the setupcomplete.cmd batch file.

The point of this is there may be a different way you can go about getting the job done, if FOG doesn’t support the feature directly.

@plegrand said in A power operation is pending:

However, the deployment task is still active/ongoing in the fog web interface, and when renaming the workstation, an error message is present in the fog client logs “HostnameChanger A power operation is pending, aborting module”.

I’ve seen this only happen when the imaging process actually doesn’t complete. The very last step in the imaging process is for the target computer to send an “all done” command to the FOG server to clear the task. This may be the root of your other issues because “imaging never really completed” according to the fog task manager.

So do you have any kind of post install script running at the end of deployment? Might that script cause the target computer to reboot before the “all done” message is sent?

@plegrand FOG can’t see bitlocker encrypted disks as being encrypted disks. It will blindly copy sector by sector to a new system. BUT a bitlocker protected system will care since the secuity token won’t match (because that is held in the TPM chip on the source computer) the TPM chip certificate. You must disable bitlocker on the mother image before cloning. If you need bitlocker enabled on the target system issue the command through the windows setupcomplete.cmd batch file or via a GPO policy.

@OutlastTrace said in FOG with TrueNAS on Proxmox Setup:

not sure what tfp is.

well that should have read ftp

@PRK08 The root cause of the issue is that you are currently running on an unsupported/old version of ubuntu [16.04] where some of the packages from the ubuntu repository are out of date or no longer supported. This is an issue with the ubuntu repo and not specifically with FOG.

@DBCountMan Now that you know the root of the problem, you can/could bring everything back together by syncing the certificates and ipxe boot files from your primary FOG server to your secondary FOG server. The issue as you found is two different certificates on your campus.

@seppim TBH Your results do not match your subject line, but…
Yes you discovered that bios computers need a different boot loader than uefi computers.

bios == undionly.kpxe
uefi == ipxe.efi or snponly.efi

If you have a windows or linux based dhcp server you can configure it to dynamically send out the right boot loader name based on the pxe booting computer.

And you are also correct to pxe boot into FOG secure boot needs to be disabled.

@greichelt said in PXE Boot - File not found:

dnsmasq is undionly,kpxe.0

You need to update dnsmasq to version 2.75 or later. Most modern linux OS already are past this version wit dnsmasq. I have a tutorial on compiling a supported version of dnsmasq if you need it. But my suspicion is that you have an old version of a linux OS that will cause you pain in the future.

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