Posts made by george1421

@GlaDio said in Boot in PXE uefi:

Server IP address is 192.168.42.233

Just confirming if this is indeed your fog server’s IP address??

If yes then would there be anything that might block the download of this file?

If this a new FOG install, where this is the first time you are trying to pxe boot “any” computer? If yes, please confirm that there are files in the /tftpboot directory? If there are no files in that directory then your installation has failed. The install has 3 steps. 1) install fog from the linux command shell. 2) When instructed go to the web ui and install/upgrade the database. 3) Return to the web ui and complete the installation. Some people miss this last step to go back to the linux console and complete the install. There are several fog specific packages that get installed at step 3.

@smazzola Specifically what do you have set in your dhcp server, dhcp option 67? For uefi based computers you need either snponly.efi or ipxe.efi. None of the bios based ipxe boot loaders will work, like undionly.kpxe. It must be a uefi boot loader.

@Krautkopf said in Batch-File from Snapin is just partially executed:

I think I’ll give it a try with your suggested solution of injecting the drivers with the post install script

In my tutorial I deliver the drivers during the post deployment scripts so the drivers are already on the the computer when it boots for the first time into windows and then after oobe completes I have the pnputil command run from the setupcomplete.cmd. The setupcomplete.cmd batch file is run as part of windows oobe and is executed as SYSTEM user.

Now in your case you have one snapin copy the files over and a second snapin install them. The fog client executes the snapins and the fog client runs as SYSTEM user. So in theory it should work.

Here are some random thoughts on the issue

One thing I do is use the start /wait "" <some_command> (so in this case the command would be start /wait "" pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install >>c:\drivers.bat hint: the 2 double quotes are needed to work around a quirk in the start program) to start a program and then wait for its execution before going on to the next step in the batch file. I’ve ran into situations where a batch file will spawn an application and then not wait before going to the next line in the batch file.

Its strange that you are not getting “anything” from the pnputil program. If you log into this computer and run this batch file does it work?

Is it possible that the path variable is not being used during a fog client snapin install where you need to provide the full path to the pnputil.exe program for it to be called.

Another check you might do in this batch file is verify a key or specific file exists in the drivers directory to confirm that the drivers are installed before this batch file runs, or at least log that it found the drivers.

Why not combine the driver copy and uncompressing with this script to install the pnputil command. By using the start /wait command you can ensure the execution is sequentially.

@Krautkopf said in Batch-File from Snapin is just partially executed:

pnputil.exe /add-driver “C:\Drivers*.inf” /subdirs /install

I see one issue that will cause a problem. Its your path where the drivers are located. So what you have is that pnputil will look in C:\ for any .inf files that match Drivers*.inf.

I assume you have the drivers in “c:\drivers” ? If that is the case you are missing a backslash in front of the start in your command.

i.e. pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install

The second part is that the log file can’t be created in the root of C drive, so I would change the path to c:\drivers\install.log or something like that. I should have posted that ppnputil couldn’t find any driver files. So its strange that the log is blank.

Just a side comment, copying over the drivers should be done as a post install script in case you need a driver to boot the system or communicate on the network. Snapins runs after windows is booted, but if the nic driver is missing the target computer will not connect to the network. This is just an opinion, if it works for you the way its configured then you have the right process that works, no need to change.

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