Drivers script

[adukes40]

So I took Lee’s scripts and tried to make them work. I will post them here, can anyone tell me where it is going wrong.

Here is what I am doing with it. It is basically the script he posted, except a couple modifications.
The script to be called is fog.driverinstall and the path to the drivers on the fog server is /images/Drivers/Win7/<Model>/<arch>

Attached are the scripts. 1_1464786939362_fog.postdownload 0_1464786939361_fog.driverinstall

[george1421]

Not to distract you from your task, but here is a write up I wrote on how to set up something similar.
.
https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

[adukes40]

@george1421 did your postdownload look any different? There are some variations with your driverinstall that differs from his. I will piece this one together and see what I get.

Also Case is important correct? so instead of fixing my case with Win7 in the directory in FOG, I can just edit the win7 in your script to Win7 instead correct?

[george1421]

@adukes40 Case is important. But the paths are different in the way they are laid out. In my case its /image/Drivers/<model>/win7/arch where the drivers are grouped by model and then OS (the way they are packed in the Dell cabs). The path really is irrelevant as long as you have a consistent structure and it can be machine calculated.

Can you provide a link to Lee’s instructions for a comparison?

[adukes40]

@george1421 https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins/23

his Main post, and on page 2 you will see the driver script

[george1421]

@adukes40 Ah ok. I see bits of my script and from the wiki page where I started. https://wiki.fogproject.org/wiki/index.php?title=Auto_driver_Install Nothing wrong with that at all.

The results are the same, the path is a little different. Also for both my posted bits of script and from Lee’s script this will only work with Dell computers, If you use Lenovo or others the system name is located in a different element of SMBIOS. That is why in my script I pick up the manufacturers name so I can create a switch statement based on the manufacturers name to look in the other spots when required.

[adukes40]

@george1421 I just do not know where my disconnect is. I have a 790 I am testing this on. I picked that because I know Win7 does not have embedded nic drivers for it, so I know when it does not work. just lost on where its not working. It looks like it is mkdir Drivers, but isn’t copying the drivers over from the server. I do have all my files extracted from the Cabs. I looked in the registry and didn’t see where it updated the device path either. still only shows %systemroot%/inf

[adukes40]

@george1421 Sorry I am new with this scripting mess, but tell me if I am correct here:

this line"

