@anothersysadmin The stuck at “iPXE initializing…” is iPXE saying that its having a problem configuring the hardware. I can see this happening on really new hardware.

1. I would start out with ensuing the firmware is up to date on the target computer.
2. See if rebuilding/compiling iPXE with the latest release solves the issue. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Understand this is a problem between iPXE, uefi firmware, and the hardware. FWIW: iPXE is created by another opensource project.

@Alan-Lim Here is a wiki page that describes migration of FOG servers. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

In general you will copy over the raw image files in the /images directory, copy over any custom scripts in /images/dev/postinstall directory then export the database and then on the new FOG server import the database.

@mashina said in Generic questions about how to use FOG:

Our laboratory requires various images for different use cases, such as Windows 11 and Ubuntu 22.04. Could you please clarify the process for capturing multiple images? Do we install each operating system individually and then capture them into FOG?

FOG has several capture modes, single disk, single partition, multiple disks. In the host definition you can define to send the image to disk 1 or disk 2, but FOG is not really desined to be dynamic in the since you want to deploy windows to disk 1 and linux to disk 2. Now if you setup your golden computer with windows on disk 1 and linux on disk 2 then you would simply use the multiple disk capture model.

When a user selects a Linux image, we want FOG to automatically deploy it to the second disk without affecting the default Windows image on the first disk. Is there a specific configuration or setting for achieving this?

Basically answered that in the first question.

Our images contain user accounts that we need to retain, making Generalized Sysprep unsuitable for our needs. Does it matter if Sysprep is set to Specialized in this case? Any recommendations or best practices for our scenario?

The short answer is you should sysprep the image and Microsoft will do what Microsoft does. I suggest that any accounts that you need that get deleted by sysprep that you create them on the deployment OOBE/WinSetup side post deployment with FOG. You can use the setupcomplete.cmd batch file or create the user account in the unattend.xml file. Either way you can create user account and set default passwords.

I noticed the option to create a new menu item, but I’m unsure about configuring the parameters to correctly point to the desired image. Could you direct me to the documentation that covers the parameters and menu configuration in detail?

The creation of the ipxe menu really depends on what you are trying to accomplish. I have a tutorial on booting different types of OS installers that will give you a clue how to populate the iPXE menu builder: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@abdel The error message indicates that no pxe boot information is making it to the target computer. Please try to pxe boot with a physical computer. For this test you don’t need to do anything other than get to the fog ipxe menu. Make sure when you pxe boot a physical computer you know if its in bios or uefi mode, because the value entered in dhcp option 67 is specific to the pxe booting computer. For bios computers you need undionly.kpxe in option 67 and for uefi computers you will need ipxe.efi in dhcp option 67.

@mareta4977 On the windows 10 side its a bit trickier to make sure that full disk encryption is turned off. On the linux side don’t let the installer auto create the partitions. For the partitions don’t use LVM, flat partitions will resize correctly.

Also watch when you capture the image and make sure each/any partition is not being captured in “RAW” mode. The partclone screen will display the file system type, if it copies any partition in 'RAW" mode then the disk will not be resizable.

As a side note, I would develop your golden image using a virtual machine and snapshot should be used to quicky restore your golden image to a pre-fubar state if needed. Changing the disk structure is a bit severe so a VM won’t help in this case, but its something to think about.

@abdel Are you running this on virtual box? IF yes, do you have dhcp options 66 and 67 configured on your dhcp server?

On your network dhcp server you need to have dhcp option 66 configured as IP address of your fog server, and dhcp option 67 as undionly.kpxe (for bios based computers) or ipxe.efi (for uefi based computers). If you don’t have your dhcp server configured you will get the error message below.

@abdel said in Error no such file or directory:

I can’t boot the file it says no such file or directory

You need to provide a lot more info than what you give so far. We need to know when/where the message is displayed. The easiest way is to provide a clear picture of the error taken with a mobile phone or screen shot. The information around the error is just as important as the error message itself.

@mareta4977 My bet is that either you have windows disk encryption enabled or you have on your linux system LVM enabled. In both cases FOG can not compress or expand the disk for deployment so it uses direct copy mode.

