The drivers that i had extracted with 7-zip was incomplete and with errors.
Removed the folder and extracted the .cab with pea zip and it started working as normal again.

Don’t know why that made it work, but it did.

I will update you next time I try it.

If you modify

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

To something like

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

And then try again, it should now also give us the exit code of rsync which should tell us what goes wrong (though not necessarily why)

#!/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:]]}"}";

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

It appears to be George’s script at a glance, but it could be an older version or modifications made to it that we don’t know about.

At any rate, for it to display that error message means that rsync encountered some kind of error. We don’t really know which one at this point, however.

Common problems: spaces in paths, permissions, firewalls (and network in general)

Again I haven’t seen a post install script (before now) stop the imaging process. This may be a new feature in fog 1.5.x series…
The other option is that the copy is setting an error level because maybe an incomplete copy happened and the master fog script is seeing that error level.

Either way I would start out by commenting out the call to your custom post install script and confirm that FOG is imaging correctly. Then we can dig into why your script is failing. I might also take a look at the target computer in the Drivers directory and compare if all of the drivers were copied over vs the master driver directory on the FOG server.

“Well your “debug mode” picture explains why the task is not done”
It’s the copy drivers that fails the entire task to not complete?

https://imgur.com/5WEjN1c
https://imgur.com/IDMD696

As @george1421 suggested, please watch the machine. Maybe grab a slo-mo video of the tail end of the partclone screen until the machine reboots?

Where we see this issue, is there is a error on the target computer at the step of updating the database. But normally on capture image, because someone has changed the password on the FOG service account in linux called fog. In your case it appears you are deploying an image. Make sure your post install scripts are not accidentally rebooting the target computer before the Update Database command is executed.

If things fly by too fast for you to see, you can always setup a debug deploy. Tick the debug checkbox before you submit the deploy task. Then pxe boot the target computer. On the target computer you will see several screens of text and then eventually get dropped to a linux command prompt on the target computer. At the linux command prompt key in fog. This will start a debug deploy, requiring you to press enter at each breakpoint. It will give you a chance to see what is going on with the deployment.