Posts made by sudburr

@sebastian-roth Thank you. That fixed it.

Just reinstalled FOG 1.5.9 from a fresh pull, on CentOS 7.x

Tell the server to update the Kernel to 5.10.50 x64 and get this error

Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 465, Message: ftp_login(): OOPS: cannot change directory:/home/fogproject, Host: 172.22.52.14, Username: fogproject

I’ll get back to ya on this. I’ve finished my image refresh for the new year and am digging deep into something else now.

I built them in Hyper-V on Windows 10v2004 .

It was a coin toss on whether I witnessed the problem on over three dozen VMs, but I was able to overcome it on every one.

And it appears to be totally random whether it throws that error, cold boot, warm boot, reset, whatever. If blkid: error comes up I just keep resetting the vm until it goes away .

Sigh … cold vs warm boot is not it.

New VMs today, and just to spite me, it failed on the warm reboot test. It worked after resetting to the checkpoint prior to the initial capture attempt. So it worked on a cold boot.

This is definitely the indicator that the capture will be bad.

blkid: error: /dev/sda4: No such file or directory

If I see this, I shut the VM down, revert the checkpoint and try again.

Looks familiar.

See my thread.

Okay, you’re going to love this. I only have one success to go on so far, but here’s my current working theory.

Failure scenario

1. Cold boot VM to Quick Inventory
2. Shutdown VM after the natural reboot after QI
3. Create Task
4. Cold boot VM into Task
5. Partition 4 is not recognized as fixed.

Success scenario

1. Cold boot VM to Quick Inventory
2. Pause VM after the natural reboot after QI
3. Create Task
4. Resume VM into Task
5. Partition 4 is recognized properly.

Testing further, but right now, Cold booting into the task appears to be the guilty party.

Not reliably.

VM I’m working on now refuses to capture with partition 4 as fixed. It’s throwing the error during capture:

blkid: error: /dev/sda4: No such file or directory

So far today, working with all new VMs again, things are looking good.

I made one change to the mastering process, to use Disk Management (diskmgmt.msc) within Windows to shrink the OS partition (to just 5GB free space) before sysprep and shutdown. It’s capturing partitions properly with fixed 1:2:4 so far.

Captured images are deploying properly to HDDs both larger and smaller than the original 64GB.

It’s consistently inconsistent.

Today I created some more VMs. All with 64 GB drives. Essentially …

Capture VM1

cat d1.fixed_size_partitions
1:2

Capture VM1 a second time

cat d1.fixed_size_partitions
1:2:4

Capture VM2

cat d1.fixed_size_partitions
1:2:4

None will deploy to a drive smaller than the original 64 GB, though the data is only 12 GB uncompressed. It’s just a Windows install.

Looking at the 50 GB drive after a failed attempt to push the 64 GB image onto it. Diskpart reports a single 63 GB partition. wha?
Gnome Partition Editor shows the drive as 50 GB unallocated.

Dumping one of the 1:2:4 images onto a 2TB drive now; and it’s good.

So Partition 3, isn’t really resizing smaller when captured, and Partition 4 is sometimes not identified as fixed size.

No.

cat d1.fixed_size_partitions
1:2

@Sebastian-Roth Okay, I wasn’t dreaming it.

Here’s the original on a 1024 GB drive after I’ve shrunk the partitions with GPARTED

And here’s the result immediately after going onto a 110 GB drive.

My original percentage math just happened to be a coincidence. But partition 4 is definitely not reproducing as intended.

Okay, that is peculiar. My test yesterday to a physical device resulted in the expanded partition 4. My test today to a VM did not. Partition 4 remained right-sized.

I don’t know when I’ll be able to do another physical test, but I will check again, somewhen.

@Sebastian-Roth The math bears it out. will check again

Shrinking partition 3, then moving partition 4, I can capture and deploy.

Going from a 110GB drive, to a 1024GB drive, partition 4 grows by roughly a factor of 10. The size of partition 4 is obviously based on % of disk space used on original instead of maintaining the fixed size that is intended.

Yes, a recovery partition is desired.

This is a workaround I can live with for now, until a fix is developed, but it puts a kink in the deployment process as we must now ensure a system has a drive that is no smaller than the original system the image was built on.

Makes me think that FOG is resizing the wrong partitions when capturing, though it says it has detected the correct fixed size partitions.

Original disk is 1 TB. Destination disk is 0.5 TB .

d1.partitions

label: gpt
label-id: FB16BC47-E9A4-4A26-9E00-495F842C2401
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 2147483614
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=DB56A1C9-1019-46FE-9C8A-8D561A3E1DE4, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B1AC3238-84AA-410A-97AC-7C2683A132C5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=  2146203765, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D6FFACFD-59C5-4AAA-995C-539E27EAD00A, name="Basic data partition"
/dev/sda4 : start=  2146445312, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A7345D7C-3D3F-44E9-B556-6F89394B0C76, attrs="RequiredPartition GUID:63"

=-=-=-=-=-

d1.minimum.partitions

label: gpt
label-id: FB16BC47-E9A4-4A26-9E00-495F842C2401
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 2147483614
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=DB56A1C9-1019-46FE-9C8A-8D561A3E1DE4, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B1AC3238-84AA-410A-97AC-7C2683A132C5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=    20614004, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D6FFACFD-59C5-4AAA-995C-539E27EAD00A, name="Basic data partition"
/dev/sda4 : start=  2146445312, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A7345D7C-3D3F-44E9-B556-6F89394B0C76, name="attrs=\x22RequiredPartition GUID:63"

=-=-=-=-=-

d1.fixed_size_partitions

1:2:4

Uh oh.

The partition structure for a bare metal UEFI install of Windows 10 has changed dramatically with v2004.

FOG 1.5.9-RC2 (installed clean today at 3pm ET) no likey.

Microsoft Windows 10_v1903 64bit (10.0.18362.30)
Partition ### Type Size Offset
Partition 1 Recovery 529 MB 1024 KB
Partition 2 System 99 MB 530 MB
Partition 3 Reserved 16 MB 629 MB
Partition 4 Primary 1023 GB 645 MB

Microsoft Windows 10_v2004 64bit (10.0.19041.264) aka 20h1
Partition ### Type Size Offset
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 1023 GB 117 MB
Partition 4 Recovery 505 MB 1023 GB

It captures, something, but deployment well, that fails because v2004’s partition structure is not sized properly.

Depends on the context what will work for you best, but in our case, not much in the way of horsepower is needed.

Gb Nic on Gb switches, at the root of each site
CPU is Intel Pentium E2220
2GB RAM
500-2 TB HDD
in 12-year-old desktops (not server boxes)
running CentOS 7.x x64

15 sites with this and 150-300 computers each. The worst-case imaging scenario is summer refresh on labs at 25 systems at a time.

More than enough.

For one-offs and 70+ other sites, we use bootable USB keys with WIM versions of the same images .

For a sysprep solution look here.

<extendospartition>
	<extend>true</extend>
</extendospartition>