@GlaDio said in Boot in PXE uefi:

I need to configure it on my dhcp server

Correct. DHCP option 67 needs to be updated for bios vs uefi. Some dhcp servers have the ability to adjust this value based on the target computer’s need. There are configurations for linux and windows dhcp servers, pfsense has this ability out of the box.

@GlaDio said in Boot in PXE uefi:

NBP filename: undionly.kpxe

This is your problem. The design of the computer’s firmware is different between bios and uefi. Because of this each firmware requires a different boot loader and technically operating system.

You are sending undionly.kpxe (bios boot loader) to a uefi system. It doesn’t know what to do with the file so it rejects it. For a uefi system you need to see the uefi boot loader of ipxe.efi or snponly.efi (its akin to undionly.kpxe). With a uefi boot loader that target computer will accept it as long as secure boot is disabled in the firmware.

If you have a mix of bios and uefi computers on your campus then you might need some configuration that support both uefi and bios pxe booing.

@jfernandz said in FOG and Secure Boot:

The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

You are correct I really missed the refind files. I will update that info too. While I had 1.6k viewers of the file not many people have returned comments. I have that turned off in the tutorial because it makes the multipart tutorial a bit messy because of the way the forum works.

I think the signing process (with sbsign) may be automated in a bash script

Towards the bottom of the document there is a bash script easter egg. I initially wrote the bash script then broke it up to explain what each part did. For those that never made it to the bottom of the post, they missed out on the bash script. I intentionally did it that way so people knew how it worked before they simply cut and pasted the script.

@jfernandz said in FOG and Secure Boot:

You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist

I can’t believe I wrote that article in 2021, man time goes by quickly. The dbx file is created for black listed certificates. It is kind of an optional for the vendors to include in the firmware. The idea is if a secure boot certificate gets compromised the vendor can add it to that database. So I can see if the database is empty on the target system then the file might not get created. I should add a note into the document explaining this, thank you for the catch here.

For reference my notes say that I referenced this document as I was writing my document: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC

Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Thank you I will fix that.

@jfernandz Looking at your video, can you confirm that 172.120.1.4 is your fog server?

From your post it looks like “time” solves the problem, because you can repeat the same steps after a few seconds and it works??

