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

  • Server
    • FOG Version: 1.3.2 (svn 6059 – which displays as 6060 after install)
    • OS: CentOS 7.2.1511
    • Service Version: n/a
    • OS: Windows 10

    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.

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

  • What I did:

    echo "Create Directory for GIT Repository"
    mkdir /opt/trunkgit
    echo "Download the latest build from GIT"
    cd /opt/trunkgit
    git clone
    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 “” file anywhere in /opt/trunkgit/fogproject.

  • Senior Developer

    To update you would run:

    git pull in the working directory too btw.

  • Senior Developer

    It can’t be persisting, the code isn’t the same. Can you remove the 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.

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

    The problem persists.

  • Senior Developer

    git clone
    git checkout working-1.3.3
    cd bin
    ./ -y

  • 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?

  • Senior Developer

    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.