fog.drivers script will not run correctly in postdownloadscripts

[THEMCV]

@Tom-Elliott It was /Drivers/ and not /drivers/ but I changed to /drivers/. Same issue.

When I was looking over the code I misread and thought I saw a reference to /Drivers, so that’s on me.

[Quazz]

Am I going crazy or is this a simple issue with the fog server not mounting on the client?

mount: mounting 10.4.200.150:/fog/ on /fog failed: permission denied

Is the IP correct? Does the /fog folder exist?

[george1421]

@Quazz That is what I was just trying to reverse engineer. Where did the /fog directory come from? The only nfs share is /images.

The info that is missing here is that I the mount isn’t happening in this script but in the fog postdownload script from here: https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins/29

[edit] Side note, I found that my post install scripts fail when deploying to NVMe disks since the disk structure is different. I was looking at merging some of the code magic Tom created into my scripts too.

[THEMCV]

@Quazz The IP is correct. I must have gotten things turned around looking at the Auto install script on the FOG wiki.

So I need to make a fog directory in root like this, correct?

/fog/Drivers/Win7/OptiPlex 980/x64

[THEMCV]

@george1421 Just so I’m understanding, so the /fog directory should or should not exist? And if it does it is because of the script?

[Quazz]

@THEMCV The fog directory does not exist by default, it must be manually created, given correct permissions and an entry in /etc/exports needs to be made to export it as a nfs share so it can be mounted on clients.

mkdir /fog
chmod 777 /fog
chown fog:fog /fog
nano /etc/exports

add this line add the bottom:

/fog *(ro,sync,no_wdelay,subtree_check,insecure_locks,no_root_squash,insecure,fsid=2

then finally do the following command to export the directory:

exportfs -a

Check if it it is being exported with:

showmount --exports

Use sudo if necesary

Do note that you still need to create diretories and add drivers yourself.

[george1421]

@THEMCV OK, I understand you may be getting conflicting information here because we are coming at the same problem from different perspectives.

In my scripts I have the drivers (on the fog server) in /images/drivers …
That is what the scripts should be trying to mount. You can use /fog/drivers but you will need to setup an export in NFS to do that. Me being lazy I just used the /images share that was already there.

Looking at the script from Lee’s page this is the line in question

remotedriverpath="/images/drivers/$osn/$machine"

In this case its saying the drivers are in /images/drivers/… on the fog server. Where is /fog/drivers coming from?

[THEMCV]

@Quazz Okay, I completed this and it’s finished. showmount --exports does show /fog is working. And I added in the drivers that I had in the other location.

[THEMCV]

@george1421 I really am not sure. I don’t see anything in the script that refers to /fog except in the notation. I added the folder and copied the drivers into there from /images/drivers and am testing it now.

[Quazz]

@THEMCV Alright, well, I just realized none of this makes sense!

You are correct, the fog folder isn’t referenced anywhere.

I’m guessing the issue is REALLY in your /images/postdownloadscipts/fog.drivers

[THEMCV]

the /fog mount error has disappeared from the process now @Quazz , but the same “Failed to download driver information”

[Quazz]

@THEMCV Did you edit the fog.drivers you got from Tom?

Because the default version would mount /images/drivers

[Wayne Workman]

@THEMCV Remove the >/dev/null 2>&1 part from that command in the script, the one that looks like this:
rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

Then we will be able to see an actual error.

[THEMCV]

@Quazz I did not, no. I think I found the /fog reference though and might be our problem.

I think it might be my postdownload script itself.

#!/bin/sh
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
#. ${postdownpath}<SCRIPTNAME>

if [ $osid == "5" -o $osid == "6" -o $osid == "7" ]; then #only handling Win7/8/8.1
    clearScreen;
    mkdir /ntfs &>/dev/null
    ntfs-3g -o force,rw $part /ntfs #mount image (remember this is mounting partition [U][B]after[/B][/U] new image is deployed)
    mkdir /fog &>/dev/null
    mount -o nolock,proto=tcp $storageip:/fog/ /fog #this is a share created on server under /fog which contains drivers, software etc.. (just add /fog to exports but you could use existing location i.e. /images and if you do, do not ne$
    dots "Mounting Device";
    if [ "$?" = "0" ]; then
        echo "Done";
        . ${postdownpath}fog.drivers # run fog.drivers script
        umount /ntfs; # unmount when all is done :-)
    else
        echo "Failed To Mount Device";
        sleep 30;
    fi
fi

@Wayne-Workman I removed it and am testing it now.

[Quazz]

@THEMCV I do not recommend having commands in the postdownloadscripts, only calls to your scripts.

Move the relevant information into another file, imo.

[george1421]

@THEMCV Well, hell now I understand where the /fog is coming from. That is NOT in the original script I was referencing. https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins/29

[THEMCV]

@george1421 I feel like an idiot. I got them jumbled up in my early stages. Bleh. Okay, so should I take the script that is from your link and use it or do as @Quazz suggested and just include a call to it?

@Wayne-Workman: The message from removing the >/dev/null 2>&1

This rsync lacks old-style --compress due to its external zlib. Try --zz. Continuing without compression.

rsync:` write failed on "/ntfs/Windows/DRV/OptiPlex 980/x64/chipset/PP0H5-A00-00.WUB7/JasperFo.uno": No space left on device (20)
rsync error: error in file IO (code 11) at receiver.c(393) [reciever=3.1.2]

Which doesn’t make much sense as the device does have space.

[Quazz]

@THEMCV Either works, I personally prefer having a more modular approach because it makes it easier to expand and debug, but it’s mostly personal taste.

[THEMCV]

@Quazz I just have

. ${postdownpath}fog.drivers

Is that good?

[Quazz]

@THEMCV Yes, that’s fine.