Drivers 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

[george1421]

What a symbolic link is (its similar to join in windows) it allows you to map one directory to another location.

so in the ln command you are saying to create a shortcut from that long path full of variables to the /nfs/Drivers… wait your link is wrong it should be to /tmp/mydrivers directory. You are trying to create a symbolic link to the target computer’s hard drive. What you will want to do after the link is established is to copy the content of /tmp/mydrivers to /ntfs/Drivers. Thus moving the drivers from the FOG server disk to the target computer disk.

[edit] your inserted picture is showing the link was created OK. Actually I had to use the link command to get around the devices having a space in the name (your welcome). Otherwise this script would have fallen down.

[adukes40]

@george1421
Ok so:

1. the ln command is the same as net use to windows. Except here it is ln -s <SP> <DP> where in windows it is net use x: \server\share<rest of path if needed>

2. Being mydrivers is a symbolic link, it doesn’t technically have a directory, just a location to point to.

3.the ls -la /tmp command shows the OptiPlex 790 having a space. Does this mean the folder on the server needs to have a space as well?

4. If the link is there, and pointing to the correct location, what is casuing this to not pull the files from the server to the ntfs mount.

[george1421]

@adukes40 not sure if I can explain this well, but

1. No the net use command is for connecting to network attached storage. This is different (at this point in the script) what is equivalent to the net use command nfsmount command
2. In the case of this script the symbolic link (directory) is a representation of the correct driver for this deployment.
3. No because you are copying the “contents” of that location and not the directory and its contents.
4. ??

You have to remember this script (when its tested) will execute from the perspective of the target computer. This script establishes a nfs mount back to the images share on the FOG server and it mounts the local windows partition. Then based on the model name it finds in smbios it creates a symbolic link from a known location to a location built based on the information its collected during execution. The last bit is to copy the files from the known location /tmp/mydrivers/* to the windows partition mounted under /nfs/Drivers. That is the general concept of the script. Of course there is some error checking along the way to ensure things are where they are suppose to be but that is the script in a nut shell.

[george1421]

since the /tmp/mydrivers link is created make sure you can list the contents of ls /ntfs/Drivers If both checkout then just issue the copy command manually cp -R /tmp/mydrivers/* /ntfs/Drivers That should copy the files to the windows drive.