Syntax Error for PostDownload Script to Install Drivers

[Mr. Taco]

Hey All!

Cannot figure out this issue, and hope all of you can help.

Background Information
I’m a newbie admin taking over for someone that implemented the FOG system for our infrastructure. Currently we are running off of version 1.5.5, and I am very wary of updating the server, as I don’t know much about how and what was setup on this server for deployment. There are some things in documentation that make me suspect an update would resolve my issue, but I want to confirm before I do something drastic enough to break things.

What I’m Trying to Accomplish
He left enough documentation for me to understand how FOG basically works, but I’d like to make a few changes to the system for driver injection. I browsed through the forums to see if this was possible and how to do it, and I came across George’s article (this man has done great work). Here’s the article: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

So here’s where the problem comes in. I set up the server just as George suggested by following that tutorial, but every time I run it, I get a syntax error. Here is a picture of the error message I receive:

I apologize for the poor quality. It’s the best I could do.

There’s a couple of things that I notice here. (1) This particular script is calling for a file that just doesn’t exist on the server, and (2) the syntax error happens around the case $osid in section. I don’t know where it pulls this information from on the server to verify settings for $osid. Here are my files:

fog.custominstall

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
case $osid in
    5|6|7|9)
        clear
        [[ ! -d /ntfs ]] && mkdir -p /ntfs
        getHardDisk
        if [[ -z $hd ]]; then
            handleError "Could not find hdd to use"
        fi
        getPartitions $hd
        for part in $parts; do
            umount /ntfs >/dev/null 2>&1
            fsTypeSetting "$part"
            case $fstype in
                ntfs)
                    dots "Testing partition $part"
                    ntfs-3g -o force,rw $part /ntfs
                    ntfsstatus="$?"
                    if [[ ! $ntfsstatus -eq 0 ]]; then
                        echo "Skipped"
                        continue
                    fi
                    if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                        echo "Not found"
                        umount /ntfs >/dev/null 2>&1
                        continue
                    fi
                    echo "Success"
                    break
                    ;;
                *)
                    echo " * Partition $part not NTFS filesystem"
                    ;;
            esac
        done
        if [[ ! $ntfsstatus -eq 0 ]]; then
            echo "Failed"
            debugPause
            handleError "Failed to mount $part ($0)\n    Args: $*"
        fi
        echo "Done"
        debugPause
        . ${postdownpath}fog.copydrivers
        # . ${postdownpath}fog.updateunattend
        umount /ntfs
        ;;
    *)
        echo "Non-Windows Deployment"
        debugPause
        return
        ;;
esac

fog.copydrivers

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
dots "Identifying hardware"
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # Technically, we can remove the Dell entry above as it is the same as this [default]
        machine=$(dmidecode -s system-product-name)
        ;;
esac

# if the machine isn't identified then no need to continue with this script, just return to caller
if [[ -z $machine ]]; then
    echo "Unable to identify the hardware for manufacturer ${manu}";
    debugPause;
    return;
fi
echo "${machine} Identified";

# Removes Spaces in machine name, works better with path definitions
machine="${machine%"${machine##*[![:space:]]}"}";
# Jeffrey Boulais posted that the above code did not work for his install. He
#  supplied this code as an alternative. If you run in to a problem using my code
#  comment out my code and see if his code works better for your installation. The
#  only right way is the one that works. Thank you Jeff for your input.
# machine="$(echo -e “${machine}” | tr -d ‘[:space:]’)"

dots "Verifying we've found the OS disk"
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo "! OS root Not found !";
    debugPause
    return;
fi
echo "Found";

dots "Verifying target Arch"
system64="/ntfs/Windows/SysWOW64/regedit.exe"
[[ ! -f $system64 ]] && arch="x86" || arch="x64"
echo "${arch} found";

debugPause

# set osn path names based on the osid set in the FOG WebGui
case $osid in
    5) osn="win7" ;;
    6) osn="win8" ;;
    7) osn="win8.1" ;;
    9) osn="win10" ;;
esac

dots "Preparing Drivers"
clientdriverpath="/ntfs/Drivers"
remotedriverpath="/images/drivers/$machine/$osn/$arch"

debugPause

if [[ ! -d "${remotedriverpath}" ]]; then
    echo "failed";
    echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
    debugPause;
    return;
fi
echo "Ready";

debugPause

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

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

debugPause

# the following code is only valid for Windows 7 operating systems since Windows 8 and beyond
# relies on the unattend.xml section to locate OEM drivers. If you are no longer deploying Win7
# you may exclude this section.

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

