@marsface Well done finding the solution, the regex expression might need to be updated in the tutorial then. It could have been FOS linux changes since the tutorial was written, or a different way that the dell firmware is reporting the model. Either way well done.

@tadziuuu I haven’t had a whole lot of time to look into this but it looks like this distro is debian based.

From the iso image it looks like the important files are

/live/vmlinuz, initrd.img, filesystem.squashfs

Just looking at your param field I would say the problem is probably in here

initrd=initrd.img config boottype=usb root=/dev/ram0 rw ramdisk_size=1300000

looking at the grub config file it says this:

	  linux /live/vmlinuz initrd=/live/initrd.img boot=live config live-media=removable nopersistence noprompt timezone=Etc/UTC splash noautologin module=Tails slab_nomerge slub_debug=FZ mce=0 vsyscall=none init_on_free=1 mds=full,nosmt page_alloc.shuffle=1 randomize_kstack_offset=on FSUUID=${rootuuid} quiet
	  initrd /live/initrd.img

So I would probably make the imgargs command look like this

imgargs vmlinuz initrd=initrd.img boot=live config live-media=removable fetch=http://${fog-ip}${path}/filesystem.squashfs nopersistence noprompt timezone=Etc/UTC splash noautologin module=Tails slab_nomerge slub_debug=FZ mce=0 vsyscall=none init_on_free=1 mds=full,nosmt page_alloc.shuffle=1 randomize_kstack_offset=on quiet

Lastly I would use the ISO image instead of the usb image for pxe booting. You might have better luck.

@marsface So outside of the autopilot thing, are you having any specific issues with FOG?

@NX06 Well researching this a bit more it seems like the if/then/else command is a bit more primitive than in my example.

Lets change this:

  if  iseq ${platform} efi {
    kernel memtest64.efi
    boot || goto MENU
  }
  else {
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
  }

Into this

goto mem-${platform}

:mem-efi
    kernel memtest64.efi
    boot || goto MENU
    goto mem-exit

:mem-pcbios
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
    goto mem-exit

:mem-exit
    goto MENU

If everything works correctly it should never get to the :mem-exit location tag.

As I said I never tested it only glued it.

@marsface said in Time for a New FOG Tutorial:

I recently got a FOG environment set up, but it was a huge pain. The documentation is all over the place, and often very outdated, but we got it done.

How much exactly did you pay for the rights to install and setup FOG?

Probably not the way I would go about asking for help from a forum driving support system. There is always room for those folks who would want to update or create the perfect FOG documentation.

My question is now, is there a new tutorial or method for using FOG with autopilot that will inject drivers without having to create a new golden image for each type of device, or need to include drivers in the golden image. I have the CAB files set up in the FOG server, so why do I need to put the drivers on the C drive as well?

As the person who wrote the tutorial on drive injection using FOG that was written before autopilot. And truth be told autopilot is a windows “thing” not a FOG thing. FOG only moves data blocks from here to there. I can tell you at the time I was deploying a single golden image to 14 different hardware platforms by injecting the drivers as I had laid out in the tutorial. The issue you have is that FOG is linux based and not MS Windows based (as with SCCM/WDS/MDT) so there are only a limited things FOG can do during deployment (move data blocks from here to there). FOG can’t step in and run windows applications. Once FOG imaging is done, its up to the target OS to complete the setup.

@NX06 I have not tried this update before so this will mostly be an educated guess to get you started. Note that you should not need to hack any FOG programming to make this newer version of memtest work.

Note1: Understand the version of memtest86 that ships with FOG only works with BIOS based computers. For UEFI computers you will need a uefi compatible kernel.

The FOG iPXE menu is created by the boot.php program. If you want to view the contents of the FOG iPXE menu just key in the following url into a brower. http://<fog_server_ip>/fog/service/ipxe/boot.php Looking at the programming code you will see this section that creates the menu on the screen.

item fog.local Boot from hard disk
>> item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
>> :fog.memtest
>> kernel memdisk initrd=memtest.bin iso raw
>> initrd memtest.bin
>> boot || goto MENU

I’ve highlighted the section of the code that is most important to you with the >> symbols.

You see when you select the Run Memtest86+ menu item it runs the commands

kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin

So the Kernel loaded will be memdisk which will intern load and run memtest.bin.

Note2: When you update the FOG settings General Settings->MEMTEST KERNEL its changing the iso image that will be loaded by the bios program memdisk. This is why with your configuration is failing. You are trying to chain to a uefi program (memtest64.efi) from a bios program (saying it using simple words).

So how should you fix this? Simply by creating a new FOG iPXE menu to replace the FOG supplied Run Memtest86+ Your new FOG iPXE menu will be a bit smarter than the FOG supplied menu in that (if this works) when you pxe boot a bios based computer the legacy bios memtest will be used and when you pxe boot a uefi computer the uefi memtest will be used.

iPXE is actually a programming language that creates and runs the FOG iPXE menu. Knowing this will will try to create a script that will call the bios files for a bios computer and uefi files for a uefi based computer.

  if  iseq ${platform} efi {
    kernel memtest64.efi
    boot || goto MENU
  }
  else {
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
  }

Note3; I have not tested this to see if this script will work. I just glued bits of code together into a logical script.

We test to see if the pxe booting platform is uefi or bios. If its uefi then we load your new memtest64 uefi file and boot it. If its bios then we call the FOG supplied commands.

ref: https://ipxe.org/cfg/platform

Now you have that script go into FOG Settings-> New iPXE menu.

Set the following fields
Menu Item: util.memtest64
Description: Run Memtest64+
Parameters:
if iseq ${platform} efi {
kernel memtest64.efi
boot || goto MENU
}
else {
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
}
Menu Show with: All Hosts

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Now pxe boot a uefi based computer and check to see if the new memtest program boots, then confirm that a bios based computer works.

@smazzola Well a question back to you is, what is your dhcp server? What is the manufacturer and model of the dhcp server. If its a linux or windows dhcp server then you are in luck. Here is a tutorial on how to create a dynamic dhcp server that will send the proper boot file based on the pxe booting computer. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

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