If this is the case, intuition is telling me spanning tree issue. One network switches using standard spanning tree it take about 27 seconds to start forwarding the data while the switch ports listens for a BPU packet. This timer starts every time the network port “winks”, and it will “wink” (go down and up quickly) as each kernel starts (ipxe firmware, ipxe.efi, and then bzImage. To test this idea, get a dumb/umanaged/cheap network switch, like one of those 5 port monoprice switches. These do not support (typically) spanning tree. Place this switch between the pxe booting computer and the building network switch. See if this fixes this refind issue. -OR- contact your network infrastructure team to verify that one of the fast spanning tree protocols are configured on the port (portfast, fast-STP, RSTP, MSTP, etc). At this point I don’t think your issue has anything to do with secureboot.

@hernani In domain moves you are better to stick to the Windows world for this action. You can use FOG to deploy vbs/ps/cmd file that changes the target computer’s affiliation. You will have less issues if you do this in the windows realm.

For one deployment I setup the computers where initially put in one Imaging OU that had no GPO policies that would break imaging. Then in the first run part of the unattend.xml file I ran a VBS script called move to OU to relocate the target computer to the proper OU. Now this was not moving to a different AD domain, just to a different OU.

I think there was a netdom command that we used at one time to join computers to domain (not by using fog). That utility had the ability to connect and disconnect a device from domains.

One other thing you need to keep in mind is make sure you have a local admin account on the target computer you can use if the domain move fails, otherwise your target system will be lost if the reconnect to the new domain fails.

@professorb24 The quick answer is YES.

The bit longer answer is around your deployment techniques.

Lets go with the driver aspect first. I have a few tutorials around this (pertaining to windows 10 and earlier but should work with windows 11 too since its built on the windows 10 kernel). While this is an older tutorial its still accurate and functional: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed Its just the unattend.xml section doesn’t work correctly now where there is a post that discusses using the pnputil.exe program called from the setupcomplete.cmd batch file.

For the applications and fonts, you can install them using FOG Snapins function to deploy those apps with FOG. Myself personally I would create a golden (mother) image and preload all of the apps that don’t use a GUID for identification (enterprise AV comes to mind) and preload them onto the golden image (using audit mode) prior to using sysprep and capturing the image with FOG. Then for one off or GUID based applications install them post deployment with FOG Snapins.

@oz-agoston said in Need help with new FOG server installation and setup (PXE, image creation):

Unfortunately our bosses wouldn’t want us to use the windows DHCP server for the FOG server to avoid possible network problems.

We have solutions you can use where you don’t or can’t update your primary dhcp server. You don’t necessarily need to setup an isolated network. Depending on your deployment your target computers may need access to AD during deployment, where an isolated network might cause a problem.

In cases where you can’t/don’t want to update your primary dhcp server you can install dnsmasq onto your fog server to provide pxe boot information only to the target computers. It takes about 10 minutes to install dnsmasq using this configuration: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

Now just be aware that dnsmasq (as well as dhcp) only works on local vlan/subnet because dnsmaq as well as dhcp uses broadcast messaging. So right there dnsmasq pxe boot information will be localized to the current subnet where the fog server is installed. If you want to pxe boot on another subnet where the FOG server is not, you will need to update your network’s router and add the FOG server’s IP address to the list of dhcp servers in the dhcp-helper/dhcp-relay service. This will allow dnsmasq to hear pxe booting from other subnets. One of the many advantages of dnsmasq running on the FOG server is that if the fog server is off-line no pxe boot information will be sent to the network.

@renewedharry While I can’t give you a solid answer with your issue, but someone else on the forums had an issue just recently with this software that you might be able to start from: https://forums.fogproject.org/topic/17124/i-can-t-boot-up-parted-magic-2023-08-22/2

For a mixed environment where you have bios and uefi computers, they take different bootloaders to successfully boot. Being on version 0.3 may be hurting your knowledge if FOG since SO MUCH has changed since that version was released. For bios/uefi coexistence you might want to review this wiki page. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@Cire3 said in Not a Fog problem, but solution ?:

Carbon X1 Gen 7 just returns to boot menu after Downloading NBP file

Check secure boot is off and if the proper boot loader is being sent to the target computer.

You might use a witness computer on same subnet as the pxe booting computer. Use a capture mask of port 67 or port 68 or display filter of bootp Start the capture, pxe boot to error and then stop the capture. You will see the DORA process (discover, offer, request, ack/nack). Look at the offer packet this is coming from the dhcp server to the target computer. Look to see if both the ethernet header (bootp part) has next-server of IP address of fog server and boot-file as the proper boot loader name. Now confirm that dhcp options 66 and 67 are set properly. Its up to the pxe boot firmware vendor to decide to use bootp fields or dhcp option fields to locate the boot information. If you grab the pcap I can look at it for you if you get lost or not sure.

@gabrielchun The error messages says (in my words) that the kernel (bzImage) doesn’t understand the virtual hard drive (init.xz)

The image name looks suspicious to me. bzImage4152 looks like one of the custom kernels I built. At least that has the same numbering format that I use. If that is true then that is linux kernel 4.15.2, which is very old. I might understand why it can’t connect to the virtual hard drive. Please upgrade your linux kernel to very 6.0 or later. You can do this from the fog ui under fog configuration->kernel update. Understand this is bzImage kernel not the fog server host OS kernel.

@oz-agoston I agree with Gabriel check your dhcp server(s) (if you have more than one) to ensure dhcp options 66 and 67 are being sent to the target computer. PXE booting will simply not work if these values are not set on your campus dhcp server.

The next questions is if you have a screening router between the subnets (client and fog server) that might be blocking tftp.

If you could supply the actual error message created by the target computer during a pxe boot that would help us identify where to look.