@PhilienTaylor I’m not sure what your question is here. Your end goal is not clear based on what you have posted.

1. FOG doesn’t support imaging over Torrent.
2. FOG doesn’t support Secure boot. There is a tutorial on how you can create your own keys and then sign the boot files. This will require you to upload the certificates into each hardware. Or to go to microsoft and go through the process to get microsoft signed signing keys for what you want to boot on the target hardware.
3. FOG doesn’t have any utlity for hypervisor environments. The FOG server can run as a vm client, but FOG has no relationship with virtualization.

Paragon Hard Disk Manager

Information kindly contributed by @Wolfbane8653

Configuration currently works for UEFI only. It appears the wim file is missing bootmgr.exe for the BIOS booting systems

It is highly recommended to use this on a machine that has 4GB+ RAM.

First we’ll create the required directories:

mkdir -p /var/www/fog/Tools/{iso folder name}
chmod -R 777 /var/www/fog/Tools/{iso folder name}

Now we’ll mount the WinPE iso over the loop directory. Then we’ll copy the contents of the DVD to the directory we built above.

mkdir -p /mnt/loop
mount -o loop /{full path where you have the iso stored}/{iso file} /mnt/loop

We are going to copy to /var/www/fog/Tools so we can use the http protocal already setup for fog management.

cp /mnt/loop/bootmgr /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/boot/bcd /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/boot/boot.sdi /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/sources/boot.wim /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/efi /var/www/fog/Tools/{iso folder name}

umount /mnt/loop

Download and install the latest wimboot kernel and extract it from the zip file.

• https://github.com/ipxe/wimboot/blob/master/wimboot
  The issue was discussed in this post: https://forums.fogproject.org/post/144293
  We will use tftp protocal for this file in the fog menu.

cd /tmp
wget http://git.ipxe.org/releases/wimboot/wimboot-latest.zip
unzip wimboot-latest.zip

Copy the wimboot file from the archive directory to root of the os directory (we’ll need this for every windows boot media, so we’ll place it in a common spot).

mkdir -p /tftpboot/os
cp ./wimboot-2.6.0-signed/wimboot /tftpboot/os
chmod -R 777 tftpboot/os

The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields

Menu Item: os.{iso file name}
Description: {iso file you would like to boot from}
Parameters:
set tftp-path tftp://${fog-ip}
set http-path http://${fog-ip}/fog/Tools/HD_Manager
kernel ${tftp-path}/os/wimboot gui
imgfetch --name bootmgr ${http-path}/bootmgr bootmgr
imgfetch --name bootx64.efi ${http-path}/efi/boot/en_us/bootx64.efi bootx64.efi
imgfetch --name BCD ${http-path}/bcd BCD
imgfetch --name boot.sdi ${http-path}/boot.sdi boot.sdi
imgfetch --name boot.wim ${http-path}/boot.wim boot.wim
boot || goto MENU

That’s it, just pxe boot your target system and pick os.{iso file name} from the FOG iPXE boot menu.

@TectonicLeader Very good you are making progress. On the plus side dnsmasq and pxe booting is working perfectly.

I have to ask you did you change the IP address of the fog server since fog was installed. The default.ipxe file has a hard coded IP address in it. Your picture shows it picked up default.ipxe from .3, but then default.ipxe called a .2 IP address. If you did change the IP address of the fog server after the install you can fix the configuration by hand. I was sure I had a tutorial on this, but I can’t seem to find it right now.

1. In the FOG Web UI goto FOG Configuration->FOG Settings and press the expand all button. Search for the old IP address and replace it with the current IP address.
2. Still in the FOG Web UI goto Storage Management and pick the default node (it should be the master node). Change the IP address in there to the proper one.
3. Log into the fog server’s linux console, and switch user to the root user so you can edit a hidden file (if your fog server has a linux desktop you can use gedit from the linux desktop too). Edit a hidden file /opt/fog/.fogsettings note the dot at the beginning of a file makes it hidden in the linux world. Correct the IP address listed in the config file.
4. Lastly rerun the fog installer to fix all of the other bits where the IP address is hard coded.
5. Inspect the content of the /tftpboot/default.ipxe file to ensure the IP address has been corrected. (this is the point where your error exists).
6. If everything looks good, try pxe booting again.

On a side note, pxe booting from net3 might be a problem in some of the fog code (not specifically this issue). Typically the fog code only looks for the first two network interfaces to boot. But since you got as far as loading default.ipxe using net3 might be OK.

