Problem with size of partitions

michelsantana · Mar 16, 2017, 8:01 AM

Server

FOG Version: 1.3.5RC16
OS: CentOS7

Client

Service Version:
OS:

Description

After upgrading to this version, there is a problem with the sizes of the partitions restored. For example, I captured with this version a disk with three partitions of aproximately 522 MB (System Reserved), 100 GB (C:) and 198 GB (D:) and when I deploy the captured image on the same computer the sizes of the partitions are 522MB, 295 GB(C:) and 2GB (D:)

Perhaps have something to do with using sectors instead of bytes since RC15?

This is the content of the file d1.minimum.partitions

label: dos
label-id: 0x5a45dfe4
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 65024, type=7, bootable
/dev/sda2 : start= 1072640, size= 37683712, type=7
/dev/sda3 : start= 190852200, size= 257024, type=7
Thank you

Tom Elliott · Mar 16, 2017, 2:01 PM

Has nothing to do with using sectors vs. bytes. It’s the same code.

What does your d1.minimum.partitions file look like? What does your d1.paritions file look like?

michelsantana · Mar 16, 2017, 2:03 PM

d1.partitions
label: dos
label-id: 0x5a45dfe4
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 1070592, type=7, bootable
/dev/sda2 : start= 1072640, size= 189747430, type=7
/dev/sda3 : start= 190852200, size= 434285145, type=7

d1.minimum.partitions

label: dos
label-id: 0x5a45dfe4
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 65024, type=7, bootable
/dev/sda2 : start= 1072640, size= 37683712, type=7
/dev/sda3 : start= 190852200, size= 257024, type=7

Tom Elliott · Mar 16, 2017, 2:07 PM

Can you create a debug task and add “ismajordebug=1” to the kernel arguments for the host?

Step through and get the output of the sgdisk information?

It will be slow, but please it will help tremendously.

michelsantana · Mar 16, 2017, 5:43 PM

@Tom-Elliott This is the output of the sgdisk command once booted with a debug deploy task with the kernel argument that you have resquested. Don’t know if is this what you are talking about.
Thank you

Tom Elliott · Mar 16, 2017, 9:14 PM

sfdisk is much more useful if you can get it.

You would start the “debug” task.

At the command prompt type fog

Step through it slowly.

It will show the output of the sfdisk as it gets applied.

michelsantana · Mar 16, 2017, 9:37 PM

@Tom-Elliott This is the output of the command you have requested. Now I only have access to a Virtual Machine, but I guess that the problem is the same. Here you have the captures in sequence:

Tom Elliott · Mar 16, 2017, 9:46 PM

@michelsantana So based on what I’m seeing, this may be a problem simply because it has no extended partitions.

I’m taking a look at the main scripts to try to narrow down another (but separate) issue so I can try to see if i can get the logic out of this too. Thanks for the information thus far.

michelsantana · Mar 16, 2017, 9:47 PM

@Tom-Elliott You are more than welcome. And yes, in our configuration all the partitions are primary, so we don’t have any extended partition.

Thank you very much

Tom Elliott · Mar 16, 2017, 9:51 PM

@michelsantana can you get the size of the disk you’re trying to apply this to?

blockdev --getsz /dev/sda I think should do it.

michelsantana · Mar 16, 2017, 10:06 PM

@Tom-Elliott In the previous example the machine (Virtual) had a 60GB hard disk. Just for testing purposes I increased the size of the harddisk to 180GB and this are the results. As you can see there is no error this time with extended partitions but the sizes of the partitions still doesn’t have the right proportions.

Tom Elliott · Mar 16, 2017, 10:08 PM

@michelsantana I realize that and am replicating your d1.minimum.partitions and d1.partitions file.

I know what’s causing it too btw.

michelsantana · Mar 16, 2017, 10:09 PM

@Tom-Elliott It seems like it’s taking the d1.minimum.partitions as source to determine the proportion between partitions instead of the d1.partitions. In our example the sda3 partition is the bigger one in size but it’s almost empty.

Tom Elliott · Mar 16, 2017, 10:12 PM

@michelsantana I know what’s causing it, just trying to figure out a way around it in a nice method.

Tom Elliott · Mar 16, 2017, 10:33 PM

Mind trying these:

Init’s are up at:

http://mastacontrola.com/init.xz
http://mastacontrola.com/init_32.xz

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

michelsantana · Mar 16, 2017, 10:45 PM

@Tom-Elliott I have downloaded those files and repeated the process. There is a minor error than you can see in the first capture, but it seems that the problem is solved. Tomorrow I will try a deployment with a physical machine and post the results.
Thank you very much for your help!