1.3.2 -- Unable to Deploy existing or Capture new Windows 10 images

[sudburr]

Server

• FOG Version: 1.3.2 (svn 6059 – which displays as 6060 after install)
• OS: CentOS 7.2.1511

Client

• Service Version: n/a
• OS: Windows 10

Description

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.

[Tom Elliott]

Please try the working-1.3.3 branch.

I removed the sgdisk -v elements and added back the piped yes as it was originally.

This was the only change from 1.3.1 to 1.3.2 for the inits so this should at least bring back what you saw originally.

[sudburr]

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?

[Tom Elliott]

git clone https://github.com/fogproject/fogproject.git
git checkout working-1.3.3
cd bin
./installfog.sh -y

[sudburr]

I have switched to working-1.3.3 branch, which installed version 176523 / svn 6060 .

The problem persists.

[Tom Elliott]

It can’t be persisting, the code isn’t the same. Can you remove the binaries1.3.2.zip file from the working directory?

I forgot there’s a check for the file. If the file exists, it will use it instead of trying to download the inits.

[Tom Elliott]

To update you would run:

git pull in the working directory too btw.

[sudburr]

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.

[sudburr]

Thanks to Tom’s speedy remote work the problem was found and fixed with the release of 1.3.3.