@TectonicLeader Many soho routers will point to themselves as the boot server, even if they have the facilities to set dhcp option 66 and 67.

If you have no option other than to use your netgear router as your dhcp server, then I recommend you install dnsmasq onto your fog server. It takes about 10 minutes to do and will solve your soho router issue. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@tlehrian Ok so you get a BSOD with windows and under linux you get a kernel panic (same but different). So that points to a hardware issue with this computer.

I would swap memory with a known good computer, even if the mem test comes back OK. By moving parts hopefully the problem will move with the hardware.

Move other pcie attached devices like GPUs (if external) or other add in riser cards.

Now that you updated the bios, go in and reset the firmware settings back to factory defaults. In case there was a firmware setting change with the new firmware that corrects a known issue.

Sorry I can only give random ideas, but since this seems to be a hardware issues I can only make logical guesses here.

@george1421 I did find this reference:

invalid opcode: 0000 [#1] PREEMPT SMP PTI

PTI(Page Table Isolation) is a Spectre/Meltdown correction at the bios and kernel level. Make sure they both are up to date.

ref: https://www.reddit.com/r/linuxquestions/comments/ajhw7e/what_can_cause_invalid_opcode_0000_1_preempt_smp/

So lets start with update the firmware.

@tlehrian It is surely a hardware issue. The error message is not detailed enough to point at one thing unfortunately.

So lets start with the basics:
What I can glean from the error message is that this computer is using firmware version 1.01. Firmware 01.08.08 Rev.A was released on 21-Nov-23. I would start by updating the firmware.

If that doesn’t solve it then, swap memory with the working computer.

If that doesn’t solve it then, remove all non-essential hardware cards.

If that doesn’t solve it then download the 5.15.x version of the linux kernel for FOG. Edit: I see now that you were at 5.15 and then upgraded. So this isn’t the issue.

@bkgoodman This can be set from the fog web ui. FOG has a concept of storage nodes and master nodes. Only master nodes can collect images, you can deploy images from both master nodes and storage nodes. Where storage nodes are deploy only.

While the following deals with synology nas devices the same info can reference other NFS aware devices. Your target system needs both nfs AND ftp enabled to be able to function as a FOG storage node.

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

@bkgoodman said in NFS Config:

Is there a way I can configure out Fog (iPXE) clients to use our NFS server directly - instead of trying to mount image stores from the Fog server, itself?

There is a way, but if this is an active NFS server, using FOG imaging would make that nfs server insecure. The FOS engine, the software that runs on the target computer is a customized linux OS. The image capture process runs as the root user, so your nfs share would need to allow root access to the nfs volume. Typically NFS is configured to squash root access to the nfs share for security reasons.

If you really want to do this you can undo the security to allow root’s access. In our tutorial section we have guidance on how to setup a synology nas as a FOG capture server, so its possible to do, but it is an unsupported configuration by the devs so YMMV. The best solution is to capture to the fog server as the devs intended. But since its opensource, if you have the skills, then almost anything is possible.

@sega I think what Tom is referring to is something like this tutorial: https://forums.fogproject.org/topic/15888/imaging-with-fog-and-secure-boot-poc

Also like Tom said the FOG Project doesn’t sign either iPXE or the FOS Linux kernel that is beyond the scope of the FOG Project. So if you must have secure boot enabled then you must do something like in the above tutorial, create your own private certificates and upload them to the uefi firmware, then sign ipxe.efi, snp.efi, snponly.efi and bzImage with your custom certificate. Then a computer with secure boot enabled will “trust” the FOG imaging process. Without the FOG Project boot files being singed, your computer will reject them and not boot.

@Bristow-0 That IS very strange that going to the older kernel solved the issue. I’m glad you have it worked out, but maybe the devs need to look into the 6.x kernel a bit more. I can understand that there was a big jump in the kernel code with the 6.x release.

@zguo Here is an unattend.xml file that I used back with windows 7 and later with windows 10. I have to be clear I don’t do as much imaging as I did back in 2022, so I don’t know if this unattend.xml file is still valid. It should be, but start with it and see where it takes you. https://forums.fogproject.org/post/87392

Staring with a proper unattend.xml file is the key to getting a good target deployment. You will want to use this command when you call sysprep. c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xm

Sysprep will still remove something out of your target image. But you can put most back on a deployment by using the unattend.xml file to create user accounts, connected to AD, and name the system as well as changing the local. If the option is not avaialble in the unattend.xml file, there is a batch file that gets called at the end of winsetup called setupcomplete.cmd you can put commands there to create users or install software that must be installed after imaging is complete, or use the first run section of the unattend.xml file with the auto login option for the first time windows boots, auto login to the desktop, run the first run section of the unattend.xml file then reboot.

@professorb24 Here is a wiki page on the fog client install and setup: https://docs.fogproject.org/en/latest/installation/client/install-fog-client/

The unattend.xml file is a windows thing. There are many resources on the internet that discusses its setup: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/update-windows-settings-and-scripts-create-your-own-answer-file-sxs?view=windows-11

The unattend.xml file is an auto answer file used by the windows setup program to preanswer all of the questions that the installer might ask during installation. There are even answer file generators on the internet that you can answer a few simple questions and it will create the answer file in the proper format like this one: https://www.windowsafg.com/win10x86_x64_uefi.html (I would be careful entering your actual license key on a internet web page, just edit the answer file when you get it by hand to include your key).

I also have some tutorials on fog post install scripts. This one has code snippets at the bottom of the post that discuss the unattend.xml file and how to potentially update the file with the script. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script The way the forum works read the first post and then scroll to the end to read the second and third posts in the series.

@professorb24 “The best” is kind of a subjective answer. The best way is the way that works the easiest for you and for the type of OS you are deploying.

If you are referring to a windows computer there are two methods.

1. Install the FOG Client software onto the golden image before image capture then enable the fog client renamer service.
2. Use a fog postinstall script to update your target computer’s unattend.xml file and then let the windows setup program rename the computer and connect it to AD.

Its generally the best practice to rename the computer before connecting it to AD.

@Tanguy The search list should be domain names you want to search through. The search list plus the host name should make the fqdn name of the computer. So short name resolution works.

@Tanguy If you have the search parameter set correctly in the resolv.conf file it should not matter what domain the target computer is vs the server. FOG only used the short name of the target (without domain reference). So if you can ping host where host is the name you registered the target computer in FOG with it should work. Also know that FOG doesn’t use the ping command to test if the target host is up or not, FOG tries to connect on port 445 to see if the host is up or not. So if you have a firewall between the fog server and target computer then the check will fail too.

@anvanster I’ve never seen this before. But lets try to see if refind is doing something strange.

The only thing that calls refind is when you are in uefi mode and you exit the FOG iPXE menu, not select an option because that calls fos linux. So the only time that refind is executed is when the fog ipxe menu exits.

So simply don’t let the fog ipxe menu exit using refind. You can (as a test) change the default exit manager for uefi to something like EXIT. That uses the uefi exit manager built into ipxe, or simply don’t use the fog menu after you image the computer.

After imaging the FOS Linux engine reboots, since its a real OS it doesn’t need to use refind, its never called directly from FOS Linux. In the context of FOG and exiting from the iPXE menu, its only used to locate the efi boot loader, unless someone has changed the configuration, it should never install itself into the efi partition.

So why are you getting that screen? Is secure boot enabled? If yes then FOS should not have run…

Does this happen on the source computer after capture or both source and target computers?

@zguo how did you install fog on this server? Did you use the tarball file or git and pulled from the repo? Either way there should be a fogproject folder, and I think bin/installfog.sh bash script to rerun the fog installer.

@zguo This issue is not related to dnsmasq. Something has zeroed out the byte size of that boot file. If you can the quickest way to fix this is to just rerun the FOG installer, it will recreate/fix file that were changed since its last run. I will not delete anything you added or changed in the UI. It will not touch dnsmasq either.

@zguo said in Cannot PXE boot on Client PCs:

I don’t know why DHCP packets don’t exist. My router is Sophos. Anything could block the DHCP packets?

I agree looking at the pcap there are no broadcast messages period. That is abnormal for a busy network. I can’t understand how your network is working, but obviously it is because you have clients picking up dhcp based addresses, right?

When we have situations where soho routers are used or people have routers managed or are unchangeable by a third party, we would typically install DNSMASQ on the FOG server to supply the pxe boot info. This normally solves the pxe boot issue, but your pxe booting clients are not even getting a dhcp address, that is before pxe booting in the startup process.

I have a tutorial for installing dnsmasq on your fog server in under 10 minutes, but my confidence level is at 40% that it will solve your issue. Once your pxe booting clients can get a dhcp address, dnsmasq should take care of sending the right boot file to your pxe booting computers. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

This may be a question for your networking admins, but are you running dhcp snooping on your network. This would be a feature of your network switches to block and or limit rouge dhcp servers on your network. I don’t know if that would restrict broadcast messages. You have something strange (something I haven’t seen before) going on in your environment.