Ok I now have my test setup on a Virtualbox host with all of the same settings I was using on the physical machine and this time the update to trunk has no problems at all. I am able to PXE boot using my test machine.

It was not my intention to suggest that I will not be using Trunk or attempting to update to the latest and greatest. During this “test” I realized i could improve my methods a little. In the future I will be sure to report problems with my tests and try to work through them with the experts rather than just starting over off the bat.

I am going to test the functionality of my original posted question and I will report back.

OK that makes sense. This got me going for driver deployment. Thank you for your help!

@Tom-Elliott Hey that did the trick. Drivers copied as expected now. Thank you!

Is there a repository somewhere I can find updated post download scripts or did I just not find the correct forum post?

@Tom-Elliott Here is the script. I modified the original script to attempt to remove the detection for OS version and x86 or x64 version. I am only going to be deploying Windows 11 64 bit.

I tested this on my Lenovo ThinkPad and the system is detecting the Lenovo correctly, but the script still errors out with "Failed to download driver information for [ThinkPad P14s Gen 4]

Its possible I have not setup the target path correctly in the script, still playing with this part.

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name) #pruduct is typo, just realized sorry :(
        ;;
    *)
        machine=$(dmidecode -s system-product-name) # Technically, we can remove the dell one as it's the "default"
        ;;
esac
[[ -z $machine ]] && return #assuming you want it to break if it is not lenovo or dell?
machine="${machine%"${machine##*[![:space:]]}"}" #Removes Trailing Spaces

#############################################
# Quick hack to find out if the installed OS image is a x86 or x64
#system64="/ntfs/Windows/SysWOW64/regedit.exe" # sloppy detect if 64bit or not
#[[ ! -f $system64 ]] && arch="x86" || arch="x64"

#############################################
#this section has been updated to bring the osn names in line
# with how the Dell CABs are defined
#case $osid in
#    5) osn="win7" ;;
#    6) osn="win8" ;;
#    7) osn="win8.1" ;;
#    9) osn="win10" ;;
#esac

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
clientdriverpath="/ntfs/Windows/DRV"
remotedriverpath="/images/drivers/$machine"

[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"

#there's 3 ways you could handle this,
#driver cab file, extracted driver files or both
#so on the server put extracted driver files to match below folder tree
#i.e. Model Latitude E5410, Windows 7 x86 image would be:
#/fog/Drivers/Latitude E5410/win7/x86

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine]"

#this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference)
# remember to make devicepath= match the path you've used locally
#also do not remove %SystemRoot%\inf
#and to add more locations just use ; in between each location

#regfile="/ntfs/Windows/System32/config/SOFTWARE"
#key="\Microsoft\Windows\CurrentVersion\DevicePath"
#devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
#reged -e "$regfile" &>/dev/null <<EOFREG
#ed $key
#$devpath
#q
#y
#EOFREG
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done"; # this just removes "In Progress and replaces it with done :-)"

@Tom-Elliott Well I feel silly. I am using a Windows workstation to set this all up. I corrected this and now the script appears to run.

Now this errors out stating it did not find drivers, which in this case is true, I’m testing this on a VM. This also seems to fail the task and imaging restarts when the machine reboots. Is there any way to tell the task to “continue on error”?

I have a test laptop on the bench that I will play with next week. Thanks for your help.

My org used FOG many years ago and is now tired of Microsoft Autopilot, so I am setting up a new FOG site for our org.

I have added the fog.drivers script from the tutorial site: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection

It looks like the script attempts to run, but indicates some errors preventing the script from running. (see screenshot). At first I was running a modified version of the script, attempting to simplify the machine identification, but I have since tried running the script as it came from the FOG tutorial and have the same result.

During installation I received the following error.

 Press [Enter] key when database is updated/installed.

 * Setting up storage..........................................OK
 * Setting up and starting DHCP Server.........................../lib/common/functions.sh: line 155: 2600:1010:b021:8a9f:e506:70ec:3154:c398: syntax error in expression (error token is ":1010:b021:8a9f:e506:70ec:3154:c398")
 * Setting up and starting TFTP and PXE Servers................OK