machine=“${machine%”${machine##*[![:space:]]}“}”;

turns OptiPlex 780 into OptiPlex780 … doesn’t it

[george1421]

@adukes40 Yes this snippet machine="${machine%"${machine##*[![:space:]]}"}"; removes all of the spaces out of the name returned from smbios. I did that so I didn’t have to escape the embedded spaces in the name. (that one spun me around for a bit trying to make it work with the spaces, then I decided to just get rid of them and make my life easier).

Remember that CASE IS IMPORTANT. So your constructed path /images/Drivers/Win7/OptiPlex780/x64 has to match exactly what is found on the FOG server.

I also noted that you referenced two systems the 780 and 790, I assume that was just a type-o.

As for the registry setting, I can’t say. I updated my registry setting on the reference image before I captured it. So I know it is set right. I have that automated with MDT so I don’t forget every time I rebuild my reference image.

[adukes40]

@george1421 I am thinking that line of code is what was doing it, along with my misunderstanding of what it was doing. I have spaces in my naming structure on the fog servers. I commented it out to see if that works for me.

more than likely my lack of knowledge causing me issues. I am testing now.

And without looking, i think Lee’s scripts also had that line in there. So that makes sense why that didn’t work either.

[george1421]

@adukes40 I can tell you a way to debug this where you won’t make too many gray hairs.

Schedule a capture or deploy task (doesn’t matter since we are not going to do either), but select the debug option before you submit the task to a target computer. PXE boot that target computer and it should start the deploy task, but instead it will drop you to a command prompt. Once at the command prompt set root’s password with passwd to anything you want. And the last bit is to get the IP address of the target computer with ip addr show.

Now once you have that info go to a windows computer and open a putty session to that target computer. Login as root. Once that is done now you can type (i.e. copy and past) in the script into the command line, line by line. That will give you a chance to debug the script while you are perfecting your environment/driver deploy script.

[adukes40]

@george1421 I will try that. Also should the permissions be set to fog root or fog fog for the Drivers folder?

Currently looks like this:

[george1421]

@adukes40 Since you will never update them from the target computer (and as a good safety measure) as long as your drivers are world readable then you are fine. They can be owned by anyone.

While I mentioned this before I’ll say it again. Spaces in the model name drove me insane for a while until I decided to remove them completely. (hint: heed the warning).

[adukes40]

@george1421 i finding something odd:

[Wed Jun 01 root@fogclient ~]#
[Wed Jun 01 root@fogclient ~]# machine=dmidecode -s system-product-name;
[Wed Jun 01 root@fogclient ~]# ${machine}
-sh: OptiPlex: command not found

So with the tick marks at the start and end of the command it doesn’t seem to resolve the rest, so then i added " marks instead and i got this:

[Wed Jun 01 root@fogclient ~]# machine=“dmidecode -s system-product-name”
[Wed Jun 01 root@fogclient ~]# ${machine}
OptiPlex 790

then i tried to run the remove spaces and it didn’t appears to remove the space.

[Wed Jun 01 root@fogclient ~]# machine=“${machine%”${machine##*[![:space:]]}“}”;
[Wed Jun 01 root@fogclient ~]# ${machine}
OptiPlex 790
[Wed Jun 01 root@fogclient ~]#

More so, why would the tick marks you have in your scirpt cause this, but quotes provide the output. If for some reason the ticks are giving a partial name, maybe thats why it can’t find the drivers, because it doesn’t populate the ln command correctly. Not sure why I am having a hard time with this. does this make sense?

Furthermore, looking at your script and Lee’s, the tick marks are there, which seems to me they should work, but I have no clue why they are for me.

[george1421]

will on the dmidecod… the back ticks tell bash to take the output of the dmidecode command and set the variable machine to that value.

for your output you might want to echo ${machine} Since how you have it, bash thinks you want to run a command called OptiPlex with a single parameter of 790. Very useful in other situations, but for you not so much.

The space removal command is a bit of bash regular expression magic that will blow your mind if I try to explain it because of all of the short hand junk that it contains. It does work.

[adukes40]

@george1421

[Wed Jun 01 root@fogclient /tmp]# osdiskpart=“/dev/sda2”;
[Wed Jun 01 root@fogclient /tmp]# driverver=“Win7”
[Wed Jun 01 root@fogclient /tmp]# osdiskpart=“/dev/sda2”;
[Wed Jun 01 root@fogclient /tmp]# driverver=“Win7”
[Wed Jun 01 root@fogclient /tmp]# mkdir /ntfs 2>/dev/null
[Wed Jun 01 root@fogclient /tmp]# mount.ntfs-3g “${osdiskpart}” /ntfs 2>/tmp/mntfail
[Wed Jun 01 root@fogclient /tmp]# mkdir /ntfs/Drivers 2>/dev/null
[Wed Jun 01 root@fogclient /tmp]# mkdir /ntfs/Drivers/TEST 2>/dev/null
[Wed Jun 01 root@fogclient /tmp]# cd /ntfs/Drivers/
[Wed Jun 01 root@fogclient /ntfs/Drivers]# dir
TEST machine.txt
[Wed Jun 01 root@fogclient /ntfs/Drivers]# nano machine.txt
-sh: nano: command not found
[Wed Jun 01 root@fogclient /ntfs/Drivers]# vi machine.txt
[Wed Jun 01 root@fogclient /ntfs/Drivers]# vi machine.txt
[Wed Jun 01 root@fogclient /ntfs/Drivers]# rm -f /tmp/mydrivers;
[Wed Jun 01 root@fogclient /ntfs/Drivers]# ln -s “/images/Drivers/${driverver}/${machine}/${setarch}/” /tmp/mydrivers;
[Wed Jun 01 root@fogclient /ntfs/Drivers]# if [ -d “/tmp/mydrivers” ]

then
cp -r /tmp/mydrivers/* /ntfs/Drivers;
else
fi
-sh: syntax error near unexpected token `fi’

Everything seems to go smoothly until the bottom. I was able to cd into the ntfs mount, and create and new folder called TEST, and view the machine.txt. Ihave tried with a space in the model name. no space. Here is the file structure as well: (they all have spaces in them currently, but I am working with the 790)

[george1421]

@adukes40 OK it looks like where it failed was the directory test (you can’t type that in via command line). Manually check to see if /tmp/mydrivers directory exists. If it does then execute the cp command.

FWIW

if [ -d “/tmp/mydrivers”] check looks for a directory

if [ -f “/tmp/mydrivers”] check looks for a file named mydrivers in the /tmp directory

Both are conditional checks to make sure things exist in the filesystem.

[adukes40]

@george1421

Looks there, but says it’s not. And it shows up a different color. I don’t know if that is normal or not.

[george1421]

@adukes40 The different color reporesents a symbolic link. But in the code you posted there is no reference to creating this link. The command should be ln -S <sourcepath> <destination path> If you do a ls -la on that temp directory you can see the target of the link.

Stick with it, you are progressing nicely. And just think about how much you’ve learned today. Don’t get discouraged at the end of the process you WILL understand how this works.

[adukes40]

@george1421 hmm, ok I think the tmp/mydrivers is throwing me off.

When you say ln -s <source path> <Dest path> It registers to me to mean ln -s “/images/Drivers/${driverver}/${machine}/${setarch}/” /ntfs/Drivers;

Now does that mean the x86 folder get moved, or the contents WITHIN the x86 get moved. Does /tmp/mydrivers part need to be done, or can it copy straight from the server to the /ntfs/Drivers