Image seems to be overwritten after depoying

[itcchs.bob]

Thanks, @george1421
I’ll look into it on Monday when I’m back in school.
I’m not so familiar with the Fog Project and the setup thereof.
My former colleague had set it all up. Anyhow, I’ll let you know in the following days.
Bob

[itcchs.bob]

@george1421
Not sure if the following picture would tell you something.
This message I got after trying to deploy an image to this workstation.

[itcchs.bob]

@george1421
I uploaded some screenshots with the info you requested.
I’m not sure if it would affect the connection between Workstation and Fog server, but ever since we got our new firewall (Fortigate 100F) I have had to enter the Fog server’s IP address. Before this, I was able to PXE boot a workstation and deploy the new image without entering the Fog IP address. The Fog Menu would show up automatically.

[george1421]

@itcchs-bob said in Image seems to be overwritten after depoying:

Before this, I was able to PXE boot a workstation and deploy the new image without entering the Fog IP address.

Depending on where you see this, we see this sometimes when you have 2 dhcp servers but only one is configured for pxe booting (dhcp options 66 and 67). The iPXE boot loader will query for dhcp options 66 once it starts to find the fog server’s ip address. If an invalid response is returned it will ask for the fog server’s ip address.

Back to your issue about unable to restore the GPT partition table, does this target computer have just an nvme drive, sata drive or both in the system?

[itcchs.bob]

@george1421
There are only SATA drives in these workstations.
Yes, I have two Win2016 servers that are replicating
I now changed both DHCP server settings to
066 : 192.168.0.55 (static IP for Fog server laptop)
067: undionly.kpxe

I,m now able to boot into the Fog Menu and all seems fine, but when I try to deploy it’s starting off correctly, but shortly after I get the Restore GPT partion error message.
I feel I’m getting closer, but confused why it doesn’t want to deploy the image. Last year I updated all workstations and it worked fine.
The picture below tells me, that the workstation is compatible.

[george1421]

@itcchs-bob Are these computers configured in uefi mode?

Do these computers have intel rst adapters and these adapters are set to raid-on mode and not ahci mode?

[itcchs.bob]

@george1421 These PCs are set in AUTO mode in the BIOS.
Also, they are set in ahci mode.
I haven’t changed any of these BIOS settings since last time.

(see pictures below)

[george1421]

@itcchs-bob Ok when you are back on your campus I want you to do this:

1. Schedule another deploy task to one of these computers, but before you hit the schedule task button tick the debug check box then schedule the task.
2. PXE boot the target computer, after a few screens of text that you need to clear with the enter key you will be dropped to the fos linux command prompt on the target computer.
3. At the FOS Linux command prompt key in the following
   lsblk This will list all of the block (disk) devices installed in the computer. What will be of interest is that you can see /dev/sda and all of the existing partitions. Post the results here.
4. Now lets single step through the deployment to see if there is an error message we missed during the automated install. Start the deployment with the fog command. At each breakpoint in the deployment it will pause and wait for a key press. Lets see if we are missing something. You can break out of the deployment script at any time by pressing ctrl-c. And then restart the deployment again by keying in fog.

I’m suspecting this auto mode is confusing the fog deployment program. This auto mode basically will switch on bios mode if it sees a bios boot loader and uefi if it sees a uefi boot loader (disk or via pxe). You are sending undionly.kpxe to the target computer (both uefi and bios modes). The computers are seeing this and switching to bios mode, the issue is windows image is probably in uefi mode. A bios mode engine should be able to deploy a uefi image as long as the first windows boot is in the format of the image on the disk.

[itcchs.bob]

@george1421 Thanks, I’ll be back after the weekend.
Hopefully, I’ll be able to follow along and presents you with the results you’re looking for.
I’m not that technically inclined.

[itcchs.bob]

@george1421 I tried following the steps like you outlined
At the FOS Linux command I typed the lsblk and get the following return:
Name maj: Min RM size RO type Mountpoint
sda 8:0 0 223.6G 0 disk (see picture)

After I Enter the FOG command I get the following screen (see picture)

At this point, I’m not sure what to do.

[george1421]

@itcchs-bob I have to ask how did you get to the FOS Linux command prompt? Did you just pick debug from the advanced menu or did you go to schedule a capture task and then tick the debug check box before scheduling the capture task. Or did you happen to boot into FOS Linux using a usb flash drive. The “Unknown task type :: Null” is a bit suspicious.

Also according to FOS Linux that hard drive / computer doesn’t have any partitions on that disk, so its pretty much blank. Is that by design?

[itcchs.bob]

@george1421
I created a capture task and then booted the workstation.
(hope it was the correct way!?) (see picture)

The drive from that workstation got wiped by my first attempt to deploy an image. After It booted It started the attempt to deploy an image, but after the first steps it starts to delete the current partition table. From there it’s giving me the error I’ve shown you in a picture before.

[itcchs.bob]

@george1421 Finally I figured out what the problem is.
The image I captured was taken from a newer drive with 512GB space, while the drives where I tried to deploy too were only 240GB.
I found this out after trying to use Clonezilla and do a disk-to-disk clone.

Once I recaptured an Image from a 240GB disk, deploying it to a workstation worked fine.

The Windows 10 image with some basic software I captured initially was only 68.7 GB and should easily fit on a 240GB drive.

My question would be, do I have to change any different settings in order to capture from a 512GB disk to Deploy to a 240GB?

Thanks for all your help so far!
Bob

[george1421]

@itcchs-bob There are a couple of things going on here then. (good you found the root of the issue)

Starting with Win10 20H2 microsoft changed the disk structure where they placed the recovery partition at the end of the disk and marked it as non-movable. In the FOG dev branch FOG version 1.5.9.110 and later has a fix for this locked partition.

There are some disk layouts that also are problematic to shrink. Think about it a 512GB hard drive could potentially have a partition starting location beyond the last block on a 256GB disk. So its always problematic haveing a source disk larger than a destination disk. Can FOG deploy larger to smaller disk? Yes as long as all of the conditions are right.

If I’m doing a one to many image deployment, I always create my golden image on a VM with the disk set to the smallest disk I will every deploy to. So for Win10 I create a 70GB disk, and Windows Server a 120GB disk. This way when deployed the disk always grows to the final size.