Interesting. This wasn’t a one off. I duplicated the results on both RC10 and RC11.

And of course you can see how I built the server in my tutorial posts.

I’m trying it again now with RC14v3 (svn5974).

What version of FOG did you have installed prior to your attempt to install RC14 ?

I had the same problem going from RC10 to RC14.

To fix it I had to download then install RC10 again, then RC13, then RC14.

Negatory on multiple NICs.

Can you make this mechanic introduced with RC14 manageable in FOG settings?

I get enough blowback from clients about long boot times. Forcing another 10 seconds will not go over well.

Server

• FOG Version: RC10 >>> RC14
• OS: CentOS_7.2.1511

Client

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

Description

When upgrading an RC10 installation to RC14, when I reach:

   http://192.168.1.1/fog/management
 * Press [Enter] key when database is updated/installed.

… the resulting web page displays:

#!db
Running Version 1.3.0-RC-14
SVN Revision: 5968
Database Schema Installer / Updater

… No update buttons, no further text below, no nuthin’.

This does not happen if upgrading from RC10 >>> RC13 >>> RC14

The original HDD as reported by Gnome Partition Editor 0.26.1-5:

Partition | Name | Label | File System | Flags
/dev/sda1 | EFI system partition |  | fat32 | boot, hidden, esp
/dev/sda2 | Microsoft reserved partition |  | unknown | msftres
/dev/sda3 | Basic data partition | Windows |ntfs | msftdata
/dev/sda4 | Basic data partition | WinRE_DRV |ntfs | hidden, diag

Editing d1.fixed_size_partitions of the captured image to be:

:1:2:4

… then deploying the image to a smaller HDD results in this:

* Attempting to expand/fill partitions ... Done
* Seems like you are trying to restore to an empty disk.  Be aware this will most probably cause trouble.

Attempting to deploy image
Using Partclone

An error has been detected!

No image file(s) found that would match the partition(s) to be restored (performRestore>
Args Passed: /dev/sda /images/test all

Computer will reboot in 1 minute

Deploying the same image to a larger (500 GB) HDD results in:

Partition | Name | Label | File System | Flags
/dev/sda1 | EFI system partition |  | fat32 | boot, esp
/dev/sda2 | Microsoft reserved partition |  | unknown | msftres
/dev/sda3 | Basic data partition | Windows | ntfs | msftdata (still shrunk at 25.4 GB)
unallocated (211.82 GB)
/dev/sda4 | Basic data partition | WinRE_DRV | ntfs | hidden, diag (correctly sized to 1000 MB)
unallocated (227.29 GB)

GParted initially launches with this error:

Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current setting?

Selecting FIX or IGNORE doesn’t change the partitions.

So it more or less mirrored the original 256 GB HDD layout onto the 500 GB HDD leaving the extra space after sda4 empty, instead of dumping sda4 onto the end of the space, then expanding sda3 into the donut hole.

I just captured the original drive with RC13 and it again generates a d1.fixed_size_partitions with:

:1:2:1

How does FOG determine if a partition is resizable when it is capturing? Is it strictly a file system match or does it look at the partition’s flag or type?

The image was created September 28th with RC10.

Interestingly, the d1.fixed_size_partitions file contains:

1:2:1

A second :1 ?

Looking closer at the original drive, there are actually 4 partitions.

1 System 260 MB
2 Reserved 16 MB
3 Primary 240 GB
4 Recover 1000 MB

Hmm.

For now I will try a deployment with 1:2:1:4 and see what happens; while I furrow my brow at that mystery `Reserved’ partition.

Partition 2 resizes, but so does Partition 3. I don’t want Partition 3 to resize, only Partition 2.

Correct me if I’m wrong, but as I understand the Windows 10 Recovery Environment partition as the operating system receives major updates, it also updates the Recovery Partition.

When FOG deploys the image it resizes partition 3 unacceptably smaller. I want to maintain the original size of the WinRE partition.

Server

• FOG Version: RC10 or higher
• OS: CentOS_7.2.1511

Client

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

Description

An original Windows 10 installation with a WinRE partition is on a 256 GB HDD consisting of 3 partitions

1= 260 MiB (EFI System Partition)
2= 236 GiB NTFS (Boot, Page File, Crash Dump, Primary Partition)
3= 1000 MiB (Recovery Partition)

Without rebuilding the install is there a way to massage the captured image files to be able to deploy onto a different size HDD (eg: a smaller 128 GB) that maintains the sizes of partitions 1 and 3, but resizes partition 2 to fill the available remaining (larger or smaller) space?

The original was captured as Single Disk Resizable.

Thank you horse’s mouth!

So, yes and no.

It’s generated by the installer, and used by the installer during re/installation to possibly configure a FOG component. Which file where is touched by this?

I’m concerned by this because we’re planning out changing scopes that will include changing the subnet mask, and I need to know if I should be worried about /opt/fog/.fogsettings and whatever else is touched by the installer or FOG’s normal operations that use that information.

Server

• FOG Version: RC10 & RC11
• OS: CentOS 7.2.1511

Description

A first-time installation generates these extended … duplicate entries in /opt/fog/.fogsettings.

routeraddress=‘192.168.1.1
192.168.1.1’
plainrouter=‘192.168.1.1
192.168.1.1’

Unless, this is somewhy intended .

After being generated by the initial installer, does FOG, and just FOG, use this information from /opt/fog/.fogsettings for anything?

submask=‘0.0.0.0’

Concurrently, does FOG reference the subnet mask of the network it’s on at any time?

Did you create your image on the source computer while it was in UEFI or Legacy mode?

Did you setup the destination computer’s BIOS to boot to match the mode the OS was created in?

Thanks for the heads-up. I have changed my posted recipe.

Would you say it’s worth removing the old?

firewall-cmd --permanent --add-port=9000-9001/udp

The entire process is the initial post. It’s been edited and indicated.