Does FOG record a deployment log?

[sat]

We are currently investigating the use of FOG and our present task is test the capture and redeployment of a CENTOS Image. Having successfully captured the image, a new disk of the same size was put into the test machine and a deployment initiated. After the deployment was complete a check of the system revealed the root partition was not resized correctly.

I have been unable to locate a log on either the newly deployed system or the FOG server which shows the steps completed during the deployment process.

Does FOG record the deployment process and if so where?

Thanks in advance
Paul

[Tom Elliott]

It records events in the database, but that’s about it. Trying to maintain logs of client taskings would be extremely difficult and cumbersome to try to guess what is what.

That said, the “root” partition, in your case, is most likely the “first” partition of the disk? Is this correct? If there’s multiple partitions on the disk, by default, the imaging system will not attempt to resize the partition. This is because, more often than not, the first partition is also the “boot” partition.

[sat]

Hi Tom

The Original partition layout of the disk is:
Boot partition
Root partition
Swap
Data

The new partition layout is:
Boot partition
Root partition
Free Space
Swap
Data

So it does appear to have shrunk the root partition at some point. To eliminate the possibility of the problem having been caused during our abortive first attempts, I am arranging for the original disk to be rebuilt from a clone and rerun the test (hopefully watching the steps). Unfortunately, I am doing all this remotely so cannot see what is going on myself.

I will report back any results.
Regards
PaulG

[Tom Elliott]

@sat said in Does FOG record a deployment log?:

Boot partition
Root partition
Swap
Data
The new partition layout is:
Boot partition
Root partition
Free Space
Swap
Data

I see no real information. Is there any actual data from the d1.original and d1.minimum.partitions files you can give us?

[Junkhacker]

also, what version of fog are you testing?
the dev build of fog would handle linux systems better than the current official release version (1.2.0)

[sat]

Hi Tom

The point of the information in my last post was simply to illustrate the change in partition layout between original and restored system, nothing more.
(FOG Version 7254)

I have conducted another test and had someone watch the process. The original disk starts out with the following partitions:
/boot /dev/sda1 548Mb
/ /dev/sda2 54Gb
(swap) /dev/sda3 25Gb
/dev/sda4 420Gb (Extended Partition)
/Vmachines /dev/sda5 420Gb (within the extended partition)

(We use ext4 filesystems)

During the capture process we see messages on the screen which indicate /dev/sda1 shrink is skipped as fixed size and then it proceeds to shrink /dev/sda2. After this it does display a message saying it is expanding /dev/sda2 and then appears to move on to until it fails an fsck check on /dev/sda5 where upon the system reboots.

Checking the partition structure again after the system reboots we see:
/boot /dev/sda1 548Mb
/ /dev/sda2 16Gb
(free space) 38Gb
(swap) /dev/sda3 25Gb
/dev/sda4 420Gb (Extended Partition)
/Vmachines /dev/sda5 420Gb (within the extended partition)

I cannot send you the files you requested for this test since the capture did not complete. However, looking at the entries in d1.partitions for the previous test (below), it does show a 38Gb gap between sda2 and sda3.
::::::::::::::
d1.partitions
::::::::::::::
label: dos
label-id: 0x00096dbc
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 1024000, type=83, bootable
/dev/sda2 : start= 1026048, size= 27308422, type=83
/dev/sda3 : start= 107522048, size= 49152000, type=82
/dev/sda4 : start= 156674048, size= 820099120, type=5
/dev/sda5 : start= 156676096, size= 820097024, type=83

So, when the restore occurs, the disk is being built according to the saved partition layout FOG captured. The problem appears to be with the re-expansion of sda2.

We are presently trying to address the fsck issue and re-expand sda2 back to its original size before trying again.

Regards
PaulG

[Sebastian Roth]

@sat Thanks for the new information. I’ll try to reproduce the issue! Please give me a little time. Won’t be today but definitely in the next days!

[sat]

UPDATE on TEST 2
We have completed a successful redeployment of the newly captured image to a new drive in the original machine. All boots ok and so far nothing untoward has been discovered. Looking at the d1.partitions file shows continuous use of the space.

So, the original problem (prompting the question about deployment logs) whereby the source disk of the image capture was left with unused disk space, was likely caused by a failure of the capture process to resize the partition after shrinking. A subsequent capture of the same disk resulted in the “unexpected” partitioning scheme when the image was redeployed.

I will mark this problem as resolved.

Thanks for your time.
PaulG

[Sebastian Roth]

Thanks a lot for letting us know! Feel free to post again if you find this is still not properly working somehow.