FOG Post install script for Win Driver injection
-
Hey George, hope all is good. So I’ve taken a break from this as I got busy with my job, so I’m almost there with this.
I copied and pasted the fog driver script and also ran a debug to confirm on the Lenovo laptop, it’s dmidecode -s system-version. Now my question is that for example, the version name for the machine is Lenovo T570 W10DG ( a zero by the way, not an o) how am I supposed to load the drivers? I have the structure as /images/Drivers/$machine/$osn/$arch, so /images/Drivers/Lenovo T570 W10DG/win7/x64 and I downloaded the drivers for sccm for example and let them in their folder structure, ex; network, display, etc… with all the files in it.My assumption was that fog will look throughout the subfolders under x64 for the correct drivers, or am I wrong? I then decided to take all of the inf drivers from the subfolder an past them in the x64 folder, but I still couldn’t get the drivers to install. Please look at the fog.driver file:
#!/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 linewith 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/$osn/$arch”if [ -d $remotedriverpath ]; then
[[ ! -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/x86rsync -aqz “$remotedriverpath” “$clientdriverpath” >/dev/null 2>&1
[[ ! $? -eq 0 ]] && handleError “Failed to download driver information for [$machine/$osn/$arch]”#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 locationregfile=“/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 :-)”fi
-
@george1421 [0_1512049987850_fog sample.pdf](Uploading 100%)
I did a command in the Fog OS called uname -m which gave me the architecture of x86_64. Now I thought
under the architecture on the fog server, I’d call the folder _x86_64 instead of x64. Is that not correct? I was fighting with this yesterday, but working at it now, will post once I have an update
. Please tell me if I have this correct, attached the pic. -
@jamaal The script assumes $arch in the path, which are defined as either x86 or x64.
x86_64 means x64
So for it to work, change the path to x64
-
@jamaal @Quazz is spot on. I know its hard to see, but the very last post in this tread actually shows you the expected disk structure: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/2
I’m working on a slighly better formatted version of this tutorial here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
Its not complete yet. The intent is to focus on what we’ve learned since 2016 and to focus a bit more on Win10 since that is the focus of the windows community now.
-
Thank you both. George, I know you said you’re still working on the driver injection-2017, but I’m testing it out right now as I’m trying to understand more about Linux commands to put under my belt, you know. Quazz/George,
in the fog.copydrivers, I put in where it says && arch= and arch= I put x64 and removed where it had 86. -
@jamaal Correct. If you follow my instructions, you should not have to modify any of the code to make it work as long as the drivers you have on the disk are in the format outlined by the tutorial.
-
@jamaal said in FOG Post install script for Win Driver injection:
I did a command in the Fog OS called uname -m which gave me the architecture of x86_64. Now I thought
The issue here is you have 2 operating systems in the mix.
- FOS which is a x64 bit OS.
- The OS on the target Operating System.
FOG / FOS is a 64 bit OS. But you could be deploying a 32 bit OS. So knowing what Arch FOS is will not ensure you deliver the proper drivers required by the target OS.
-
George, ok, thanks for explaining that to me. Now I understand why I saw _x86_64 and I changed the
folder in the osn back to x64. I guess where I’m lost is for example, I installed the Lenovo sccm drivers for a T570 laptop, right? then in each folder, I took any inf’s I can find and put it in the x64 folder. The structure I followed on your other pages and in the file is /images/Drivers/ThinkPad T570 W10DG/Windows 7/x64.I did Windows 7 because when I ran the fog debug, it came out osname=Windows 7. Now my question is in the fog.drivers script for example, do I change osn to osname=Windows 7? I know I tried that yesterday and it didn’t work.
When I changed the folder back to x64, during driver deployment, it goes quickly and says done instead of failed, which is good, but the drivers never make it to the T570…Not sure what I’m doing wrong.
-
@jamaal You shouldn’t (have to) alter the script.
osname is not the same as osid, the script uses osid.
The folder name for windows 7 should be win7 as it mentions in a comment in the script.
#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 -
@jamaal You have to remember the script was designed to work directly with the Dell CAB file format. I understand you are working with lenovo, but as long as you have inf file format you can adapt it easily.
osid vs osname. In the case of FOG it knows internal osid == a certain operating system. So instead of requiring the FOG IT admin to create directories based on an integer number to represent windows 7 or windows 10, I created a map so when osid == 5 that mapped to a directory path of win7 and osid == 9 would be win10 and so on. That way when you looked at the directory path you would know the win7 drivers go into the win7 directory and not the “5” directory. That is the logic of the osid to osn name matching.
-
Ok, thanks for the explaination George, appreciate your help.
-
@george1421 Why do you have lines 7-12 REMed out? I know very very very little bash so this is like looking at french for me.
-
@agray said in FOG Post install script for Win Driver injection:
@george1421 Why do you have lines 7-12 REMed out? I know very very very little bash so this is like looking at french for me.
In which script?
-
@george1421 fog.ad-the 3rd post
I’m not getting anything of this either. Looking at the thread here, and here (https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed) the scripts are different. What is right? What do you name everything/make the file type? -
@agray Ok you can ignore that section. It is in there to remove the unattend.xml file if its found in the setup directory. There should be only one unattend.xml file and it should be in c:\windows\panther directory.
What the fog.ad script does, it dynamically update the unattend.xml file with fog run time parameters. If you are not using an unattend.xml file or using the FOG client to connect the computer to AD and give it its name then you don’t need the fog.ad script at all.
If you look at the fog.postdownload script in this section
debugPause # . ${postdownpath}fog.log . ${postdownpath}fog.drivers # . ${postdownpath}fog.ad umount /ntfsYou will see that the call to those scripts are commented out. The only script that is required is fog.drivers the others provide functionality beyond driver injection.
As for the 2017 ed why are they different? Because we’ve learned things since this thread was published. I would look at the 2017 version if you are doing a new install. This thread gives the background behind why the 2017 is the way it is.
-
@george1421 From what I’m getting from all the threads, the unattend.xml file is required with win10 now. Is that no longer the case?
If it is, is that required to be edited in the master image before cloned?
Later in your 2017 ed thread you gave an update on the 1703+ Win, saying “add the following lines to your setupcomplete.cmd batch file.” That batch file already created, if not, where can i find code for it, or it that it in the code box? -
@agray The unattend.xml file is required if you want an unattended windows setup. You can use an online unattend.xml generator to create this file: http://www.windowsafg.com/ or craft one by hand with your site specific configuration.
The setupcomplete.cmd file is run by windows setup at the end of the OOBE process and just before the first windows logon is displayed. You place batch commands in there to be executed before the user’s first login. Google “setupcomplete.cmd” to find out its location and structure.
-
@george1421 Thank you! all is appreciated! I’m sorry for the bombardment of questions.
-
Hello,
Thanks a lot for all this stuff ! We used it since year start (HP/Dell, a dozen of differents models, 300 computers). We made some minor update on this script, if it can be reused :
# lowercase machine name and remove all spaces machine=$(echo $machine | tr A-Z a-z | tr -d ' ')So, our drivers directory looks like :
/images/drivers ├── forAll ├── hpelitedesk800g3twr ├── hpz230towerworkstation ├── optiplex7040 ├── optiplex7050 ├── optiplex7060 ├── optiplex9010 ├── optiplex9020 ├── optiplex9030aioAnother one concern the drivers download (unicast/NFS) by each client. By default, all unicast rsync start after the last multicast session. To make «subgroups» of rsync based on last IP number:
dots "Calculate IP (wait4sync)" MY_IP=$(ip route get 9.9.9.9 | awk '{print $7}') IP_LAST=$(echo ${MY_IP} | cut -f 4 -d '.') # IP OK ? if ! [[ ${IP_LAST} =~ ^[0-9]{1,3}$ ]] then IP_LAST=4 echo -n " bad IP..., use ${IP_LAST}," fi # Want each to wait ((IP_LAST % 5) ) * 3mn ## w.x.y.zz0|5|10|... => no wait ## w.x.y.zz1|6|11|... => wait 3mn ## w.x.y.zz2|7|12|... => wait 6mn WAIT=$((${IP_LAST} % 5 * 3))m echo " IP: ${MY_IP} => wait ${WAIT}" sleep ${WAIT} dots "Preparing Drivers" ...the last one concern the «forAll» directory, used for all common drivers like «pci simplified communication»:
remotecommondriverpath="/images/drivers/forAll" [[ ! -d "${clientdriverpath}" ]] && mkdir -p "${clientdriverpath}" >/dev/null 2>&1 dots "Common drivers In Progress" rsync -aq "$remotecommondriverpath" "$clientdriverpath" >/dev/null 2>&1 [[ ! $? -eq 0 ]] && handleWarning "Failed to download common drivers" echo "Finish" -
I hate to admit it took me a full day to realize there should be no space in the directory structure for the driver folders when I (poorly) read George’s instructions in the 2017 thread (lmao)
I also have a question that is related to the driver injection concept, but it is after the post download scripts.
For one of the machine types, the .cab comes with an unknown amount unsigned driver for some stupid reason. This complicates things because a prompt to “install the unverified driver(s)” during the setupcomplete.cmd. I can’t find a method to force/silently say yes to this with pnputil.
Most fixes involve an extra reboot to turn off driver integrity checks. I am trying a really roundabout method:
Setupcomplete.cmd
BCDEDIT /set nointegritychecks ON shutdown -t 0 -rThen, a script that lives in the startup folder found at C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup does the following, then deletes itself after it runs once.
pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install rmdir /Q /S C:\drivers BCDEDIT /set nointegritychecks OFF (goto) 2>nul & del "%~f0"Finally, I have a scheduled task built into the image that takes care of the commands usually in the typical setupcomplete.cmd, then deletes itself as well. The reboot should theoretically take care of the client service config and turning the integrity check back on.
sc config FOGService start= delayed-auto shutdown -t 0 -rI got to the point of being ready to test this yesterday, but the workday ended. I will test in a few hours when I am in. I am open to suggestions of how to make this less clunky (if it even works).
