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

@atlas When it comes to opensource, the only wrong answer is one that doesn’t work. Well done!

Another hackish way would be to instead of changing the programming, you could enter a fake/but valid entry in the /etc/hosts table to point the dns entry to your internal server. This way you can use fog native code when version next comes out. But again if it worked for you it was the right answer.

@zguo said in Cannot PXE boot on Client PCs:

Not sure why it shows 172.20.4.1. I guess maybe because the client PC cannot find the server, then it goes to the default gateway? Then back to the question, how can I let my client PC detect the server?

99% of the time, your dhcp server is not telling the pxe booting computer the right thing. And your dhcp server’s IP address is at .1

When you run wireshark are you running it as administrator AND are you picking the wired network interface to monitor. It should see multicast on any computer connected to the same subnet.

For wireshark, launch is as Administrator, then your wireshark startup screen should look like this before launching capture. If you don’t see any data or the ethernet port, then you did not run wiershark as admin. Make sure you enter a capture filter like this (1), and then select the network adapter where you see traffice (2)

@atlas You need to have internet access to install FOG. I have seen some people install 2 network adapters in the fog server, one on the business network and one on the isolated network. The nic on the business network is for management and (install time only) internet access. This keeps the isolated network isolated.

FWIW that wiki page you referenced is 10 years old and does not currently apply to a current version of FOG.

FWIW: You can manually download the inits and kernels from here: https://github.com/FOGProject/fos/releases/

@zguo Ok this is a good start. Look at the “server” ip address, that should be your FOG server’s IP address. I’m guessing its your router’s IP address. As I mentioned before most soho routers put themselves as the boot-server / next-server.

We have to be missing something here, because you should be able to see the dhcp process with both tcpdump and wireshark, because the pxe booting computer is now getting the info.

@nils98 Well that’s not great news. I really thought that I had it with including the intel rst driver. Would you mind sending me the messages log from booting this new kernel? Also make sure when you are in debug mode that you run uname -a and make sure the kernel version is right.

@nils98 Ok there have been a few things I gleaned by looking over everything in details.

The stock FOS linux kernel looks like its working because I see this in the messages file during boot. I do see all of the drives being detected.

Mar  1 15:46:40 fogclient kern.info kernel: md: Waiting for all devices to be available before autodetect
Mar  1 15:46:40 fogclient kern.info kernel: md: If you don't use raid, use raid=noautodetect
Mar  1 15:46:40 fogclient kern.info kernel: md: Autodetecting RAID arrays.
Mar  1 15:46:40 fogclient kern.info kernel: md: autorun ...
Mar  1 15:46:40 fogclient kern.info kernel: md: ... autorun DONE.

This tells me its scanning but not finding an existing array. It would be handy to have the live CD startup file to verify that is the case.

Intel VROC is the rebranded Intel Rapid Store Technology [RSTe]

ref: https://www.intel.com/content/www/us/en/download/19472/intel-rapid-storage-technology-enterprise-intel-rste-software-raid-driver-for-the-intel-server-board-m10jnp2sb.html

There is no setting for CONFIG_INTEL_RST in the current kernel configuration file: https://github.com/FOGProject/fos/blob/master/configs/kernelx64.config Its not clear if this is a problem or not, but just connecting the dots between VROC and RSTe: https://cateee.net/lkddb/web-lkddb/INTEL_RST.html I did enable it in the test kernel below

Test kernel based on linux kernel 6.6.18 (hint: newer kernel that is available via fog repo).
https://drive.google.com/file/d/12IOjoKmEwpCxumk9zF1vtQJt523t8Sps/view?usp=drive_link

To use this kernel copy it to /var/www/html/fog/service/ipxe directory and keep its existing name. This will not overwrite the FOG delivered kernel. Now go to the FOG Web UI and go to FOG Configuration->FOG Settings and hit the expand all button. Search for bzImage, replace bzImage name with bzImage-6.6.18-vroc2 then save the settings. Note this will make all of your computers that boot into fog load this new kernel. Understand this is untested and you can always put things back by just replacing bzImage-6.6.18-vroc2 with bzImage in the fog configuration.

Now pxe boot into a debug console on the target computer.

Do the normal routine to see if lsblk and cat /proc/mdstat and mdm --detailed-platform returns anything positive.

If the kernel doesn’t assemble the array correctly then we will have to try to see if we can manually assemble the array using mdadm tool.

I should say that we need to ensure the array already exists before we perform these test because if the array is defunct or not created we will not see it with the above tests.

@zguo Not seeing packets regarding port 67 or 68 is suspicious, but also follows what you see on the pxe booting client. So I see a connection.

One other comment is that many soho routers (ones you might find in your home), do not support pxe booting properly. They work perfect for dhcp but fail to send out the right boot file names and often define the router as the pxe boot server.

dhcp works by sending broadcast messages to all computers on the local subnet, so a computer running wireshark or tcpdump should record these packets. If you ran tcpdump on the fog server and it did not record any dhcp packets that means that something is blocking these broadcast messages from getting to your fog server. Understand at the moment your problem is your network infrastructure and not specifically with FOG.

I do have to say that if your fog server and pxe booting computer is on a different subnet than your dhcp server you will need to configure your router to send dhcp broadcast messages across the router because they are not enabled by default.

Yes on only the file name and not path with FOG (there is an exception if you have a x32 bit uefi computer but I don’t think that applies here). The tftp server program uses the tftpboot directory as the root directory. This keeps the tftp service program from being able to download random files from your fog server. So it does a change root to /tftpboot. That is probably more than you care about at the moment. But in this case having a full path or not isn’t your current issue, getting the client and fog server to see the dhcp DISCOVER request is the first step.

@zguo in your screen shot you have listed the full path to the boot file, that should only be the boot file name in reference to the /tftpboot directory which for tftp is the root directory for tftp.

I think you have something missing in your setup. You can use the FOG server or a witness (third computer) with wireshark installed to monitor the communications. If you use wireshark you can use a capture filter of port 67 or port 68 Or follow the guide here to use the fog server to monitor the dhcp/pxeboot process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue then load the output file into wireshark.

So what you are looking for is the DORA process (DISCOVER, OFFER, REQUEST, ACK).

So the pxe booting computer will send out a discover packet (please configure me)
The dhcp server will respond with an OFFER packet that should contain the next-server and boot-file fields as well as dhcp options 66 and 67 which will align with the next-server and boot-file fields. My guess is that there is something wrong with OFFER packet or your dhcp server.

@zguo Just to be clear, what device is your dhcp server? Is it the fog server or something else?

At this point FOG isn’t involved if FOG isn’t your dhcp server. The error message is telling you that the dhcp server isn’t answering your computer.