I’m now in this situation as well. I need to stop rEFInd from stopping.
… To answer my own question, I have added the following to my fog configuration:
echo "Change UEFI rEFInd default action to remove user prompt"
sed -i.bak "s|scanfor internal,hdbios,external,biosexternal''|scanfor internal|g" /var/www/html/fog/service/ipxe/refind.conf
@Tom-Elliott So what happens if you re-use that external NIC on another laptop when it comes to FOG naming it?
Thanks to Tom’s speedy remote work the problem was found and fixed with the release of 1.3.3.
@jdd49 I ran into this same problem beginning with Windows 8 not recursively pulling from folders I added to “c:\windows\inf”.
My later tests using “offlineServicing” were only partially successful. Many modern devices have devices hanging off devices, which the “offlineServicing” doesn’t seem to want to wait around for to detect and install once the parent device is fully enumerated. If there was a way to force “offlineServicing” to trip more than once that’d be great but …
Now I’m working on my first large scale Windows 10 image deployment; we’ll see what happens.
Nimble as always. Thanks for the quick work Tom.
What I did:
echo "Create Directory for GIT Repository"
mkdir /opt/trunkgit
echo "Download the latest build from GIT"
cd /opt/trunkgit
git clone https://github.com/FOGProject/fogproject.git
echo "Change Respository to working-1.3.3 and repull"
cd /opt/trunkgit/fogproject
git checkout working-1.3.3
git pull
The final command ‘git pull’ generates “Already up-to-date”. There is no “binaries1.3.2.zip” file anywhere in /opt/trunkgit/fogproject.
I have switched to working-1.3.3 branch, which installed version 176523 / svn 6060 .
The problem persists.
Just finished building the 6059 server from scratch and the problem persists for both deploy and capture.
Where do I find the working 1.3.3 branch?
At first I thought my Windows 10 OEM images with Recovery partition managed to corrupt themselves.
1.3.2 (svn6058) would fail after deploying the first partition with
Cannot determine partition type (getpartitionTableType)
1.3.1 (svn6053) would successfully deploy all partitions except the last one with a paraphrased error
source file is smaller
I rolled back through other revisions back to 6017 with similar results, so I figured my images corrupted somehow. No biggie, I’ll recapture.
Except I can’t. Attempts to capture I’m also getting
Cannot determine partition type (getpartitionTableType)
Three different images, all worked fine in December, now won’t deploy to anything. This is my development server, so I’m going to blow it away and try a clean install next, but that I can’t even capture now is odd as heck.
BTW, checked out svn6059 displays as 6060 in the cloud.
So upon generating this error indication, should we do anything?
Even logged into the machine using an account that is a member of the Local\Administrators group isn’t enough to uninstall the legacy client.
Deployment of a program I don’t have a problem with… just this removal.
I know it’s discussed here in the forums, but I found the Wiki (FOG Client) is missing this information.
I used the following for a silent, non-interactive removal:
msiexec.exe /x {91C5D423-B6AB-4EAB-8F17-2BB3AE162CA1} /quiet
Buuuuut, there is more fun to this story.
The “FOG Project Service 3.0.29” was installed to Windows while the image was built in Audit mode. I could not uninstall using the above command until I invoked it from a CMD prompt run as Administrator. Running it as a scheduled task using account “NT Authority\SYSTEM” would not remove it.
Hopefully a .vbs with Self-Elevation will work because I have 8000+ systems to upgrade.
Looking at the FOG Wiki for more answers, but it has only three pages that use the word ‘Postdownloadscripts’ and only one of those, ‘Auto driver install’, is actually about using it.
Unfortunately that page, ‘Auto driver install’, says it requires two files at a login-barred external site to work.
Is there any control on which Postdownloadscripts the FOS init engine runs post-imaging or does it simply and only run the script ‘fog.postdownload’ universally after any imaging on any host?
Is the Postdownloadscripts (fog.postdownload) run by a ‘Deploy Image’ action that is invoked locally at the host or is it just referenced when imaging through the FOG Web GUI?
When exactly do Postdownloadscripts run?
What is required on a Windows host / FOG server for Postdownloadscripts to work?
Does the host computer require the FOG client running for Snapins to work?
The server itself had no hosts; it’s my development server so I regularly blast it; and it was indeed waiting in Pending Hosts.
Thank you for clarifying what to expect .
Installed FOG client for first time on a system via scheduled task:
msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="devfog"
Reboot, then Fog.log says:
------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
20/12/2016 6:00 PM Client-Info Version: 0.11.7
20/12/2016 6:00 PM Client-Info OS: Windows
20/12/2016 6:00 PM Middleware::Authentication Waiting for authentication timeout to pass
20/12/2016 6:00 PM Middleware::Communication Download: http://devfog/fog/management/other/ssl/srvpublic.crt
20/12/2016 6:00 PM Data::RSA FOG Server CA cert found
20/12/2016 6:00 PM Middleware::Authentication Cert OK
20/12/2016 6:00 PM Middleware::Authentication ERROR: Could not get security token
20/12/2016 6:00 PM Middleware::Authentication ERROR: Could not find file 'C:\Program Files\FOG\token.dat'.
20/12/2016 6:00 PM Middleware::Communication POST URL: http://devfog/fog/management/index.php?sub=requestClientInfo&authorize&newService
20/12/2016 6:00 PM Middleware::Response Invalid host
20/12/2016 6:00 PM Middleware::Communication URL: http://devfog/fog/service/register.php?hostname=rjs201612201615&mac=6C:F0:49:25:FF:3B||00:00:00:00:00:00:00:E0&newService&json
There is no token.dat … or spoon.
@kyle.heath In Windows 7, some drivers for newer devices must be installed after drivers for older devices are installed with a reboot in between and vice versa.
And as @Quazz said, you can quite simply dump your entire library of drivers into ‘c:\windows\inf’, but you will still be limited by Windows 7’s ability, or inability to prioritize driver installation order.