If anyone can offer suggestions, or help, I would be most appreciative. I think that’s all the information that I have, but if you need clarification on anything, please ask. Thanks in advance for any help offered!

[Sebastian Roth]

@Mr-Taco Welcome to the forum! From what you write it seems like you are doing fine taking over this FOG server from someone else. While we do suggest to update to the latest version quite often it’s not something I tell people blindly. In the issue described I don’t think updating is of any help as we have not changed much in regards of this part since 1.5.5 as far as I remember.

Get comfortable with the system first before jumping into updating it. Read about what to consider and what backups to take before.

There’s a couple of things that I notice here. (1) This particular script is calling for a file that just doesn’t exist on the server

The .../funcs.sh script is not directly accessable on the server. It’s part of a Linux initrd file we build to do all the cloning work. I am sure the file exists within the initrd and works properly because you would run into more serious issues if it wasn’t there.

The first thing coming to my mind: possibly you created this file with Windows line endings and this is causing the trouble here. While I would expect other errors in this case I still want to mention this early on just to make sure.

[Mr. Taco]

@Sebastian-Roth Thank you so much for that information. I tried that, and it seemed to do the trick! Unfortunately, the setupcomplete.cmd that george suggested I use to install the drivers did not work. Do I need to add anything to FOG/sysprep in addition to this file? Again, thank you so much for the solution.

[george1421]

@Mr-Taco Are you deploying a VLK media or OEM media? OEM media, I believe doesn’t run the setupcomplete.cmd batch file.

If you are using vlk media, then we need to look at the setup complete batch file and if the drivers are where you say they are. We’ve had great success using the pnputil.exe program to force in the drives.

[Mr. Taco]

Hey @george1421! Thanks for getting back to me. I am indeed using OEM Media. I don’t believe we have access to VLK media. Honestly, I think I have a workaround to try and get those drivers installed via Sysprep. If y’all have any other information about another way to get these drivers installed, that would be great. Otherwise, thanks for all the help that has been offered today. You guys are great!

[george1421]

@Mr-Taco OK I need to pull out my EULA soapbox for a minute. The microsoft EULA doesn’t allow for customizing an image and then deploying that image with any imaging tool (including Microsoft’s). The only way you are allowed to deploy an OEM image is from the OEM media (untouched). (EULA soap box is now stored in its home)

I have seen people setup in the unattend.xml file a X times auto admin log. This is typically done to configure resources that need a GUI desktop to complete. There is also a section in the unattend.xml where you can run any number of commands on the first login. One of those commands could be any random executable like pnputil.exe. Here is an example of an unattend.xml file that has such a feature as autoadmin login and to run .exe programs on the first login: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7 You will see in that unattend.xml script I run shutdown.exe (a random executable) to reboot the workstation at the end of the first run section.

[Mr. Taco]

Hey @george1421! Thanks again for getting back to me with more information. I was not aware that changing the software for deployment purposes was in violation of the EULA. We certainly do not want to be liable for violating such an agreement. I would like to share this with my superiors to become compliant with the EULA again. I have been looking through the EULA and various forums to see where we aren’t in agreement, and what we are supposed to use instead. So my two questions are:

• Can you point us to which part of the Agreement we are in violation of?
• How can we become compliant again? I’m assuming we are supposed to use VLSC to get VLK media and use that to deploy to the machine?

I understand that this is well outside the scope of FOG, so if you cannot provide any more information I understand. You clearly know much more than I do, so I’m just trying to get as much information as I can. Again, I am truly grateful for all the support I have received thus far. You all have been amazing. Thank you.

[george1421]

@Mr-Taco Here is an article from Chris at Microsoft that covers reimaging rights. https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

I can tell you that if you have 100 Window 10 OEM licenses, you only need to purchase (1) Windows 10 Pro VLK key to deploy to all 100 of those Windows 10 Pro OEM machines. That rule only works for the same version. You can not purchase 1 Windows 10 Enterprise VLK key to do a version upgrade to those 100 Win10 Pro OEM machines. For a version upgrade you need a 1 for 1 volume key. So 100 OEM would require 100 Enterprise keys.

But back on the 1 Win10 Pro VLK key, you can purchase that key but you need to get a count of 5 so people will often purchase Win 10 Pro VLK key and 4 windows (4) server CALs (or something else cheap that you can’t get enough of anyway) to get to your count of 5.