I then checked the status and sure enough DHCP had not started.

eud@FOGVM ~/fogtrunk/bin $ sudo service isc-dhcp-server status
isc-dhcp-server stop/waiting
eud@FOGVM ~/fogtrunk/bin $ sudo /etc/init.d/isc-dhcp-server start
dhcpd self-test failed. Please fix /etc/dhcp/dhcpd.conf.
The error was: 
Internet Systems Consortium DHCP Server 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
/etc/dhcp/dhcpd.conf line 35: expecting numeric value.
subnet  netmask 
         ^
Configuration file errors encountered -- exiting
eud@FOGVM ~/fogtrunk/bin $ 

Looks like i spoke too soon. Immediately after installing trunk everything was working fine. I then shutdown the VM to create a snapshot and rebooted and now the DHCP service will not start (automatically or manually).

This is what i get when trying to start the service.

eud@FOGVM ~/Desktop $ sudo /etc/init.d/isc-dhcp-server start
dhcpd self-test failed. 
Please fix /etc/dhcp/dhcpd.conf.

The error was: 
Internet Systems Consortium DHCP Server 4.2.4

Copyright 2004-2012 Internet Systems Consortium. 
All rights reserved.
 For info, please visit 

https://www.isc.org/software/dhcp/

/etc/dhcp/dhcpd.conf line 0: expecting a parameter or declaration
# Code
      ^
/etc/dhcp/dhcpd.conf line 17: no option space named PXE.
option PXE.mtftp-ip
           ^
/etc/dhcp/dhcpd.conf line 18: no option space named PXE.
option PXE.mtftp-cport
           ^
/etc/dhcp/dhcpd.conf line 19: no option space named PXE.
option PXE.mtftp-sport
           ^
/etc/dhcp/dhcpd.conf line 20: no option space named PXE.
option PXE.mtftp-tmout
           ^
/etc/dhcp/dhcpd.conf line 21: no option space named PXE.
option PXE.mtftp-delay
           ^
/etc/dhcp/dhcpd.conf line 40: semicolon expected.
	max-lease-time
         ^
/etc/dhcp/dhcpd.conf line 40: expecting a parameter or declaration
	max-lease-time 43200;
                             ^
Configuration file errors encountered -- exiting

FOG 1.2.0 Base install dhcpd.conf before trunk update

# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
use-host-decl-names on;

ddns-update-style interim;
ignore client-updates;
next-server 192.168.0.2;

subnet 192.168.0.0 netmask 255.255.255.0 {
        option subnet-mask              255.255.255.0;
        range dynamic-bootp 192.168.0.10 192.168.0.254;
        default-lease-time 21600;
        max-lease-time 43200;
#	option domain-name-servers      x.x.x.x;
#	option routers      x.x.x.x;
        filename "undionly.kpxe";

}

FOG 1.2.0 dhcpd.conf AFTER trunk update

# DHCP Server Configuration file
#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code
    5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer

option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 192.168.0.2;

# Specify subnet of ether device you do NOT want service. for systems with
# two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}

subnet 192.168.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	range dynamic-bootp 192.168.0.10 192.168.0.254;
	default-lease-time 21600
	max-lease-time 43200;
	#	option domain-name-servers      x.x.x.x;
	#	option routers      x.x.x.x;
	filename ;

}

Ok I now have my test setup on a Virtualbox host with all of the same settings I was using on the physical machine and this time the update to trunk has no problems at all. I am able to PXE boot using my test machine.

It was not my intention to suggest that I will not be using Trunk or attempting to update to the latest and greatest. During this “test” I realized i could improve my methods a little. In the future I will be sure to report problems with my tests and try to work through them with the experts rather than just starting over off the bat.

I am going to test the functionality of my original posted question and I will report back.

I am going to take the opportunity to setup the test server on a VM so I can make the rollback process easier. Once i get this setup I will try again and request help.

My production setup does not utilize the FOG DHCP service and i unfortunately do not have the resources to emulate prod so there wont be an issue related to DHCP on my production machine.

Well unfortunately when I loaded Trunk on my test setup it caused the fog DHCP server to stop functioning. I am going to start over on the test machine.